We stopped whiteboarding architecture, and let the agent interview us instead

the decision nobody wrote down

Every senior developer has lived this cycle. A spec lands, mostly solid, and now someone has to figure out how it actually gets built: which service owns the change, whether it’s a new module or an extension of something that already exists, what happens to the data that’s already sitting in production. That conversation used to happen in a Slack thread that scrolled out of relevance by lunchtime, or a whiteboard session where the photo of the board was the only artifact anyone kept.

Most of those decisions were fine. A few of them weren’t, and you didn’t find out which was which until months later, when someone asked “why did we do it this way?” and the honest answer was a shrug, because the person who made the call had moved to another project and the reasoning had never left the room. Architecture decision records were supposed to fix this. In practice, under deadline pressure, they were the first thing to get skipped, because writing one felt like paperwork layered on top of the actual thinking, rather than the thinking itself.

We wrote about our agentic SDLC a little while ago: six staged phases, each with its own gate, though several of them run inside the same command, AI agents doing the volume work while our team makes every call that matters. Our PM wrote the first close-up, on Discover (our /feature command), from the seat of the person who runs it. This is the same thing, one phase over: Design, from the seat of the person who owns that gate.

I’ll be specific, because the short version sounds like the same story with different words: the design phase that used to cost us days of meetings now closes in about an hour, and the difference isn’t speed for its own sake. It’s that every real trade-off gets written down, and the ones that aren’t real trade-offs don’t generate paperwork pretending to be one.

what actually changed: from deciding alone to being interviewed

The old workflow put the entire weight of the architecture on whoever was in the room when the question came up, usually me, sometimes whoever was free. It was our job to hold the whole system in our head, spot every place a change would ripple, and remember to write it down afterward, if we remembered at all.

The new workflow inverts that. I don’t arrive to draw the diagram. I arrive to be interviewed for it.

You run a single command in Claude Code, and Claude reads the validated spec and the acceptance tests from Discover, scans our actual codebase, and interviews me one trade-off at a time, in the order the decisions actually need to be made. My job stops being “have I thought of every place this touches the system?” and becomes “which of these two real options do I actually want, and why?” That’s a narrower question, and a much harder one to get wrong, because it’s grounded in code I can go and look at while I answer it.

It doesn’t ask me how I’d architect it. It asks me why, one fork at a time, until only the real decisions are left.

you don’t need to arrive with the architecture already decided

This is the part that surprised me, so I’ll say it plainly: you don’t need to walk in with a design in your head. You need the validated spec and the acceptance tests Discover already produced. That’s the whole prerequisite.

Before it asks a single question, the agent scans the codebase silently, the services, the models, the routes, the permission layer, and finds every real anchor point the change will touch. You get to see the plan before it executes it, and you get to argue with it.

That grounding is why the questions don’t feel abstract. It doesn’t ask “how should we architect the reallocation logic?” It asks whether we extend the existing allocation service or introduce a new one, because it already knows the allocation service exists and roughly what it currently does. The question is real because the premise is real.

inside the interview: one fork in the road at a time

Here’s what the session actually feels like, because “AI-assisted architecture” could mean almost anything.

It works through one decision at a time and won’t move to the next until this one has an answer with a reason attached. It doesn’t ask for a design. It asks for a choice between options it has already identified from the code, and it writes an ADR only when the choice had a genuine alternative. A change with no real fork in the road gets zero ADRs, and that’s treated as a correct outcome, not a shortfall.

The moment that stuck with me from our own session looked small at the time, and it mattered more than anything else that came out of that hour. We were designing how mid-month allocation changes should flow through the cost engine, and there was a known bug in how salary changes got blended into an engineer’s historical cost. My instinct, the one I would have acted on without a second thought in the old workflow, was to just fix the bug where it lived. The interview stopped me. Fixing it in place, it pointed out, would silently rewrite every historical forecast the system had ever produced, not just the ones going forward. That’s not a bug fix, that’s a change to what our historical numbers mean, and it needed to be a decision, not a side effect.

“It found a fork I would have blown straight through. Fixing the salary bug in place would have silently rewritten every historical forecast, the interview made me choose that out loud, in writing, before a line of code existed.”

That’s the whole value of the phase in one moment. Not that it’s smarter than a senior developer about the domain, it isn’t, I still made the call. It’s that it refuses to let a real fork pass as a non-event just because fixing it felt like the obvious next step.

