IA y automatización

De revisar código a convertir el criterio: apuntes sobre el trabajo diario con agentes

¿Qué cambia con los agentes de programación en el día a día? Quizá la habilidad más útil sea la que nadie ha aprendido: convertir en estructura duradera las decisiones que repites.

— Nodal Studio

Ilustración geométrica plana en naranja, salvia y lavanda: unas líneas que recuerdan a un circuito unen bloques y nodos, un pequeño robot se asoma tras un muro oscuro y un monitor muestra líneas de código.

¿Qué cambia de verdad en la cadena de producción cuando los agentes de programación pasan a formar parte del trabajo diario? Pues puede que la habilidad más útil acabe siendo una para la que nadie se ha formado.

La literatura de 2026 sobre flujos de trabajo ha convergido en gran medida en un único relato: el papel del desarrollador pasa de escribir código a dirigirlo, revisarlo y verificarlo. Andrej Karpathy, que acuñó el término «vibe coding» a principios de 2025, actualizó el planteamiento con la expresión «agentic engineering», en la que el desarrollador ejerce de supervisor más que de autor; las encuestas del sector publicadas hasta mediados de 2026 indican que una amplia mayoría de los desarrolladores profesionales ya usa agentes de programación al menos una vez por semana: el 90 % en la encuesta de JetBrains de 2026. Es cierto hasta cierto punto, pero también superficial: describe el cambio sin afrontar el problema con el que de verdad se topan los profesionales, que es que el artefacto que se revisa se ha vuelto a la vez más grande y más seguro de sí mismo cuando se equivoca.

Ese problema ya tiene nombre en el debate que empieza a tomar forma: la paradoja de la revisión de código. Cuando un agente genera no solo la implementación, sino también sus tests y su documentación, los puntos de anclaje tradicionales del revisor se erosionan: los tests pueden ser sondas de observación en lugar de tests de regresión con abundantes aserciones (un patrón señalado en análisis de tests escritos por agentes en trayectorias de SWE-bench), y la documentación describe lo que ha hecho el agente, no lo que tú querías. Las propias pautas de Anthropic para Claude Code responden a esto anteponiendo la verificación al diálogo: la práctica más rentable, sostiene Anthropic, es dar al agente una forma de comprobar su propio trabajo —tests ejecutables, comandos de lint, comparaciones que devuelven éxito o fallo—, porque sin criterios de éxito verificables el agente produce código que parece correcto y a menudo no lo es.

Plantearlo en términos de presupuesto de riesgo no es una simple metáfora. Responde a una asimetría real: el criterio de un ingeniero humano sobre lo que no merece la pena hacer es tácito, circunstancial y difícil de explicitar, mientras que un agente optimiza hacia un máximo teórico de exactitud porque no tiene ninguna representación de lo que cuesta el esfuerzo: más superficie, más complejidad, más carga de revisión. El plan en tres niveles (mínimo / razonable / reescritura completa) es un mecanismo ligero para hacer explícito ese presupuesto en la fase de planificación, y encaja con la recomendación documentada de separar de la implementación una fase de planificación de solo lectura.

La corriente más radical de la literatura de 2026 cuestiona la premisa sobre la que descansa todo esto. Una línea de argumentación (Cao, «Agentic Software: How AI Agents Are Restructuring the Software Paradigm», publicado inicialmente como «The End of Software Engineering») sostiene que, en los sistemas plenamente agénticos, el código deja de ser el soporte de la lógica de decisión y se convierte en una herramienta efímera, que se genera y se desecha dentro de un bucle de razonamiento impulsado por un LLM. Si el código es desechable, el impulso mismo de blindar una sentencia SELECT que volverás a generar la semana que viene se disuelve en parte; lo que merece protección ya no es la implementación, sino la especificación y los invariantes que hay detrás. Una corriente paralela (recogida en trabajos como «Skills for the Future Software Profession», de Roychoudhury, Kang y Ray) argumenta que, a medida que los LLM automatizan la búsqueda de demostraciones, el cuello de botella de la verificación formal se desplaza de demostrar la corrección a inferir la especificación adecuada, lo que convierte la especificación, y no el código, en el artefacto fundamental; y advierte de que las especificaciones inferidas se desvían de unas implementaciones en constante evolución y exigen comprobaciones continuas de coherencia.

La conversión en gobernanza, el concepto en el que apoyamos nuestra conclusión, procede de James C. Davis y sus colegas: primero en un estudio de caso de 12 semanas, «Cheap Code, Costly Judgment» (julio de 2026), y después en su marco Model-Based Agentic Software Engineering (MAGE) (agosto de 2026). La tesis es precisa: la implementación agéntica a gran velocidad saca a la luz clases recurrentes de fallos estructurales, y el criterio de ingeniería sostiene esa velocidad al convertir esos fallos en mecanismos de gobernanza duraderos. Es la jugada con mordiente, porque transforma determinadas lecciones en estructura de ingeniería duradera para que el trabajo futuro las herede. La palabra «conversión» importa aquí: el criterio es un activo efímero que se usa una vez y se pierde; la gobernanza es la forma duradera en la que se convierte; y, a medida que esa estructura se acumula y abarata el trabajo futuro, pasa a ser lo que MAGE llama capital de ingeniería: estructura duradera que reduce el coste o la incertidumbre del trabajo futuro gracias a la reutilización. Trabajos independientes sobre la fiabilidad de la ingeniería de software agéntica (por ejemplo, «Agents as Software», de Barke y Murali) llegan a lo mismo desde el ámbito de los lenguajes de programación: replantean el comportamiento de los agentes como algo que hay que especificar sobre trazas y estados, comprobar antes del despliegue y monitorizar en tiempo de ejecución, lo que en la práctica equivale a aplicar la conversión en gobernanza a los propios agentes.

La consecuencia práctica para un estudio como el nuestro es que cambia dónde invertimos el esfuerzo. Revisar más rápido lo que producen los agentes es una rueda de hámster. Lo que sí genera intereses es tratar cada comentario de revisión recurrente como un diagnóstico: el acto reflejo del borrado de la tabla delata, en realidad, una especificación que falta; nunca declaraste que ese invariante importara, así que deja de volver a discutirlo en cada revisión y, o bien codifícalo como un control, o bien decide, de una vez y de forma explícita, que no importa. La habilidad escasa y duradera ya no es escribir código, ni siquiera revisarlo, sino enunciar con precisión lo que tiene que ser cierto y convertir las decisiones que repites una y otra vez en una estructura que el sistema mantiene por ti. El riesgo que sigue abierto, y que señalan los mismos investigadores, es la deriva de las especificaciones: este capital se deprecia, y mantener las especificaciones coherentes con unas implementaciones que cambian deprisa es el próximo cuello de botella que nos espera. Y ese es el problema en el que preferimos estar trabajando.

Fuentes

Volver a la lectura rápida (5 min).

Artículos relacionados