El ingeniero de software Neil Kakkar pasó de integrar un promedio de 19 solicitudes de cambios de código al mes en PostHog a 207 en Tano, donde trabaja con agentes de inteligencia artificial. En un ensayo publicado por The Pragmatic Engineer, atribuye gran parte del aumento a esas herramientas, aunque sus registros también muestran diferencias en la revisión del código y en las correcciones posteriores.
Una pull request o PR reúne cambios propuestos para incorporarlos a un proyecto de software. Puede contener desde un arreglo pequeño hasta una función extensa, de modo que contar solicitudes integradas sirve para observar el ritmo de entrega, pero no mide por sí solo el valor de cada cambio.
Kakkar comparó su actividad en PostHog entre mayo de 2021 y enero de 2025 con sus primeros ocho meses en Tano, entre enero y septiembre de 2026. Su registro, elaborado con datos de GitHub, contabiliza 859 solicitudes integradas en 25 repositorios de PostHog y 1,638 en el repositorio de Tano. Las tasas están calculadas por periodos de 30 días.
La diferencia es de unas 11 veces en solicitudes por periodo, no una medición de que la IA lo haya hecho 11 veces más productivo. Además de usar herramientas distintas, el ingeniero cambió de empresa, de funciones y de entorno técnico. PostHog tenía una base de código más madura y un equipo mayor; Tano era una startup más joven, donde Kakkar fue el primer ingeniero.
Agentes en paralelo y menos espera por revisiones
En Tano, una agencia de marketing de creadores que utiliza agentes de IA, Kakkar trabaja con Claude Code y suele mantener entre tres y cinco tareas en paralelo. Según su ensayo, revisa el plan de trabajo y deja que un agente avance hasta preparar la solicitud y atender los comentarios; después examina un resumen de los cambios y revisa el código según el riesgo y el contexto.
El proceso también cambió para el resto del equipo. En PostHog, explica, las solicitudes requerían revisión de compañeros. En Tano, la revisión humana por otro integrante pasa a ser opcional cuando el ingeniero ya conoce el código. Un agente creado por Kakkar revisa cada solicitud de forma automática, y existe una revisión automatizada más profunda para cambios delicados.
Eso no significa que las personas hayan dejado de revisar el código: Kakkar dice que examina su propio trabajo y el de quienes acaban de incorporarse. La diferencia es que, en muchos cambios de integrantes experimentados, no se espera una revisión de otro compañero antes de integrar la solicitud.
En sus registros, el tiempo mediano entre abrir e integrar una solicitud bajó de unas 15 horas en PostHog a 42 minutos en Tano. El ingeniero atribuye parte de esa reducción a que ya no necesita esperar la aprobación de otra persona para cada cambio.
Menos reversiones, más arreglos posteriores
La comparación también muestra señales que necesitan leerse juntas. La proporción de solicitudes de Kakkar que después fueron revertidas pasó de 2.3 % en PostHog a 0.4 % en Tano. Sin embargo, en sus gráficos calcula que la proporción que necesitó un arreglo posterior durante la semana siguiente subió de alrededor de 8 % a 14 %.
Una reversión deshace un cambio, mientras que un arreglo posterior intenta corregirlo con otro cambio. Kakkar explica que su equipo suele optar por la segunda vía, por lo que una caída en las reversiones no demuestra por sí sola que haya menos errores.
El ingeniero cuenta que una actualización de reportes asumió que todas las monedas tenían 100 unidades menores. Esa regla falló con el dinar de Baréin, que tiene 1,000. Según su relato, el equipo detectó la discrepancia después de desplegar el cambio y la corrigió en menos de una hora. En otra migración, la ausencia de controles provocó pagos duplicados a creadores.
Kakkar presenta estos episodios como parte de una decisión de su equipo: aceptar ciertos fallos para avanzar rápido y corregirlos después. El relato no establece que ese equilibrio funcione igual en sistemas donde un error sea más difícil o costoso de reparar.
El límite de comparar experiencias
El ingeniero reconoce que contar solicitudes no permite comparar directamente el valor del trabajo: una corrección pequeña en un servicio esencial puede importar más que un cambio grande en otra parte del producto. También señala que PostHog ya usaba herramientas como GitHub Copilot y ChatGPT durante parte de su etapa allí, aunque no los agentes actuales que planifican tareas, editan archivos y ejecutan pruebas.
Otro costo es la atención. Kakkar afirma que coordinar varios proyectos a la vez lo deja más cansado y que, al revisar menos trabajo de sus compañeros, pierde parte del conocimiento compartido sobre lo que construye el equipo. Propone documentar mejor cada área para facilitar que otras personas puedan retomarla.
Medir el efecto de la IA por separado sigue siendo difícil. En un experimento aleatorizado de 2025, la organización de investigación METR observó a 16 desarrolladores con experiencia en proyectos de código abierto y 246 tareas. En ese entorno, con herramientas disponibles a principios de 2025, las tareas con IA permitida tardaron un 19 % más.
En febrero de 2026, METR advirtió que un experimento posterior tenía sesgos de selección que impedían calcular con fiabilidad el efecto de herramientas más recientes. La organización consideró probable que para entonces los desarrolladores obtuvieran mayores beneficios, pero dijo que sus nuevos datos eran una evidencia débil para precisar cuánto.
Los resultados de METR y el registro de Kakkar cubren herramientas, tareas y condiciones distintas. El caso de Tano muestra un aumento pronunciado en una métrica de entrega, acompañado de cambios en la manera de revisar, corregir y repartir el trabajo.
