Gautam Korlam, Engenheiro Principal na Sonar – Série de Entrevistas

Gautam Korlam, Engenheiro Principal na Sonar, é um engenheiro de software veterano e líder tecnológico cuja carreira se concentrou em infraestrutura para desenvolvedores, qualidade de código, automação e desenvolvimento de software assistido por IA. Antes de ingressar na Sonar, co‑fundou a Gitar e atuou como CTO, construindo uma plataforma nativa em IA projetada para automatizar revisões de código, diagnosticar falhas de integração contínua (CI), identificar causas raiz e gerar correções. A Sonar adquiriu a Gitar em maio de 2026, com Korlam e a equipe da Gitar juntando‑se à empresa para continuar desenvolvendo a tecnologia como parte da plataforma mais ampla de verificação de código da Sonar. Antes da Gitar, Korlam passou quase uma década na Uber, evoluindo de engenheiro fundador na equipe de plataforma móvel para Engenheiro Principal. Durante esse período, ajudou a construir e escalar a infraestrutura centralizada de desenvolvedores da Uber, liderou importantes iniciativas de monorepo e sistema de build, desenvolveu ambientes de desenvolvimento remotos e ferramentas CI/CD, e experimentou grandes modelos de linguagem de código aberto como StarCoder, OctoCoder e Code Llama para melhorar a codificação assistida por IA no código‑fonte da Uber. Sua experiência anterior inclui cargos de engenharia na Lookout e pesquisa na UC Santa Barbara, além de estágios na Microsoft e na Oracle.

Sonar é uma empresa de software focada em verificação de código, revisão automática de código, qualidade de código e segurança de aplicações. Sua plataforma principal, SonarQube, analisa código escrito por desenvolvedores e gerado por IA para identificar bugs, vulnerabilidades, problemas de manutenibilidade e outras questões de qualidade antes que cheguem à produção, oferecendo opções em nuvem, auto‑gerenciadas e integradas a fluxos de trabalho de ambientes de desenvolvimento. A Sonar afirma que sua tecnologia é usada por mais de 7 milhões de desenvolvedores e 22 mil clientes, analisando mais de 750 bilhões de linhas de código por dia. A aquisição da Gitar ampliou essa abordagem para revisão e remediação de código nativas em IA, combinando o motor de verificação do SonarQube com ferramentas agentes capazes de revisar código, investigar falhas de CI e propor ou aplicar correções à medida que o desenvolvimento de software se torna cada vez mais orientado por IA.

Sua carreira o levou de construir a infraestrutura móvel e de desenvolvedores da Uber ao treinamento de grandes modelos de linguagem de código aberto em seu código‑fonte, antes de co‑fundar a Gitar e ingressar na Sonar após a aquisição. Como essas experiências moldaram sua convicção de que gerar código é apenas parte do desafio, e que validar esse código de forma confiável pode ser o problema mais difícil?

Na Uber eu trabalhei nas partes do sistema que decidem se algo pode ser entregue: o monorepo, o build, a fila de CI, a suíte de testes. Facilitar a produção de mudanças transfere toda a pressão para essa maquinaria. Você obtém mais serviços interagindo de maneiras inesperadas e mais engenheiros aguardando para descobrir se sua mudança é segura para mesclar.

Depois trabalhei no treinamento de modelos em nosso próprio código‑fonte, e foi aí que a assimetria ficou evidente. Um modelo pode produzir uma implementação plausível rapidamente. Demonstrar que a implementação se encaixa em um sistema de produção ativo, segue as convenções que a equipe realmente usa e não quebra algo em dois serviços diferentes leva muito mais tempo, e a maior parte desse trabalho recai sobre as pessoas. A Gitar surgiu disso, e se alinha ao que a Sonar vem fazendo do lado da análise há mais de dezessete anos.

Você argumenta que a revisão de código por IA deve complementar a análise determinística, e não substituí‑la. Que tipos de problemas são melhor identificados por meio de análise repetível baseada em regras, e onde a IA pode oferecer capacidades que técnicas tradicionais não conseguem?

A análise baseada em regras é a ferramenta certa quando a propriedade é decidível a partir do próprio código. Entrada contaminada chegando a um sink, uma desreferência nula em um caminho que alguém deixou passar, credencial codificada, dependência com CVE conhecido, importação que cruza uma camada que não deveria. Você obtém a mesma resposta em cada execução e pode apontar a razão do disparo, por isso a aplicação de políticas pertence a essa camada.

O que as regras não cobrem é a intenção. Nenhum analisador dirá que uma string voltada ao usuário será ambígua para quem a traduz, ou que uma mudança afirma fechar um ticket enquanto implementa apenas metade do que o ticket pediu, ou que um novo loop de retry conflita com a forma como o restante do serviço lida com backpressure. Um modelo que lê o diff junto com a issue vinculada e o contexto completo do código‑fonte levantará esses pontos, e eles devem aparecer como achados que uma pessoa verifica, e não como veredictos automáticos.

