Brief to Build

Turn a natural-language request into a structured brief, a Codex-built landing page, and browser-verified revisions.

Comment

Inspiration

The hardest part of creating a landing page is rarely typing the HTML. It is converting an ambiguous business request into a coherent chain of decisions: who the page is for, what promise it makes, which evidence is safe to use, what information comes first, how the call to action works, and what “done” means on desktop and mobile.

Small teams either coordinate several specialists or ask an AI to generate a page in one shot. The first path is slow; the second often hides assumptions and makes revisions unpredictable. We wanted a third path: an inspectable production workflow where Codex implements an approved specification and can revise one section without destabilizing the rest of the page.

What it does

The user starts with one natural-language request. Brief to Build extracts requirements, identifies missing information, and explicitly lists reasonable assumptions. It then creates a strict LP Blueprint containing strategy, information architecture, copy, design direction, asset planning, compliance constraints, an implementation plan, QA requirements, and allowed revision boundaries.

After approval, a feature-scoped Codex App Server adapter creates the real self-contained landing page inside a dedicated workspace. The app launches a tokenized local browser preview, checks the artifact against the Blueprint, and lets the user switch between desktop and mobile views.

The user can then select one section and send a focused revision back to Codex. The system verifies that shared CSS, the selected layout, protected attributes, and all non-target sections remain unchanged. It runs QA again and makes the final HTML available only when the quality gate passes.

How we built it

  • Next.js 16 and React 19 for the product interface
  • TypeScript and Zod for strict contracts across Intake, Blueprint, Document, QA, and Revision artifacts
  • Codex App Server for ChatGPT-authenticated implementation and focused revision
  • parse5 for structural HTML inspection
  • A feature-owned immutable workspace and atomic revision pointer
  • A tokenized loopback preview server for generated artifacts
  • Deterministic QA for copy coverage, CTA and form presence, links, layout contracts, safety policy, and responsive requirements
  • A deterministic compiler retained as a clearly labeled design preview and fallback

Four visual tones are independent from three responsive layout patterns—Split, Editorial, and Bento—so visual choices do not change the content contract or revision boundary.

How we used Codex and GPT-5.6

Codex is part of both the product and the Build Week development process.

Inside the product, Codex receives the validated implementation contract and produces the landing-page artifact. Its structured result is validated before storage. For revision, Codex receives only the selected section, the issue, the requested change, and explicit invariants for everything it must not modify.

During Build Week, GPT-5.6 and Codex were used to audit the host architecture, define the narrow public boundary, extend the LP contracts, implement the end-to-end flow, test failure cases, and review the final changes.

Human control remains over product scope and high-impact decisions. Image generation is optional, the deterministic fallback remains available, the host application stays private, and an artifact that fails QA cannot be exported.

Challenges we ran into

The main challenge was making agentic implementation useful without giving it an unsafe or ambiguous workspace. A normal “generate this page” prompt was not enough. We needed a contract that could prove which layout, copy, sections, and constraints had been approved, then verify that the generated HTML matched them.

Focused revision was another difficult boundary. We solved it by preserving section markers and signatures for tags, classes, protected attributes, shared CSS, the page shell, and every non-target section. This lets Codex improve one section without silently rebuilding the page.

We also deliberately kept image generation outside the critical path. The product remains useful and demonstrable even when an image provider is unavailable.

Accomplishments that we are proud of

  • A complete request-to-code-to-QA-to-revision product experience
  • Real Codex-authored HTML rather than a mocked “AI generated” result
  • Explicit assumptions and missing-information reporting
  • Immutable revisions and a bounded, section-scoped correction loop
  • Deterministic safety and Brief-matching checks around an agentic implementation step
  • A fallback path that is clearly labeled and never presented as Codex output
  • 27 passing tests across 5 test files and a successful production build

What we learned

The best role for an implementation agent is not to replace product judgment. It is to operate inside a clear contract. Separating the Brief, implementation plan, artifact, QA result, and revision request made the system easier to trust and much easier to debug.

We also learned that graceful degradation is a product feature. Optional visuals can improve approval, but they should not decide whether the core workflow succeeds.

What's next

  • Add optional GPT Image visual-direction approval without blocking implementation
  • Add automated visual-regression coverage for all layout and viewport combinations
  • Explore additional landing-page templates after the core workflow is proven with users

Built With

Share this project:

Updates