Phase 2: Build

What is the Build phase?

Build is where the work happens. Code gets written. Designs get made. Articles get drafted. Systems get configured.

But Build is not just execution — it is structured discovery. You will learn things during the build that planning couldn't reveal. The goal is not to follow the plan blindly; it is to stay anchored to the goal and success criteria from the plan, while adapting tactically as you learn.

The Build phase is a diverging phase. You start with the plan and expand outward — discovering what works, what doesn't, what was missed, what needs to change. This divergence is healthy and expected. The gates that follow Build (Build Validation, pre-ship Review) are where you converge. Don't try to converge during Build — that is what the gates are for.

The Build phase ends when you have something that meets the success criteria from your Plan Brief — not when the work feels complete, not when it feels perfect.

How to run the Build phase

Start from the success criteria and rabbit holes

Before writing a line of code or a single sentence, re-read your Plan Brief. Specifically, re-read the success criteria, out of scope, and rabbit holes sections.

These are your anchors and your fences. If a decision during Build doesn't serve the success criteria, it is likely scope creep. If it's heading toward a rabbit hole you named in the brief, stop.

Break it into units of work

Translate the goal into the smallest possible units of work that can be completed and verified independently. This creates momentum and makes it easier to spot when you are drifting.

A good unit of work is: completable in one focused session, independently verifiable ("is this done?"), and traceable back to the Plan Brief.

Build, then verify, then move

After each unit of work, ask: does this still connect to the goal? If yes, continue. If no, stop and decide: either the goal evolved (update the Plan Brief) or you drifted (course correct).

Flag blockers early

When you hit a blocker — a missing constraint, an unknown, a dependency that doesn't behave as expected — surface it immediately. Don't route around it silently. Either resolve it, update the plan, or use a Build Validation gate.

What to expect during Build

When you start building, you have imagined tasks — the work you think needs to happen based on the plan. As you build, you discover real tasks — the actual work that surfaces once you're inside the problem. This is normal. Discovered tasks are not failures; they are the process working.

The goal is to handle discovered tasks without losing direction:

If a discovered task serves the success criteria → do it
If it doesn't → note it as a future improvement and move on
If it changes the goal or constraints → update the Plan Brief before continuing

Signs the Build is going wrong

Signal	What it means	What to do
You've lost track of why you're building a specific thing	Direction drift	Re-read the Plan Brief. If the goal changed, update it.
The scope has expanded significantly since you started	Scope creep	Return to "out of scope" in the Plan Brief. Cut or defer.
You are exploring a rabbit hole named in the Plan Brief	You went somewhere you told yourself not to go	Stop. Flag it. Return to the plan.
You are optimizing something that wasn't in the success criteria	Perfectionism	Note it as a future improvement and move on.
You've been building for a long time without something verifiable	Unit of work is too large	Break it down further.

Updating the Plan Brief from Build

It is normal and expected that the Build phase reveals gaps or errors in the plan. When this happens:

Stop — don't just silently change course
Assess — is this a tactical adjustment or a strategic shift?
Update the Plan Brief — if the goal, constraints, or success criteria changed, write it down
Continue — with the updated brief as your new anchor

Never let the plan become a fiction you are quietly ignoring.

Optional gates from Build

Use a gate if:

The build is producing something you haven't built before → use Research
You need to verify the output is matching the goal before investing more → use Build Validation
The output is getting complex and you need a second opinion → use Build Validation

Using AI in the Build phase

In solveOS, Build is where AI does the most work. AI can participate as an assistant — accelerating execution while a human steers — or as an autonomous agent given a Plan Brief and reference files and expected to produce the output.

Reference files

When AI is building, it needs two inputs:

The Plan Brief — the goal, audience, constraints, and success criteria
Reference files — files that give AI the information it needs to build correctly

Reference files are not the problem description. They are the working environment: existing code, documentation, API specs, style guides, design files. The more relevant reference files you provide, the less AI has to guess.

Where AI helps

Writing, generating, and iterating on artifacts quickly
Catching errors or edge cases you missed
Explaining things you don't understand in the build
Proposing approaches to a problem you're stuck on

Where human judgment must lead

Deciding which approach to take when there are trade-offs
Recognizing when the output doesn't match the goal
Deciding when to cut scope and ship vs. keep building
Updating the Plan Brief when the build reveals new information

AI-specific failure modes

