Definir el margen de decisión del agente

El margen de decisión del agente (agentic latitude) es el grado de discreción que un Product Engineer concede para decidir más allá de los detalles explícitos. No es un permiso global: varía por categoría, incremento, proyecto o cliente.

El Product Engineer identifica dónde se agradece libertad, para proponer o implementar sin instrucciones detalladas, y dónde hace falta precisión, para que el agente no amplíe, reinterprete ni cambie límites o requisitos por su cuenta.

Libertad y especificidad se complementan. Un proyecto puede permitir creatividad amplia de UX y fijar exactamente funciones y páginas. Otro puede invitar propuestas funcionales pero exigir un sistema visual y políticas de contenido estrictos.

Estas cuatro categorías son perspectivas prácticas, no una taxonomía exclusiva de todas las decisiones.

Pueden ser útiles otras categorías, como integración u operaciones, sin convertirlas en burocracia obligatoria. Seguridad empresarial y arquitectura aprobada siguen siendo vinculantes.

El Product Engineer define libertad y precisión para el próximo resultado. Un cliente puede desear explorar UX conservando inventario de páginas y funciones; otro permite propuestas funcionales pero fija reglas visuales y editoriales. Los límites deben ser tan explícitos como la invitación a crear.

Una categoría omitida no concede permiso ilimitado para ampliar el producto. Rigen la petición actual, instrucciones permanentes y alcance razonablemente implícito. Proponer adiciones importantes por separado y consultar antes de implementarlas. El margen nunca autoriza inventar políticas empresariales, privilegios, dependencias ni efectos irreversibles fuera de la autoridad concedida.

SHAPE recomienda construir y validar en incrementos pequeños y coherentes, definiendo el margen para cada uno. Es el camino recomendado por defecto, no otra alternativa equivalente.

Comenzar con la base mínima útil, implementar una capacidad comprensible, probar el resultado, ajustar intención y margen y avanzar. Pequeño no significa commits diminutos ni cambios de una sola pantalla. El PE y las partes pertinentes deben poder comprender y evaluar las consecuencias.

Ejemplos de incrementos web: estructura/navegación, orientación visual, autenticación, cuentas y primer flujo de producto. En una extensión ERP: integración/modelo de datos, una operación empresarial, permisos/validaciones y flujos relacionados. Son ejemplos, no nuevas etapas universales ni instrucciones para añadir cuentas a este sitio.

Una petición inicial grande o una especificación exhaustiva puede producir un prototipo impresionante y ser apropiada para experimentos acotados. También puede acumular decisiones inconscientes: páginas adicionales, funciones no pedidas, reglas inventadas, grandes textos, dependencias u organización no deseada.

El resultado puede parecer pulido y superar lo que el responsable entiende o quiere publicar. El PE pasa de dirección proactiva a control reactivo de daños: descubrir qué existe, quitar comportamiento y revertir supuestos. Revertir rápido ayuda, pero no elimina el esfuerzo de comprender, revisar y desenredar un resultado amplio.

No todos los prompts amplios fracasan ni los prototipos de agentes son malos por naturaleza. Se admiten experimentos amplios; aun así, SHAPE recomienda incrementos pequeños y revisables.

Esta práctica ligera sirve durante descubrimiento, implementación y mejora; no añade una etapa de gobierno.

1. Definir el próximo resultado. Identificar el resultado funcional coherente más pequeño que merezca inspección, usuarios y comportamiento demostrable. Ejemplo: una persona autenticada ve sus datos y cambia su contraseña en una página de cuenta. No describir todo el producto futuro.
2. Fijar alcance. Indicar inclusiones, exclusiones y adiciones que requieren consulta, sobre todo páginas, reglas, integraciones o grandes textos. Ejemplo: sin fotos, suscripciones, ajustes extra ni navegación nueva; proponer ideas aparte.
3. Definir margen por categoría. Considerar y expresar categorías cuando exista riesgo sin exigir matrices para cada detalle. Ejemplo: UX moderada dentro del sistema; estructura baja con rutas fijas; funciones solo las acciones descritas; contenido breve sin ayuda inventada.
4. Identificar restricciones inmutables o controladas. Seguridad, tecnologías aprobadas, diseño e instrucciones protegidas siguen rigiendo. Políticas, borrado, permisos y efectos externos requieren personas autorizadas.
5. Implementar un incremento coherente. Usar recursos aprobados y construir solo el resultado acotado. Presentar oportunidades adicionales por separado, sin ampliar silenciosamente.
6. Inspeccionar el producto funcional. Usarlo: qué se construyó, supuso o añadió, y qué corregir. Examinar páginas, flujos, operaciones o API reales, no solo el resumen del agente. Mantener manejable el esfuerzo de revisión.
7. Ajustar y repetir. Revisar producto y margen con comentarios directos. El agente mantiene intención para trabajo futuro y verificación independiente. Avanzar cuando el resultado sea adecuado para su etapa, no tras una aprobación ritual del texto.

