✨︎ Resumen (TL;DR):
- Neil Kakkar integró un promedio de 207 solicitudes de cambios de código al mes en Tano, frente a 19 en PostHog.
- Su registro de GitHub reúne 859 solicitudes en 25 repositorios de PostHog y 1,638 en el repositorio de Tano.
- El tiempo mediano de integración bajó de 15 horas a 42 minutos, mientras los arreglos posteriores durante la semana siguiente subieron de alrededor de 8 % a 14 %.
Neil Kakkar pasó de integrar un promedio de 19 a 207 solicitudes de cambios de código al mes al cambiar PostHog por Tano, donde trabaja con agentes de inteligencia artificial. En un ensayo publicado por The Pragmatic Engineer, atribuye gran parte del aumento a esas herramientas. En Tano, además, mantiene entre tres y cinco tareas en paralelo. El salto no prueba que la IA lo haya hecho 11 veces más productivo: también cambiaron la empresa, sus funciones y el entorno técnico.
Qué mide realmente una PR
Una pull request (PR) es una propuesta de cambios que reúne modificaciones para integrarlas a un proyecto de software. Puede contener desde un arreglo pequeño hasta una función extensa. Contar las solicitudes integradas sirve para observar el ritmo de entrega, pero no mide por sí solo el valor de cada cambio.
La comparación reúne dos etapas distintas
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. Elaboró el registro con datos de GitHub y contabilizó 859 solicitudes integradas en 25 repositorios de PostHog, frente a 1,638 en el repositorio de Tano. Las tasas se calcularon con periodos de 30 días.
La diferencia es de unas 11 veces por periodo en solicitudes, no una medición de que la IA lo haya hecho 11 veces más productivo. Además de usar herramientas distintas, Kakkar cambió de empresa, funciones y 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
Tano es una agencia de marketing de creadores que utiliza agentes de IA. Ahí Kakkar trabaja con Claude Code y suele mantener entre tres y cinco tareas en paralelo.
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 flujo de revisión también cambió para el resto del equipo:
- En PostHog, las solicitudes requerían revisión de compañeros.
- En Tano, la revisión humana de otro integrante es 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 examina su propio trabajo y el de quienes acaban de incorporarse. La diferencia es que, en muchos cambios de integrantes experimentados, no se espera la aprobación de otro compañero antes de integrar la solicitud.
El tiempo mediano entre abrir e integrar una solicitud cayó de unas 15 horas a 42 minutos. Kakkar atribuye parte de esa reducción a que ya no necesita esperar la aprobación de otra persona para cada cambio.
Más entregas, otro patrón de corrección
La comparación muestra dos métricas que deben leerse juntas. La proporción de solicitudes de Kakkar que después fueron revertidas bajó de 2.3 % en PostHog a 0.4 % en Tano. Sin embargo, 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; un arreglo posterior intenta corregirlo con otra solicitud. Kakkar explica que su equipo suele elegir la segunda vía, por lo que la caída de las reversiones no demuestra por sí sola que haya menos errores.
Un ejemplo apareció en una actualización de reportes. El cambio asumió que todas las monedas tenían 100 unidades menores y falló con el dinar de Baréin, que tiene 1,000. El equipo detectó la discrepancia después del despliegue y la corrigió en menos de una hora.
En otra migración, la falta de controles provocó pagos duplicados a creadores. Kakkar presenta esos casos como parte de la decisión de su equipo de 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.
Lo que la cifra no puede responder
El propio 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.
Además, PostHog ya usaba GitHub Copilot y ChatGPT durante parte de su etapa allí. La diferencia es que no eran los agentes actuales que planifican tareas, editan archivos y ejecutan pruebas.
El costo no aparece solo en los gráficos. Kakkar afirma que coordinar varios proyectos a la vez lo deja más cansado. Al revisar menos trabajo de sus compañeros, también pierde parte del conocimiento compartido sobre lo que construye el equipo. Su propuesta es documentar mejor cada área para que otras personas puedan retomarla.
METR midió otro escenario
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. Con las herramientas disponibles a principios de 2025, las tareas en las que se permitía usar IA 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. Tano sí muestra un aumento pronunciado en una métrica de entrega, pero junto con cambios en la revisión, las correcciones y la forma de repartir el trabajo. El caso describe un flujo concreto de ingeniería, no una medida universal de productividad con IA.
