Ali-Reza Adl-Tabatabai, Fundador e CEO da Gitar – Série de Entrevistas

Ali-Reza Adl-Tabatabai, Fundador e CEO da Gitar, é um líder de engenharia veterano cuja carreira abrange algumas das empresas de tecnologia mais influentes do Vale do Silício, incluindo Uber, Google, Facebook, Intel, AMD e IBM. Antes de lançar a Gitar em 2023, ele atuou como Diretor Sênior de Engenharia da Uber, onde ajudou a liderar as iniciativas de plataforma de desenvolvedor da empresa, após funções de liderança anteriores no Google, supervisionando a Engenharia de Confiabilidade do Site para produtos como Comunicações, Fotos, Social, Nuvem e infraestrutura técnica.

No início de sua carreira, ele trabalhou em tecnologias de compilador, máquinas virtuais, sistemas de computação paralela e otimização de hardware nos laboratórios da Intel e na equipe do HipHop VM do Facebook, enquanto também ensinava design de compilador avançado na Universidade de Stanford. Seu histórico de décadas em linguagens de programação, confiabilidade de infraestrutura, ferramentas de desenvolvedor e arquitetura de sistemas de grande escala o posicionou como uma figura proeminente no cenário de engenharia de software impulsionada por IA em constante evolução.

Gitar está focada em um problema crescente que surge com o aumento do desenvolvimento de software assistido por IA: validar e garantir a segurança do enorme volume de código gerado por máquina que agora flui para os sistemas empresariais. A plataforma usa agentes de IA para automatizar a revisão de código, investigar falhas na pipeline de CI/CD, identificar bugs e vulnerabilidades, recomendar correções e integrar-se diretamente nos fluxos de trabalho de engenharia existentes por meio de ferramentas como GitHub, GitLab, Jenkins, Jira e Slack. Em vez de competir apenas na geração de código de IA, a empresa está se posicionando em torno do que descreve como “portas de qualidade de agentes”, ajudando as equipes de engenharia a manter a confiabilidade, a segurança e a supervisão operacional à medida que o desenvolvimento de software cada vez mais se desloca para fluxos de trabalho de codificação autônoma e assistida por IA.

Você liderou a engenharia na Uber, Google e Intel Labs, trabalhando em plataformas de desenvolvedor e infraestrutura de grande escala. Quais experiências específicas dessa jornada o levaram a fundar a Gitar, e por que se concentrar na validação de código em vez de geração de código?

Ao longo da Uber, Google, Facebook e Intel Labs, trabalhei em plataformas de desenvolvedor em escalas muito diferentes, e a mesma lição continuou aparecendo: a experiência do desenvolvedor é uma vantagem competitiva. Grandes ferramentas atraem e retêm os melhores engenheiros e permitem que as empresas se movam rapidamente. Os desenvolvedores querem ferramentas rápidas e sem ruído que os mantenham no fluxo e automatem o trabalho braçal. No entanto, as ferramentas de desenvolvedor estão profundamente fragmentadas, e a maioria das empresas queima enormes recursos de engenharia apenas para criar uma experiência coerente. Eu vi pessoalmente quanto alavancagem há em consertar isso.

A IA muda a equação tornando possível automatizar muito mais do fluxo de trabalho do desenvolvedor do que antes. A geração de código já está bem coberta, mas isso apenas moveu o gargalo para baixo, para a validação, refatoração e manutenção do código que agora produzimos em volume sem precedentes. É aí que a Gitar se concentra. À medida que a IA escreve mais código, o recurso escasso não é a geração; é a confiança, a correção e a manutenibilidade do que é enviado. A validação de código é a parte do fluxo de trabalho que determina se o código gerado por IA realmente chega à produção com segurança, e esse é o problema mais difícil e valioso a ser resolvido.

Com o aumento do código gerado por IA, muitas equipes agora estão lidando com o que alguns chamam de “sobrecarga de código”. Quão significativo é esse problema dentro das empresas hoje, e onde as equipes estão enfrentando mais dificuldades?

A mudança não está em escrever código. Essa parte já está se movendo mais rápido do que a maioria das equipes pode absorver. O que mudou é tudo o que vem depois. As ferramentas de IA estão gerando um fluxo constante de solicitações de pull, frequentemente mais rápido do que as equipes podem revisá-las, o que cria pressão em partes do sistema que nunca foram projetadas para esse nível de saída.

Cada alteração ainda precisa passar pela validação. Revisão de código. CI. Verificações de segurança. Aprovações. Nada disso some apenas porque o código é gerado mais rapidamente. O que costumava ser um fluxo administrável se transformou em uma fila de espera. As equipes não estão bloqueadas por ideias ou implementação; elas estão bloqueadas por confiança. Posso enviar isso? É seguro? Elebrou algo sutil?

É aí que a fricção está agora. Não na criação, mas em levar o código para a linha de chegada sem introduzir risco.

A indústria se concentrou principalmente em gerar código mais rápido. Por que você acredita que a validação foi negligenciada, e por que está se tornando mais crítica agora?

