For founders shipping real product with AI in the loop. An essay worth your time, plus the sharpest things I've read, filtered hard. No hype. Just signal.
⏱️ The 30-second version
Some rules you write to direct AI work survive every project. Most you rewrite within weeks. Telling which is which is the real skill, and the week I got it wrong my studio went down for three days.
Sharpest read this fortnight: “When building gets cheap, judgment becomes expensive”, the cleanest version of the thing I keep saying.
This issue's question: don't open a file. Ask your team, or ask the AI itself, what's the one rule you'd never let it break? That's your fence. Vote below.
📄 The essay: “Rules That Hold, Rules That Don’t”
This April my entire AI studio stopped working for about three days. The rule that broke it was one I’d just rewritten, and I’d been rewriting that same rule every other week for months.
I’ve been writing direction files for AI work for ten months. CLAUDE.md, AGENTS.md, standing briefs, playbooks. Some rules haven’t moved since week one. Others I rewrite constantly. Telling them apart is the actual practice, and it isn’t universal: it depends on what you’re directing the work toward.
The ones that hold encode a cost you can’t take back. Lose credentials, lose client trust, ship a paragraph the client never approved. A rule that prevents one of those is a fence around a cliff. The ones I rewrite are the current best guess at how to shape the work. Those are paths through a field: useful while the grass is short, re-walked every time it grows back.
So which of your rules are fences, and which are just paths? Here's how I tell them apart now, and why the cliffs are different for a founder shipping product than they are for me.
📡 The radar
The best things I read this fortnight on building product with AI. I read them so you don’t have to. Click the ones that earn it.
Building product in the age of AI · 7 min
Guardrails beat guidelines, how to keep AI-generated code honest
By Michael (masimplo), software engineer of 20+ years and engineering lead at Covve.
The builder's version of this issue's whole idea: “you cannot build a quality system on probability.” Deterministic guardrails are fences, prompts are paths, and the guardrail outlives whoever wrote it.
Craft & judgment · 6 min
When building gets cheap, judgment becomes expensive
By Alexander Hipp, AI Product Lead.
The cleanest statement I've read of the thing I keep saying: when anyone can build anything, the scarce skill is deciding what not to. Speed stopped being the moat.
Building the business · 9 min
The solo founder scaling playbook
By Vikas Malpani, founder and investor who has scaled multiple ventures solo.
One rule in it is pure fences-vs-paths: don't automate anything you've done fewer than ten times. Automate an unstable process and you've just built tech debt with your name on it.
The industry shift · 8 min · paid
Slow down to speed up: how AI is changing software engineering
By Gergely Orosz, ex-Uber engineering leader, author of The Pragmatic Engineer.
This issue's “builder is never the reviewer” fence, with the data behind it: teams now ship far more AI-written code with far less human review, and Orosz traces a recent Instagram outage straight to an AI-generated, AI-reviewed change. The review step is the fence.
🔧 One thing worth trying
A single thing I actually used this fortnight. For you, not a listicle.
Plan mode before anything you can’t easily undo · 2 min to adopt
What it’s for: making an AI coding agent show you its plan, which files it’ll touch, in what order, before it executes, so you approve the intent instead of cleaning up the result.
What makes it click: use it any time the task touches more than a couple of files, or anything you can’t easily reverse (auth, billing, migrations). Thirty seconds reading the plan saves thirty minutes unwinding a bad one. (Clearest write-up: Claude Code in Production, 6 months.)
When to skip it: trivial, contained, reversible work, like fixing a lint error or updating a README. Plan mode there is just friction. It’s a fence for the cliffs, not every step.
🚦 When speed isn’t the problem
9 min
The founders who built a product before they built an opinion
A designer describes the founders landing on her desk: the AI build is polished, the onboarding works, the gradients are real. What isn’t real is who it’s for and what problem it solves. AI made them fast, and fast is good, it means they can learn from real users sooner. But the experience, the strategy, the decisions underneath: those come from listening to users and doing the design work, with or without AI. Speed was never the problem. Expecting the first build to be the right one was.
Your turn
Don't open a file. Ask your team, or ask the AI itself: what's one rule we'd never let it break, no matter how fast we're moving? That's your fence. Everything you rewrite every week is a path. So which is most of your list?
Open the file you use to direct AI work. Most of the rules in it are:
Know a founder who’d get value from this? Forward it.
Not subscribed yet? Get it in your inbox →
Build Less, Solve More is from Boald. We help founders build digital products that matter, with AI as the engine, not the pitch.