Designer and Programmer Working in Sync
A structured two‑mind workflow from brief to green gates
Parallel work in AiStudio is not a single chat thread.
It is two distinct roles sharing one repo under hard rails:
- Designer — read‑only; architecture, naming, seams, risks, critique
- Programmer — read/write; implementation under strict rules and build gates
This separation keeps speed high without drift.
The cadence below shows how a project moves from a raw brief to shippable code.
Roles and Shared Ground
Designer
- Reads the repo
- Shapes architecture, names, seams, invariants, risks
- Runs critiques and design reviews
- Cannot write code
Programmer
- Reads before writing
- Implements under rails (RBW, staging, green gates)
- Cannot change architecture without a new design pass
Shared Repo + Tools
Both roles see the same tree and the same facts.
All tool calls are visible through ObserverView so I can supervise the process.
End‑to‑End Flow (Chronological)
1. Brief from me
I describe the desired outcome. Unknowns are flagged.
If facts are thin, we trigger deep research (grounding lives in the research article).
2. Scratchpad + Q/A
Designer and I iterate in a scratchpad: fragments, risks, open questions.
The LLM asks clarifying questions and summarizes thin areas.
3. Design doc draft
When the scratchpad feels solid, I hand it to the Programmer.
The Programmer synthesizes it into a clean Markdown design doc in the repo.
This becomes shared context for both roles.
4. Design review pass
Designer reads the in‑repo design doc and comments on gaps or risks.
We loop once or twice until it’s “good enough.”
5. Structured start prompt
Designer produces a concise start prompt:
scope, seams, invariants, non‑goals, and constraints.
6. Implementation plan
I give the start prompt to the Programmer.
It returns a stepwise plan and then executes with strict rules:
- small steps (≈5–6 files) with green commits between
- strict SOC; files stay under ~200 LOC
- each step ends with a summary and next‑step plan
- I can simply say “next” when satisfied
7. Build‑and‑review loop
Programmer reads before writing, stages full files, and lands only through green builds.
If architecture needs to change, we bounce back to the Designer first.
8. Periodic design critique
At suitable checkpoints, Designer reviews the new code and issues actionable critique.
This keeps implementation aligned with the design doc.
9. Harness‑driven testing
When behavior matters, Programmer uses the runnable harness project:
it accepts args and returns stdout, stderr, and exit code.
Hard problems are solved inside this loop.
10. Finish
The loop continues until the feature is complete:
clean, structured, readable code that matches the design doc.
Guardrails That Keep Speed Without Chaos
- Read Before Write — always inspect the tree before editing
- Atomic writes — full‑file staged edits; no blind patches
- Hard gates — every landing path is a build; failures land nothing
- Visibility — ObserverView shows tool calls, staged deltas, and builds live
- Role purity — Designer never writes code; Programmer never rewrites architecture
- Rhythm — small, green, well‑summarized steps; easy to pause or say “next”
Why This Works
- Fast parallelism without parallel drift
- Early gap detection through scratchpad Q/A and design critiques
- Trustworthy implementation because every change is gated by real builds
- Full transparency through observable tool use
Quick Checklist
- Brief captured and unknowns flagged; research done if needed
- Scratchpad turned into an in‑repo design doc by the Programmer
- Designer issued a structured start prompt; Programmer produced a plan
- Steps are small, green, and summarized with next actions
- Design critiques applied; architecture changes loop through the Designer
- Harness used for runnable tests when behavior matters