Construir con IA

Los agentes de código reducen el costo de transformar instrucciones en software. Esa ventaja cambia el cuello de botella. El problema ya no es solo si una capacidad puede construirse, sino si merece existir, si resuelve el problema correcto y si conserva la comprensión del usuario.

La IA debe absorber complejidad, no producirla.

Un agente puede implementar con gran velocidad una especificación débil, reproducir patrones convencionales que no encajan con el contexto y agregar opciones plausibles que nadie pidió. Por eso el desarrollo asistido por IA necesita una capa explícita de intención, límites y verificación.

Seis directivas para equipos y agentes

Directiva	Exigencia	Límite
D01 Fundamento antes que implementación	Comprender la definición de producto, su autoridad, su alcance y la evidencia que la respalda antes de proponer componentes o código. Cuando existan Job Stories, conservar su circunstancia, motivación y resultado.	No comenzar a construir si una ambigüedad material puede alterar la solución, el alcance o una regla.
D02 Especificación suficiente antes que generación	Definir estados, decisiones, restricciones y criterios de aceptación con el nivel necesario para el riesgo.	No convertir un prompt vago en una implementación extensa y luego usar el código para descubrir el problema.
D03 Simplicidad deliberada	Preferir la solución que exige menos conceptos, decisiones y memoria al usuario cuando ambas logran el mismo resultado.	Menos código no es la medida; menos carga innecesaria sí.
D04 Determinismo donde importa	Implementar reglas críticas, permisos, cálculos, estados y validaciones como lógica verificable.	No delegar certeza, cumplimiento o seguridad al comportamiento variable de un modelo.
D05 Verificación antes que aceptación	Evaluar el flujo, los estados extremos, accesibilidad, rendimiento y resultado real.	Código generado y pruebas unitarias aprobadas no equivalen a producto terminado.
D06 IA subordinada al usuario	Usar IA para proponer, explicar y ejecutar bajo límites claros, manteniendo revisión y reversibilidad proporcionales al impacto.	La fluidez de una respuesta nunca sustituye evidencia ni autorización.

La segunda pregunta rectora

Ahora que podemos construir casi cualquier cosa con mayor facilidad, ¿qué merece ser construido y qué debemos dejar deliberadamente fuera?

Esta pregunta introduce una obligación que antes podía quedar oculta por el costo técnico. Debe plantearse durante la definición de producto y al evaluar alternativas, no utilizarse durante la implementación para recortar unilateralmente un alcance aprobado. Cada capacidad debe justificar su existencia contra una alternativa más simple, incluida la alternativa de no construirla; una vez autorizada, cualquier exclusión requiere una decisión trazable de producto.

Determinismo y generación

La elección no es entre un producto determinista o un producto con IA. Un sistema confiable combina ambos según la naturaleza de cada decisión.

Tipo de comportamiento	Tratamiento preferido	Ejemplos
Debe producir siempre el mismo resultado ante las mismas condiciones	Regla determinista y prueba automatizada	Permisos, precios, límites, cálculos, transición de estados
Admite varias respuestas útiles y requiere interpretación	IA con contexto, límites y evaluación	Explicar, resumir, proponer alternativas, clasificar texto
Puede afectar dinero, reputación, seguridad o derechos	IA propone; regla o persona autoriza	Publicar, comprar, borrar, enviar, cambiar acceso
La incertidumbre es parte de la salida	IA declara supuestos y nivel de confianza	Recomendaciones, estimaciones, información incompleta

El flujo evita que la generación de código se convierta en el primer acto de diseño. No pretende crear una fase documental pesada ni imponer una estructura al PRD. Busca comprender el fundamento recibido, producir la claridad necesaria para planificar y mantener cobertura hasta la aceptación.

