I know a lot of us don’t read the code, but I jumped too quickly into it. An incredibly kind PR review from a Replicated engineer set me straight. He had great taste in code and I realized I was wasting his time by not applying my own. I wasn’t as fluent in Go (or the codebase) but I know what good code is. I just got lazy.
The latest incarnation of this tendency is relying on the summary of context artifacts. When I’m working with an agent to brainstorm and plan, I read what they tell me about the document, nod along, and move on. I too often skip the part where I read the actual brainstorm or plan. When I don’t skip it, I almost always find something just a little off. Something my tastebuds detected when my eyes didn’t.
Most of what I’ve built over the last few months has followed the principles of Compound Engineering. It’s the soundest approach to engineering context I’ve encountered, and I was engineering context before I knew that’s what it was. The pattern took over how I worked after reading Harper Reed’s My LLM codegen workflow atm. I’d adopted a loop like Dex’s RPI before he and I even talked about it, and it changed how I worked and wrote end to end, not just with code. Sensitive email? Strategy doc? Performance review? Cute note on flowers I sent my wife? I ask-me-one-question-at-a-time-d my way though all of it.
This was a modern answer to something I’d internalized so deeply didn’t think about it: the later you find the problem, the more expensive it is to unwind. That was true when hundreds of people were riding waterfalls to systems that didn’t work. It’s still true when an agent does all of it in 20 minutes. Maybe even more true, because speed makes the drift feel like progress until you finally stop and look at what got produced.
That’s why context-oriented approaches like spec-driven development matter. It’s why Compound Engineering lets you ship like a team of five. It’s why RPI evolved to QRSPI. All of these ideas are trying to solve the same problem. We need to catch drift while it is still cheap, legible, and we’re still emotionally able to correct it. The context artifacts we create along the way aren’t just for ceremony. They are the surface where work gets done. Which is why my little moments of “the summary looks good” eventually turn into much bigger moments of “why the fuck is it doing that”.
When I don’t read the brainstorm, I’m damaging the plan in an unknown way. Skipping the plan damages the code in other unknown ways. The little detail the model missed in each one might even have escaped a human collaborator. But it drifted just enough from my intent to have an exponential impact on how I feel about the final results.
I need to make judgments throughout the process. Not just directional nudges. I need to verify, find errors, and assert my taste. I need to listen to the small reactions that tell me something’s off before I can even articulate why. No one, agent or human, can relay my intent as well as I can. The best collaborators can do is bring their own attention to the artifacts that are supposed to carry that intent. When I pass up the chance to judge, the real risk isn’t skill atrophy down the road. It’s that I’m abdicating responsibility right now.
Only I can catch the moments where the right response is: “I can see how you got there, but that’s not what I want at all.” If I don’t care enough to do that, it doesn’t matter if I have the newest frontier model and the hottest harness. I still won’t get what I wanted.
There’s something familiar about that sentence: “I can see how you got there, but that’s not what I meant.” That is exactly what users have always hated about programmers. Yet here I am, someone who still identifies as a software developer at cocktail parties, putting myself in the same position. I’ve had long conversations with frustrated stakeholders where I wanted to jump on the table and scream: “I built exactly what you asked for. What don’t you like about it?”
I’m glad my agents can’t jump on the table.
My own table-jumping tendencies were tamed by the rise of the agile software movement. I’ve attended meetups and conferences where I recited the Agile Manifesto, declaring that I value “working software over comprehensive documentation.” I saw in my work how a simpler MVP or even SVP answered more questions than hours of abstract conversation.
As builders, our conversation with models isn’t abstract, and the artifacts we build to capture context are not comprehensive documentation. We built them to avoid the begging, pleading, and bartering it took to get close to what we wanted, declare it “good enough,” and move on to maintaining the slop. Like our users before us, we just wanted to get our jobs done. As builders, that job is to build.
Context engineering emerged because context is finite and degrades. The artifacts in these workflows exist to counter that. They are not busywork. They are not just receipts for the model. They are the places to make intent explicit enough to inspect. Staying only in the chat thread and trusting the summaries doesn’t eliminate the degradation. It relocates it. I give the model more context while neutering my intent. The failure mode is not that I lose the ability to think. It’s that I stop bothering to inspect the places where my thinking is supposed to show up.
Our industry tried this before with technology outsourcing, especially offshore. The people with the clearest sense of what to build got farther and farther from the building of it. Then we built translation layers, handoff documents, and managerial abstractions to cross that gap, and acted surprised when those layers introduced drift of their own. A lot of modern software process is a scar from that mistake. That’s part of why this current moment feels so familiar to me. The agents are new, but the failure is not.
Relying on the summaries risks context engineering collapsing into the same bureaucratic mess. The point of the agent should be to collapse distance between builder and outcome, not to create a more efficient buffer between them. If I hide inside the thread and its summaries, I’m recreating an old failure mode in a faster wrapper.
When the agent’s assessment of the conversation becomes the source of truth, I lose the whole point of crafting context in the first place. My context artifacts exist to force contact with my intent. Not the vibe of the exchange. Not the model’s summary of its own work. Not the comforting feeling that the thread seems coherent. They are where ambiguity cashes out.
This isn’t just a discipline of “read the docs.” That would be no better than saying “read the code” in a world where agentic output keeps expanding. My value as a builder is not raw output. It is vision, discernment, and the instinct to notice drift when I can do something about it. If I let an unreliable narrator replace my own assessment, I shouldn’t be surprised when the result feels wrong. Even if it got there quickly with the right vibes.