La inteligencia artificial está cambiando la forma de desarrollar software. Ya no se trata solamente de pedirle a un modelo que escriba una función o explique un error. Los agentes de código pueden explorar repositorios, modificar múltiples archivos, ejecutar pruebas, revisar resultados y trabajar sobre solicitudes de integración.
El cambio más importante es que estamos pasando de asistentes que sugieren código a agentes que ejecutan tareas.
Pero delegar trabajo no significa entregar el control del proyecto.
## De escribir código a administrar tareas
El 29 de octubre, Qwen Code presentó nuevas funciones para automatizar el seguimiento de Pull Requests.
Su función `/autofix-pr` puede detectar errores de compilación, responder observaciones de revisión, resolver conflictos, ejecutar verificaciones y actualizar una PR.
También incorporó mecanismos para mantener sesiones de trabajo en segundo plano y recuperar esas conversaciones desde otra terminal.
Esto muestra hacia dónde evoluciona el desarrollo asistido por IA: los agentes empiezan a participar en ciclos completos de trabajo.
## El archivo de instrucciones es parte de la arquitectura
Uno de los elementos más importantes de un proyecto con agentes es contar con instrucciones persistentes.
Archivos como `CLAUDE.md` o `AGENTS.md` permiten establecer contexto que el agente debe consultar antes de trabajar.
No deberían convertirse en documentos interminables. Su función es comunicar las reglas fundamentales del proyecto.
Por ejemplo:
- Qué tecnologías utiliza.
- Cómo está organizado el repositorio.
- Qué comandos ejecutar para verificar cambios.
- Qué convenciones debe respetar.
- Qué archivos o directorios no debe modificar.
- Qué operaciones requieren autorización.
El agente necesita entender no solamente qué queremos construir, sino también qué no tiene permitido hacer.
## Qué delegaría y qué mantendría bajo control
En mi flujo de trabajo, separo las tareas según el nivel de riesgo.
**Buenas candidatas para delegar:**
- Análisis de código existente.
- Identificación de errores.
- Propuestas de refactorización.
- Creación de pruebas.
- Actualización de documentación.
- Revisión de dependencias.
- Análisis de rendimiento.
- Preparación de cambios para revisión.
**Operaciones que requieren controles adicionales:**
- Modificación de configuraciones críticas.
- Cambios en bases de datos.
- Gestión de credenciales.
- Modificación de infraestructura.
- Cambios en producción.
- Despliegues y publicación de versiones.
Una regla importante de mi metodología es que los agentes no reciben credenciales sensibles ni realizan commits o despliegues sin autorización explícita.
Para tareas de análisis, prefiero comenzar en modo de solo lectura.
## Una estructura de trabajo más segura
Un flujo razonable puede dividirse en seis etapas:
1. El agente inspecciona el repositorio.
2. Presenta un plan de trabajo.
3. Se autoriza el alcance de los cambios.
4. Ejecuta modificaciones en un entorno aislado o rama independiente.
5. Ejecuta las pruebas y presenta los resultados.
6. Una persona revisa el diff y autoriza la integración.
La utilización de worktrees o ramas independientes ayuda a evitar que distintas tareas modifiquen simultáneamente el mismo espacio de trabajo.
## La automatización no reemplaza la responsabilidad
Un agente puede ejecutar correctamente todos los tests disponibles y aun así introducir un error de negocio, una vulnerabilidad o una decisión arquitectónica equivocada.
Los tests verifican lo que fueron diseñados para verificar. No garantizan que la solución sea correcta en todos sus aspectos.
Por eso, la revisión humana sigue siendo importante.
El verdadero beneficio de estos agentes no está en eliminar al desarrollador, sino en permitirle dedicar más tiempo a la arquitectura, las decisiones técnicas y la calidad del producto.
La pregunta ya no es solamente qué modelo programa mejor.
También es qué grado de autonomía estamos preparados para concederle.
**Referencias:** Qwen Code, actualizaciones del 29 de octubre de 2026.