Ali-Reza Adl-Tabatabai, Fundador y CEO de Gitar – Serie de Entrevistas

Ali-Reza Adl-Tabatabai, Fundador y CEO de Gitar, es un veterano líder de ingeniería cuya carrera abarca algunas de las empresas de tecnología más influyentes del Valle de Silicio, incluyendo Uber, Google, Facebook, Intel, AMD y IBM. Antes de lanzar Gitar en 2023, se desempeñó como Director Senior de Ingeniería en Uber, donde ayudó a liderar las iniciativas de la plataforma de desarrolladores de la empresa, después de desempeñar roles de liderazgo en Google que supervisaban la Ingeniería de Confiabilidad del Sitio para productos como Comunicaciones, Fotos, Sociales, Nube y infraestructura técnica.

Al comienzo de su carrera, trabajó en tecnologías de compiladores, máquinas virtuales, sistemas de computación paralela y optimización de hardware en Intel Labs y en el equipo de HipHop VM de Facebook, mientras también enseñaba diseño de compiladores avanzados en Stanford University. Su fondo de décadas en lenguajes de programación, confiabilidad de infraestructura, herramientas de desarrolladores y arquitectura de sistemas a gran escala lo ha posicionado como una figura prominente en el paisaje de ingeniería de software impulsada por IA en evolución.

Gitar se centra en un problema creciente que surge del auge del desarrollo de software asistido por IA: validar y asegurar el enorme volumen de código generado por máquina que ahora fluye hacia los sistemas empresariales. La plataforma utiliza agentes de IA para automatizar la revisión de código, investigar fallas en la canalización de integración y entrega continuas (CI/CD), identificar errores y vulnerabilidades, recomendar soluciones y integrarse directamente en los flujos de trabajo de ingeniería existentes a través de herramientas como GitHub, GitLab, Jenkins, Jira y Slack. En lugar de competir únicamente en la generación de código de IA, la empresa se está posicionando alrededor de lo que describe como “puertas de calidad de agentes”, ayudando a los equipos de ingeniería a mantener la confiabilidad, la seguridad y la supervisión operativa a medida que el desarrollo de software se desplaza cada vez más hacia flujos de trabajo de codificación autónomos y asistidos por IA.

Ha liderado la ingeniería en Uber, Google e Intel Labs, trabajando en plataformas de desarrolladores y infraestructura a gran escala. ¿Qué experiencias específicas de ese viaje lo llevaron a fundar Gitar, y por qué se centra en la validación de código en lugar de la generación de código?

A lo largo de Uber, Google, Facebook e Intel Labs, trabajé en plataformas de desarrolladores a escalas muy diferentes, y la misma lección seguía apareciendo: la experiencia del desarrollador es una ventaja competitiva. Las grandes herramientas atraen y retienen a los mejores ingenieros y permiten que las empresas se muevan rápidamente. Los desarrolladores quieren herramientas rápidas y silenciosas que los mantengan en flujo y automaten el trabajo pesado. Pero la herramienta de desarrollador está profundamente fragmentada, y la mayoría de las empresas queman enormes recursos de ingeniería solo para ensamblar una experiencia coherente. Vi de primera mano cuánto apalancamiento hay en arreglar eso.

La IA cambia la ecuación al hacer posible automatizar mucho más del flujo de trabajo del desarrollador de lo que se podía antes. La generación de código ya está bien cubierta, pero eso solo ha desplazado el cuello de botella hacia abajo, a la validación, refactorización y mantenimiento del código que ahora producimos a un volumen sin precedentes. Ahí es donde se centra Gitar. A medida que la IA escribe más código, el recurso escaso no es la generación; es la confianza, la corrección y la mantenibilidad de lo que se envía. La validación de código es la parte del flujo de trabajo que determina si el código generado por IA realmente llega a la producción de manera segura, y ese es el problema más difícil y valioso de resolver.

