The previous essay ended with a claim: software engineering, at its core, is a cognition problem. The bottleneck for experienced engineers isn't writing code — it's building and maintaining a theory of the system. Understanding what will break. Knowing what the code is actually doing, not just what it appears to do.
If that's right, then the natural question is whether current AI tools address it. The honest answer is: not structurally. Not because they're not useful — they are — but because prompting, as an interaction model, has three failures that make it incapable of supporting how teams actually build software. They're worth naming precisely, because the gap between what we have and what we need is larger than it looks.
The first failure is that the model has no memory of your system. You spend a session building up context — explaining the architecture, the constraints, the decisions that seem strange but have reasons behind them. The tool gets useful. Then you close the window, and the next session starts from zero. Whatever understanding existed lived in the conversation, not in anything persistent. The tool has no theory of your system. It has tokens from this session.
Peter Naur argued in 1985 that the primary product of programming is not the program but the programmer's theory — the mental model of how the problem is solved by the code. The code is a residue of that understanding. Lose the understanding and the code becomes archaeology. What Naur couldn't have anticipated is a tool that reconstructs a plausible-sounding theory from the code alone, every time you need it, from scratch, as if understanding were a retrieval problem rather than something that is built up over time.
The second failure is that even if the context persisted, it would belong to one engineer. Every person on the team has their own private conversation history, their own accumulated context, none of it visible or accessible to anyone else. There is no shared object. When five engineers are using AI tools on the same codebase, they're each building their own private approximation of the system in five separate chat windows. None of those approximations are composable. None are inspectable. When someone leaves, their context goes with them.
There are products that let you share a conversation — give a colleague a link to the thread. But sharing a transcript isn't the same as sharing a model. It's a log, not a living artifact. And the moment a second person engages, it forks. You don't get a three-way conversation; you get two separate conversations that happened to start from the same place, immediately diverging. The team still has no shared object. It has n private contexts, all drifting apart from the first keystroke.
Excel is powerful for one person. Accounting software is what you need when multiple people work on the same shared reality — enforced rules, shared state, audit trails, coordination built in. The reason you don't just give everyone a spreadsheet isn't that spreadsheets are bad. It's that the organisation needs a single coherent model that exists independently of any individual using it. Current AI tools are Excel. Individually powerful, organisationally invisible.
The third failure is that the outputs aren't stable. Ask the same question in two different sessions and you'll get different answers — different phrasings, different emphases, sometimes different conclusions. Ask it after updating your system prompt and you'll get something else again. A shared abstraction layer needs to produce consistent answers to the same question. Otherwise there's nothing for the team to coordinate around. Prompting doesn't give you that, not by accident but by design: it's a probabilistic system generating plausible continuations, not a deterministic one deriving answers from a fixed model.
There's an analogy from software development that sharpens this. Imagine committing the compiled output of your code to version control rather than the source — checking in the bytecode instead of the Java, the assembled binary instead of the C. You could do it. The program would run. But you'd have lost the layer where reasoning happens. You can read the output, diff it, maybe reverse-engineer parts of it, but you can't work at that level. The meaningful artifact is upstream.
Prompting is like that, except worse: at least bytecode is deterministic. Given the same source and the same compiler, you get the same output. The prompt's output isn't even that. You're committing the output of a tool rather than the input to it, and the output changes every time you run it.
People working around these problems have tried a few things. Updating the system prompt. Building richer context documents. Feeding the AI more of the codebase. These help at the margins, but they don't change the structure. Instructions are a summary of understanding, not understanding itself. They're someone's best attempt to compress the theory into text the AI can use — which means they're already lossy, already one person's interpretation, already manual to maintain. A sticky note on the fridge instead of actually knowing your way around the kitchen.
The individual case is different. One engineer, working alone, can manage the context problem well enough — starting each session with the right files, building their own habits around how to prime the tool, accepting the ephemerality as a constraint. Current AI tools are genuinely useful at that scale. The problem isn't that prompting is bad for individual cognition. It's that cognition at team scale requires something different: shared, persistent, stable representations of the system. Representations the whole team can reason about, that survive individual sessions, that accumulate rather than reset.
To be clear: the code the tool produces is real and useful. Individuals are genuinely faster. But speed of output and speed of the team are different things, and they can move in opposite directions over time. And code output is actually the least of it — architecture is where the real cost accumulates.
Architectural decisions are where the feedback is slowest. You don't feel the damage for months, sometimes years. An AI that's very good at making new code fit the existing structure — without questioning whether the structure itself should change — optimises locally at the expense of the whole. The better it is at squeezing new code in, the less visible the degradation becomes. A human struggling to add a feature might notice the smell and push back. The tool just finds a way. Faster code production with no shared model of the system's structure means the architecture degrades quietly, in ways nobody notices until the debt is suddenly very expensive. The tool is good at local fit. It has no view of the whole.
There's a related problem that doesn't require any degradation at all. What I've said to teams I work with is: I want to know the direction we're taking the architecture, so I don't write code that pulls in the opposite direction. Not the fine details — those can be worked out as you go. Just enough shared picture that individual decisions add up rather than cancel each other out. That direction needs to be visible to everyone working on the system, and it needs to evolve as the system does. Writing it down and feeding it into each AI session would help at the margins — but a document someone maintains by hand goes stale, doesn't update when the system changes, and still lives outside any real understanding of the codebase. It's closer to what you need than nothing. It's not the thing itself.
Which raises the question this essay is designed to leave open: what would it actually take for this to work at team scale? Not a better interface, not a longer context window, not shared chat transcripts. Something with different structural properties entirely.
That's the question the rest of this series is trying to answer.
Johan Aludden has been building software since the late nineties. He is currently thinking about what comes next.