Flujo de 4 puertas: reducir incertidumbre antes de programar con agentes

El costo de descubrir un supuesto tarde

Los agentes pueden producir cambios en varias capas con rapidez. Si una suposición equivocada está en la definición del problema, implementarla primero en base de datos, servicios y UI multiplica el costo de corregirla. El trabajo previo busca hacer visibles las decisiones con mayor radio de impacto antes de generar mucho código.

Las cuatro puertas que propone el material de partida son un patrón de planificación, no un estándar formal. Se pueden adaptar según el tamaño y el riesgo de la tarea; un cambio trivial no requiere la misma ceremonia que una modificación con impacto de datos, permisos o despliegues.

Las cuatro puertas de decisión

Cada checkpoint produce una respuesta que puede revisarse. Si una decisión clave sigue abierta, el siguiente paso debe reducir esa incertidumbre y no esconderla bajo más implementación.

1. Producto: quién tiene el problema, qué resultado busca y cómo se reconocerá el éxito.
2. Arquitectura: qué sistemas, interfaces, datos, permisos y límites se ven afectados.
3. Diseño de programa: qué módulos, contratos, archivos y pruebas forman el cambio.
4. Slices verticales: cuál es el recorrido mínimo que atraviesa UI, lógica y datos para probar la hipótesis.

Separar investigación de solución: una secuencia QRDSPI

El documento de NotebookLM llama “QRSPI” a una secuencia, aunque enumera seis fases. Para no ocultar esa discrepancia, aquí se escriben las seis iniciales como QRDSPI: Questions, Research, Design, Structure, Plan e Implement. Es una etiqueta editorial para explicar el flujo del artículo, no una metodología certificada ni un marco universal.

Primero se formulan preguntas neutrales sobre el código y el problema; después se investiga el repositorio sin presuponer la solución. Con esa evidencia se diseña el comportamiento, se define la estructura, se planifican pruebas y slices y, finalmente, se implementa en partes revisables.

1. Questions: convertir el ticket en preguntas verificables.
2. Research: buscar respuestas y restricciones en el sistema existente.
3. Design: acordar experiencia, comportamiento y criterios de aceptación.
4. Structure: definir límites, contratos y responsabilidades de componentes.
5. Plan: ordenar pruebas y slices verticales pequeños.
6. Implement: ejecutar una slice, validarla y continuar con la siguiente.

Hacer las puertas proporcionales al riesgo

Usa checkpoints más livianos para cambios reversibles y amplía la revisión cuando una tarea toca datos sensibles, pagos, acceso, migraciones o producción. Un plan útil registra decisiones pendientes y criterios de salida; no intenta adivinar todos los detalles antes de aprender algo del primer slice.

La aprobación pertenece a las personas responsables del producto y del sistema. El agente puede preparar alternativas, pruebas y documentación, pero no convierte sus propias propuestas en decisiones aprobadas.