Este es un patrón opcional de petición, no formato obligatorio, artefacto adicional ni ceremonia de aprobación. Usar solo el detalle necesario; los límites pueden expresarse hablando, por escrito o en contexto permanente.

## Próximo incremento
[¿Qué resultado funcional debe existir?]

## Alcance
Incluir: [comportamiento y contenido requeridos]
Excluir: [funciones, páginas, flujos o contenido que no deben añadirse]

## Margen de decisión del agente
- Creativa / UX: [discreción y restricciones]
- Estructural: [organización que puede cambiar]
- Funcional: [si puede proponer o implementar comportamiento adicional]
- Contenido: [qué puede redactar o inventar]

## Decisiones que requieren aprobación
[Políticas, dependencias, ampliaciones importantes u otras decisiones a elevar]

## Objetivo de revisión
[¿Qué utilizará, inspeccionará o demostrará el Product Engineer?]

Omitir una categoría no permite expansión ilimitada. Las sugerencias útiles pueden mantenerse separadas de lo implementado.

Los tres escenarios son ilustrativos e hipotéticos, no proyectos reales de clientes.

Sitio de documentación: UX amplia, alcance y contenido estrechos

Intención: primera web del marco con secciones autorizadas. Creativa/UX: libertad amplia para presentación clara dentro del diseño. Estructural: organizar dentro de páginas aprobadas; no añadir páginas principales ni secciones sin permiso. Funcional: solo capacidades pedidas; proponer utilidades extras. Contenido: hechos y decisiones proporcionados, sin inventar casos ni metodologías como aprobados. Incremento: navegación, inicio y una página representativa antes de completar las demás.

Motivo: una especificación enorme puede generar páginas y casos plausibles de buena calidad cuyas afirmaciones el responsable todavía desconoce.

Flujo ERP: margen funcional limitado

Intención: añadir una operación de aprobación a un sistema existente. Creativa/UX: reutilizar patrones mejorando claridad. Estructural: respetar módulos y extensiones. Funcional: no añadir estados, efectos contables, permisos ni integraciones sin aprobación. Contenido: terminología y políticas existentes. Incremento: una operación completa con autorización y validación, inspeccionada antes de ampliar.

Motivo: un flujo adicional plausible puede producir efectos empresariales y de datos aunque la interfaz parezca útil.

Prototipo interno exploratorio: margen amplio deliberado

Intención: explorar alternativas a un problema limitado, sin publicación en producción ni efectos irreversibles. Creativa/UX: amplia. Estructural: amplia dentro del prototipo. Funcional: propuestas exploratorias e implementaciones desechables permitidas. Contenido: ejemplos sintéticos claramente identificados. Incremento: empezar igualmente con una parte demostrable y ampliar tras inspección.

Motivo: libertad amplia puede ayudar cuando la exploración es explícita y reversible. Debe concederse intencionadamente, no surgir de una petición imprecisa.

La deriva del agente es expansión o redirección del producto por decisiones fuera de los límites previstos o autorizados del PE. Una idea inesperada no es deriva solo por ser inesperada. Hay problema si implementarla excede el margen, viola restricciones o introduce decisiones sin autorización.

Señales: páginas, módulos, funciones, integraciones o contenido complejo no pedidos; políticas, validaciones, permisos o criterios inventados; dependencias nuevas pese a recursos aprobados; superficie imposible de revisar; resúmenes centrados en cantidad generada y no resultados validados; y limpieza repetida después de grandes ejecuciones.

La respuesta no prohíbe creatividad: acotar el próximo incremento, definir discreción, inspeccionar el resultado y ampliar deliberadamente. Así se conserva dirección proactiva en vez de control reactivo de daños.

Product Engineer: fija resultado, alcance y margen, identifica autoridad necesaria, usa el producto, redirige y mantiene incrementos revisables. No necesita documentación elaborada ni firmar cada texto.

Agente de programación: decide solo dentro del margen y reglas permanentes, no amplía en silencio, propone adiciones importantes y mantiene intención.

Arquitecto / Ingeniero sénior: establece límites técnicos y revisa desviaciones e implementación en los puntos acordados. No se añade aprobación arquitectónica obligatoria.

Diseñador de UX: establece límites cuando hace falta y revisa resultados; puede conceder creatividad dentro de un sistema. No se exige diseño exhaustivo previo.

Parte interesada del negocio: decide reglas importantes y acepta producto funcional mediante revisión/UAT. El margen no transfiere responsabilidad al agente.

Se mantiene el enfoque orientado a resultados: intención conversacional y contexto actualizado por agentes para mantenimiento y verificación independiente. Las personas aceptan el producto, no el documento. Una declaración breve de libertad y límites puede ser mejor que gran documentación previa.