Failure	What it looks like	What to do
Instruction drift	AI follows the letter of the brief but misses the intent — technically correct, wrong result	Re-read the brief alongside the output. If the intent was ambiguous, rewrite that section of the brief and re-run.
Silent assumptions	The brief was ambiguous on a decision point. AI made a choice without flagging it.	Review the output for implicit choices not stated in the brief. Accept them explicitly or correct and update the brief.
Scope expansion	AI added things not in the brief because they seemed useful or complete	Compare output to the success criteria only. Cut anything not traceable to the brief.
Reference file blindness	AI ignored the reference files and produced output based on its training data instead	Check whether the output fits the environment. If not, re-run with reference files highlighted more explicitly.
Confidence without verification	AI produced plausible-sounding output that contains factual errors or fabricated specifics	Never accept factual claims in AI output without independent verification.

Prompt to try (with reference files attached):

Here is my Plan Brief: [paste brief]
Here is what I've built so far: [describe or paste output]

Does what I've built so far serve the goal and success criteria?
What am I missing?
What should I cut to reach a shippable version faster?

Exit checklist

All success criteria from the Plan Brief are met
Nothing in scope was skipped without a deliberate decision
The Plan Brief is up to date (reflects any changes made during Build)
The output can be put in front of a real person or system
Out of scope items are noted for future work, not silently dropped

¿Qué es la fase Build?

El Build es donde ocurre el trabajo. Se escribe código. Se hacen diseños. Se redactan artículos. Se configuran sistemas.

Pero el Build no es solo ejecución — es descubrimiento estructurado. Aprenderás cosas durante el build que la planificación no podía revelar. El objetivo no es seguir el plan ciegamente; es mantenerse anclado al objetivo y los criterios de éxito del plan, mientras te adaptas tácticamente a medida que aprendes.

La fase Build es una fase de divergencia. Comienzas con el plan y te expandes hacia afuera — descubriendo qué funciona, qué no, qué se omitió, qué necesita cambiar. Esta divergencia es saludable y esperada. Los gates que siguen al Build (Build Validation, Review pre-entrega) son donde converges. No intentes converger durante el Build — para eso existen los gates.

La fase Build termina cuando tienes algo que cumple los criterios de éxito de tu Plan Brief — no cuando el trabajo se siente completo, no cuando se siente perfecto.

Cómo ejecutar la fase Build

Comienza desde los criterios de éxito y los pozos sin fondo

Antes de escribir una línea de código o una sola oración, vuelve a leer tu Plan Brief. Específicamente, vuelve a leer las secciones de criterios de éxito, fuera de alcance y pozos sin fondo.

Estos son tus anclas y tus vallas. Si una decisión durante el Build no sirve los criterios de éxito, probablemente es expansión de alcance. Si se dirige hacia un pozo sin fondo que nombraste en el brief, detente.

Divide en unidades de trabajo

Traduce el objetivo en las unidades de trabajo más pequeñas posibles que puedan completarse y verificarse de forma independiente. Esto crea impulso y facilita detectar cuándo te estás desviando.

Una buena unidad de trabajo es: completable en una sesión enfocada, verificable de forma independiente ("¿esto está hecho?") y trazable hasta el Plan Brief.

Construye, luego verifica, luego avanza

Después de cada unidad de trabajo, pregunta: ¿esto todavía conecta con el objetivo? Si sí, continúa. Si no, detente y decide: o el objetivo evolucionó (actualiza el Plan Brief) o te desviaste (corrige el rumbo).

Señala los bloqueadores a tiempo

Cuando encuentres un bloqueador — una restricción faltante, una incógnita, una dependencia que no se comporta como se esperaba — señálalo de inmediato. No lo rodees en silencio. O resuélvelo, actualiza el plan, o usa un gate de Build Validation.

Qué esperar durante el Build

Cuando comienzas a construir, tienes tareas imaginadas — el trabajo que crees que necesita ocurrir según el plan. A medida que construyes, descubres tareas reales — el trabajo real que surge una vez que estás dentro del problema. Esto es normal. Las tareas descubiertas no son fracasos; son el proceso funcionando.

El objetivo es manejar las tareas descubiertas sin perder dirección:

Si una tarea descubierta sirve los criterios de éxito → hazla
Si no → anótala como una mejora futura y sigue adelante
Si cambia el objetivo o las restricciones → actualiza el Plan Brief antes de continuar

Señales de que el Build va mal

