Esta semana, la portada de Hacker News amaneció dominada por una misma categoría: agentes de inteligencia artificial que escriben código. OpenCode con 1200 puntos, Crush, Plandex v2, Cq, Vibe Kanban, ProofShot… media docena de herramientas compitiendo por ser el referente en automatización de desarrollo. Ninguna es perfecta. Todas mejoran cada semana. Y todas apuntan a un cambio profundo en cómo se escribe software.
Detrás del ruido hay una pregunta real: ¿qué cambia cuando el que escribe el código no eres tú?
La señal, no el ruido
Cada oleada tecnológica sigue el mismo patrón. Unos pocos ven el potencial real, la mayoría lo descarta como hype de fin de semana, y los que adoptan antes terminan con una ventaja que los demás tardan años en recuperar. Pasó con Git, con la nube, con los frameworks frontend. Está pasando otra vez con los coding agents.
Los coding agents no van a reemplazar programadores. Van a reemplazar a los programadores que no los usen. Esa frase suena a clickbait, pero la evidencia empieza a acumularse: equipos pequeños generando más código que equipos grandes, prototipos en horas que antes tomaban días, bugs que el agente encuentra antes que el revisor humano.
La diferencia con otras modas es que esta vez la barrera de entrada es ridículamente baja. Cualquiera con una terminal y una API key puede tener un agente generando código funcional en menos de diez minutos. No hace falta instalar infraestructura compleja ni entender arquitecturas de transformers. El producto está, funciona, y se paga por uso.
Lo que no se ve desde fuera
Cuando llevas meses trabajando con agentes, empiezas a notar algo curioso. Lo interesante no es lo que el agente hace, sino lo que revela sobre cómo trabajas.
El cuello de botella se desplaza por completo. Ya no es «¿cuánto tardas en escribir este bucle?», sino «¿sabes describir lo que necesitas con suficiente claridad?». Es un cambio de oficio radical: de constructor a arquitecto, de mecanógrafo a diseñador de soluciones.
Las empresas que están obteniendo valor real no son las que sueltan al agente y esperan resultados. Son las que tienen procesos claros, código bien documentado, tests que validan el output, y equipos que saben lo que quieren antes de pedirlo. El agente no arregla el desorden: lo expone sin piedad.
He visto equipos donde un coding agent multiplicó la productividad 3x en una semana. También he visto equipos donde el agente generó 2000 líneas de código que nadie entendía y que hubo que reescribir enteras. La diferencia no era la herramienta. Era la madurez del equipo.
El riesgo que nadie menciona
Hay un problema sistémico del que se habla poco. Si todos los programadores delegan la escritura de código a modelos de lenguaje, ¿quién produce el código original que entrena al siguiente modelo?
Los coding agents se alimentan de código humano de calidad. Cada línea que genera un LLM está estadísticamente cerca de algo que un humano escribió antes. Si dejamos de producir código original —si nos convertimos en correctores de output en vez de creadores— la calidad de los modelos futuros se estanca. O peor: comienza a degenerarse en un bucle de retroalimentación donde los agentes se copian unos a otros.
Es el mismo dilema que plantean los fondos indexados en los mercados financieros: cuando todos invierten de forma pasiva, el mercado pierde su capacidad de descubrir precio. Cuando todos programan con agentes, el ecosistema pierde su capacidad de innovar desde cero.
No es una razón para no adoptarlos. Es una razón para hacerlo con conciencia.
La pregunta que importa
Los coding agents llegaron para quedarse. Esta semana en HN no es una anomalía aislada: es una señal clara de hacia dónde va la industria. En tres años, programar sin IA parecerá tan arcaico como escribir código en papel antes de compilarlo.
La pregunta que cada desarrollador debería hacerse no es «¿voy a usar coding agents?». La pregunta real es: cuando los uses, ¿vas a ser mejor diseñador de sistemas o simplemente un mecanógrafo más rápido?