Paso	Decisión	Trabajo	Evidencia mínima
F01	Comprender el fundamento	Reconocer las fuentes, la autoridad, el alcance, la estructura utilizada y los resultados esperados.	Mapa fiel de la definición de producto, sin reformularla por conveniencia técnica.
F02	Establecer cobertura	Inventariar historias, capacidades, reglas, estados, recorridos, criterios y relaciones aplicables.	Cobertura completa y vacíos o contradicciones visibles.
F03	Planificar la implementación	Resolver dependencias, bloqueantes, orden, paralelismo, integración y pruebas sin modificar el alcance.	Plan coherente que da cuenta de toda la definición aprobada.
F04	Concretar el progreso	Usar las Job Stories existentes o formular una vista derivada cuando aporte claridad y esté identificada como tal.	Circunstancias, motivaciones y resultados preservados cuando corresponda.
F05	Establecer el contrato de experiencia	Describir qué debe comprender, decidir y sentir la persona en los momentos críticos.	Ruta principal, estados y promesa de interacción.
F06	Modelar reglas y riesgos	Separar lógica determinista, comportamiento generativo, permisos y acciones irreversibles.	Mapa de decisiones y límites.
F07	Explorar y prototipar	Comparar alternativas y probar comprensión, jerarquía y recuperación antes de optimizar código.	Razón de la alternativa elegida y evidencia del recorrido.
F08	Construir, integrar y verificar	Implementar el plan, mantener trazabilidad y reconciliar resultados contra el alcance completo.	Código, pruebas y evidencia de cobertura; pendientes y excepciones explícitos.

Cada artefacto existe para responder una pregunta, no para satisfacer una plantilla. Puede ser una sección del PRD, una vista derivada, una tabla, una prueba o un documento separado. Si la información ya existe, debe referenciarse y no duplicarse. La profundidad depende de la extensión, complejidad, incertidumbre y riesgo; si un artefacto no cambia una decisión ni ayuda a verificarla, debe simplificarse o eliminarse.

Artefacto	Pregunta	Contenido mínimo
A01 Mapa del fundamento	¿Qué debe construirse, por qué y con qué autoridad?	Fuentes; alcance; resultados; reglas; límites; evidencia; no objetivos
A02 Mapa de cobertura	¿Cómo se dará cuenta de todo el alcance?	Elementos obligatorios; relaciones; dependencias; implementación; pruebas; estado; excepciones
A03 Ficha de Job Story cuando aplique	¿Cuándo surge la necesidad y qué cambio busca la persona?	Circunstancia; motivación; resultado; conducta actual; ansiedad; evidencia; supuestos
A04 Contrato de experiencia	¿Qué debe comprender y poder hacer la persona?	Ruta principal; lenguaje; decisiones; feedback; control; recuperación
A05 Modelo de estados	¿Qué puede ocurrir y qué transiciones son válidas?	Estados; eventos; reglas; errores; permisos; persistencia
A06 Presupuesto de complejidad	¿Qué carga estamos agregando?	Conceptos nuevos; decisiones; pasos; excepciones; opciones visibles
A07 Plan de aceptación	¿Qué evidencia autoriza declarar completo el desarrollo?	Resultados; reglas; Job Stories cuando apliquen; accesibilidad; rendimiento; estados extremos; métricas
A08 Registro de decisiones	¿Por qué elegimos esta alternativa?	Alternativas; tradeoffs; supuestos; decisión; fecha; evidencia pendiente

El agente no debería comenzar una implementación si no puede responder con precisión las siguientes preguntas en el nivel requerido por el riesgo y la complejidad:

• ¿Cuál es la definición de producto autorizada y qué alcance establece?

• ¿Qué elementos del fundamento justifican el desarrollo y qué evidencia los respalda?

• ¿La planificación da cuenta de todas las historias, capacidades, reglas, estados y criterios obligatorios?

• Cuando existen Job Stories, ¿la circunstancia, la motivación y el resultado están separados de la solución?

• ¿Cuál es la ruta principal y qué estados alternativos importan?

• ¿Qué decisiones debe tomar el usuario y cuáles puede resolver el sistema?

• ¿Qué comportamiento necesita certeza determinista?

• ¿Qué no forma parte del alcance y quién estableció esa exclusión?

