Gautam Korlam, Ingeniero Principal en Sonar – Serie de Entrevistas

Gautam Korlam, Ingeniero Principal en Sonar, es un ingeniero de software veterano y líder tecnológico cuya carrera se ha centrado en la infraestructura para desarrolladores, la calidad del código, la automatización y el desarrollo de software asistido por IA. Antes de unirse a Sonar, cofundó Gitar y se desempeñó como CTO, creando una plataforma nativa de IA diseñada para automatizar la revisión de código, diagnosticar fallos de integración continua (CI), identificar causas raíz y generar correcciones. Sonar adquirió Gitar en mayo de 2026, y Korlam y el equipo de Gitar se incorporaron a la empresa para seguir desarrollando la tecnología como parte de la plataforma más amplia de verificación de código de Sonar. Antes de Gitar, Korlam pasó casi una década en Uber, ascendiendo de ingeniero fundador en su equipo de plataforma móvil a Ingeniero Principal. Durante su permanencia, ayudó a construir y escalar la infraestructura centralizada para desarrolladores de Uber, lideró importantes iniciativas de monorepo y del sistema de compilación, desarrolló entornos de desarrollo remotos y herramientas CI/CD, y experimentó con modelos de lenguaje de gran escala de código abierto como StarCoder, OctoCoder y Code Llama para mejorar la codificación asistida por IA dentro del código de Uber. Su experiencia anterior incluye roles de ingeniería en Lookout y trabajo de investigación en UC Santa Barbara, así como pasantías en Microsoft y Oracle.

Sonar es una empresa de software centrada en la verificación de código, la revisión automática de código, la calidad del código y la seguridad de aplicaciones. Su plataforma insignia, SonarQube, analiza el código escrito por desarrolladores y generado por IA para identificar errores, vulnerabilidades, problemas de mantenibilidad y otras cuestiones de calidad antes de que lleguen a producción, con ofertas que abarcan flujos de trabajo en la nube, autogestionados y en entornos de desarrollo integrados. Sonar afirma que su tecnología es utilizada por más de 7 millones de desarrolladores y 22 000 clientes, y analiza más de 750 mil millones de líneas de código cada día. La adquisición de Gitar amplió este enfoque hacia la revisión y remediación de código nativa de IA, combinando el motor de verificación de SonarQube con herramientas agentes capaces de revisar código, investigar fallos de CI y proponer o aplicar correcciones a medida que el desarrollo de software se vuelve cada vez más impulsado por IA.

Su carrera lo ha llevado desde construir la infraestructura móvil y de desarrolladores de Uber hasta entrenar modelos de lenguaje de gran escala de código abierto en su base de código, antes de cofundar Gitar y unirse a Sonar tras su adquisición. ¿Cómo influyeron esas experiencias en su convicción de que generar código es solo una parte del desafío, y que validar su fiabilidad puede ser el problema más difícil?

En Uber trabajé en las partes del sistema que deciden si algo se lanza: el monorepo, la compilación, la cola de CI, el conjunto de pruebas. Facilitar la producción de cambios traslada toda la presión a esa maquinaria. Aparecen más servicios interactuando de maneras inesperadas, y más ingenieros esperando averiguar si su cambio es seguro de fusionar.

Más tarde trabajé en entrenar modelos con nuestra propia base de código, y allí la asimetría se volvió evidente. Un modelo puede producir una implementación plausible rápidamente. Demostrar que la implementación encaja en un sistema de producción en vivo, sigue las convenciones que este equipo realmente usa y no rompe algo a dos servicios de distancia lleva mucho más tiempo, y la mayor parte de ese trabajo recae en las personas. Gitar surgió de eso, y se alinea con lo que Sonar ha estado haciendo del lado del análisis durante más de diecisiete años.

Usted ha argumentado que la revisión de código con IA debe complementar el análisis determinista en lugar de reemplazarlo. ¿Qué tipos de problemas se identifican mejor mediante análisis repetibles basados en reglas, y dónde puede la IA ofrecer capacidades que las técnicas tradicionales no pueden?

El análisis basado en reglas es la herramienta adecuada cuando la propiedad es decidible a partir del propio código. Entrada contaminada que llega a un sumidero, una desreferencia nula en una ruta que alguien pasó por alto, una credencial codificada, una dependencia con una CVE conocida, una importación que cruza una capa que no debería. Obtienes la misma respuesta en cada ejecución y puedes señalar la razón por la que se activó, por lo que la aplicación pertenece a esa capa.

Lo que las reglas no cubren es la intención. Ningún analizador le dirá que una cadena visible para el usuario será ambigua para quien la traduzca, o que un cambio afirma cerrar un ticket mientras implementa solo la mitad de lo que el ticket solicitó, o que un nuevo bucle de reintentos entra en conflicto con la forma en que el resto del servicio maneja la presión de retorno. Un modelo que lea el diff junto con el issue vinculado y el contexto completo de la base de código señalará esos casos, y deberían aparecer como hallazgos que una persona verifica en lugar de como veredictos.