Con el auge del código generado por IA, muchos equipos ahora lidian con lo que algunos llaman sobrecarga de código. ¿Cuán significativo es este problema dentro de las empresas hoy en día, y dónde están luchando los equipos más?

El cambio no está en escribir código. Esa parte ya se está moviendo más rápido de lo que la mayoría de los equipos puede absorber. Lo que ha cambiado es todo lo que viene después. Las herramientas de IA están generando un flujo constante de solicitudes de extracción, a menudo más rápido de lo que los equipos pueden revisarlas, lo que crea presión en partes del sistema que nunca estuvieron diseñadas para este nivel de salida.

Cada cambio todavía tiene que pasar por validación. Revisión de código. Integración continua. Verificaciones de seguridad. Aprobaciones. Nada de eso desaparece solo porque el código se genera más rápido. Lo que solía ser un flujo manejable se ha convertido en un atraso. Los equipos no están bloqueados en ideas o implementación. Están bloqueados en confianza. ¿Puede esto enviar? ¿Es seguro? ¿Rompió algo sutil?

Ahí es donde se encuentra la fricción ahora. No en la creación, sino en obtener el código a través de la línea de meta sin introducir riesgos.

La industria se ha centrado en gran medida en generar código más rápido. ¿Por qué cree que la validación ha sido pasada por alto, y por qué se está volviendo más crítica ahora?

Porque el sistema aguas abajo de la generación de código no ha evolucionado al mismo ritmo. Cuando la salida aumenta, todo aguas abajo se estresa. Las solicitudes de extracción se vuelven más grandes y más frecuentes. Las fallas de integración continua comienzan a apilarse. Los ciclos de revisión se comprimen porque nadie tiene el tiempo de profundizar en cada cambio.

La calidad comienza a resbalar, no porque los ingenieros no se preocupen, sino porque el volumen fuerza compromisos. Los equipos de plataforma asumen más de la carga, manejando problemas de canalización, triaje de fallas y tratando de mantener las cosas en marcha. Los ingenieros senior terminan actuando como coordinadores, ensamblando registros, diagnosticando problemas y decidiendo qué es seguro para fusionar.

Los equipos enfrentan una elección que no funciona de ninguna manera. Empujar el código a través de él rápidamente y lidiar con las regresiones más tarde, o ralentizar y proteger la calidad, pero aceptar que la velocidad disminuye. Esa tensión está apareciendo en todas las organizaciones de ingeniería en este momento.

Gitar utiliza agentes de IA para manejar revisiones de código, pruebas y flujos de trabajo de integración continua (CI). ¿Cómo difieren fundamentalmente estos agentes de las herramientas de análisis estático tradicionales y las canalizaciones basadas en reglas?

La diferencia no es cosmética. Un agente real necesita hacer más que responder a prompts. Necesita manejar trabajo de múltiples pasos, planificar, utilizar herramientas, mantener el contexto y mover tareas hacia adelante sin entrada constante.

La mayoría de los sistemas no cumplen con ese estándar. Generan salidas, pero no manejan la ejecución. Cuando estas herramientas se colocan dentro de flujos de trabajo reales, las brechas se hacen evidentes rápidamente. No reducen la complejidad. En muchos casos, agregan otra capa que alguien tiene que administrar.

Eso es por qué la conversación se está desplazando desde “¿tenemos agentes” a “¿qué trabajo se puede manejar de manera confiable”.

La confianza es una barrera importante para la automatización en el desarrollo de software. ¿Cómo garantiza Gitar que su proceso de validación es lo suficientemente confiable como para que los equipos dependan de él?

El patrón que funciona es simple. Desglose el trabajo en pasos más pequeños. Defina límites claros. Valide las salidas continuamente. Mantenga a los humanos involucrados donde las decisiones conllevan riesgos.

Los agentes pueden revisar el código y hacer que los problemas que son fáciles de pasar por alto a gran escala sean visibles. Pueden analizar fallas de integración continua, agrupar errores relacionados y señalar una causa raíz probable. Pueden sugerir soluciones y, en algunos casos, aplicarlas de manera controlada.