Sistemas de IA podem avaliar lógica de negócio, intenção do desenvolvedor e trade‑offs arquiteturais, mas suas conclusões são probabilísticas. Como as equipes de desenvolvimento podem se beneficiar desse raciocínio contextual sem tratar a saída de um revisor de IA como inerentemente correta?

A revisão por IA ganha seu lugar nos problemas que verificações convencionais perdem: erros lógicos, comportamentos que não correspondem à intenção declarada, uma mudança que parece correta isoladamente mas está errada para aquele sistema específico. Essas conclusões são probabilísticas, portanto pertencem ao input de uma decisão, não à decisão em si. As equipes mantêm essa fronteira mantendo os controles determinísticos antes da mesclagem, como testes automatizados, validação de CI, varredura de segurança, verificações de políticas e um ser humano responsável pela mudança. A IA pode propor correções ou implementá‑las dentro das diretrizes que a equipe define, desde que essas mudanças passem pela mesma verificação que qualquer código escrito por pessoa e não recebam tratamento preferencial por terem sido geradas por máquina.

Aplicamos a mesma fronteira em nossa própria implementação. O modelo propõe achados, e o veredicto da revisão é calculado em código a partir do estado desses achados. A resolução funciona da mesma forma. Quando o código associado a um achado desaparece do diff, isso constitui uma verificação determinística contra o diff analisado, e o modelo não pode “des‑resolver” o que o diff já corrigiu.

A versão geral disso é delegar à camada probabilística os trabalhos onde errar é recuperável, manter a máquina de estado determinística e deixar a responsabilidade com a equipe. O que gera confiança são evidências que alguém pode inspecionar e controlar, comportando‑se da mesma forma em cada execução.

A Sonar está combinando revisões de pull request conscientes de contexto com análise determinística e quality gates. Como se parece um processo de verificação multilayer eficaz, e como as diferentes camadas devem interagir sem duplicar trabalho ou sobrecarregar os desenvolvedores com achados?

Análise determinística e quality gates tratam dos itens que não estão em negociação, e são o que bloqueia uma mesclagem. A revisão contextual cuida dos julgamentos sobre se uma mudança faz o que afirma, se se encaixa no código‑fonte e se um determinado risco vale a atenção de uma pessoa.

Um muro de achados é ignorado na mesma taxa que a ausência total de achados. Nós deduplicamos entre revisores antes que algo chegue ao autor, descartamos candidatos que não podem ser verificados e focamos nos achados de alto sinal. No lado das regras, um predicado decide se uma regra se aplica ao diff atual antes de qualquer modelo ser executado, de modo que a maioria das regras não custa nada na maioria das mudanças. Tudo isso aparece no pull request que o desenvolvedor já tem aberto.

À medida que agentes de codificação produzem mais código e pull requests, a revisão e verificação de software podem se tornar o novo gargalo? Quais partes do processo de revisão devem ser automatizadas, e quais decisões devem permanecer nas mãos de engenheiros experientes?

Revisão e verificação já se tornaram o gargalo. Na verdade, nossa Pesquisa de Desenvolvedores State of Code 2026 constatou que as equipes gastam aproximadamente um quarto da semana de trabalho verificando e corrigindo a saída de IA. Não é surpresa que apenas 48 % dos desenvolvedores sempre verifiquem o código gerado por IA antes de confirmá‑lo, embora a maioria (96 %) não confie plenamente que ele seja funcionalmente correto.

O trabalho que vale a pena automatizar é mecânico e desagradável: agrupar uma falha de CI até sua causa raiz para que ninguém precise ler quatro mil linhas de log, decidir se um achado ainda se aplica após um rebase, reproduzir uma falha, escrever a correção óbvia. Engenheiros devem manter a intenção, o design e a decisão sobre quanta evidência é suficiente para uma mudança específica. Quando um engenheiro sênior passa a noite lendo logs para descobrir qual das nove falhas importa, isso é triagem, não julgamento, e é exatamente o tipo de trabalho que devemos tirar deles.

Sistemas de revisão de código por IA podem identificar problemas, propor correções e validar essas mudanças contra o pipeline de integração contínua. Como impedir que um sistema autônomo de remediação introduza regressões ou otimize apenas para um build bem‑sucedido em vez da qualidade geral do software?

A principal medida é recusar tratar o “verde” como critério de aceitação, já que um build bem‑sucedido apenas indica que os testes existentes não falharam.

