Was this newsletter forwarded to you? Sign up to get it in your inbox.
I’m shipping more than I ever have, but I think my brain has gotten softer.
For the last year, I’ve hunted for the parts of coding that still needed me, then replaced myself with something that could do it, whether that’s a skill, a framework, a data source, or a step that routes work to the next agent. This is the essence of Compound Engineering: Teach the system to work once, and it does that work forever. This is how I build Cora, Every’s email assistant, and across my career, I believe it to be the best product and engineering work I have done.
But somewhere along the way, I found that I had lost a feeling. It used to be that learning itself was the reward. But my mind increasingly felt like a TikTok feed—full of short-lived hits of dopamine that left nothing behind.
I started to notice that although the work was improving, I wasn’t. My own mind was the part of the system I had forgotten to measure.
So I built another loop into my system—to fill the gaps in my understanding before they became blind spots in my judgment.
The dark factory turns out the light in your head
When building a product, getting out of the AI’s way is usually the right move. It makes sense to route around yourself when you are the slowest part of the system. But if all you’re thinking about is the product, you’re neglecting your own development.
The “dark factory” describes an ideal state for automation in manufacturing: lights off, nobody on the floor, machines running through the night. But the risk, when automating your own work, is turning out the light in your head, too.
Plenty of work should run in the dark. When we rebuilt part of Cora’s inbox, we noticed that the space between the rows was four pixels too small. It was simple to have an agent diagnose the bug, restore the spacing, write the tests, and open the pull request—the package of code changes ready for review. My understanding would not have changed the decision. But it was important to understand it anyway.
Plenty of work looks mechanical until you understand enough to see the decision hiding inside it. Those are the places where I want to keep the lights on.
Read the code to learn
Last year, I wrote about how I stopped reading every line of code during code review. That’s still true—I don’t read code to verify the work. The planning, testing, and review agents handle that better than I do. What’s changed is that recently, I’ve started reading the code again. Not to check the work, but to learn. If your only reason for opening a diff—the line-by-line view of what changed—is suspicion, reading harder will not fix your process.
Here’s an example of what I mean: Back in July, I asked /ce-explain—a command I built that explains a concept or change by tracing it through my own codebase—to walk me through how Cora turns a change in Gmail into something a customer sees: Gmail flags the change, Cora waits a moment so related changes can arrive together, then works through the batch message by message. That one pass replaced dozens of scattered details with a single picture I could hold in my head.
Two weeks later, that picture is what let me tell the difference between a fix that sounded right and one that actually was. A customer reported that Cora had permanently deleted emails he’d already sent—his audit logs showed several deletions, one just seconds after he hit Send. I suspected a recent speedup had let two parts of the system collide, and I was right: A change that made part of the cleanup process run much faster had exposed a bug that had been sitting there for months.
I pointed /ce-explain at the failure this time instead of a feature, and asked it to reconstruct what happened. Cora had created a draft in Gmail and saved its address to clean up later. The customer opened that same draft, edited it, and sent it. The saved address still worked, but Cora’s cleanup process had no way of knowing the draft wasn’t a draft anymore. It deleted the message anyway. The first fixes proposed were reasonable-sounding and both wrong: Wait 30 seconds before deleting, or skip deletion if Cora had just sent the draft itself. Neither matched what had happened—the customer had sent it through Gmail, not through Cora, so there was no signal to check, and 30 seconds was only a guess about Gmail’s timing. What I pushed for instead was a rule that didn’t guess: Before deleting anything, ask Gmail directly whether it’s still a draft, and if Gmail can’t say for certain, delete nothing. Within hours of shipping that rule, it was tested for real: The same dangerous condition came up again, and this time the guard refused to proceed.
I didn’t need to read every line of the fix. I needed to understand the system well enough to recognize that a plausible-sounding answer wasn’t a safe one.
That’s what you contribute to an agentic workflow: not code, but discernment—knowing where to point the agent, when to stop it, and which of two reasonable-sounding plans will hurt you six months from now. Left alone, it doesn’t hold steady, but erodes.
A codebase compounds from the ground up. If a person doesn’t compound alongside it, the two curves start to diverge: The system keeps getting more capable while the person’s ability to judge it keeps getting weaker.
This isn’t just a casual observation. Researchers Margaret Mitchell, Avijit Ghosh, and Samir Passi reviewed the evidence on this in a recent paper and found a consistent pattern: Extended use of AI agents measurably erodes the vigilance, critical thinking, and domain skill that human oversight depends on. While AI agents are new, the phenomenon isn’t. It was called the “irony of automation” as far back as 1983, by a safety researcher studying human operators of automated factories and power plants. The more capable the automation, the more the human’s own skill erodes. Agents just made it move faster.
Four ways I compound the human
Discernment is built the same way a codebase is: one accumulated piece of understanding at a time. Here’s what that looks like day to day. None of these depend on Cora, /ce-explain, or any particular tool; they work with whatever agent you’re already pointing at your own codebase.
1. Open the files tab again and keep a list. Revisit a pull request you merged without reading. When you hit something you don’t recognize—a pattern, a library, or a call you wouldn’t have made—ask the model why it chose this approach. You don’t need to understand every line. Notice every place you don’t and keep those gaps as your syllabus.
2. Ask for the mechanics, not the diff. Most changes depend on existing code paths the diff never shows you. Ask where the process begins, what happens next, where the information goes, and which other systems touch it. A map of the whole journey is easier to reason with than a pile of changed lines.
3. Recover the reason the code can’t show you. Design choices that look needlessly complicated in isolation usually have an incident buried behind them—a fix for a failure that already happened once. Ask why: Why does this write to a log instead of acting immediately, why does this retry three times instead of once, why does this validate a field that looks obviously fine. The code shows you what the system does. The history explains why someone built it that way—and until you know that, you can’t tell whether removing the safeguard is a simplification or a regression waiting to happen.
For me, that meant learning why Cora writes every intended action to a permanent log before acting on it. A database change once mixed up which record IDs mapped to which actions, corrupting hundreds of thousands of records overnight. Because the log of intended actions had survived, we could replay it and recover in two days instead of rebuilding from scratch.
4. Let the model quiz you without turning the quiz into a gate. I got this from Thariq Shihipar: After a long session, ask for a written explanation and a quiz on any change. He merges only after a perfect score. I let tests decide whether the work can merge; the quiz finds what I still need to learn. If I miss a question, I keep the miss on my list.
‘But I only care that it works’
The objection I hear most is some version of “I only care that it works”—and it’s also one I’m least equipped to wave off, because as a general manager, caring about outcomes over process is literally the job. My version of it is more specific: Product judgment comes from watching users, not from reading diffs. Some of my best calls came from watching somebody use Cora and feeling the wrongness of it. Reading the source code wouldn’t have gotten me there.
But on an AI product, what looks like a taste question is really a mechanics question in disguise. Deciding what Cora should do with a 40-message thread means deciding how much context the model gets, how long the customer waits, and how much the request costs. If I don’t understand those tradeoffs, I can’t tell whether a proposed limit is a real constraint or just the first version that happened to work.
Technical understanding doesn’t replace taste, but gives me what I need to apply taste to products I couldn’t otherwise imagine or evaluate.
Turn the light on
The tools that once felt like my edge are becoming easier to copy. Domain knowledge and the judgment to know where to point the machine at are not. Experienced people are the most exposed here—junior engineers run into unfamiliar things constantly, but if you already know a lot, “I know this” is always available as an excuse.
So force it. Pick the task you have been routing around for years, then define a measurable version of it. Replace “get better at the back end” with “find where this request spends its time and take 50 milliseconds off it.” Replace “understand the front end” with “explain why this component renders three times.” The specificity makes the work possible, and the resistance you feel is useful information. In doing this myself, here are three things I’ve come to understand:
There’s no substitute for wanting to learn. Even a strict gate can lose to a tired Friday afternoon, and /ce-explain was never a gate to begin with. It can’t make me want to learn—it simply takes away the excuse that I don’t have time to write the lesson myself.
Knowing how to use the tool is not knowing the work. Learning how to use AI is worth doing, but learning the work it’s doing for you is a separate task, and the easier one to let slide.It’s tempting to spend all your attention on the harness around the model, the routing and the prompting, and forget that the point was the product.
Understanding doesn’t stay once you’ve earned it. I do this most days now: one concept, pushed a little further than is comfortable. It makes the work less overwhelming, and more fun. AI can make us more human, but only if we keep choosing to stay in the work.
Kieran Klaassen is the general manager of Cora, Every’s email product. Follow him on X at @kieranklaassen or on LinkedIn. To read more essays like this, subscribe to Every, and follow us on X at @every and on LinkedIn.
Everyone’s a builder now. Every All Access gets you the full membership plus the Builder Pack—$9,000+ in credits for the tools we build with.