Esto reduce la cantidad de triaje manual que los ingenieros tienen que hacer. No elimina a los ingenieros del bucle, pero cambia dónde pasan el tiempo. La mayoría de los sistemas operan con puntos de control, no con independencia completa.

Su plataforma permite a los equipos crear sus propios agentes. ¿Cuán importante es la personalización para la adopción empresarial, y cuáles son algunos de los casos de uso más interesantes que está viendo?

La personalización es esencial para la adopción empresarial. Cada equipo de plataforma dedica importantes recursos a personalizar la integración continua para las necesidades específicas de su empresa, lo que tradicionalmente ha requerido scripts personalizados, configuración, integraciones de herramientas, procesadores de registros y el resto del duct tape que mantiene unida la infraestructura de desarrollo moderna.

Gitar colapsa ese trabajo. Los equipos de plataforma pueden escribir verificaciones personalizadas utilizando prompts de lenguaje natural, lo que les permite validar cosas que son difíciles o imposibles con el análisis de programa tradicional, por ejemplo, marcar cadenas de usuario que son ambiguas para la traducción, o validar actualizaciones de archivos AGENTS.md. También pueden automatizar flujos de trabajo personalizados sobre solicitudes de extracción: vincular solicitudes de extracción a problemas de Jira, abrir tickets de seguimiento para comentarios de revisión no resueltos, volver a intentar pruebas poco fiables automáticamente o agregar listas de tareas personalizadas a resúmenes de solicitudes de extracción.

Los casos de uso más interesantes tienden a ser aquellos que no anticipamos. Los equipos conocen sus bases de código y sus puntos dolorosos mejor que cualquier proveedor, así que cuando les das un primitivo que convierte “nos gustaría que la integración continua pudiera verificar X” en una llamada de 10 líneas, inmediatamente comienzan a automatizar cosas que nunca habríamos construido por defecto. Eso es exactamente lo que queremos.

Los equipos de ingeniería modernos dependen de una pila compleja de herramientas como GitHub, GitLab y Jira. ¿Cuán importante es que Gitar se integre en los flujos de trabajo existentes en lugar de tratar de reemplazarlos?

La adopción depende de encontrar a los desarrolladores donde ya están. Los ingenieros no quieren otra superficie que aprender, otro panel que verificar o más conmutación de contexto entre herramientas. Quieren que sus flujos de trabajo existentes se vuelvan más rápidos y más silenciosos. Así que integrar profundamente con GitHub, GitLab, Jira y el resto de la pila no es un buen tener para nosotros; es toda la estrategia.

Pero nuestra ambición va más allá de la integración. No estamos tratando de reemplazar estas herramientas, y no estamos tratando de enchufarlas tampoco. Estamos automatizando los flujos de trabajo que corren a través de ellas. La revisión de la solicitud de extracción, el enlace del ticket, las tareas de seguimiento, las reintentos de pruebas poco fiables, todo debería ocurrir de manera autónoma, en segundo plano. Y estamos empujando más lejos: un agente edita la solicitud de extracción directamente para abordar la retroalimentación de la revisión de código y arreglar fallas de integración continua, y finalmente maneja la aprobación y la fusión para los cambios que cumplen con las políticas del equipo. El papel del desarrollador se desplaza de impulsar cada paso a establecer la intención, revisar los resultados y manejar las excepciones.

El estado final no es una nueva herramienta en la que los desarrolladores inician sesión. Es la herramienta existente que hace más por sí misma, para que los desarrolladores puedan mantenerse enfocados en el trabajo que realmente requiere su juicio.

Ha sugerido que las revisiones de código humanas podrían eventualmente convertirse en la excepción en lugar de la regla. ¿Qué necesita suceder para que las organizaciones se sientan cómodas con ese cambio?

