La newsletter The Pragmatic Engineer organizó un concurso de ensayos entre sus lectores, y el texto ganador, publicado el 3 de noviembre, es un relato en primera persona de cómo se ve programar con IA a toda velocidad. Su autor, Neil Kakkar, tiene nueve años de experiencia, incluidos Bloomberg y PostHog, y hoy es el primer ingeniero de Tano, una startup de unas diez personas.
Las cifras
En empleos anteriores, Kakkar fusionaba entre 8 y 20 pull requests al mes. En Tano entrega más de 200, unas 11 veces lo que hacía en PostHog. Afirma que su tasa de reversiones es unas seis veces menor, sobre todo porque los problemas se corrigen hacia delante, y que la mediana desde que abre un PR hasta que lo fusiona es de menos de una hora. Todo el equipo fusiona unos 30 PR al día.
La configuración
Todo funciona sobre Claude Code. Cada ingeniero tiene una suscripción a Claude Max 20x; Kakkar calcula que su uso costaría más de 8.000 $ al mes a precios de la API. Trabaja en la app de escritorio de Claude Code con su navegador integrado en lugar de la línea de comandos, mantiene de 3 a 5 tareas en paralelo y deja que los agentes trabajen de una a dos horas por funcionalidad, incluidas sus propias comprobaciones y capturas de pantalla. Cada PR recibe una revisión automática de un agente de Claude Code en GitHub Actions, con un agente de revisión más profundo para los cambios arriesgados. En la mayoría de los PR, ese agente es el único revisor. El contexto de cada área del producto está escrito en archivos AGENTS.md para que los agentes puedan encontrarlo.
Lo que salió mal
Enumera los fallos sin rodeos. Un agente multiplicó importes en moneda por 100, algo incorrecto para divisas como el dinar bareiní; se detectó después del deploy y se corrigió en menos de una hora. Una migración de base de datos bloqueante sobre una tabla grande detuvo la ingesta de datos. Otra migración sin salvaguardas pagó dos veces a algunos creadores. Reglas como estas viven ahora en las instrucciones del agente revisor.
Los costes humanos también están en la lista: cambio de contexto constante, menos personas que conocen cada parte del código, un diseño de aspecto genérico y toparse con los límites del plan cuando los agentes entran en bucles. La regla del propio Kakkar es parar a las 6 de la tarde y dejar sus dispositivos de trabajo en la oficina.
La advertencia del editor
Gergely Orosz, que dirige la newsletter, añade que en el conjunto de la industria el número de PR se ha duplicado aproximadamente desde enero, así que este caso está muy por encima de la media, y que la velocidad por sí sola no demuestra que un producto tenga éxito. Las empresas maduras, sostiene, deberían cambiar sus procesos con más cuidado.
Qué significa esto si estás eligiendo un agente de programación
La mejora vino del proceso, no solo de la herramienta. El contexto por escrito, un revisor automático en cada PR y las reglas aprendidas de los incidentes aportaron tanto como el modelo.
Ten en cuenta los límites. Incluso el plan más alto de Claude se agotaba cuando los agentes trabajaban en bucles, así que revisa la cuota antes de planificar ejecuciones nocturnas. Si estás comparando opciones, consulta Codex vs Claude Code y nuestra lista de herramientas de IA para programar.