- Resumen de 6 semanas de experiencia en las que la cantidad de commits aumentó drásticamente al mejorar la infraestructura de desarrollo mediante la automatización de tareas repetitivas simples de agentes de IA, la eliminación de tiempos de espera de compilación y la construcción de un sistema de worktrees en paralelo
- Con la skill
/git-pr, se automatiza el proceso de creación de PR para eliminar el costo del cambio de contexto, y el agente redacta descripciones de PR más detalladas por sí mismo
- Al cambiar la herramienta de build a SWC, el reinicio del servidor se redujo a menos de 1 segundo, logrando un entorno de desarrollo donde el flujo no se interrumpe
- Con la función de preview de Claude Code, el agente puede validar por sí mismo la UI, eliminando el cuello de botella de que el desarrollador tenga que revisar manualmente todos los cambios
- Al eliminar cada punto de fricción de forma secuencial, se aplica tal cual el patrón de la Teoría de Restricciones (Theory of Constraints), donde aparece el siguiente cuello de botella
- Ahora, más que implementar funcionalidades, el foco está en construir infraestructura para que los agentes trabajen eficientemente y mejorar la velocidad del loop
Automatización de tareas repetitivas simples
- Al principio, todo el proceso se hacía manualmente: staging de cambios, redacción del mensaje de commit, redacción de la descripción del PR, push y creación del PR en GitHub
- Reconocer que este trabajo era una tarea repetitiva (grunt work) fue el primer punto de inflexión, y el rol cambió de implementador a manager que gestiona agentes
- Se creó la primera skill de Claude Code,
/git-pr, para automatizar todo el proceso previo a la creación del PR
- Como el agente lee el diff completo y resume bien los cambios, la descripción del PR es más detallada que cuando se escribía manualmente
- En el
CLAUDE.md del codebase se especifica el uso de Graphite, pero personalmente se prefiere plain git, así que se opera con /git-pr
- Más que el ahorro de tiempo en sí, el efecto mayor fue la eliminación de la sobrecarga mental: desapareció ese pequeño cambio de contexto de pasar de “pensar en código” a “pensar en explicar el código” cada vez que se escribía un PR
Eliminación del tiempo de espera
- Para hacer un preview local, se repetía constantemente el proceso de detener el servidor de desarrollo y reiniciarlo en una rama nueva, saliéndose de lo que se estaba haciendo
- El build del servidor tomaba alrededor de 1 minuto, suficiente para romper la concentración, pero demasiado corto como para ponerse a hacer otra cosa
- Al cambiar el build a SWC, el reinicio del servidor se redujo a menos de 1 segundo
- Apenas se guarda el archivo, el servidor ya está levantado, así que desaparece la brecha en la que se dispersa la atención
- Se compara con la diferencia entre “una conversación con silencios incómodos” y “una conversación que fluye naturalmente”
Validación autónoma de UI por parte del agente
- Antes, había que revisar directamente en preview local todos los cambios de UI, así que el desarrollador se convertía en el cuello de botella de todas las funcionalidades
- Después de que la extensión de Chrome siguiera fallando, se cambió a la función de preview de Claude Code
- El agente puede configurar el preview, mantener los datos de sesión y ver directamente cómo se ve realmente la UI
- Al integrarlo al workflow, una tarea solo se marca como “completada” si el agente valida directamente la UI
- Como se puede delegar la validación, solo hace falta intervenir en la revisión final, y el agente puede trabajar de forma autónoma por más tiempo
- Un efecto mucho más importante de lo esperado es que el agente detecta sus propios errores
Sistema de worktrees en paralelo
- Una vez que ya había rebuilds rápidos y previews automatizados, apareció el siguiente punto de fricción: solo se podía trabajar cómodamente en una tarea a la vez
- Para revisar el PR de otro agente o de un compañero, había que hacer checkout desde main hacia la rama del PR y luego rebuild y test, pero eso chocaba con cambios no committeados
stash → checkout → rebuild → test → switch back → pop stash, o crear un worktree manualmente y luego encontrarse con conflictos de puertos
- La app requiere puertos separados para frontend y backend, y todos los worktrees comparten las mismas variables de entorno, por lo que intentan hacer bind al mismo puerto
- Para resolverlo, se construyó un sistema que asigna automáticamente un rango de puertos único a cada servidor al crear un worktree
- Así se pueden ejecutar incluso 10 previews al mismo tiempo
- Se pasó de sentirse abrumado incluso con 2 ramas en paralelo a operar 5 worktrees simultáneamente
- Se ponen a correr varios agentes en worktrees separados para que construyan distintas funcionalidades, y trabajan de forma autónoma hasta completar la validación de la propia UI
- Se participa a fondo en la etapa de planificación y luego ya no se interviene hasta el momento del code review
- El review también se volvió mucho más fluido: sin trabajo de configuración, rebuilds ni conflictos de puertos, el flujo es leer, comprobar y mergear
La clave no es la IA, sino la infraestructura
- El rol cambió: en vez de dedicar tiempo a resolver personalmente problemas complejos y crear una UI perfecta, se volvió más interesante construir infraestructura que haga a los agentes más efectivos
- Es parecido a convertirse en el manager de un equipo de 10 personas, en vez de un desarrollador solitario
- Es un trabajo de plumbing poco vistoso, pero eso es lo que define si uno permanece en estado de flujo o pelea contra el entorno
- En Tano, el trabajo de mayor apalancamiento no fue desarrollar funcionalidades, sino construir infraestructura que convirtió el flujo de commits en un torrente
El loop: aplicación de la Teoría de Restricciones
- Cada etapa elimina un tipo distinto de fricción:
/git-pr: elimina la fricción de formateo al convertir cambios de código en un PR- SWC: elimina la fricción de espera entre hacer un cambio y ver el resultado
- función de preview: elimina la fricción de verificación al revisar cambios
- sistema de worktrees: elimina la fricción del cambio de contexto entre múltiples flujos de trabajo
- Cada vez que se elimina una, aparece de inmediato el siguiente cuello de botella: un patrón clásico de la Teoría de Restricciones (Theory of Constraints)
- La naturaleza del trabajo cambia: ya no es “usar herramientas para escribir código”, sino un loop ajustado de feedback de iniciar una tarea → el agente escribe código → revisar el preview → leer el diff → dar feedback o mergear → pasar a la siguiente tarea
- Si el loop es lo suficientemente rápido, no hay espacio para que se escape la atención, y mejorar la velocidad en sí misma se vuelve el juego
- Al final, el objetivo del desarrollo deja de ser implementar funcionalidades y pasa a ser cuánto más se puede aumentar la velocidad del loop
- Se llega a una etapa en la que la velocidad misma se vuelve el placer de la ingeniería
2 comentarios
Como revisor, cuando veo una descripción de PR escrita por una máquina, la experiencia no me resulta muy buena. Aunque también pienso que quizá se resuelva si se ajusta bien el prompt..
Opiniones de Hacker News
Se siente como si hubiera vuelto la métrica noventera de “líneas de código por semana”
Decir “hago más PRs” no prueba que la IA funcione bien; solo significa que estás haciendo más merges
Juzgar el rendimiento solo por volumen, sin considerar calidad del código, bugs ni carga de mantenimiento, no es distinto de esas malas métricas que antes imponían los managers
Al final, parece que no nos oponíamos a las malas métricas, sino a ser medidos en sí
El objetivo real es que el código sea simple y produzca resultados de impacto
Estoy experimentando con correr varios agentes al mismo tiempo para que prueben implementaciones distintas y luego combinar las mejores ideas
También junto documentación y requisitos, le hago preguntas al agente, y generalizo el feedback de code review en forma de checklists para aplicarlo en revisiones futuras
Trabajar hasta enfermarse no es motivo de orgullo, sino una señal de que el sistema está mal
Por ejemplo, el modelo COCOMO es lo bastante confiable como para usarse incluso en tribunales al estimar el valor de un sistema
La mayoría de los desarrolladores no quiere cuantificarse a sí misma
Aun así, quienes defienden la IA creen que hace falta medir para demostrar mejoras
Creo que los LLM deberían usarse en la dirección de reducir la carga cognitiva
Las personas son malas para el multitasking, y los LLM no arreglan eso
Yo no le delego la implementación a Claude; más bien lo uso de forma que me guíe durante el proceso de implementación
Así puedo entender todo el proceso y ver al mismo tiempo los detalles y el panorama general
Solo hace falta dejarle a Claude las partes repetitivas y mecánicas
Le hago preguntas al LLM para que entienda el problema, escribo yo mismo el código clave y luego dejo que proponga el plan para el resto de la implementación
El LLM es fuerte para leer código, explicarlo y hacer tareas simples, y yo me concentro en elegir la dirección para resolver el problema
Estoy experimentando con prompts como “haz una lista de supuestos” o “enumera decisiones que no estaban en el plan” para rastrear qué partes decidió el LLM por su cuenta
Si entiendes las características de Claude, también mejora la eficiencia al validar, y mientras acumulas experiencia, se vuelve más fácil controlar la calidad
Cuando haces una funcionalidad grande con varios agentes, al final aparece el problema de que el tiempo de revisión crece muchísimo
Porque leer código de otra persona (o de una IA) es más difícil que escribirlo uno mismo
Tal vez se pueda cubrir con automatización de tests, pero es difícil confiar por completo
Dejo claro el alcance, los tests y el plan de documentación, y aplico bots de code review (Sourcery, CodeRabbit, Codescene) junto con reglas de linting fuertes
También uso BDD, property testing, tests e2e, auditoría de código y hasta tests de mutation/fuzzing
La ventaja del agentic coding es que te libera tiempo para dedicarlo a este tipo de control de calidad
Estoy probando despliegues graduales con enfoques como 100 PRs a day
Si divides bien el trabajo y confías en los tests, también se aligera la revisión de código generado por IA
Reviso los casos de prueba con más cuidado y cierro el code review rápido
No corro varios agentes en paralelo, pero igual mi productividad sí mejoró claramente gracias a la IA
Si el proceso de escribir PRs se automatiza por completo, se pierde una oportunidad de autoverificación
A mí me pasaba mucho que, al escribir la descripción del PR, descubría rarezas en mi propio código
Ese momento de explicarlo en inglés era el último sanity check
Gracias al sistema de worktrees cambió más fácil hacer cambio de contexto, pero al mismo tiempo aumentó el cansancio mental
Si lo divides en unidades pequeñas y mantienes ciclos de revisión cortos, es más fácil controlar la calidad
Lo bueno es poder volver al día siguiente sin romper mi flujo y encontrar que ya hubo avance
Soy escéptico ante la idea de que Claude escriba código de alta calidad por sí solo
En la práctica hacen falta múltiples rondas de feedback y correcciones, y manejar varias tareas en paralelo al mismo tiempo termina siendo ineficiente
Claude Code es revolucionario como herramienta de aprendizaje, pero la calidad del código que genera es irregular
Mientras aprendía Flutter/Dart, estudié preguntándole conceptos a Claude, y pude hacer una app en una semana sin usar libros
Se siente como una enciclopedia interactiva
A preguntas como “¿cuál es la forma idiomática de hacer X en este lenguaje?” responde al instante con algo útil
Pero más que algo que cambia el mundo, es simplemente una herramienta muy buena
Pero el marketing excesivo está teniendo efectos negativos en toda la economía
También preocupa que, por la ilusión de que la IA reemplazará empleos, la gente joven esté renunciando a ciertas carreras
Se mencionó que “después de cambiar la build a SWC, el reinicio del servidor bajó a menos de 1 segundo”,
SWC significa Speedy Web Compiler y es una herramienta que transpila rápido sin hacer type checking
La documentación de NestJS explica lo mismo
Usar LLM no significa que haya que presumir que la productividad explotó
Si todos usan las mismas herramientas, lo único que sube es la línea base
Además, si el código generado por IA en gran volumen no se revisa bien, la calidad a largo plazo queda en duda
Los LLM sí aumentan la productividad, pero medir eso con una gráfica de cantidad de commits no tiene sentido
Es tan absurdo como juzgar calidad por LOC
Yo escribo el código directamente para entenderlo, y Claude me ayuda mucho como compañero para descomponer tareas y revisar
La verdadera productividad es la capacidad de reemplazar código complejo por abstracciones simples