AI didn't kill the hallway conversation
Solo flow is the engine. Shared context is the steering. You need both, and most teams are losing the second one.
Two weekends ago, I spent a Saturday in deep work on a payments feature. Music on, agent humming, six hours of clean architectural thinking. I shipped a design I was proud of. The following Monday, a senior colleague mentioned in passing that another team was building something, an adjacent work I had no visibility into, that would land in two weeks, that materially changed the shape of what I’d just designed. The conversation lasted maybe four minutes. It saved me a week of rework.
Nothing in my Saturday flow would have surfaced that. Not my agent. Not the codebase. Not any documentation. The information existed in exactly one place: my colleague’s head. And it only reached me because he chose to mention it.
This is the part of the AI-augmented engineering era that nobody is writing about. I run Codex and Claude harder than most engineers I know. I have prompt files scoped to specific subsystems. I argue with my agents rather than instruct them. I move from spec to working code faster than I could three years ago. The productivity gain is real, and I will defend it against anyone who tries to dismiss it. The very same tools that have collapsed the cost of one kind of knowledge have made the absence of another kind much more dangerous. And we’re starting to feel it.
Four kinds of knowledge
There are at least four kinds of knowledge in any working codebase. They have very different acquisition costs, and AI agents are good at exactly one of them.
Implementation detail. What does this function do? What does that Lambda emit? What endpoint does this service expose? This is in the code. It is fetchable, mappable, and summarisable. AI agents are excellent at this: better than any wiki, better than asking a colleague who’d have to context-switch to answer. This is the category where solo flow plus a good agent beats every other approach, and it isn’t close.
System topology. What touches what? Which services share the state? Which couplings are load-bearing and which are accidents of history? This is partially in the code and partially in the heads of the people who built it. An agent can trace a call graph. It cannot tell you that a particular service boundary was drawn for a regulatory reason that no longer applies, or that two seemingly independent modules are coupled through a shared assumption about time zones. You can sometimes reconstruct this from the code with enough effort. Often you can’t.
Domain rules. Why is the data model structured this way? Why does this entity carry that field? Why does the journal post against an accrued account before it posts against a due account? The code reflects these decisions but does not explain them. The reasoning lives in the heads of the people who made the call, usually in a meeting, sometimes documented, often not. No amount of solo exploration recovers the reasoning. You can recover the outcome, but the outcome without the reasoning leaves you unable to know whether the next change you make breaks the rule or honors it.
Active decisions in flight. What is the team next to mine designing right now that will land in two weeks and intersect my work? This exists nowhere except in the heads of the people currently making it. There is no document to fetch. There is no PR to read. There is no Confluence page to find. The artifact does not exist yet. There is only the conversation that creates it, and you are either in that conversation or you are not.
AI agents are good at category one. They are partial on category two. They are useless on three and four.
The half-right response
The common reaction to this observation, especially from engineers who’ve fallen in love with their agents, and I include myself in that group, is “fine, then engineers should just do more homework themselves.” Go read the code. Go ask the architect. Take responsibility for your own context.
This is half right and half catastrophically wrong. It’s right for category one. The era of being handed a spec and writing code against it is over. Senior engineers now write the spec, debate it with an agent, refine it, and only then turn to implementation. That shift is correct and overdue.
It’s wrong for categories three and four. You cannot fetch domain rules from a system that doesn’t contain them. You cannot read the PR for a feature that hasn’t been written yet. The “do more homework” model assumes the homework is accessible somewhere. For the knowledge that lives in people’s heads, and especially for the decisions being made right now by your colleagues, the homework is the conversation. There is no other source.
The cost of pretending otherwise is paid in rework. In bugs that come from two engineers stepping on each other’s work because neither knew the other was touching the same surface. In features that don’t compose because the assumptions baked into each were never reconciled. In the slow, expensive accumulation of architectural drift that nobody is empowered to name because nobody was in the room when the drift began.
Engine and steering
Solo flow with AI agents is the engine. Shared context between humans is the steering. If you only have the engine, you go very fast in the wrong direction. If you only have the steering, you don’t go anywhere at all. The teams that will win in this era are not the ones who run their agents hardest. They’re the ones who know, for any given piece of knowledge, whether to fetch it from the agent or fetch it from a person, and who have the operational discipline to do both.
What to actually do
This translates to four practical things:
Drop the standing architecture meeting. Calendar-driven architecture sessions decay predictably. Week one has substance. Week three is half-attended. Week six, it’s theatre. Architecture conversations need a specific decision to gather around. Without one, the meeting eats time and produces nothing.
Trigger architecture conversations on intersection, not on cadence. When a feature crosses team or service boundaries, the owner books a scoped session with the people whose work materially intersects. A proposed architecture comes into the room, not “let’s figure out what to build,” which is a different kind of session and rarely works. Decisions get recorded. The session ends.
Add a lightweight cross-team surfacing slot. Fifteen minutes, embedded in an existing forum. Each team says: here’s what we’re building, here’s what it touches, raise a flag if it intersects your work. This is not architecture. It is a tripwire. It is cheap to run, and it is the mechanism that would have caught my Saturday deep work intersection before my colleague had to surface it in the corridor on Monday.
Protect solo flow as the default execution mode. The forum and the architecture session are the exceptions, not the operating model. Most of the week is closed-door work with the agent. The conversations exist to make sure that work points in the right direction.
The asymmetry forming underneath
The genuinely new thing in engineering right now is not that AI agents have arrived. The productivity asymmetry between engineers who use them well and those who don’t is enormous and growing. That asymmetry is real, and I am not interested in arguments that try to minimize it.
But there is a second asymmetry forming underneath the first. It’s between engineers who understand which knowledge their tools can fetch and which they can’t, and who structure their work accordingly, and engineers who treat the agent as an oracle and stop asking their colleagues anything at all.
The first asymmetry has obvious winners. The second has slower winners, but the gap is wider and lasts longer. The engineers who will compound their advantage over the next five years are the ones who run their agents hard and who have not forgotten how to walk over to a colleague’s desk and ask the one question only that colleague can answer.
I had a four-minute conversation last Monday that saved a week of work. No agent could have given me that. What are your thoughts?


