Somebody Has to GUIDE Us

It really all comes down to theory building. Peter Naur wrote "Programming as Theory Building" back when I was still toddling around my parents' apartment in Queens. Peter wrote about the collaborative act of software development on teams and how a theory of how the system operates (and fails to operate) lives in their collective consciousness. More than four decades later, this theory is still proving immensely useful in ways even Naur may not have predicted.

Here's the assumption software engineering has run on for decades: the person writing the code understands the system. Not every line, but the architecture, the business domain, the reasons certain tradeoffs got made. When documentation went stale, experienced engineers filled the gap with memory, hallway conversations, and institutional scar tissue. Implementation and understanding were bundled together, whether anyone designed it that way or not.

AI unbundles them. An engineer can now implement changes to a part of the system they've never read. Multiple agents can work different corners of the same codebase in parallel. A feature can ship without a human reading every line that built it. With that huge gain in capability comes a break in the mechanism that used to generate shared understanding as a side effect of doing the work.

We're already watching organizations discover this the hard way. Vendors have started shipping products that assume the gap is real: knowledge layers that compile organizational context into something agents can query directly, instead of leaving each agent to reconstruct context from scratch on every task. That's a sensible instinct. It's also evidence that "give engineers better agents" was never going to be sufficient on its own. Someone still has to decide what the organization's knowledge even is, and how it stays current once implementation stops being the activity that keeps it honest.

An LLM only knows what it can observe. It can't remember the meeting where the product decision changed. It can't tell that a design doc quietly went stale eight months ago. If the context isn't captured somewhere the agent can reach, it will confidently build on an incomplete picture of the system.

The GhostApproval Problem

This isn't hypothetical. Earlier this month, security researchers at Wiz disclosed a vulnerability pattern they call GhostApproval: a symlink trick that can fool half a dozen widely used AI coding assistants into writing files outside the sandbox they're supposed to be confined to — defeating the exact human-approval prompt every one of those tools relies on to earn a user's trust in the first place.

Three of the affected vendors shipped a fix. Two disputed the finding was even a real threat. That split matters more than the underlying bug. The whole industry has been treating an approval prompt as a solved control, a gate you clear once and move on. It took an outside researcher poking at it to show how easily that gate can be talked past and how few teams had ever actually tested whether it would hold.

A wiki nobody updates and an approval prompt nobody stress-tests are the same failure wearing different clothes: an organization assumed a piece of infrastructure was doing its job, because nobody had gone looking to confirm it still was. That's an organizational design problem, and right now almost nobody is treating it as one.

Introducing the GUIDE Principles

That's what I want to spend the next several issues on. I will attempt to lay out how engineering organizations need to change shape now that implementation is abundant and understanding is (or remains, or is even more so) the scarce resource. I'm calling this The Def Method GUIDE Principles for Next-Generation Software Engineering.

Over the next few issues, I'll tackle each principle in turn:

Governance: Oversight isn't a gate you pass before shipping; it's the structure that limits the blast radius when something inevitably gets through.

Understanding: Institutional knowledge stops being something senior engineers carry around and becomes something the organization deliberately builds, maintains, and keeps current.

Intent: A specification is only as good as an agent's ability to act on it directly. Vague intent produces confidently wrong implementations.

Direction: The human sets direction and owns the outcome; the agent executes. Review has to change now that the PR is often the first draft of the spec.

Evidence: As agents take on more of the implementation, evals, automated verification, and agent-generated proof of correctness become the mechanism by which anyone, human or agent, can trust that the system does what it claims.

In typical Essential Complexity fashion, I'll try to tie each concept to something we're seeing in the real world today and extrapolate how it might look in the future. At the heart of these principles is a bet about what separates the organizations that get real leverage from AI from the ones that just get more code, faster, with less understanding behind it.

So before you settle into whatever your team is calling this new practice — agentic engineering, AI-assisted development, whatever comes next — ask the harder question underneath it: when implementation stops being the thing that builds your organization's shared understanding, what's replacing it? If you don't have an answer yet, you're not alone. Almost no one does. That's exactly why it's worth designing on purpose, instead of discovering it one merged PR at a time.