Qué hacía antes un desarrollador y qué tiene que hacer ahora con agentes de IA
Qué cambia en el trabajo del desarrollador cuando delega parte de la implementación en agentes de IA: análisis, contexto, programación, pruebas y responsabilidad.
Cuando un agente puede explorar un repositorio, modificar archivos y ejecutar pruebas, cambia la forma de desarrollar software. El profesional puede delegar una parte de la implementación que antes hacía manualmente, pero sigue teniendo que entender la petición, decidir cómo encaja en el sistema y comprobar si el resultado resuelve el problema.
Por eso, describir su nuevo trabajo como «saber pedirle cosas a la IA» se queda corto. Para trasladar correctamente un problema técnico necesitas entenderlo. También necesitas reconocer cuándo una solución aparentemente razonable introduce un error, incumple una restricción o complica el mantenimiento.
La programación manual puede ocupar menos tiempo. 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.
Qué cambia en el trabajo cotidiano
Antes de los agentes, un desarrollador ya aclaraba requisitos, diseñaba soluciones, escribía pruebas y revisaba código. El reparto variaba según su experiencia, el producto y la organización. Sería engañoso contar esta evolución como si hasta ahora se hubiera limitado a escribir líneas de código.
Lo que cambia es cuánto puede delegar y qué necesita hacer para que esa delegación funcione.
| Área | Antes, con una implementación principalmente manual | Ahora, al trabajar con agentes |
|---|---|---|
| Entender la necesidad | Aclarar requisitos y detectar contradicciones antes de implementar. | Resolver esas mismas dudas y hacerlas explícitas antes de que el agente avance sobre una suposición. |
| Analizar el sistema | Investigar el código y decidir dónde intervenir. | Orientar la investigación del agente, contrastar sus conclusiones y delimitar el cambio. |
| Diseñar la solución | Elegir arquitectura, componentes e interfaces. | Evaluar propuestas del agente y fijar las decisiones y restricciones que debe respetar. |
| Descomponer el trabajo | Dividir el desarrollo en tareas que pudiera implementar y revisar. | Preparar encargos con alcance, dependencias y resultados comprobables. |
| Programar | Escribir y modificar directamente buena parte del código. | Delegar parte de la implementación y editar personalmente cuando sea necesario. |
| Aportar contexto | Consultar documentación y apoyarse en el conocimiento acumulado del sistema. | Facilitar al agente ese conocimiento mediante instrucciones, documentación y referencias concretas al código. |
| Probar | Diseñar casos de prueba, implementarlos y ejecutarlos. | Definir qué debe demostrarse, delegar pruebas y comprobar que evalúan el comportamiento correcto. |
| Revisar | Examinar cambios propios y de otros desarrolladores. | Revisar también cambios generados por agentes, incluidos los que parecen correctos a primera vista. |
| Resolver errores | Formular hipótesis, localizar la causa y corregirla. | Contrastar el diagnóstico del agente y reconducirlo cuando encadena intentos sin resolver la causa. |
| Integrar y desplegar | Incorporar el cambio siguiendo los controles del producto. | Mantener esos controles y decidir si el resultado puede incorporarse y ponerse en producción. |
La diferencia aparece con claridad cuando una petición breve oculta decisiones que alguien tiene que tomar.
De una petición a un encargo que se pueda verificar
Imagina que una empresa pide añadir inicio de sesión corporativo a su plataforma de formación:
«Queremos que los empleados entren con su cuenta de empresa».
Un agente puede empezar a implementar una solución a partir de esa frase. Sin embargo, todavía faltan decisiones que afectan al funcionamiento del producto.
Puede haber empleados que ya tengan una cuenta con cursos completados. También puede haber alumnos externos que deban seguir entrando por otro procedimiento. Alguien tiene que decidir cómo se vinculan las identidades, qué ocurre con las cuentas existentes y qué acceso conserva cada persona.
Si esas condiciones quedan sin resolver, el desarrollador tendrá que descubrir después qué ha supuesto el agente y corregir lo que no corresponda.
Antes, muchas de estas dudas podían aparecer mientras el propio desarrollador escribía la integración. Con un agente capaz de modificar varios componentes en una sola intervención, conviene identificarlas y documentarlas antes de delegar ese trabajo.
Un encargo más preciso establecería, por ejemplo, que los empleados deben acceder mediante el proveedor corporativo, que las cuentas existentes deben conservar su historial y que los alumnos externos deben mantener su acceso. A continuación habría que concretar el mecanismo de vinculación, las restricciones técnicas y los casos con los que se comprobará cada comportamiento.
El desarrollador puede pedir ayuda al agente para investigar esas cuestiones y comparar alternativas. Lo que necesita conservar es la capacidad de evaluar las respuestas y resolver las decisiones que afectan al producto.
El contexto que antes estaba en la cabeza debe poder consultarse
Un profesional que conoce una aplicación sabe cosas 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.
Al modificar personalmente el código, puede aplicar ese conocimiento sin escribirlo. Cuando delega, necesita facilitarlo de alguna forma.
Los archivos de instrucciones, las reglas del repositorio y la documentación de arquitectura ayudan a hacerlo. Su utilidad depende de que describan el sistema real y permitan localizar las restricciones relevantes para cada cambio.
Por ejemplo, una indicación genérica como «mantén la compatibilidad» deja demasiado por decidir. Resulta más útil identificar qué interfaz consumen otras aplicaciones, qué comportamiento debe conservarse y dónde están las pruebas que lo comprueban.
Esto exige mantener el contexto. 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 de código no elimina la necesidad de leerlo. El desarrollador tiene que poder seguir la implementación, entender sus dependencias y valorar sus consecuencias.
También debe examinar las pruebas. Si el agente interpreta mal un requisito y genera tanto la solución como sus pruebas a partir de esa interpretación, puede entregar un conjunto coherente que compruebe un comportamiento equivocado.
En el ejemplo del acceso corporativo, una prueba que confirme que una cuenta nueva consigue entrar no demuestra que un empleado conserve el historial de su cuenta anterior. Para detectar esa carencia hay que conocer el requisito y comprobar cómo se ha traducido a la implementación.
Por eso, los criterios de aceptación deben servir como referencia durante la revisión. El desarrollador necesita contrastar el resultado con lo que se pretendía conseguir, además de comprobar que el código compila o que las pruebas terminan correctamente.
La capacidad de desarrollo depende también de lo que se puede revisar
Si se generan cambios más deprisa de lo que se pueden validar, aumentará el trabajo pendiente de revisión. En esas condiciones, producir más código no implica entregar más mejoras utilizables.
Quien organiza el desarrollo tendrá que ajustar el tamaño de los encargos, reservar tiempo para comprobarlos y evitar que los cambios se acumulen sin integrar. La autonomía que se conceda al agente deberá guardar relación con el alcance del trabajo y con los medios disponibles para verificarlo.
El desarrollador, por su parte, necesita practicar una delegación que pueda supervisar: explicar el resultado esperado, aportar las restricciones y pedir evidencias suficientes para decidir si acepta el cambio.
Su responsabilidad sigue incluyendo todo el recorrido, desde comprender la necesidad hasta incorporar una solución que funcione dentro del producto. Con agentes, puede ejecutar menos pasos personalmente, pero tiene que saber qué se ha hecho en su nombre y por qué está dispuesto a darlo por válido.
Esta distinción también afecta a la organización: repartir licencias de IA no transforma por sí solo la forma de trabajar. Para aumentar la capacidad de desarrollo hay que poder analizar, revisar e integrar el trabajo que se delega.
Más de 22 años construyendo y evolucionando plataformas de aprendizaje en producción.
Sobre Alberto Lara y su trayectoria profesional →Lecturas recomendadas
Lo que he aprendido trabajando con agentes en desarrollo de software
La experiencia de trabajar con agentes en repositorios reales: errores, decisiones y límites.
Qué decisiones de arquitectura deja abiertas una spec
Por qué describir un comportamiento no resuelve todas las decisiones de implementación.