the moment it earns its keep

We ran this on the same P&L engine Discover was run on, continuing straight from the spec and acceptance tests that phase produced. One session, roughly an hour, difficulty triaged moderate to major depending on the area. In principle a feature can earn zero ADRs, when it turns out there was no real fork in the road, but in practice, across the six features we’ve taken through Design so far, the count has ranged from one to five. On average that’s landed at two to three ADRs per feature, which is roughly what you’d expect from a system that’s honest about which decisions are real.

Validate-design, the check that runs before anything moves to planning, runs in session and doesn’t persist its reports, so this is an observation, not a metric we’re tracking automatically: in our sessions so far, it’s been catching under two gaps per feature, missing coverage, a claim about existing code that didn’t resolve to anything real, an open question from the spec nobody had closed. Small numbers, but they’re gaps that would otherwise have surfaced during implementation, where fixing them costs a rewrite instead of a sentence.

what you walk away with: artifacts that don’t rot

The output isn’t a whiteboard photo or a paragraph buried in a ticket. Two things come out of the phase, and both are treated as contracts the rest of the pipeline answers to, not documentation for its own sake.

A system design, with ADRs for the decisions that were actually decisions. Components, data flow, the real file paths the change touches, so the plan phase and the reviewer after it can check the design against the same code the design claims to extend. Zero ADRs is a valid, sometimes correct, output. So is five.

A UX spec, scaled to what the change actually needs. A backend-only change gets a short note explaining why there’s no UI impact, which matters, because it means “no design” was a decision, not an oversight. That’s been every feature so far. When a substantial UI change comes through, the same skill produces a full screen-by-screen spec and mockups built from our real compiled CSS, not generic placeholders, we just haven’t had a feature with enough UI surface to exercise that path yet.

Before either is allowed to be called done, validate-design checks three things: every acceptance scenario maps to something in the design, every place the design claims to extend existing code actually resolves to code that exists, and every open architectural question from the spec is either resolved or explicitly carried forward with an owner. The loop that fixes gaps runs a bounded number of times; if it can’t close them, it stops and hands the discrepancy to a human rather than quietly shipping a design that doesn’t match the code underneath it.

the gate didn’t move, the thinking did

The question I get most often is some version of “so does the AI decide the architecture now?” No. I still sign off. That part didn’t move.

Design ends at a gate, and I own it. The bar is concrete: zero blocking gaps from validate-design, every architectural open question resolved or carried forward with an owner, the difficulty triage acknowledged rather than silently overridden. What changed isn’t who’s accountable for the call. It’s how much of the real thinking has already happened, out loud and in writing, by the time I have to make it.

doing this as a senior developer

I want to be direct about what this asks of me, because it isn’t what I expected going in. It doesn’t ask me to type faster or draw a cleaner diagram. It asks me to recognise a real trade-off when it’s in front of me, and to say, out loud, why I’m choosing one option over the other. That’s the part of the job that was always the actual job. Everything else, remembering every file the change touches, holding the whole system in your head, writing it all down before you forget, was overhead that happened to require seniority to get right, without being the thing seniority is actually for.

The override matters here too. It announces its difficulty read up front, trivial, moderate, or major, and I can push back on it, the same way I’d push back on a junior engineer’s read of a problem: not because the tool is untrustworthy, but because judgment about how much ceremony a change deserves is exactly the kind of call a senior developer should keep making. The agent proposes. I still decide what the change earns.

why this matters beyond one phase

Design is the second of six phases, but it’s the point where Discover’s clarity either compounds or gets lost. A validated spec is only as useful as the architecture built on top of it, and an architecture nobody wrote a reason for is a liability with a delay on it. Every ADR this phase produces, and every one it correctly declines to produce, is an input the plan phase, the build phase, and the reviewer after that all depend on being accurate.

Which is really the same lesson from the other side of the process: the bottleneck was never drawing the diagram. It was making the decision, and writing it down, at the point where it was still cheap to change.

what’s next

This is the second in a series looking at each phase of our agentic SDLC in turn, each written from the seat of the person who owns that gate. Four more to go: Plan, Build, Review, and Ship.

If you’re a senior developer or tech lead tired of finding out about an architecture decision the day someone asks why it was made, or a leader wondering what “human in the loop” looks like at the design table rather than on a slide, we’d be glad to talk.