For a long time I thought the leverage in working with AI came down to the model and the prompt: use the smarter one, phrase the ask better, and the output gets better. That’s not wrong, exactly. It’s also not where most of the actual difference has turned out to live.
Where That Assumption Breaks Down
I’ve tested this the expensive way, by running several AI-driven threads at once and checking in on each one briefly. The individual responses in any one thread weren’t noticeably worse than usual. What got worse was the overall result: decisions made without enough context, small inconsistencies between threads nobody caught because nobody was actually holding the whole picture at once, a plan half-steered and then left to drift.
None of that is really a model problem. It’s an attention problem wearing a model’s clothes. The model can only work with the context it’s given and the direction it’s steered in, and both of those come from whoever’s paying attention. Split that attention four ways and all four threads get a worse version of it, even if the model itself didn’t change at all.
One Thread, Everything Else Delegated
The fix wasn’t a better prompt. It was reducing back down to one actively steered thread at a time, and treating everything else as something to delegate rather than something to half-watch.
The minimal version of that is a single background thread picked up when it’s actually ready, instead of checked on out of anxiety every few minutes:
git worktree add ../feature-x feature-xOver the past week that idea scaled from a trick into an actual pattern. One entrypoint session does the active steering, the only one I actually work through directly. Everything else gets delegated to separate sessions, each in its own isolated environment, each running a real pipeline on its own: plan, design, implement, verify locally, then drive the result through review. I don’t look inside those sessions. They only come back to the entrypoint when something genuinely needs deciding, and they arrive with the decision already framed, what the problem is, why it matters, and the evidence for it, a screenshot, a design doc, whatever makes the decision possible without reconstructing the context first.
The output difference was immediate and a little absurd: one week running that pattern burned through two separate AI subscriptions. The number isn’t really the point. What matters is that almost none of the interruptions were status updates. They were decisions, and I could make most of them from a phone, laptop left awake and unattended, without needing to sit back down and rebuild context before answering.
Matching the Shape of the Work to the Goal
Prototyping doesn’t have one correct shape. Which shape is right depends on what you’re actually trying to learn.
Vertical, end to end slices make sense when the goal is shipping something real: pushing a thin path all the way through the stack surfaces the problems that would otherwise multiply if you built every layer in isolation first. Horizontal, breadth first exploration makes sense when the goal is understanding a space you don’t have a feel for yet: covering more ground shallowly, before committing to a corner of it and building down.
The two day trial that led to the job I ended up taking split cleanly along exactly that line, without either of us planning it that way in advance. Day one was horizontal: exploring the product broadly and modeling a fictional company against it, understanding the shape of the thing before touching anything real. Day two was vertical: one feature, start to finish, from client requirements up through the broader product vision, presented and defended at the end.
The Terraform provider for Beszel went the other way on purpose, because it wasn’t exploration, it was a build with a known destination. It moved through a staged plan, scaffolding, core framework, individual resources, CI/CD, release tooling, each stage a working slice before the next one started. Vertical the entire way through, because the goal from day one was a released provider, not a survey of what a Terraform provider for Beszel could look like.
Neither shape is the right one in general. They’re answers to different questions, and picking the wrong one for the goal in front of you wastes the exploration or ships something narrower than it needed to be.
Keeping the Context Honest
None of this works if the sessions doing the work are reasoning about a stale or incomplete picture of what they’re actually inside. The standing version of that is boring: docs that describe the actual project, kept current instead of written once and left to rot, running commands directly rather than relaying a summary of what they said.
The sharper version shows up in the handoff itself. A session that escalates well doesn’t just say it’s stuck, it arrives with a breakdown: what the problem actually is, why it matters, and the evidence for it, already assembled. That’s only possible because the context it built up along the way was kept honest the whole time, not reconstructed under pressure at the moment of asking.
The same discipline is what makes it possible to actually change a plan mid-stream, which happened in both the trial and the Terraform provider. The plan moved not just because I steered it somewhere new, but because the model pushed back on something in it and the pushback held up. Stale context turns that kind of pushback into noise, because neither side is actually looking at the same thing anymore.
Trust Isn’t One Setting
None of this collapses into a single verification story, and I don’t think it should. How much a piece of output gets checked, and how, depends on the task and what’s actually at stake if it’s wrong, not on a fixed rule applied the same way everywhere. Local verification and a review pass happen before anything reaches me at all, and that’s precisely what makes it safe not to look inside the delegated sessions directly, the checking already happened somewhere I don’t have to watch. I’ve written elsewhere about what that kind of calibration looked like on the Terraform provider specifically; the point here isn’t to repeat that, it’s that deciding how much scrutiny a given piece of work has earned is a different skill from the attention and process questions above, and it’s worth keeping the two separate rather than folding trust into “just pay closer attention.”
The Actual Point
None of the things that actually made this go well were about the model. One thread actively steered at a time, with everything else properly delegated instead of half-watched. A process shape chosen for the goal, not out of habit. Context kept honest enough that a handoff arrives already framed, and pushback means something when it happens. Trust calibrated to what’s actually at stake, not spent watching things that don’t need watching.
Those were the job before any of it had “AI” in the name. The wrapper changed. Most of the actual work underneath didn’t, it just moved a lot faster.