Los sistemas de IA pueden evaluar la lógica de negocio, la intención del desarrollador y los compromisos arquitectónicos, pero sus conclusiones son probabilísticas. ¿Cómo pueden los equipos de desarrollo beneficiarse de este razonamiento contextual sin considerar que la salida del revisor de IA es inherentemente correcta?

La revisión de IA gana su lugar en los problemas que las comprobaciones convencionales pasan por alto: errores lógicos, comportamientos que no coinciden con la intención declarada, un cambio que parece correcto por sí solo pero es erróneo para este sistema en particular. Esas conclusiones son probabilísticas, por lo que forman parte de la entrada a una decisión en lugar de ser la decisión misma. Los equipos mantienen ese límite manteniendo los controles deterministas antes de la fusión, lo que implica pruebas automatizadas, validación de CI, escaneo de seguridad, verificaciones de políticas y un ser humano responsable del cambio. La IA puede proponer correcciones o implementarlas dentro de los límites que el equipo establece, siempre que esos cambios superen la misma verificación que cualquier cosa escrita por una persona y no reciban un atajo por haber sido generados por máquina.

Aplicamos el mismo límite dentro de nuestra propia implementación. El modelo propone hallazgos, y el veredicto de la revisión se calcula en código a partir del estado de esos hallazgos. La resolución funciona de la misma manera. Cuando el código detrás de un hallazgo desaparece del diff, eso constituye una comprobación determinista contra el diff analizado, y al modelo no se le permite desresolver lo que el diff ya ha corregido.

La versión general de esto es asignar a la capa probabilística los trabajos donde equivocarse es recuperable, mantener la máquina de estados determinista y dejar la responsabilidad al equipo. Lo que genera confianza es la evidencia de que alguien puede inspeccionar y controlar que se comporte de la misma manera en cada ejecución.

Sonar está combinando revisiones de pull request con contexto con análisis determinista y puertas de calidad. ¿Cómo se ve un proceso de verificación multicapas eficaz, y cómo deben interactuar las distintas capas sin duplicar trabajo o abrumar a los desarrolladores con hallazgos?

El análisis determinista y las puertas de calidad manejan los aspectos que no están sujetos a negociación, y son los que bloquean una fusión. La revisión contextual asume los juicios sobre si un cambio hace lo que afirma, si encaja en la base de código y si un riesgo dado merece la atención de una persona.

Una pared de hallazgos se ignora aproximadamente al mismo ritmo que la ausencia total de hallazgos. Deduplcamos entre revisores antes de que algo llegue al autor, descartamos candidatos que no puede verificar y nos enfocamos en hallazgos de alta señal. En el lado de las reglas, un predicado decide si una regla se aplica al diff actual antes de que se ejecute cualquier modelo, de modo que la mayoría de las reglas no cuestan nada en la mayoría de los cambios. Todo eso aparece en el pull request que el desarrollador ya tiene abierto.

A medida que los agentes de codificación generan más código y pull requests, ¿podría la revisión y verificación de software convertirse en el nuevo cuello de botella? ¿Qué partes del proceso de revisión deberían automatizarse y qué decisiones deberían permanecer en manos de ingenieros experimentados?

La revisión y verificación ya se han convertido en el cuello de botella. De hecho, nuestra Encuesta de Desarrolladores del Estado del Código 2026 descubrió que los equipos informan que dedican aproximadamente una cuarta parte de la semana laboral a revisar y corregir la salida de IA. Con esto, no sorprende que solo el 48 % de los desarrolladores siempre revisen el código generado por IA antes de comprometerlo, aunque la mayoría (96 %) no confíen plenamente en que sea funcionalmente correcto.

El trabajo que vale la pena automatizar es mecánico y desagradable: agrupar un fallo de CI hasta su causa raíz para que nadie tenga que leer cuatro mil líneas de registro, decidir si un hallazgo sigue aplicándose después de un rebase, reproducir un fallo, escribir la corrección obvia. Los ingenieros deben conservar la intención, el diseño y la decisión sobre cuánta evidencia es suficiente para un cambio concreto. Cuando un ingeniero senior pasa una noche leyendo registros para determinar cuál de los nueve fallos importa, eso es triage más que juicio, y es exactamente el tipo de trabajo que deberíamos quitarles.

Los sistemas de revisión de código con IA pueden identificar problemas, proponer correcciones y validar esos cambios contra la canalización de integración continua. ¿Cómo se evita que un sistema de remediación autónomo introduzca regresiones o se optimice estrechamente para una compilación exitosa en lugar de la calidad más amplia del software?

Lo principal es negarse a tratar el verde como criterio de aceptación, ya que una compilación exitosa solo indica que las pruebas existentes no fallaron.

