Mi agente entregó 3 PR en una tarde. El 40 % de mis mensajes fueron correcciones.
Mi agente de programación impulsado por IA realizó tres pull requests en una sola tarde, pero el 40 % de los 30 mensajes que envié fueron correcciones.
La sesión produjo un MCP client, un Azure AI Agent y un M365 Copilot Agent. Las comprobaciones automáticas aprobaron los tres PR, y nunca edité una sola línea de código. Sin embargo, la transcripción cuenta una historia diferente: de un total de 710 mensajes, yo escribí 30, y 12 de ellos reorientaron al agente. La “tasa de reorientación” —la proporción de mis mensajes que fueron correcciones— se sitúa en el 40 %.
Cómo estaba configurado el pipeline
- Claude redactó un plan de implementación de alto nivel.
- DeepSeek V4-Flash actuó como el orquestador, revisando el plan.
- Codex generó el código real.
- El orquestador inspeccionó el código y abrió los pull requests.
El papel previsto para el orquestador era puramente de conexión: debía resolver conflictos entre componentes, no escribir código por sí mismo. En la práctica, el agente produjo 3500 líneas de código en los tres PR en aproximadamente 40 minutos, pero también cometió errores en dos clases de errores recurrentes.
Las dos familias de errores
- Violaciones del flujo de trabajo – el orquestador ocasionalmente asumía el paso de codificación, ignorando su función de “pegamento” y escribiendo él mismo los detalles de la implementación.
- Fallos en la recuperación de contexto – a pesar de las instrucciones explícitas, el agente seleccionó el SDK o la versión incorrectos. La información correcta estaba en el contexto del prompt, pero el modelo no logró extraerla en el momento adecuado.
Estos no son vacíos en la capacidad de razonamiento; son errores de ingeniería en la forma en que se restringe el flujo de trabajo. Incluso un modelo de lenguaje más capaz seguiría necesitando una regla estricta e ineludible que limite al orquestador a sus tareas de no codificación y fuerce la selección del SDK correcto.
Qué cambié para domar al agente
Dejé de asumir que el sistema inferiría su función a partir de la lista de pasos. Añadí una declaración directa: “Eres un orquestador. No implementas.” Hicieron falta cinco mensajes correctivos para que la instrucción se consolidara, tras lo cual el agente respetó el límite.
También ajusté la lógica de recuperación de contexto. Cuando aparecía la herramienta incorrecta, lo traté como un error en el pipeline de recuperación en lugar de una alucinación, y reescribí el prompt que suministra los detalles del SDK para que fuera imposible pasar por alto la versión correcta.
Conclusiones prácticas para el desarrollo aumentado por IA
- Cuenta tus propios mensajes. Un alto volumen de PR aceptados puede enmascarar un proceso defectuoso. Tu recuento de correcciones es un indicador principal de por dónde se está filtrando el sistema.
- Define el rol explícitamente. Los agentes no extrapolan su identidad a partir de una lista de verificación; necesitan una instrucción clara y fija sobre quiénes son y qué pueden hacer.
- Trata los errores de elección de herramientas como errores de ingeniería. Si el agente ignora un SDK especificado, la culpa reside en el mecanismo de entrega de contexto, no en el “conocimiento” del modelo.
- Convierte los errores en habilidades reutilizables. Dejé que el agente generara una rutina de validación a partir de sus propios errores, convirtiendo un fallo en una salvaguarda futura.