La falsa velocidad de los Coding Agents
El mundo de los Coding Agents nos ha dado una herramienta tremendamente potente.
A todos los que pagamos una suscripción a alguna de estas plataformas se nos ofrece una promesa muy atractiva: desarrollar más rápido, resolver tareas complejas en menos tiempo y apoyarnos en un asistente que parece capaz de producir código a un ritmo imposible para una persona.
Pero aquí es donde creo que empieza el problema.
Esa sensación de velocidad puede llevarnos a dar por hecho que lo que nos devuelve un agente de IA se equipara automáticamente a lo que haría un desarrollador senior con años de experiencia.
Y, sinceramente, creo que eso queda bastante lejos de la realidad.
¿Cuántas veces os ha pasado...?
El otro día hice unos cambios en uno de mis side projects.
Le pedía que hiciese ciertos cambios en uno de los módulos que ya tenía cubiertos con tests unitarios y con todos sus edge cases definidos.
Pues bien, los tests empezaron a fallar y, al pedirle que solucionase los tests, lo que hacía era modificar la implementación para que, sin tocar los tests, estos pasasen en verde...
Este tipo de problemas son los que refuerzan mi idea de que hay que invertir algo de tiempo en confeccionar un flujo robusto para que estos casos no sucedan.
Generar código rápido no es lo mismo que desarrollar software
Un Coding Agent puede generar código muy rápido.
Puede proponer soluciones.
Puede leer parte de nuestro contexto.
Puede ayudarnos a explorar alternativas.
Incluso puede ejecutar tareas completas si le damos las herramientas adecuadas.
Pero eso no significa que entienda el producto como lo entiende una persona.
No significa que conozca todos los compromisos técnicos del proyecto.
No significa que tenga criterio arquitectónico real.
No significa que sepa cuándo una solución es mantenible a largo plazo.
Y, desde luego, no significa que podamos dejar de pensar.
La IA necesita que no seamos vagos
Después de usar este tipo de agentes durante bastante tiempo, mi sensación es que la IA necesita que no seamos vagos.
Necesita contexto.
Necesita restricciones.
Necesita buenos prompts.
Necesita ejemplos.
Necesita límites.
Necesita que sepamos exactamente qué queremos conseguir.
Pedirle a un agente que “implemente una feature” sin más contexto es muy parecido a entrar en una biblioteca y pedir:
Quiero un libro interesante.
Puede que te recomiende algo útil.
Puede que acierte parcialmente.
Pero también puede que la respuesta no tenga nada que ver con lo que realmente necesitabas.
En cambio, si pides:
Quiero un libro de ciencia ficción, basado en galaxias y naves espaciales, en español, y que no haya leído antes teniendo en cuenta esta lista de libros.
Las posibilidades de obtener una buena recomendación aumentan mucho.
Con los Coding Agents ocurre algo muy parecido.
Cuanto mejor defines el problema, mejor puede ayudarte la IA
Cuanto mejor defines el problema, mejores opciones tienes de obtener una respuesta útil.
Pero eso implica trabajo.
Implica criterio.
Implica conocer tu proyecto.
Implica saber qué restricciones son importantes.
Implica entender qué partes del resultado puedes aceptar y cuáles deberías cuestionar.
Y ahí es donde creo que estamos empezando a confundir velocidad con productividad.
Que algo se genere rápido no significa que esté bien.
Que algo compile no significa que sea correcto.
Que algo pase algunos tests no significa que sea mantenible.
Que una solución parezca elegante no significa que encaje con la arquitectura de tu producto.
La velocidad también puede esconder costes
La IA puede acelerar mucho algunas partes del desarrollo, pero también puede trasladar el coste a otras fases:
- Revisión.
- Debugging.
- Testing.
- Refactorización.
- Deuda técnica.
- Reescritura completa.
Por eso creo que la conversación no debería ser simplemente:
¿Qué agente de IA usas?
Sino más bien:
¿Cómo estás trabajando con ese agente?
¿Qué contexto le das?
¿Qué restricciones tiene?
¿Qué herramientas puede usar?
¿Cómo validas lo que genera?
¿Dónde entra el criterio humano?
¿Qué partes del proceso no estás dispuesto a delegar?
Usar IA no es lo mismo que hacer ingeniería con IA
Para mí, esa es la diferencia entre usar IA como una máquina de escupir código y usarla como una herramienta real de ingeniería.
Un agente de IA puede ser una ayuda brutal, pero solo si lo rodeamos de un buen sistema de trabajo:
- Buenas especificaciones.
- Buen contexto.
- Restricciones claras.
- Validaciones automáticas.
- Tests.
- Revisión humana.
- Criterio técnico.
- Límites bien definidos.
Y ahí es donde empieza a tener sentido hablar de Harness Engineering.
Conclusión
La pregunta importante no es si usamos o no usamos Coding Agents.
La pregunta importante es:
¿Estamos usando estos agentes para pensar mejor, o para dejar de pensar?
Porque si solo buscamos velocidad, probablemente acabaremos generando más código.
Pero no necesariamente mejor software.