La confianza se construye en etapas, no de una vez. Las organizaciones necesitan ver, con su propio código, que la IA puede encontrar los errores y vulnerabilidades que realmente importan y hacer cumplir sus reglas personalizadas con precisión y alta cobertura. Desde allí, el camino hacia la fusión autónoma es una progresión natural a través de cuatro niveles de confianza creciente.

El primer nivel es la detección. Los equipos construyen confianza en que los agentes encuentran problemas reales con una tasa de falsos positivos baja. Una vez que se establece esa confianza, dejan que la IA bloquee las solicitudes de extracción automáticamente cuando encuentre problemas críticos.

El segundo nivel es la remediación. La IA no solo señalaiza los problemas, los arregla, desbloquea la solicitud de extracción y vuelve a poner la integración continua en verde sin intervención humana. La confianza aquí significa que el agente puede resolver problemas y fallas de integración continua con precisión, sin romper nada.

El tercer nivel es la aprobación. Una vez que los equipos ven a los agentes aprobar solicitudes de extracción de manera confiable, dejan que la IA apruebe las solicitudes de extracción bajo reglas que definen. Dar a las organizaciones un control explícito sobre las condiciones para la aprobación automática es lo que hace que este paso se sienta seguro en lugar de temerario.

El cuarto nivel es la fusión. La IA aterriza el cambio, nuevamente bajo condiciones con las que el equipo está cómodo. Este paso tiene su propia barra: el agente tiene que resolver conflictos de fusión con precisión, sin introducir regresiones o romper la rama principal. Eso importa más de lo que la gente se da cuenta, porque la frecuencia de conflictos aumenta con el rendimiento de confirmación, y el rendimiento está explotando a medida que la IA genera más código. Los monorepositorios grandes ya sienten esto; todos los demás están a punto de sentirlo.

El cambio a la IA como revisor predeterminado no es un solo salto de fe. Es una escalera, y las organizaciones suben un peldaño a la vez a medida que se acumula la evidencia.

A medida que la IA asume más del proceso de codificación, ¿cómo ve evolucionar el papel de los ingenieros senior en los próximos años?

Los ingenieros senior ya están cambiando a roles de coordinación, ensamblando registros, diagnosticando problemas y decidiendo qué es seguro para fusionar. Ese no es un papel que nadie planeó. Es una reacción al sistema que se rompe bajo la carga.

A medida que los agentes asumen más del trabajo de validación repetitivo, los ingenieros permanecen en el bucle pero se mueven más arriba de la pila. Pasan menos tiempo en triaje manual y más tiempo tomando decisiones sobre qué debe enviar y por qué.

Gitar recientemente recaudó $9 millones para escalar la plataforma. ¿Cuáles son sus principales prioridades para ese capital, y qué se ve como el éxito en los próximos 12 a 18 meses?

El capital se destina a dos prioridades. La primera es ir al mercado: estamos escalando nuestro movimiento empresarial y estamos invirtiendo en la conciencia de los desarrolladores para que los equipos que se beneficiarían de Gitar realmente sepan que existimos. La segunda es el producto: estamos continuando la construcción hacia nuestra visión de validación de código y calidad completamente autónoma, lo que significa capacidades de agente más profundas, una cobertura de flujo de trabajo más amplia y una integración más estrecha con las herramientas que los desarrolladores ya utilizan.

El éxito en los próximos 12 a 18 meses se ve como una base significativa de clientes empresariales que ejecutan Gitar en sus bases de código, una comunidad de desarrolladores que nos reconoce como el predeterminado para la validación de código impulsada por IA, y una clara evidencia de que nuestros agentes están haciendo más del trabajo de revisión, remediación y fusión de manera autónoma con el tiempo. Si estamos en el camino correcto, la conversación dentro de un año no es si la IA puede validar el código, sino cuánta parte de la canalización de validación un equipo ha entregado a los agentes. Gracias por la gran entrevista, los lectores que desean aprender más deben visitar Gitar.