Qué hacía antes un desarrollador y qué tiene que hacer ahora con agentes de IA

He trabajado de forma intensiva con agentes de codificación en repositorios reales. Esa experiencia ha cambiado dónde pongo el esfuerzo: puedo delegar partes de la implementación, pero dedico más atención a entender qué hace el sistema, qué resultado necesita el cambio y cómo voy a comprobarlo.

Me ha ocurrido con cambios de autorización que parecían sencillos. Se protegía la acción visible en la interfaz y la ruta principal de la API, pero la misma operación también podía ejecutarse desde una tarea programada, una importación o una herramienta administrativa. Si reduzco el requisito a «oculta este botón», puedo dejar abierto el flujo que de verdad necesitaba proteger.

Por eso, cuando explico qué ha cambiado en mi trabajo, no lo resumo en «saber pedirle cosas a la IA». Para trasladar correctamente un problema técnico necesito entenderlo y reconocer cuándo una solución aparentemente razonable introduce un error, incumple una restricción o complica el mantenimiento. La mayor parte de mi experiencia la he adquirido con Claude Code; la cuento como experiencia propia, no como una comparación universal entre herramientas o equipos. En este artículo describo con más detalle lo que he aprendido al trabajar con agentes.

En mi caso, la programación manual puede ocupar menos tiempo en algunas tareas. El análisis, el diseño y la verificación adquieren más peso en la relación con el agente, aunque siempre hayan formado parte del oficio.

Lo que he cambiado en mi forma de trabajar

Al principio me interesaba, sobre todo, aprender a pedir mejor. Pensaba que, con suficiente contexto e instrucciones, el agente acabaría comportándose como un desarrollador muy rápido al que bastaba con asignar tareas. Con el tiempo vi que el reto no era conseguir más código, sino controlar lo que ocurre antes, durante y después de cada cambio.

Ahora empiezo por pedirle que reconstruya el funcionamiento actual. Reviso el mapa de actores, estados, reglas e integraciones antes de autorizar cambios. Si la interpretación está mal, prefiero detectarlo en el análisis y no después de modificar varios archivos. También empiezo con un caso pequeño y comprobable; si el enfoque funciona, lo amplío. Así puedo delegar más implementación sin perder de vista qué estoy aceptando.

Cuando una autorización tiene más de un camino

En los cambios de autorización que he trabajado, primero reconstruyo todos los caminos por los que puede ejecutarse la operación. Después compruebo qué actores y restricciones afectan a cada uno. Pedir al agente que empiece por la pantalla visible habría dejado fuera parte del requisito.

El contexto que antes aplicaba de memoria tengo que hacerlo visible

En un repositorio pueden quedar decisiones que no siempre están documentadas: por qué existe una excepción, qué integración depende de un comportamiento antiguo o qué módulo está pendiente de sustituirse. Las trato como preguntas que debo resolver si afectan al cambio. Al delegar, tengo que hacer consultable ese contexto.

Las instrucciones del repositorio y la documentación de arquitectura me ayudan cuando describen el sistema real y me permiten localizar las restricciones relevantes para cada cambio. Una indicación genérica como «mantén la compatibilidad» me deja demasiado por decidir; necesito señalar qué interfaz consumen otras aplicaciones, qué comportamiento debe conservarse y dónde están las pruebas que lo comprueban.

También reviso si ese contexto sigue vigente. Una instrucción desactualizada puede llevar al agente a respetar una decisión que ya no se aplica o a modificar un componente que debía conservarse.

Verificar exige entender lo que se ha construido

Delegar la escritura no me exime de leer el código. Tengo que seguir la implementación, entender sus dependencias y valorar sus consecuencias. También reviso las pruebas: si el agente interpreta mal el requisito y genera la solución y las pruebas desde esa misma interpretación, puede dejar un conjunto coherente que compruebe el comportamiento equivocado.

En el caso de la autorización, no me basta con comprobar que la ruta principal devuelve el permiso correcto. Recorro también las tareas programadas, las importaciones y las herramientas administrativas que pueden ejecutar la operación. Los criterios de aceptación me sirven de referencia: contrasto el cambio con lo que debía ocurrir, además de comprobar que el código compila y que las pruebas se superan.

La capacidad de desarrollo depende también de lo que se puede revisar

En mi experiencia, si genero cambios más deprisa de lo que puedo validarlos, acumulo trabajo pendiente de revisión. Producir más código no significa que haya terminado más mejoras utilizables.

Al decidir cuánto delego, ajusto el tamaño del encargo, reservo tiempo para comprobarlo y evito acumular cambios que todavía no puedo integrar. La autonomía que doy al agente depende del alcance del trabajo y de los medios que tengo para verificarlo.

Mi responsabilidad sigue abarcando todo el recorrido, desde entender la necesidad hasta incorporar una solución que funcione dentro del producto. Con agentes puedo ejecutar menos pasos personalmente, pero necesito saber qué se ha hecho en mi nombre y por qué acepto el resultado.

Esta distinción también afecta a la organización: repartir licencias de IA no transforma por sí solo la forma de trabajar. En mi experiencia, aumentar la capacidad de desarrollo exige poder analizar, revisar e integrar el trabajo que delego.