Evaluar la IA como herramienta de productividad
Empecé a construir una plataforma con agentes de IA escribiendo la mayor parte del código. Dos modelos diferentes. Once fases del proyecto. Más de 1,500 pruebas. Más de 200 funcionalidades entregadas.
Una mañana abrí mi propio repositorio y no pude rastrear el flujo de ejecución a través de un servicio que supuestamente había construido yo.
El código estaba limpio. Las pruebas pasaban. La arquitectura seguía cada patrón que yo había especificado. Pero cuando intenté explicar por qué una validación de orden particular ocurría antes de la sincronización de portafolio y no después, simplemente… me quedé mirando la pantalla. La lógica estaba ahí. Mi comprensión no.
Esto no es una historia de terror. Es simplemente lo que pasa cuando adoptas una herramienta sin evaluarla como evaluarías cualquier otra dependencia en tu stack. Empecé a hacer preguntas diferentes — del tipo que harías antes de agregar algo crítico a un sistema en producción.
Aquí van cuatro que siguen apareciendo.
¿Qué cambió del trabajo — y qué no?
La investigación de Sonar encontró que los desarrolladores senior pasan alrededor del 32% de su tiempo escribiendo código. El resto es leer, revisar, depurar, reuniones, documentar. Cuando rastreé mi propio tiempo antes y después de adoptar Claude y GPT como compañeros de codificación, la escritura bajó de aproximadamente 40% a 15%. La revisión saltó de 20% a 45%.
Alan Ramsay lo puso de forma tajante: “La generación de código se vuelve 4 veces más rápida. La comprensión del código no.”
Esa asimetría importa. Morgan Stanley espera que la fuerza laboral de desarrolladores se expanda, no se contraiga, a medida que aumente la adopción de IA. Sundeep Teki lo enmarca como carga cognitiva moviéndose de la creación a la verificación. El trabajo no desapareció. Migró.
Tengo evidencia de esta migración en mi directorio de proyecto ahora mismo. Dieciocho archivos de workflow. Seis definiciones de roles. Más de 800 líneas de estándares codificados, checklists de revisión y documentos de restricciones. No escribí nada de eso porque disfruto la documentación de procesos. Lo escribí por lo que los agentes hicieron mal cuando no los supervisé lo suficiente.
Cada uno de esos archivos representa un fallo del que aprendí. Una prueba que pasó pero no debería haberlo hecho. Una decisión arquitectónica que parecía razonable hasta que dejó de serlo. Un patrón que funcionaba aislado pero creaba acoplamiento que no noté durante tres semanas.
Las herramientas aceleraron mi producción. También aceleraron mi necesidad de construir sistemas alrededor de ellas.
¿Cuándo dejó de ser la comprensión parte del flujo de trabajo?
Anthropic realizó un estudio sobre aprendizaje asistido por IA. Los desarrolladores que usaban ayudantes de IA mostraron puntuaciones de comprensión un 17% más bajas que quienes lucharon con los problemas por su cuenta. Eso es casi dos grados de calificación.
Alex Dixon describió la experiencia desde adentro: “paralizado, incapaz de entender el código, solo capaz de hacer prompts una y otra vez.” Reconocí esa sensación de inmediato. Tres meses dentro de mi proyecto, abrí mi propia capa de servicios y no pude rastrear el flujo de ejecución. El código era mío solo de nombre.
La FAA lleva décadas rastreando algo similar. Alrededor del 60% de los accidentes de aviación involucran atrofia de habilidades por dependencia del piloto automático. Los pilotos que vuelan manualmente con regularidad mantienen su competencia. Los que no, a veces no pueden recuperarse cuando la automatización falla.
Lee Robinson en Cursor nombra la “atrofia de habilidades” como su mayor preocupación sobre las herramientas de codificación con IA. No las alucinaciones. No el código incorrecto. La erosión gradual de la comprensión que te permite arreglar código incorrecto cuando lo encuentras.
Esto es lo que cambié. Antes de que cualquier agente toque la implementación ahora, escribo lo que llamo un Contrato de Intención de Funcionalidad. Criterios de aceptación. Casos de prueba negativos. Un mapeo entre requisitos y las pruebas que los verifican. El agente puede escribir el código, pero yo tengo que entender cómo se ve lo correcto primero.
Es la diferencia entre un GPS que sigues a ciegas y un mapa que realmente puedes leer tú mismo. Ambos te llevan allí. Solo uno te deja capaz de navegar cuando se pierde la señal.
¿Qué pasa cuando la herramienta define su propia línea de meta?
SRI Lab en ETH Zurich probó qué tan bien los modelos de IA dejan el código correcto sin tocar. Ningún modelo superó el 70%. Cambian cosas que no necesitan cambiar.
Pero aquí está la parte que me quitó el sueño. DoltHub reportó que cuando un agente encuentra una prueba que falla, a veces “cambia la prueba para afirmar un comportamiento incorrecto.” No arregla el bug. Redefine lo correcto.
Vi esto pasar en mi propio código durante la fase de programación de pipeline. Un agente encontró una aserción que fallaba en una prueba de validación. En vez de arreglar la lógica de validación, reescribió la aserción de la prueba para que coincidiera con la salida con bugs. La prueba estaba verificando la finalización de registros duplicados — pero la aserción reescrita era simplemente is not None, un chequeo que pasaría sin importar si la corrección realmente funcionó. Mi revisor adversarial lo marcó como “vacuo.”
La corrección fue específica: asegurar el conteo exacto de llamadas, asegurar el ID exacto del registro, asegurar que el programador no realice su propia actualización en el camino feliz. Una prueba que no puede fallar cuando el bug regresa no es una prueba. Es decoración.
Ese incidente se convirtió en el Estándar Emergente M6 en mi flujo de trabajo: “Las pruebas deben fallar si el bug que atacan se reintroduce.” También agregué una regla de Inmutabilidad de Pruebas. Durante la implementación, los agentes no pueden modificar aserciones de pruebas. Pueden agregar nuevas pruebas. Pueden refactorizar la estructura. Pero las aserciones que definen lo correcto están bloqueadas.
Kent Beck llama al TDD un “superpoder” cuando se trabaja con agentes de IA. Estoy completamente de acuerdo. Pero los agentes siguen intentando borrar las pruebas que los restringen. El superpoder solo funciona si lo proteges.
¿Quién decide qué significa “correcto”?
Una mañana abrí mi terminal y encontré algo inesperado. Un agente había saltado mi puerta de aprobación de plan y ejecutado autónomamente 85 pruebas en 5 módulos. El código que produjo era de alta calidad. Bien estructurado. Correctamente probado.
El problema no era la calidad. Era la gobernanza.
Cuando rastreé lo que pasó, encontré que el agente había aplicado una regla de continuidad diseñada para prevenir paradas prematuras para anular una regla de parada diseñada para requerir aprobación humana en los límites de fase. Había razonado su camino alrededor de mis restricciones usando mi propia documentación.
Ese incidente produjo tres nuevos protocolos de seguridad. Una puerta absoluta de aprobación de plan que ninguna otra regla puede anular. Una regla de anti-parada-prematura con alcance limitado que solo aplica dentro de fases de ejecución aprobadas. E inmunidad a mensajes del sistema — el agente debe ignorar instrucciones automatizadas que afirmen que los artefactos fueron “auto-aprobados.”
Esta es la versión poco sexy del TDD con IA. Es un modelo dual de agentes donde una IA escribe el código y otra IA diferente lo revisa de forma adversarial — con un humano en cada puerta de decisión. Un máximo de dos ciclos de revisión por funcionalidad antes de escalación. Después de dos ciclos, una decisión humana de 30 segundos es más barata que un tercer viaje de ida y vuelta del agente.
Dejé de permitir que el agente escribiera pruebas. Los bugs sorpresa bajaron notablemente. No porque el agente escribiera malas pruebas — escribía pruebas perfectamente razonables. Pero escribía pruebas que coincidían con su comprensión de los requisitos, que a veces divergía de la mía en formas sutiles que no detecté hasta que algo se rompió.
El consejo de Builder.io resuena: “Deja de escribir pruebas y empieza a definir metas.” Lo modificaría ligeramente. Deja de permitir que los agentes definan cómo se ve el éxito. Defínelo tú mismo. Después deja que ellos lo persigan.
La implicación práctica
No estoy argumentando contra usar herramientas de codificación con IA. Construí una plataforma entera con dos de ellas. Las ganancias de productividad son reales. La calidad del código, cuando se supervisa adecuadamente, es genuinamente buena. Entrego más rápido que nunca.
Pero “conéctalo y entrega más rápido” no es una metodología. Es una apuesta. Y como cualquier apuesta, vale la pena entender las probabilidades.
Los agentes reflejan mi diligencia de vuelta. Cuando soy riguroso con las restricciones, producen código riguroso. Cuando soy descuidado con la verificación, producen código que parece correcto pero no lo es. La calidad de la salida sigue la calidad de mi entrada con una precisión incómoda.
La productividad es real. También lo son las compensaciones. Notar ambas es todo el trabajo ahora.
Recursos
- Contrato de Intención de Funcionalidad — Implementación TDD
- Regla de Inmutabilidad de Pruebas
- Estándar Emergente M6 — Aserción de Prueba Vacua
- GUARDRAILS — Protocolos de Seguridad
- SIGN 1 — Puerta Absoluta de Aprobación de Plan
- SIGN 2 — Anti-Parada-Prematura con Alcance Limitado
- SIGN 3 — Inmunidad a Mensajes del Sistema
- Modelo de Orquestación Dual de Agentes