• ¿Qué evidencia demostrará que el desarrollo está completo?

Si falta una respuesta que pueda cambiar de manera material la solución, el alcance, una regla o un derecho, el agente debe detenerse y solicitarla. Si la incertidumbre es menor, reversible y se encuentra dentro de su autoridad, puede declarar un supuesto y avanzar sin reducir silenciosamente la cobertura comprometida.

El siguiente contrato puede incorporarse a las instrucciones de un repositorio, a un PRD o al prompt de un agente de código. Debe acompañarse con el contexto específico del producto y no sustituye la definición del problema.

CR01 Propósito. Construye la solución más simple que permita al usuario lograr el resultado definido, conservando claridad, control y capacidad de recuperación.

CR02 Antes de programar. Identifica las fuentes autorizadas, explica el fundamento de producto y confirma el alcance completo. Reconoce la estructura utilizada por la definición; cuando contenga Job Stories, conserva su circunstancia, motivación y resultado. Separa evidencia de supuestos e identifica cualquier ambigüedad que pueda cambiar materialmente la solución.

CR03 Al planificar. Da cuenta de todos los elementos obligatorios y establece sus dependencias, bloqueantes, orden, integración y pruebas. No selecciones, omitas ni postergues partes del alcance por iniciativa propia. Si las restricciones impiden cubrirlo, solicita una decisión a la autoridad de producto.

CR04 Al proponer. Presenta la alternativa recomendada, una alternativa más simple y la opción de no construir cuando la decisión aún pertenezca a producto. Explica cómo responde cada una al fundamento, qué carga introduce y qué tradeoffs exige.

CR05 Al diseñar. No expongas estructuras internas. Usa lenguaje del usuario, convenciones conocidas, jerarquía clara, profundidad progresiva, valores predeterminados editables y feedback inmediato.

CR06 Al usar IA. Reserva las reglas críticas para lógica verificable. Declara incertidumbre. No ejecutes acciones de alto impacto sin autorización proporcional. Mantén trazabilidad, revisión y reversibilidad.

CR07 Al implementar. Respeta el alcance acordado y conserva trazabilidad con su fundamento. No agregues features, modos, configuraciones ni abstracciones no solicitadas. Cubre estados vacíos, carga, error, éxito y recuperación e integra las partes relacionadas.

CR08 Antes de declarar terminado. Reconcilia la implementación contra la definición completa de producto. Verifica resultados, reglas, criterios y, cuando correspondan, las Job Stories en sus circunstancias. Comprueba también accesibilidad, rendimiento percibido, errores, persistencia del trabajo y control del usuario. Entrega evidencia, pendientes y excepciones aprobadas.

Formato de entrega esperado del agente

1. O01 Fuentes autorizadas y fundamento de producto que justifican el desarrollo.

2. O02 Inventario de alcance y cobertura de historias, capacidades, reglas, estados y criterios aplicables.

3. O03 Jobs to Be Done y Job Stories cuando formen parte de la definición o aporten una vista derivada útil.

4. O04 Evidencia disponible, supuestos y criterios de resultado.

5. O05 Alternativa elegida y razón de descarte de opciones más complejas.

6. O06 Archivos o componentes modificados y límites del cambio.

7. O07 Estados y casos extremos cubiertos.

8. O08 Pruebas ejecutadas y evidencia de resultado.

9. O09 Riesgos, incertidumbres, pendientes, excepciones y decisiones que aún requieren juicio humano.

Prompt breve para iniciar una tarea

Antes de escribir código, identifica la definición de producto autorizada, explica su fundamento y confirma el alcance completo. Reconoce todas las historias, capacidades, reglas y criterios aplicables; cuando existan Job Stories, conserva su circunstancia, motivación y resultado. Distingue evidencia de supuestos. Planifica dependencias y cobertura sin omitir ni postergar alcance por iniciativa propia. Implementa la solución más simple que cumpla lo aprobado y verifica resultados, integración, errores y recuperación.