AI Won't Run Your Company by Itself
AI can accelerate work, but it cannot own judgment, accountability, or operations. Leaders who expect magic buy local...
Stop Arguing From Memory About Code
7 min read
The Code Changed. The Argument Didn’t.
12.06.2026, By Stephan Schwab
A strange ritual keeps repeating in software development and every field orbiting it: people argue from memory instead of looking at the work itself. AI made first drafts cheaper, but it did nothing to make stale opinions more accurate. The code changed. The tests changed. The behavior changed. The conversation did not. That is how teams waste hours defending ghosts and calling it expertise.
Software is especially good at producing these fake arguments because the thing under discussion is invisible. You cannot glance across the room and see whether the integration logic is better now than it was last month. You have to open the code. Run the tests. Trace the behavior. Most people would rather protect their memory than update their model.
That is the whole problem.
I have seen it with integration glue built by a half-technical builder using Claude Code and a spec-writing tool. The first version sort of worked, in the way a chair with three legs sort of works until you sit down too fast. Then someone came in, untangled the mess, added hundreds of tests, removed the markdown files that kept steering the AI toward stale assumptions, and made the system substantially more trustworthy.
And still the conversation kept orbiting the old codebase.
Not the code in the repository. The code in someone’s head.
Memory Is Cheap. Looking Is Work.
"Many arguments continue only because nobody wants to pay the price of checking reality."
People do not usually argue from memory because they are malicious. They do it because memory is fast, socially convenient, and flattering.
Looking at the subject of the work is slower. It can expose that your opinion is out of date. It can prove that the person you dismissed actually improved the system. It can force you to say a sentence many professionals hate: “I was talking about an older version.”
Memory lets you avoid all that.
In software development this gets worse because the object itself is soft. A sales manager arguing about a broken shipment can at least point to the missing box. A developer, product manager, founder, or adjacent expert arguing about an integration flow is usually pointing at an internal simulation. A remembered stack trace. A remembered failure. A remembered architectural complaint. A remembered impression from three weeks ago that calcified into certainty.
The less visible the work, the easier it is to mythologize.
That is one reason the invisible nature of software causes so much management theater. People fill the visibility gap with narrative. Once the narrative hardens, evidence feels like a personal attack.
AI Made the First Draft Cheap, Not the Truth Automatic
"AI lowers the cost of producing code. It does not lower the cost of understanding what the code really does."
AI coding tools made this pattern more common, not less.
Now a semi-developer can create integration glue in a weekend. Fine. That can be useful. The first draft of software has always been the easiest moment to impress people who do not have to maintain it.
Then reality arrives.
The workflow that actually improves the system is boring in exactly the right way: characterize the behavior, add tests, remove misleading scaffolding, narrow the feedback loop, and force every future change through executable checks. That is where the real work starts. Not at the moment the AI emits files. At the moment someone turns a pile of plausible output into a system another human can trust.
This is why tests beat instructions for AI coding agents. A stack of markdown files telling the model how the world should work is fragile. A few hundred tests showing what the system must actually do is harder to argue with.
Or at least it should be.
In practice, people often keep defending the markdown fiction because that fiction is what they remember. The deleted .md files remain more real to them than the passing test suite. That sounds absurd until you remember that organizations are full of people who confuse documentation with truth and plans with evidence.
Defensive Arguments Are Usually About Status
"When evidence threatens identity, people call it disagreement."
Once somebody has publicly explained how the code behaves, a later correction can feel humiliating. If the system changed under their feet, they now have two choices.
They can inspect the current state and update their model.
Or they can keep talking as if the old model still holds and turn every correction into a debate.
Many choose the second option because it protects status in the short term.
This is where the conversation gets stupid fast. One person is talking about the repository as it exists now. The other is talking about a remembered repository, an old prompt chain, an earlier failure mode, or a design they emotionally committed to. Both think they are discussing the same object. They are not.
Then the usual nonsense starts.
- “That module is still flaky.” No, it used to be flaky.
- “The AI needs those spec files.” No, those files were poisoning the output.
- “The behavior is probably still broken.” Probably is what people say before they refuse to run the tests.
None of this is really about code. It is about self-protection.
That does not make it harmless. It slows down decisions, poisons collaboration, and turns straightforward verification into a miniature political crisis.
The Better Question Is Always: What Does It Do Now?
"If the answer is not based on the current code, the current tests, or the current behavior, it is gossip."
There is a clean way out of this trap, and it is much less glamorous than the argument.
Ask better questions.
Not “Wasn’t this integration unreliable?”
Ask: what does it do now?
Not “Didn’t the AI need that requirements file?”
Ask: what changed after removing it?
Not “I remember this flow breaking when the upstream system timed out.”
Ask: is there a test for that case, and does it pass?
That shift matters because it forces the conversation back toward observable reality. It also reveals who is collaborating and who is defending a memory artifact.
This is the same reason the concept document was a workaround. Descriptions age badly. Executable evidence ages much better. The same applies to arguments in a code review, architecture discussion, or founder-developer debate. If you can inspect the thing, then inspect the thing. Stop litigating a description of the thing.
The Codebase Deserves Witnesses, Not Historians
Software teams have a bad habit of rewarding confident recollection. Someone remembers an outage from six months ago and suddenly becomes the authority on a subsystem they have not touched since. Someone remembers a draft prompt file and treats it as permanent architecture. Someone remembers a prototype and keeps speaking about it long after another person did the hard work of turning it into an actual system.
This is how teams stay trapped in outdated narratives.
What a codebase needs is not more historians. It needs witnesses.
A witness checks the current branch. Reads the failing test. Reproduces the behavior. Looks at the logs. Updates their view when the facts change.
A historian tells you what the system once was and quietly smuggles that story into the present tense.
Both kinds of knowledge matter. Only one should win an argument about current behavior.
If that sounds harsh, good. Too many technical debates are really just memory contests dressed up as expertise.
The Professional Move
"Serious people do not defend memories against evidence. They revise quickly and move on."
The professional move is not to argue harder. It is to reduce the surface area where memory can pretend to be truth.
- Put behavior under tests.
- Delete misleading documents when they stop matching reality.
- Treat stale AI guidance as a defect, not as sacred lore.
- Ask people to point to current evidence, not remembered behavior.
- Reward fast correction more than stubborn confidence.
That last one matters more than most leaders realize. If updating your view makes you look weak, people will cling to old stories. If updating your view makes you look competent, the team gets smarter faster.
Vibe coding is not software development. The same principle applies socially. Vibe-based opinions are not technical judgment. If the artifact is available, look at the artifact.
The code changed. The tests changed. The behavior changed.
The adult response is to change your mind too.
Contact
Let's talk about your real situation. Want to accelerate delivery, remove technical blockers, or validate whether an idea deserves more investment? I listen to your context and give 1-2 practical recommendations. No pitch, no obligation. Confidential and direct.
Need help? Practical advice, no pitch.
Let's Work Together🎭 This Week's Episodes
Telenovelas show what we can't say in client meetings. The drama is heightened, but the patterns are real.
The Live Ops Disaster
Pixel Spree's summer event launches with no realistic staging environment and no load testing. Hassan's infrastructure cracks under traffic three t...
Technical Consultancy
Embedded Delivery Partner
Embedded into your team as an active contributor, reducing delivery friction and helping important work move cleanly.
Technical Advisor
Peer-style technical assessments before far-reaching decisions; reduce architectural and product risk early.
Product & Delivery
Ship working software to real users earlier. Measure impact and adapt based on evidence rather than assumption.
Custom Software Development
High quality, maintainable software. Short-term augmentation that leaves lasting capability in your own team.
Recent Articles
- Stop Arguing From Memory About Code (12.06.2026)
- AI Makes Great Developers Dangerous (08.06.2026)
- Why Staff Augmentation Misses Good Developers (05.06.2026)
- What CTOs Need From Consultants and Hands-On Experts (01.06.2026)
- AI Coding Agents Need XP (29.05.2026)