#013 - Plan Once, Then Get Out of the Way
June 19, 2026
Enjoying this newsletter?
Subscribe to get future issues
June 19 2026
A few issues ago I planted a flag: building software in a calmer, more process-oriented way.
The thesis is simple: in the AI era, the human-in-the-loop work moves to the front. Not to the middle, not to the end. The front. The leverage isn’t writing code. It’s planning the product and the engineering together, then encoding those decisions so the agent can run the compressed middle without you babysitting every step.
Conventions Are the Unlock
Before any of this works, you need to encode your decisions. House style. Testing rules. Architecture patterns. How the codebase is structured. What the agent should reach for by default and what it should never do.
This is what AGENTS.md and CLAUDE.md files and skills are for. Spend some time here, it unlocks real leverage.
The convention layer is what makes a deliberate human-in-the-loop possible. Without it, you’re either re-explaining yourself on every task or constantly cleaning up surprises. With it, you show up at the gates that matter and step back everywhere else.
The gates that matter: planning, a spot-check review, and testing. Everything between those three is compressed by the agents’ work.
Human in the loop.
Here’s what actually gets automated: most of the implementation, most of the code review, most of the formatting, most of the mechanical decisions and the pre-deploy prep.
Here’s what stays human: the upfront plan, confirming the agent followed it, and testing everything before it ships.
The review gate has gotten lighter recently for me. For me, it’s no longer a line-by-line read. I fan out several models to look at the code and ensure its quality and security matches my standards (which I've encoded into a review skill and a fan-out process). So I mostly focus on a spot-check: did the agent build what we planned? Is the code coherent and does it follow what I asked? Did the architecture hold? Did anything drift? I'm confirming a plan, not re-evaluating the codebase from scratch.
The testing gate is non-negotiable. I test everything myself. Not because I don’t trust the agent (I don't truly trust them, yet); because no one else is going to catch the edge cases in the real product.
Plan the Product and the Engineering at the Same Time
The rollout strategy is the architecture. How a feature ships directly determines how it gets built. If you plan those separately, you pay for it later in rework, in edge cases you didn’t anticipate, in a system that does the right thing technically but ships wrong.
Planning with an agent is a real back-and-forth. I’m not dictating a spec at it. I talk through what the feature does, and it pushes on the parts I’ve left vague: how does this roll out, who sees it first, what does the cutoff look like, what’s the migration path. It surfaces the tradeoffs I’d have hit three days into the build, while they’re still cheap to change. By the time that conversation is done, the shape of the code is already decided. The agent is executing a decision we reached together, not making one on its own.
Money Code as the Real Test
PHAiTO recently relaunched. You can check it out at phaito.com.
PHAiTO combines the latest advancements in artificial intelligence with the expertise of human retouchers - it's a really cool software and I'm proud of the work we were able to do on it as a very small team!
One of the biggest things we shipped for the relaunch was a full subscription and billing system. Stripe, webhooks, upgrades, downgrades, pauses, resumes, grace periods. The whole 9 yards.
This is the scariest kind of code to hand an agent. Money code. If the webhook handler has a bug, customers get double-charged, or get locked out of an account they paid for. If the upgrade logic is wrong, you find out from an angry user at 11pm. There’s no “we’ll fix it next sprint” when it comes to billing.
So the planning gate had to carry the weight up-front. And the striking part was how much of the engineering got decided by product questions.
The rollout was: hidden by default, then manual enrolment of a handful of users, then a hard cutoff. We kept the legacy pay-as-you-go system running underneath as a fallback, for both product and engineering reasons. Every one of those choices was also an architecture choice. Deciding to enrol users by hand is what produced the per-user feature flag, the middleware that gates it, the extra API field, the admin toggle. I didn’t design the rollout and then design the system. It was one conversation: how billing would ship and how it would be built were the same set of decisions.
Once that plan existed, the agent ran the build against it. My job at the other end was small and specific: spot-check that the architecture matched what we planned, then test every path myself (and with help from the team), end to end, before it went live.
A full billing system, device management, and an account overhaul, built, tested and shipped in just a couple weeks, while working on many other projects at the same time.
My interview skill
The planning is the one part of this I won’t automate. It’s too important. The decisions made during planning determine everything downstream.
So here’s the tool I use to do it.
The /interview-me skill is a structured interviewing skill for your coding agent. You run it before building anything. It walks you through the questions that actually matter: what the feature is, who it’s for, where the edges are, and how it should ship. Then it hands off to the engineering questions: architecture, patterns, tradeoffs.
The default mode is product + engineering together (but you can do them separately if needed). One session, one plan, product and engineering fused before the agent touches a line of code.
I’m releasing a public version. Take it, install it, customize it, use it before your next build.
Cool stuff from the web
I Improved 15 LLMs at Coding in One Afternoon. Only the Harness Changed. by Can Bölük
Hard proof for the convention-layer argument. Bölük swaps the harness, not the model, and 15 different LLMs all get better at code. The leverage was never the model. It’s the scaffolding you build around it. Exactly the thing I’m arguing you should be investing your time in.
Agent-Native Engineering by Andrew Pignanelli
generalintelligencecompany.com
The same idea taken to the org level. Rule specifications over review. Tests as the quality gate instead of line-by-line reads. Engineers becoming tech leads who decompose and oversee instead of typing. A good look at what happens when you push the compressed-middle model across a whole team.
Keep shipping,
Joey
P.S. PHAiTO is live. Go take a look at phaito.com and see what we built - and pass it along to any photographers you might know!