Un agente vale lo que vale lo que puede alcanzar.
Casi todo lo que se escribe sobre desarrollo con IA habla de herramientas. Esta página describe los sistemas donde vive el trabajo, los estándares con los que lo medimos, y el único sistema que un agente nunca toca.
- Doce sistemas, cada uno con un patrón de acceso definido
- Dos estándares publicados completos
- Los secretos quedan solo para humanos, por diseño
Un proyecto son doce sistemas, no un repositorio
Casi todos los diagramas de entrega de software dibujan fases. Las fases no son el problema. El problema es que la información que un agente necesita está repartida en una docena de sistemas, y un agente sirve solo hasta donde alcanza.
Cada sistema de abajo tiene un patrón de acceso definido. Recuperación significa que el agente consulta un índice en lugar de leer archivos crudos. Protocolo significa una conexión estructurada a un servicio. Sistema de archivos y línea de comandos significan acceso directo. Un sistema está cerrado por completo.
| Sistema | Qué vive ahí | Cómo lo alcanza un agente |
|---|---|---|
| Documentación | Manual del proyecto, visión de producto, solución técnica, decisiones, y el conocimiento de dominio que explica cómo funciona el negocio del cliente | Recuperación |
| Especificación | Especificaciones, criterios de aceptación, backlog, priorización y estado de entrega | Línea de comandos o protocolo |
| Diseño | Wireframes, interfaces, flujos de interacción, tokens y documentación de componentes | Protocolo o línea de comandos |
| Desarrollo | Código fuente, configuración, reglas de rama, y el archivo de contexto versionado que todo agente lee al iniciar una sesión | Sistema de archivos y línea de comandos |
| Validación | Escenarios de prueba por criterio de aceptación, cobertura, y la trazabilidad entre ambos | Sistema de archivos y línea de comandos |
| Entrega | El pipeline que construye y despliega, y la distribución que publica releases | Línea de comandos |
| Infraestructura | Ambientes, infraestructura como código, y las reglas que aprovisionan y limitan a los agentes | Línea de comandos |
| Observabilidad | Seguimiento de errores, rendimiento, logs estructurados, health checks, ruteo de alertas y telemetría de agentes | Línea de comandos o protocolo |
| Comunicación | Canales, notificaciones, eventos del sistema y agenda | Protocolo o línea de comandos |
| Gobernanza | Política de uso de IA, divulgación al cliente, clasificación de datos, evaluación de herramientas, y el modelo de identidad y permisos de agentes | Recuperación y sistema de archivos |
| Cuenta | Contratos, presupuesto, métricas de entrega y escalamientos. Restringido por rol, no abierto al equipo por defecto | Recuperación, restringido |
| Secretos | Llaves de API, credenciales, variables de ambiente y certificados de firma | Sin acceso |
El conocimiento de dominio es lo que más falta
Si el negocio de un cliente es especializado, y en servicios de salud, pagos o trabajo industrial siempre lo es, un agente sin ese contexto produce respuestas equivocadas con seguridad. Cualquier documento que explique cómo funciona el negocio pertenece al sistema de documentación, sin importar quién lo escribió.
El sistema que un agente nunca alcanza
Secretos es solo para humanos. No restringido, ni auditado, ni limitado por rol. Cerrado.
Un agente referencia el nombre de una variable y nunca ve un valor. Esa regla es la razón por la que el sistema existe como dominio propio y no como una carpeta dentro de infraestructura: su trabajo es definir cómo se nombran las credenciales, dónde viven y cómo se inyectan, para que ninguna llegue a un prompt.
Los patrones de acceso son fáciles de escribir y fáciles de ampliar en silencio. Este es el que no se amplía.
Qué cubren los estándares
Seis estándares cubren los doce sistemas.
| Estándar | Qué cubre |
|---|---|
| Especificación | Qué se construye, y con cuánto detalle se describe antes de construirlo |
| Validación | Qué prueba que el build coincide con la especificación, diseñado antes de empezar |
| Entrega | Las compuertas de calidad que pasa un cambio antes de llegar a producción |
| Desarrollo | El ciclo de build, y qué debe estar en el repositorio antes de que un agente trabaje ahí |
| Observabilidad | Las capas que convierten una falla silenciosa en runtime en una señal |
| Diseño | Cómo sobreviven las decisiones de diseño el viaje hasta el código |
Dónde estás tú
Conocer los estándares no es lo mismo que conocer tu posición frente a ellos. La auditoría de preparación para IA califica cuatro dimensiones con evidencia, etiqueta cada hallazgo según qué tan respaldado está, y devuelve una lista de brechas priorizada. Es el mismo procedimiento que corremos en nuestros propios proyectos.
La falla que esto existe para evitar
Un agente al que le das un requerimiento poco claro no se frena. No hace una pregunta ni consulta a un diseñador. Implementa una lectura plausible de lo que recibió, completa y con confianza.
Eso produce una falla específica. Una misma pasada genera la implementación y las pruebas desde la misma lectura de la especificación. Cuando la lectura está mal, el código está mal y las pruebas le dan la razón. Nada sale a la superficie.
Cada estándar de abajo existe para cerrar esa brecha. La especificación elimina la ambigüedad antes del build. El plan de validación se escribe desde la especificación y no desde el código terminado, así que una prueba pregunta si el trabajo hace lo que se pidió en lugar de si hace lo que hace.
¿Quieres esto aplicado a tu proyecto?
La auditoría de preparación califica cuatro dimensiones contra estos estándares y devuelve una lista de brechas priorizada con la evidencia detrás de cada hallazgo.