The four-layer program design system: how to plan before the agent codes

The four layers, in order

Each layer answers a different question, and each one is deliberately made before implementation begins. Dex's framing throughout: spend a little time up front to raise the odds that what comes out does not need a round of fixes to merge.

1. Layer 1 — Product. What user problem are we solving, and how will we measure it? No tech at all: no databases, no schemas, no architecture. The PRD he shows on screen has a problem statement, a "how we measure success" section, and — borrowing the Amazon practice — the announcement post written before the feature is built, forcing you to explain the value to a user first. He also prototypes the relevant views as plain HTML mockups at this stage.
2. Layer 2 — System architecture. How the services fit together, the request flow, the new endpoints, the new tables and outlines of the queries. He notes this is the level most experienced teams have already reached — people are generally comfortable designing architecture back-and-forth with a model.
3. Layer 3 — Program design. This is the one people skip. One level below architecture: where the files are going to live, the types and method signatures, what the call stack looks like when this runs, and what the tests will look like. Deliberately not implementation detail. He cites a Dylan Mulroy (Cloudflare) post to the same effect — a good plan ends with the tests and the call stack. The point is that these are decisions the agent will otherwise make silently, and that you may not like.
4. Layer 4 — Vertical slices (tracer bullets). Models default to building horizontally — the whole database layer, then the whole service layer, then the whole API, then the whole front end — which leaves nothing testable until thousands of lines are done. A vertical slice is thin and end-to-end: mock the API endpoint, stub the front end, wire them together, and only then add migrations, business logic and error handling. Dex says he has never seen a model do this without a human telling it the order.

Why the planning sessions are cheap — and why that matters

The most concrete argument in the interview is about context economics. These design sessions are token-light: he pulls up one in progress sitting at 43,000 tokens with the PRD read in and most of the endpoint and flow decisions already made. His reasoning:

• Once the model has written hundreds or thousands of lines, changing direction is harder — you are deep in a context window, there is a great deal of context loaded, and the run is already biased toward the choices the model made first. Sub-agents do not fully solve this.
• Early in a long context window you get the most model intelligence per token. Making structural decisions there is the cheapest they will ever be.
• He prompts for output in code blocks — types and method signatures — specifically because those are fast for a human to scan and judge right-or-wrong, which is what makes the review take minutes.

A related trick raised in the conversation, credited to Victor Tali: after a change, ask the model "while working on this, which choices did you make that you're not confident of?" Dex's system is described as doing the same thing in the opposite direction — surfacing those choices before the run instead of after it.

Measurable goals beat instructions

Both speakers converge on the same point: an agent given a number to move will go much further than one given a description. Dex calls it back-pressure — LLM-as-judge is acceptable, but a real metric tied to the business (conversion rate, a resource-reduction target for a CUDA kernel) is what lets an agent run an experiment, check the data each day and pick a winner. David's framing: "if you can tell it a measurable output, the agent will move mountains for you."

Gotchas & Caveats

• The "light software factory" — never reading the code — did not work, and the failure is instructive. Dex's team ran it in July 2025: reviewing plans and tickets, not code. They then hit a bug in a shipping desktop app that no amount of prompting could fix — several frontier models in a council kept diagnosing the wrong cause and shipping fixes that did not fix it. Resolving it meant going back into a codebase nobody had read for three months and working through unfamiliar, sloppy code for weeks while users were angry. His thesis: the odds of this happening to you are higher than the odds that the models get good enough before it does.
• David's counter, which Dex accepts: the requirement may be understanding the logic rather than the literal code — what the first five minutes of onboarding does, what happens when someone cancels, what fires when this endpoint is hit. The failure mode is losing the shape of the system, not skipping a line-by-line read.
• Guard against silently losing the thread. They describe a prototype that quizzed the operator mid-session on the current state of the codebase and what the new implementation changes, using multiple-choice questions and Mermaid diagrams. David's version: have the agent deliberately slow down and educate you when you start losing grip.
• Benchmarks reward the wrong thing. Dex's objection is structural, not vibes: reinforcement learning scores traces on whether the human-written tests pass, and on problems like SWE-bench multilingual the golden patch is often 100–200 lines. There is no penalty for bad design anywhere in that loop — which is a coherent explanation of why models solve problems well and still produce code that is hard to maintain.
• There are times to skip all of this. Pre-product-market-fit, when the job is putting many different things in front of customers to find what they will pay for, he calls this overkill. It starts earning its keep at roughly five-plus engineers, with paying users and a six-month maintenance horizon.

Also covered: routing incidents into the loop

A smaller but immediately usable idea. Instead of paging a human at 3am, route the incident straight into the agent pipeline — "I don't wake up to an alert, I wake up to a pull request." The same applies to triaging part of a support queue directly to an agent. David describes a working version of this: GLM 5.2 reviews every uptime incident on his API product and returns a report classifying it — provider outage with nothing to do, or a missing migration with a specific fix — running on cron jobs on Vercel and GitHub Actions, with a small agent loop on render.com doing the inference.

Key Takeaways

• Four layers before code: product (problem + metric + announcement post), system architecture (services, flow, endpoints, tables), program design (file locations, types, method signatures, call stack, tests), vertical slices (thin end-to-end first).
• Program design is the layer almost everyone skips, and it is where the agent makes decisions you will dislike later.
• Make structural decisions early in the context window, where they are cheap and the model is sharpest — one planning session at 43k tokens is worth more than re-steering a 3,000-line diff.
• Ask the model which choices it was not confident about — before the run, not after.
• Give the agent a real measurable outcome rather than a description of the work.
• Fully removing yourself from the code is a bet you will probably lose; the useful target is keeping the system's logic in your head, not reading every line.