Señal	Qué significa	Qué hacer
Perdiste el rastro de por qué estás construyendo algo específico	Deriva de dirección	Vuelve a leer el Plan Brief. Si el objetivo cambió, actualízalo.
El alcance se expandió significativamente desde que empezaste	Expansión de alcance	Vuelve a "fuera de alcance" en el Plan Brief. Corta o difiere.
Estás explorando un pozo sin fondo nombrado en el Plan Brief	Fuiste a donde te dijiste que no ibas	Detente. Señálalo. Vuelve al plan.
Estás optimizando algo que no estaba en los criterios de éxito	Perfeccionismo	Anótalo como mejora futura y sigue adelante.
Has estado construyendo mucho tiempo sin nada verificable	La unidad de trabajo es demasiado grande	Divídela más.

Actualizar el Plan Brief desde el Build

Es normal y esperado que la fase Build revele vacíos o errores en el plan. Cuando esto sucede:

Detente — no cambies de rumbo en silencio
Evalúa — ¿es este un ajuste táctico o un cambio estratégico?
Actualiza el Plan Brief — si el objetivo, las restricciones o los criterios de éxito cambiaron, escríbelo
Continúa — con el brief actualizado como tu nuevo ancla

Nunca dejes que el plan se convierta en una ficción que estás ignorando en silencio.

Gates opcionales desde Build

Usa un gate si:

El build está produciendo algo que no has construido antes → usa Research
Necesitas verificar que el resultado coincida con el objetivo antes de invertir más → usa Build Validation
El resultado se está volviendo complejo y necesitas una segunda opinión → usa Build Validation

Usar IA en la fase Build

En solveOS, el Build es donde la IA hace más trabajo. La IA puede participar como asistente — acelerando la ejecución mientras un humano dirige — o como agente autónomo al que se le da un Plan Brief y archivos de referencia y se espera que produzca el resultado.

Archivos de referencia

Cuando la IA construye, necesita dos insumos:

El Plan Brief — el objetivo, la audiencia, las restricciones y los criterios de éxito
Archivos de referencia — archivos que dan a la IA la información que necesita para construir correctamente

Los archivos de referencia no son la descripción del problema. Son el entorno de trabajo: código existente, documentación, especificaciones de API, guías de estilo, archivos de diseño. Cuantos más archivos de referencia relevantes proporciones, menos tiene que adivinar la IA.

Dónde ayuda la IA

Escribir, generar e iterar sobre artefactos rápidamente
Detectar errores o casos límite que pasaste por alto
Explicar cosas que no entiendes en el build
Proponer enfoques para un problema en el que estás atascado

Dónde debe liderar el juicio humano

Decidir qué enfoque tomar cuando hay compensaciones
Reconocer cuando el resultado no coincide con el objetivo
Decidir cuándo reducir el alcance y entregar vs. seguir construyendo
Actualizar el Plan Brief cuando el build revela nueva información

Modos de fracaso específicos de la IA

Fracaso	Cómo se ve	Qué hacer
Deriva de instrucciones	La IA sigue la letra del brief pero pierde la intención — técnicamente correcto, resultado incorrecto	Vuelve a leer el brief junto con el resultado. Si la intención era ambigua, reescribe esa sección del brief y vuelve a ejecutar.
Suposiciones silenciosas	El brief era ambiguo en un punto de decisión. La IA tomó una decisión sin señalarlo.	Revisa el resultado en busca de elecciones implícitas no declaradas en el brief. Acéptalas explícitamente o corrígelas y actualiza el brief.
Expansión de alcance	La IA agregó cosas que no estaban en el brief porque parecían útiles o completas	Compara el resultado solo con los criterios de éxito. Corta cualquier cosa que no sea trazable hasta el brief.
Ceguera a archivos de referencia	La IA ignoró los archivos de referencia y produjo resultados basados en sus datos de entrenamiento	Verifica si el resultado encaja en el entorno. Si no, vuelve a ejecutar con los archivos de referencia destacados más explícitamente.
Confianza sin verificación	La IA produjo un resultado plausible que contiene errores fácticos o especificaciones fabricadas	Nunca aceptes afirmaciones fácticas en resultados de IA sin verificación independiente.

Prompt para probar (con archivos de referencia adjuntos):

Aquí está mi Plan Brief: [pegar brief]
Aquí está lo que he construido hasta ahora: [describir o pegar resultado]

¿Lo que he construido hasta ahora sirve al objetivo y los criterios de éxito?
¿Qué me falta?
¿Qué debería cortar para llegar a una versión entregable más rápido?

Lista de verificación de salida

Todos los criterios de éxito del Plan Brief están cumplidos
Nada dentro del alcance fue omitido sin una decisión deliberada
El Plan Brief está actualizado (refleja cualquier cambio hecho durante el Build)
El resultado puede ponerse frente a una persona o sistema real
Los elementos fuera de alcance están anotados para trabajo futuro, no descartados en silencio