Cuando el código se vuelve barato: qué hacer en la era del agentic coding
Si la IA ya puede escribir código rápido, la ventaja no está en programar más, sino en diseñar mejores sistemas, pruebas, criterios y procesos de mantenimiento.
Table of Contents(11 sections)
On This Page
Idea central
Los agentes de coding como Codex, Claude Code, Cursor y Kiro están bajando el costo de producir software. Ya pueden leer repositorios, modificar archivos, ejecutar tests, corregir errores y entregar cambios completos. Fallan, necesitan supervisión y todavía no reemplazan el criterio técnico, pero sí cambiaron la pregunta.
Antes preguntábamos: "¿puedo escribir este código?"
Ahora la pregunta importante es: "si el código es barato, qué parte del trabajo sigue siendo cara?"
La respuesta: intención, arquitectura, validación, seguridad, mantenimiento y criterio de producto. El código se abarató. Construir sistemas confiables no.
Esta guía adapta las ideas de Drew Breunig en "10 Lessons for Agentic Coding" al contexto de builders, solopreneurs y equipos pequeños que quieren usar IA para moverse más rápido sin crear software frágil.
1. Usa el código barato para aprender, no para acumular
Cuando generar una implementación cuesta menos, implementar deja de ser solo producción y se vuelve investigación. Puedes pedirle a un agente una versión simple, una versión robusta o un prototipo descartable para entender qué decisiones estaban ocultas.
Ese cambio es enorme. Antes, una especificación tenía que anticipar mucho porque construir era caro. Ahora puedes usar una primera implementación para descubrir dónde la idea estaba incompleta.
Ejemplo: quieres automatizar leads de WhatsApp hacia un CRM. En el brief parece fácil: recibir mensaje, extraer datos, guardar lead y avisar al equipo. Pero al construir aparecen las decisiones reales: audios, mensajes partidos, contactos duplicados, usuarios que piden humano, países distintos, datos obligatorios y permisos.
El código no solo ejecuta la idea. La interroga.
La regla práctica: no uses agentes solo para cerrar tickets. Úsalos para revelar decisiones que todavía no sabes formular.
2. Reconstruye más seguido, pero solo con contratos
Cuando escribir código era caro, reescribir era una decisión pesada. Hoy un agente puede rehacer un módulo en minutos u horas. Eso permite comparar enfoques en vez de discutir abstracciones: una versión más simple, otra más modular, otra más fácil de testear.
Pero reconstruir sin contratos produce movimiento, no progreso. Si no sabes qué comportamiento debe mantenerse, cada reimplementación puede romper algo distinto.
El contrato no tiene que empezar como una suite perfecta de tests unitarios. Para un equipo pequeño, puede ser un conjunto de validaciones end-to-end: si llega un mensaje con intención de compra, crea un lead; si falta email, pide confirmación; si el contacto existe, no lo duplica; si el usuario pide una persona, escala.
Ese tipo de contrato protege lo que importa: el comportamiento desde el punto de vista del producto. Te permite decirle al agente: "puedes cambiar la implementación, pero esto tiene que seguir siendo verdad".
La libertad de reconstruir depende de la calidad de tus pruebas. Sin pruebas, el código barato se convierte en deuda barata de crear y cara de entender.
3. Mantén sincronizados spec, tests y código
El desarrollo con agentes acelera una fuente clásica de deuda: la documentación queda vieja antes de que alguien la mire. El agente modifica código, ajusta pruebas, cambia flujos y la especificación original sigue diciendo otra cosa.
Breunig propone pensar en un triángulo: spec, tests y code. La spec explica qué queremos y por qué. Los tests validan si se cumple. El código implementa la decisión. Cuando una de las tres partes cambia, las otras dos tienen que revisarse.
Esto suena obvio, pero se vuelve crítico cuando producir cambios cuesta poco. La deuda no aparece solo porque una línea esté mal. Aparece cuando el sistema pierde coherencia.
También por eso documentar intención importa más que documentar instrucciones. Un agente puede ver una validación extra y eliminarla por parecer redundante, sin saber que evita leads basura. Puede simplificar un flujo que parece raro, sin saber que existe por una restricción legal, comercial o de soporte.
No necesitas una enciclopedia. Un SPEC.md, DECISIONS.md o AGENTS.md bien mantenido puede alcanzar. Lo importante es capturar decisiones que un agente podría revertir por no entender el contexto: por qué se priorizó claridad sobre performance, por qué no se automatiza la respuesta final, por qué cierta tabla existe aunque parezca duplicada.
Una práctica útil al cerrar cada cambio: pedirle al agente un resumen de decisiones nuevas, comportamiento cambiado, tests que deberían existir y documentación afectada. Luego tú decides qué queda. El agente detecta gaps; el criterio sigue siendo humano.
4. Busca lo difícil: ahí está tu ventaja
El código barato elimina mucho trabajo mecánico: boilerplate, CRUD, refactors controlados, componentes repetitivos, migraciones simples, scripts internos e integraciones comunes.
Eso libera tiempo, pero también expone más rápido lo difícil: elegir el problema correcto, diseñar un flujo usable, definir permisos, proteger datos, pensar fallos, mantener observabilidad, decidir qué no automatizar y entender qué parte será costosa de cambiar después.
Cualquiera puede pedir una pantalla. Menos personas pueden decidir si esa pantalla debería existir, qué caso límite rompe el negocio, qué comportamiento necesita consistencia y qué decisión será cara de revertir en seis meses.
Para builders, la ventaja ya no está en producir más líneas. Está en saber dónde poner atención.
Cuando el agente resuelve lo fácil, no uses esa velocidad para agregar complejidad por reflejo. Úsala para llegar antes a las preguntas importantes: qué pasa si falla una dependencia, qué dato sensible toca el flujo, qué necesita entender un humano para confiar en esta automatización, qué parte no debería automatizarse todavía.
5. Automatiza tareas repetibles, no decisiones confusas
Agentic coding invita a automatizar todo: reviews, tickets, tests, deploys, changelogs, documentación, subagentes y flujos de control. Algunas automatizaciones son excelentes. Otras solo esconden complejidad detrás de otra capa.
La automatización buena reduce carga cognitiva. La mala crea un sistema opaco donde nadie sabe quién decidió qué, dónde falló algo o cómo apagarlo.
La pregunta no es "¿puedo automatizar esto?". La pregunta es "¿este proceso ya está claro manualmente?". Si todavía no sabes cómo revisar bien una feature, no automatices la review completa. Empieza por checks concretos: typecheck, tests, validación de links, screenshots, variables de entorno, logs esperados y revisión básica de permisos.
La automatización debe convertir criterio en proceso. No debe reemplazar criterio que todavía no existe.
6. El costo real aparece después del merge
El riesgo del código barato es que baja la fricción para decir que sí: otra feature, otra integración, otro flujo personalizado, otro microservicio, otra automatización interna.
Pero cada pieza que vive en producción trae soporte, bugs, datos, permisos, migraciones, documentación, usuarios confundidos, alertas y decisiones futuras condicionadas.
La pregunta madura no es: "¿puede el agente construirlo?"
La pregunta es: "¿queremos ser responsables de esto después de que exista?"
Antes de aceptar código generado por IA, revisa si sabes quién lo mantiene, cómo se detecta una falla, qué comportamiento principal está protegido, qué datos toca, qué permiso necesita, cómo se desactiva y qué documento explica la intención.
Si no puedes responder, probablemente no necesitas más código. Necesitas más claridad.
Workflow práctico para construir con agentes sin perder control
Empieza cada cambio con una intención breve: problema, usuario, resultado esperado, restricciones, riesgos y qué no debe cambiar. Si no puedes escribir eso, el agente tampoco va a tener una buena dirección.
Antes de editar archivos, pide un plan: qué tocaría, por qué, qué riesgos ve, qué pruebas recomienda y qué dudas necesita resolver. Esto evita que el agente convierta ambigüedad en cambios silenciosos.
Implementa en ciclos pequeños. Tres cambios revisables suelen ser mejores que una modificación gigante y opaca. La velocidad de los agentes no justifica perder legibilidad del proceso.
Valida comportamiento, no solo compilación. Build, lint o typecheck son el piso. Encima necesitas una prueba real del flujo: fixture de datos, test end-to-end, screenshot, prueba manual guiada o comparación antes/después.
Al cerrar, actualiza spec y decisiones. Si cambió el comportamiento, la documentación tiene que reflejarlo. Si apareció una deuda aceptada, déjala visible. Si el prototipo solo sirvió para aprender, descarta el código y conserva la decisión.
Qué cambia para emprendedores y equipos pequeños
Para AIPaths, esta tendencia importa porque baja una barrera histórica: la implementación. Un emprendedor puede prototipar más rápido. Una persona técnica puede multiplicar output. Una persona no técnica puede acercarse más al producto real sin esperar meses.
Pero "usar IA para programar" se va a volver commodity. La ventaja será tener un sistema de trabajo donde la IA pueda producir sin destruir coherencia: mejores briefs, mejores specs, mejores pruebas, mejor documentación, mejor revisión y mejor mantenimiento.
El mercado se va a llenar de software generado rápido. Mucho será frágil, difícil de mantener o superficial. La oportunidad está en usar código barato para llegar más rápido a software útil, confiable y bien pensado.
Conclusión
Agentic coding no elimina el trabajo del builder. Lo desplaza.
Antes, gran parte del esfuerzo estaba en convertir una idea en código. Ahora, cada vez más, el esfuerzo está en convertir intención en sistemas verificables.
Cuando el código es barato, escribir código deja de ser el centro del juego. El centro pasa a ser saber qué construir, cómo validarlo, cómo mantenerlo y cuándo decir que no.
Esa es la habilidad que más va a valer.
Fuentes y lecturas recomendadas
- Drew Breunig, "10 Lessons for Agentic Coding"
- Drew Breunig, "The Rise of Spec Driven Development"
- Drew Breunig, "Keeping the Spec Driven Development Triangle in Sync"
- LangChain, "Agentic Engineering: How Swarms of AI Agents Are Redefining Software Engineering"
- Google Cloud, "What is agentic coding?"