Porque o sistema a jusante da geração de código não evoluiu no mesmo ritmo. Quando a saída aumenta, tudo a jusante fica estressado. As solicitações de pull se tornam maiores e mais frequentes. As falhas de CI começam a se acumular. Os ciclos de revisão são comprimidos porque ninguém tem tempo para ir fundo em cada alteração.

A qualidade começa a escorregar, não porque os engenheiros não se importam, mas porque o volume força escolhas. As equipes de plataforma assumem mais da carga, lidando com problemas de pipeline, triagem de falhas e tentando manter as coisas em movimento. Os engenheiros seniores acabam agindo como coordenadores, montando logs, diagnosticando problemas e decidindo o que é seguro para mesclar.

As equipes enfrentam uma escolha que não funciona de verdade em nenhum dos casos. Empurrar o código rapidamente e lidar com regressões mais tarde, ou desacelerar e proteger a qualidade, mas aceitar que a velocidade cai. Essa tensão está aparecendo em todas as organizações de engenharia agora.

Gitar usa agentes de IA para lidar com revisões de código, testes e fluxos de trabalho de integração contínua (CI). Como esses agentes diferem fundamentalmente das ferramentas de análise estática tradicionais e pipelines baseados em regras?

A diferença não é cosmética. Um agente real precisa fazer mais do que responder a prompts. Ele precisa lidar com trabalho em várias etapas, planejar, usar ferramentas, manter o contexto e mover tarefas para a frente sem entrada constante.

A maioria dos sistemas não atende a esse padrão. Eles geram saídas, mas não gerenciam a execução. Quando essas ferramentas são colocadas em fluxos de trabalho reais, as lacunas se tornam aparentes rapidamente. Elas não reduzem a complexidade. Em muitos casos, elas adicionam outra camada que alguém precisa gerenciar.

É por isso que a conversa está mudando de “temos agentes” para “qual trabalho pode ser realmente tratado de forma confiável”.

Confiança é uma grande barreira para a automação no desenvolvimento de software. Como a Gitar garante que seu processo de validação seja confiável o suficiente para as equipes dependerem?

O padrão que funciona é simples. Divida o trabalho em etapas menores. Defina limites claros. Valide as saídas continuamente. Mantenha os humanos envolvidos onde as decisões envolvem risco.

Os agentes podem revisar o código e destacar problemas que são fáceis de perder em escala. Eles podem analisar falhas de CI, agrupar erros relacionados e apontar para uma causa raiz provável. Eles podem sugerir correções e, em alguns casos, aplicá-las de forma controlada.

Isso reduz a quantidade de triagem manual que os engenheiros precisam fazer. Não remove os engenheiros do loop, mas muda onde eles gastam tempo. A maioria dos sistemas opera com pontos de verificação, não com independência completa.

Sua plataforma permite que as equipes criem seus próprios agentes. Quão importante é a personalização para a adoção empresarial, e quais são alguns dos casos de uso mais interessantes que você está vendo?

A personalização é essencial para a adoção empresarial. Cada equipe de plataforma gasta recursos significativos personalizando o CI para as necessidades específicas da empresa, e isso tradicionalmente exigiu scripts personalizados, configuração, integração de ferramentas, processadores de log e todo o resto do duct tape que mantém a infraestrutura de desenvolvimento moderna unida.

A Gitar colapsa esse trabalho. As equipes de plataforma podem escrever verificações personalizadas usando prompts de linguagem natural, o que permite que elas validem coisas que são difíceis ou impossíveis com a análise de programa tradicional, por exemplo, sinalizando strings de interface do usuário que são ambíguas para tradução, ou validando atualizações para arquivos AGENTS.md. Elas também podem automatizar fluxos de trabalho personalizados em cima de solicitações de pull: vinculando PRs a problemas do Jira, abrindo tickets de follow-up para comentários de revisão não resolvidos, tentando novamente testes instáveis de forma automática ou anexando listas de tarefas personalizadas a resumos de PR.

Os casos de uso mais interessantes tendem a ser aqueles que não antecipamos. As equipes conhecem melhor seus repositórios de código e seus pontos de dor do que qualquer fornecedor, então, quando você dá a elas um primitivo que transforma “desejamos que o CI apenas verifique X” em um prompt de 10 linhas, elas imediatamente começam a automatizar coisas que nunca teríamos construído por padrão. É exatamente isso que queremos.

As equipes de engenharia modernas dependem de uma pilha complexa de ferramentas como GitHub, GitLab e Jira. Quão importante é para a Gitar se integrar a fluxos de trabalho existentes em vez de tentar substituí-los?

A adoção depende de atender aos desenvolvedores onde eles já estão. Os engenheiros não querem outra superfície para aprender, outra dashboard para verificar ou mais commutação de contexto entre ferramentas. Eles querem que seus fluxos de trabalho existentes sejam mais rápidos e mais silenciosos. Portanto, integrar profundamente com o GitHub, GitLab, Jira e o resto da pilha não é um gostaria para nós; é a estratégia inteira.