A maioria das restrições que impomos à nossa própria remediação diz respeito ao escopo. A Gitar corrige CI que quebrou e verifica se o commit anterior ao seu próprio push estava verde antes de assumir responsabilidade por qualquer coisa. Ela para após dois commits subsequentes, em vez de insistir em um build vermelho. Quando a falha não tem relação com a mudança — um teste intermitente ou um problema de infraestrutura — isso segue o caminho de retry ao invés do caminho de correção, porque “fazer o teste parar de falhar” é o objetivo que menos queremos que um agente capaz persiga.

Depois disso, a mudança precisa passar por uma camada que a Gitar não controla. O SonarQube avalia o resultado nos seus próprios termos, o quality gate é o que a mesclagem depende, e a equipe detém essa política. Também verificamos a mudança em relação à issue que ela afirma implementar, mantendo a extração de requisitos separada do julgamento de conclusão, de modo que um requisito que silenciosamente saiu do ticket não volte como implementado.

Uma revisão de código por IA eficaz depende de entender as convenções, dependências, arquitetura e o propósito de uma mudança proposta em um repositório. Que contexto um revisor de IA precisa para tomar decisões úteis, e como as organizações podem manter esse contexto preciso à medida que seus sistemas evoluem?

Ele precisa de contexto suficiente para raciocinar como um revisor experiente, não apenas o suficiente para ler o diff. Isso inclui o propósito da mudança, caminhos de código relevantes e informações de tipo, dependências, comportamento de testes, convenções do repositório e os limites arquiteturais que a equipe espera que a mudança respeite.

O contexto também deve viver junto ao código. Mantenha regras e diretrizes de revisão versionadas no repositório, atualize‑as quando serviços ou convenções mudarem, e deixe clara a responsabilidade por decisões arquiteturais e de política. Caso contrário, um revisor de IA pode gerar uma sugestão plausível individualmente que conflita com o modo como o sistema mais amplo realmente funciona.

Análise determinística produz resultados consistentes e auditáveis, enquanto a revisão baseada em grandes modelos de linguagem pode variar entre execuções. Como as empresas devem documentar, reproduzir e governar achados gerados por IA em ambientes regulados ou sensíveis à segurança?

O rastro de auditoria deve mostrar a mudança revisada, o achado de IA, a decisão tomada e as evidências independentes usadas para validar o resultado. As equipes podem usar IA para acelerar revisão e remediação, mantendo a aplicação de políticas e decisões de aprovação ancoradas em políticas definidas e responsabilidade humana.

Quais métricas os líderes de engenharia devem usar para determinar se a revisão de código por IA está realmente melhorando o desenvolvimento de software? Devem priorizar tempo de revisão, defeitos escapados, taxa de falsos positivos, falhas de CI, dívida técnica, confiança dos desenvolvedores ou outra medida?

Comece pelos resultados, não pelo número de comentários que o sistema de IA produz. Eu mediria o tempo do pull request até a mesclagem, o tempo gasto diagnosticando falhas de CI, a taxa de correções que passam na primeira tentativa de validação e a frequência com que problemas escapam para estágios posteriores ou produção.

Depois observe sinais de qualidade como taxa de falsos positivos e de descartes, issues reabertas, regressões vinculadas a mudanças recentemente mescladas e feedback dos desenvolvedores sobre se os achados são acionáveis. A combinação correta de métricas varia por equipe, mas a pergunta permanece constante: estamos reduzindo retrabalho e tempo de espera na revisão sem baixar o patamar de software seguro e confiável?

Olhando para o futuro, você espera que o desenvolvimento de software se torne um loop contínuo em que agentes geram, revisam, testam e corrigem código sob guardrails determinísticos? Nesse cenário, como mudarão as responsabilidades e habilidades necessárias dos engenheiros de software humanos?

Esse loop já existe, e as equipes tendem a adotá‑lo em ordem fixa: detecção primeiro, depois remediação, então aprovação sob condições que elas documentam, e por fim a mesclagem. Ninguém pula direto para a última etapa, e a evidência que os impulsiona ao longo do caminho é seu próprio código‑fonte, não um benchmark. A mesclagem é a etapa que acho mais interessante, porque a frequência de conflitos aumenta com o volume de commits, e esse volume é o que tudo isso eleva.

As habilidades que ganham valor ficam ao redor do loop, não dentro dele. Ser preciso sobre o problema e suas restrições importa mais quando um agente interpreta sua descrição literalmente. Também importa decidir que evidência é suficiente para liberar uma mudança, algo que antes vivia na cabeça das pessoas como hábito e agora precisa ser escrito como política que algo automatizado pode aplicar. O resto é design de sistemas: delimitar o que o trabalho automatizado pode tocar, ter algo que o agente não controla verificando o resultado e mantê‑lo atribuível quando algo dá errado. Os engenheiros passarão menos tempo produzindo a implementação e mais tempo decidindo o que deve existir e o que contaria como prova de que funciona.

Obrigado pela ótima entrevista, leitores que desejam saber mais devem visitar Sonar.