Guard the ideas, not the lines
Salvatore Sanfilippo, the creator of Redis, wrote a post recently called Control the ideas, not the code. The short version: AI now writes more code than any human can read, so reviewing it line by line is a losing game. The place a programmer still matters is one level up, in the ideas the code exists to serve.
Nobody should anymore look at this code, but only at the ideas the code contains.
We build Boswell with AI in the loop every day, so this landed. Here's how it looks from a small team shipping a Mac app.
The arithmetic doesn't work anymore
An agent can produce a few thousand lines before lunch. You cannot honestly review a few thousand lines before lunch. You can skim them, which feels like review but isn't, or you can admit the bottleneck moved.
And every hour spent skimming is an hour not spent on the work that actually decides whether the software is good: the design, the tests, the question of what to build next. Sanfilippo's point is that the trade was always there. It was just easier to ignore when the code came out slowly.
None of this is new, either. Peter Naur argued back in 1985, in "Programming as Theory Building," that the real program is the theory in the builders' heads, and the source text is only a lossy record of it. Fred Brooks wrote a year later that the hard part of software was never typing it in; it was the conceptual construct behind it. The old books had it right. AI just made the typing free.
What we hold on to instead
Boswell is, at bottom, a handful of ideas. Audio gets transcribed on your Mac and doesn't leave the machine that recorded it. No bot joins your call. Your notes sync through your own private iCloud, not a server we run, and export as plain Markdown that outlives any app, including ours.
Code that upholds those ideas can be rewritten, refactored, or regenerated, and the product survives. Code that quietly violates one of them is a bug no matter how clean the diff looks. So that's where our review attention goes: not "is this loop idiomatic" but "does anything in here open a network connection it shouldn't."
That doesn't mean we never read a diff. Code that touches permissions, audio capture, or anything that talks to the network still gets human eyes, because that's where the promises live. It means we stopped pretending we read all of it.
In practice that means the durable artifacts aren't the source files. They're the design notes that say what the app promises, and the tests that fail loudly when a change breaks a promise. The code in between gets churned by agents all the time. The ideas don't.
A concrete example: recording, transcription, and dictation are supposed to work with the network unplugged. That's not a code-review checklist item, it's a promise we can test. If a change makes recording reach for the internet, we want a red test, not a sharp-eyed reviewer having a good day.
The honest caveat
Sanfilippo flags it and we'll repeat it: this only works if you already understand the layer below. You can't judge a design you couldn't have built. If you're early in your career, write the small database, the interpreter, the audio pipeline, by hand, at least once. That's how you earn the altitude.
The part that doesn't change
Tools for writing software will keep changing under our feet. What Boswell is supposed to be, an accurate listener that keeps your conversations in your own hands, was decided by people and stays decided by people.
The code is how we say it this week. The ideas are what we mean.