Agentes, evaluación y gobierno
De copilotos a fábricas de software con IA: qué debe cambiar
Un cambio ficticio de reservas muestra qué decisiones, evidencias y responsabilidades deben preceder a una mayor delegación del trabajo.
Joan ArandaLa idea de una fábrica de software con IA resulta atractiva cuando vemos a los agentes completar tareas. Para llevarla a una organización, necesitamos decidir cómo se prepara el trabajo, quién lo acepta y qué ocurre cuando la evidencia no es suficiente.
Antes de ampliar autonomía, examinaría una modificación pequeña de principio a fin. Si sus condiciones de aceptación siguen siendo ambiguas, añadir más capacidad de ejecución probablemente hará esa ambigüedad más difícil de gestionar.
Una modificación ficticia
Usaremos una aplicación hipotética de reservas. La petición es permitir la cancelación cuando faltan al menos 24 horas para el inicio. No describe una migración o producto real.
Para hacer el ejemplo verificable, fijamos estas reglas: el servidor compara instantes en UTC; se permite cancelar exactamente en el límite de 24 horas; solo una reserva confirmada admite la primera cancelación; repetir una cancelación ya aceptada no duplica sus efectos. Las políticas de devoluciones y la interfaz de usuario quedan fuera de este cambio.
Estas decisiones no son universales. Otro producto puede necesitar otra política. Su valor consiste en hacer visible qué comportamiento estamos pidiendo.
Condiciones de paso
| Punto | Evidencia necesaria | Responsabilidad | Si falta evidencia |
|---|---|---|---|
| Comprender el sistema | Estados y efectos actuales relevantes, con dudas identificadas | Ingeniería y responsable funcional | Acotar el cambio o investigar |
| Acordar comportamiento | Regla de límite, estados, repetición y alcance | Responsable funcional con ingeniería | Resolver discrepancias antes de implementar |
| Preparar ejecución | Módulos afectados, restricciones y plan proporcional | Ingeniería | Reducir alcance o completar contexto |
| Revisar propuesta | Cambios coherentes con reglas y contratos | Revisor técnico | Corregir o rechazar propuesta |
| Validar resultado | Casos funcionales y preservación de comportamiento relevante | QA/ingeniería y aceptación funcional | Iterar; no declarar el cambio terminado |
| Entregar | Aceptación registrada y mecanismo de recuperación adecuado | Responsable de entrega | No activar el cambio |
Un punto de validación útil no se define por el nombre de la fase. Se define por la decisión, su evidencia y una responsabilidad que puede detener el flujo. Las funciones pueden recaer en pocas personas; la tabla no exige contratar un rol por fila.
Qué demostraría la validación
En este ejemplo comprobaríamos una reserva confirmada a 24 horas exactas, otra justo fuera del plazo permitido y otra justo dentro. También estados no cancelables, repetición de una petición ya aceptada y ausencia de efectos duplicados. Los instantes serían fijos para que las pruebas no dependan del reloj del momento.
Comprobar el límite con pruebas no basta para afirmar equivalencia de todo el sistema. Necesitamos delimitar qué comportamiento preservamos y examinar la integración relevante. Un evaluador que repite los mismos supuestos erróneos de la implementación puede dar una aprobación falsa.
Anthropic recomienda tareas bien especificadas, entornos estables y pruebas adecuadas para evaluar agentes de programación. Esa guía es útil, pero la aceptación de una entrega concreta sigue necesitando contexto y responsabilidad del equipo.
La especificación también puede cambiar
Si durante la revisión aparece una restricción no prevista, debemos decidir si modifica el acuerdo. Bloquear cualquier cambio para conservar el documento produciría una falsa estabilidad. Cambiarlo sin registrar la razón produciría una referencia poco fiable.
La respuesta es mantener ciclos pequeños: revisar la intención o el contexto, ajustar las comprobaciones y repetir la ejecución que resulte afectada. El flujo no necesita convertirse en una cascada de documentos extensos.
Qué debe mejorar al ampliar capacidad
Solo después de entender una tarea consideraría ejecución paralela o varios agentes. Querría saber qué trabajo se puede separar, dónde aparecen conflictos y cuánto cuesta integrar y revisar las propuestas.
La ampliación tiene sentido si mejora el resultado aceptado dentro de límites conocidos. Más propuestas abiertas pueden consumir capacidad de revisión sin aumentar entregas. El modelo operativo debe permitir observar esa compensación.
Una fábrica de software con IA empieza a ser una propuesta examinable cuando podemos explicar sus condiciones de paso y sus fallos. La ejecución es una capacidad; la posibilidad de aceptar o detener el resultado forma parte del sistema que la hace utilizable.
Referencia
- Anthropic Engineering, Demystifying evals for AI agents: guía sobre evaluación, no validación empírica de este ejemplo.
La tabla, las reglas y el caso son ilustraciones originales e hipotéticas preparadas para publicación. No se han ejecutado pruebas de ese producto ni se reportan resultados de producción.