La mayor parte de las limitaciones que imponemos a nuestra propia remediación se refieren al alcance. Gitar corrige CI que se rompió, y verifica que el commit anterior a su propio push estaba verde antes de asumir responsabilidad por cualquier cosa. Se detiene después de dos commits de seguimiento en lugar de seguir trabajando en una compilación roja. Cuando el fallo no tiene nada que ver con el cambio, una prueba inestable o un problema de infraestructura, se sigue la ruta de reintento en lugar de la ruta de corrección, porque “hacer que la prueba deje de fallar” es el objetivo que menos desea que persiga un agente capaz.

Después de eso, el cambio debe superar una capa que Gitar no controla. SonarQube evalúa el resultado bajo sus propios criterios, la puerta de calidad es en la que depende la fusión, y el equipo es responsable de esa política. También verificamos el cambio contra el issue que afirma implementar, manteniendo la extracción de requisitos separada del juicio de finalización, de modo que un requisito que salió silenciosamente del ticket no pueda volver como implementado.

Una revisión de código con IA eficaz depende de comprender las convenciones, dependencias, arquitectura y el propósito de un cambio propuesto en un repositorio. ¿Qué contexto necesita un revisor de IA para tomar decisiones útiles, y cómo pueden las organizaciones mantener ese contexto preciso a medida que sus sistemas evolucionan?

Necesita suficiente contexto para razonar como un revisor experimentado, no solo lo suficiente para leer el diff. Eso incluye el propósito del cambio, rutas de código relevantes e información de tipos, dependencias, comportamiento de pruebas, convenciones del repositorio y los límites arquitectónicos que el equipo espera que el cambio respete.

El contexto también debe vivir con el código. Mantenga las reglas y la guía de revisión versionadas en el repositorio, actualícelas cuando los servicios o convenciones cambien, y deje clara la propiedad de las decisiones arquitectónicas y de políticas. De lo contrario, un revisor de IA puede producir una sugerencia individualmente plausible que entre en conflicto con el funcionamiento real del sistema más amplio.

El análisis determinista produce resultados consistentes y auditables, mientras que la revisión basada en modelos de lenguaje de gran escala puede variar entre ejecuciones. ¿Cómo deben las empresas documentar, reproducir y gobernar los hallazgos generados por IA en entornos regulados o sensibles a la seguridad?

El registro de auditoría debe mostrar el cambio revisado, el hallazgo de IA, la decisión tomada y la evidencia independiente utilizada para validar el resultado. Los equipos pueden usar IA para acelerar la revisión y la remediación, mientras mantienen la aplicación y las decisiones de aprobación ancladas en políticas definidas y en la responsabilidad humana.

¿Qué métricas deberían usar los líderes de ingeniería para determinar si la revisión de código con IA realmente está mejorando el desarrollo de software? ¿Deberían priorizar el tiempo de revisión, los defectos escapados, las tasas de falsos positivos, los fallos de integración continua, la deuda técnica, la confianza del desarrollador u otra medida?

Comience con los resultados, no con la cantidad de comentarios que produce un sistema de IA. Mediría el tiempo desde el pull request hasta la fusión, el tiempo dedicado a diagnosticar fallos de CI, la tasa a la que las correcciones pasan en el primer intento de validación y la frecuencia con la que los problemas escapan a etapas posteriores o a producción.

Luego observe señales de calidad como las tasas de falsos positivos y de descartes, issues reabiertos, regresiones vinculadas a cambios recién fusionados y la retroalimentación de los desarrolladores sobre si los hallazgos son accionables. La combinación adecuada de métricas varía según el equipo, pero la pregunta es constante: ¿estamos reduciendo el retrabajo y el tiempo de espera de revisión sin bajar el nivel de seguridad y fiabilidad del software?

De cara al futuro, ¿espera que el desarrollo de software se convierta en un bucle continuo en el que los agentes generen, revisen, prueben y reparen código bajo barreras deterministas? En ese entorno, ¿cómo cambiarán las responsabilidades y habilidades requeridas de los ingenieros de software humanos?

Ese bucle ya existe, y los equipos tienden a adoptarlo en un orden fijo: detección primero, luego remediación, después aprobación bajo condiciones que documentan, y finalmente fusión. Nadie salta directamente al último paso, y la evidencia que los impulsa es su propia base de código en lugar de un punto de referencia. La fusión es el paso que más me interesa, porque la frecuencia de conflictos aumenta con el volumen de commits, y el rendimiento es lo que todo esto incrementa.

Las habilidades que adquieren valor se sitúan alrededor del bucle más que dentro de él. Ser preciso acerca del problema y sus limitaciones importa más cuando un agente toma su descripción literalmente. Lo mismo ocurre al decidir qué evidencia es suficiente para permitir un cambio, lo que antes vivía en la cabeza de las personas como hábito y ahora debe plasmarse como política que algo automatizado pueda aplicar. El resto es diseño de sistemas: delimitar qué trabajo automatizado puede tocar, contar con algo que el agente no controla para verificar el resultado y mantener la atribución cuando algo falla. Los ingenieros pasarán menos tiempo produciendo la implementación y más tiempo decidiendo qué debe existir y qué contaría como prueba de que funciona.

Gracias por la excelente entrevista, los lectores que deseen obtener más información deberían visitar Sonar.