Mas nossa ambição vai além da integração. Não estamos tentando substituir essas ferramentas, e não estamos apenas tentando conectar a elas. Estamos automatizando os fluxos de trabalho que executam através delas. A revisão de PR, o vinculação de tickets, as tarefas de follow-up, as retrys de testes instáveis, tudo isso deve acontecer de forma autônoma, em segundo plano. E estamos empurrando mais: um agente edita o PR diretamente para abordar feedback de revisão de código e corrigir falhas de CI, e eventualmente lida com aprovação e mesclagem para alterações que atendem às políticas da equipe. O papel do desenvolvedor muda de conduzir cada etapa para definir intenção, revisar resultados e lidar com exceções.

O estado final não é uma nova ferramenta que os desenvolvedores entram. É as ferramentas existentes fazendo mais por conta própria, para que os desenvolvedores possam se manter focados no trabalho que realmente requer seu julgamento.

Você sugeriu que as revisões de código humanas poderiam eventualmente se tornar a exceção em vez da regra. O que precisa acontecer para que as organizações se sintam confortáveis com essa mudança?

A confiança é construída em estágios, não de uma vez. As organizações precisam ver, com seu próprio código, que a IA pode encontrar os bugs e vulnerabilidades que realmente importam e aplicar regras personalizadas com precisão e alta cobertura. A partir daí, o caminho para a mesclagem autônoma é uma progressão natural por meio de quatro níveis de confiança crescente.

O primeiro nível é detecção. As equipes constroem confiança de que os agentes encontram problemas reais com uma taxa de falsos positivos baixa. Uma vez que essa confiança seja estabelecida, elas permitem que a IA bloqueie automaticamente PRs quando encontra problemas críticos.

O segundo nível é remediação. A IA não apenas sinaliza problemas, mas os corrige, desbloqueando o PR e tornando o CI verde sem intervenção humana. A confiança aqui significa que o agente pode resolver problemas e falhas de CI com precisão, sem quebrar as coisas.

O terceiro nível é aprovação. Uma vez que as equipes veem os agentes confiavelmente tornando os PRs verdes, elas permitem que a IA aprove PRs sob regras que elas definem. Dar às organizações controle explícito sobre as condições para aprovação automática é o que torna essa etapa sentir-se segura em vez de temerária.

O quarto nível é mesclagem. A IA aterra a alteração, novamente sob condições com as quais a equipe está confortável. Essa etapa tem sua própria barra: o agente precisa resolver conflitos de mesclagem com precisão, sem introduzir regressões ou quebrar o main. Isso importa mais do que as pessoas percebem, porque a frequência de conflito aumenta com o throughput de commit, e o throughput está explodindo à medida que a IA gera mais código. Os monorepos grandes já sentem isso; todos os outros estão prestes a sentir.

A mudança para a IA como revisor padrão não é um salto único de fé. É uma escada, e as organizações subem uma escada de cada vez à medida que as evidências se acumulam.

À medida que a IA assume mais do processo de codificação, como você vê o papel dos engenheiros seniores evoluindo nos próximos anos?

Os engenheiros seniores já estão se mudando para funções de coordenação, montando logs, diagnosticando problemas e decidindo o que é seguro para mesclar. Esse não é um papel que alguém planejou. É uma reação ao sistema quebrando sob carga.

À medida que os agentes assumem mais do trabalho de validação repetitivo, os engenheiros permanecem no loop, mas se movem mais para cima da pilha. Eles gastam menos tempo em triagem manual e mais tempo tomando decisões sobre o que deve ser enviado e por quê.

A Gitar recentemente arrecadou $9 milhões para escalar a plataforma. Quais são suas principais prioridades para esse capital, e como o sucesso parece nos próximos 12 a 18 meses?

O capital vai para duas prioridades. A primeira é go-to-market: estamos escalando nosso movimento empresarial e investindo na conscientização do desenvolvedor para que as equipes que se beneficiariam da Gitar saibam que existimos. A segunda é produto: estamos continuando a construir em direção à nossa visão de validação de código e qualidade totalmente autônoma, o que significa capacidades de agente mais profundas, cobertura de fluxo de trabalho mais ampla e integração mais próxima com as ferramentas que os desenvolvedores já usam.

O sucesso nos próximos 12 a 18 meses parece uma base significativa de clientes empresariais executando a Gitar em seus repositórios de código, uma comunidade de desenvolvedores que nos reconhece como o padrão para validação de código impulsionada por IA, e evidências claras de que nossos agentes estão fazendo mais do trabalho de revisão, remediação e mesclagem de forma autônoma ao longo do tempo. Se estivermos no caminho certo, a conversa daqui a um ano não é se a IA pode validar o código, mas quanto da pipeline de validação uma equipe passou para os agentes.

Obrigado pela grande entrevista, leitores que desejam aprender mais devem visitar Gitar.