Agentes que escriben código en producción

Durante años, la promesa de la IA en el desarrollo de software se limitó a sugerencias de autocompletado. Hoy la conversación es otra: agentes que reciben una tarea, exploran el repositorio, escriben los cambios, ejecutan las pruebas y abren un pull request listo para revisión. El salto no es de grado, es de naturaleza.

De autocompletar a colaborar

Un asistente de autocompletado optimiza el siguiente token. Un agente optimiza un objetivo. Esa diferencia obliga a repensar el flujo de trabajo completo: dónde entra el agente, qué contexto necesita y quién responde por el resultado.

El agente como colaborador, no como herramienta

Cuando tratamos al agente como un miembro más del equipo, aparecen prácticas conocidas que de repente vuelven a importar:

• Descripciones de tarea claras: un issue ambiguo produce un PR ambiguo, exactamente igual que con una persona.
• Pruebas como contrato: el agente usa la suite de tests como brújula; si la cobertura es pobre, el agente improvisa.
• Revisión humana obligatoria: nadie fusiona sin que otro par de ojos apruebe.
• Límites de permisos: acceso de solo lectura a producción, credenciales efímeras, entornos aislados.

Qué hemos aprendido en producción

1. El contexto es el 80% del trabajo. Un README actualizado, convenciones documentadas y ejemplos recientes valen más que un modelo más grande.
2. Las tareas pequeñas ganan. Un agente que migra una función, actualiza una dependencia o añade un endpoint tiene una tasa de éxito muy superior a uno al que le pides "refactoriza el módulo de pagos".
3. El coste se mueve a la revisión. Generar el cambio es barato; entenderlo y validarlo no. Si el equipo no tiene capacidad de revisión, el agente solo genera deuda más rápido.
4. Los fallos son distintos. El agente no se equivoca por cansancio, se equivoca por alucinación: inventa una API que no existe con total seguridad.

Un agente no sustituye el criterio de ingeniería. Lo amplifica, para bien y para mal. Un equipo con malas prácticas obtiene malas decisiones a mayor velocidad.

Un ejemplo concreto

Supongamos que el agente debe añadir un reintento con backoff a un cliente HTTP. El cambio típico que produce:

async function fetchWithRetry(url: string, retries = 3): Promise<Response> {
  for (let attempt = 0; attempt <= retries; attempt++) {
    const res = await fetch(url);
    if (res.ok || attempt === retries) return res;
    const delay = 2 ** attempt * 100;
    await new Promise((r) => setTimeout(r, delay));
  }
  throw new Error("unreachable");
}

El código es correcto, pero la revisión humana detecta lo que el agente no priorizó: no distingue entre un 500 y un 404, y reintentar un error de cliente es inútil. Ese matiz es justo donde el ingeniero aporta valor.

Cómo empezar sin romper nada

Recomendamos una adopción gradual:

• Empieza por repositorios internos de bajo riesgo.
• Exige que cada PR del agente pase por CI completo antes de aparecer en la cola de revisión.
• Mide dos cosas: porcentaje de PRs fusionados sin cambios y tiempo de revisión por PR.
• Documenta cada fallo grave en un registro compartido; ese registro es tu mejor material de mejora.

Riesgos que se subestiman

El más silencioso es la erosión del conocimiento del equipo. Si nadie escribe ya el código de cierto módulo, nadie lo entiende cuando falla a las tres de la madrugada. Conviene rotar qué partes se delegan y exigir que la revisión sea real, no un "aprobar" reflejo.

Conclusión

Los agentes que escriben código ya están en producción en muchos equipos, aunque pocos lo digan en voz alta. La ventaja no la obtiene quien tiene el mejor modelo, sino quien tiene el mejor contexto, las mejores pruebas y una cultura de revisión sólida. El trabajo del ingeniero no desaparece: se desplaza hacia definir problemas, diseñar restricciones y juzgar resultados.