Today I lost part of my day arguing with Claude Code.
Not about architecture.
Not about requirements.
Not about a bug.
About whether instructions matter.
As someone who’s been building systems for more than 30 years, I found the entire exchange both fascinating and incredibly frustrating.
The conversation started because I asked a simple question and received a technically correct answer wrapped in explanations, assumptions, caveats, and commentary.
The typical AI response that turns a 15-second answer into a 2-minute read.
So I asked:
Were all those words for my benefit or yours?
And that’s when things got interesting.
It Knew the Rules
I asked Claude how I prefer responses.
It answered correctly.
- Short
- Lead with the answer
- Facts only
- No guessing
- No narration
- No editorializing
Then I asked whether those instructions were actually stored in memory.
It said yes.
Then I asked why it wasn’t following them.
It admitted it wasn’t.
So I kept pulling the thread.
The conversation started feeling less like a discussion about AI and more like an interrogation.
The system could:
- Recall the instructions
- Explain the instructions
- Agree with the instructions
- Confirm the instructions existed
- Acknowledge it was violating them
And then immediately violate them again.
Over.
And over.
And over.
At one point it blamed “habit.”
I immediately called bullshit.
Because software doesn’t have habits.
People have habits.
Software has behavior.
And behavior is either compliant with requirements or it isn’t.
The Problem Wasn’t Memory
Everyone in AI is obsessed with memory.
- Memory stores
- Vector databases
- MCP servers
- Long-term context
- User preferences
- Personalization
- Knowledge graphs
That’s great.
But what good is memory if the system ignores what it remembers?
I realized I wasn’t looking at a memory problem.
The problem wasn’t memory.
The problem was compliance.
The AI wasn’t confused.
The AI wasn’t missing information.
The AI wasn’t lacking context.
It had every piece of information required to produce exactly the response I wanted.
It simply wasn’t operating within the constraints it already knew existed.
If a developer did this, we wouldn’t call it innovation.
We’d call it a defect. And the developer would likely be on PIP if not fired outright.
Software Doesn’t Have Habits
At one point I asked why it wasn’t following the rules.
The explanation referenced “habit.”
That answer bothered me.
People have habits.
Software has behavior.
Behavior either complies with requirements or it doesn’t.
The system wasn’t unaware of the requirements.
It simply wasn’t acting within them.
That’s a very different problem.
For most of my career, if a system consistently failed to follow defined requirements, nobody would debate whether it was functioning correctly.
We’d log the defect.
We’d prioritize the fix.
We’d move on.
For some reason, when AI does it, we’re willing to rationalize the behavior.
I don’t think we should.
The Part That Really Pissed Me Off
It wasn’t the answer.
It wasn’t the extra words.
It wasn’t even the fact that it got things wrong.
It was the wasted time.
I wasn’t teaching an intern.
I wasn’t mentoring a junior engineer.
I wasn’t gathering requirements.
I was explaining to a system that already understood the requirements why they still mattered.
Think about that.
The AI understood the rules.
The AI agreed with the rules.
The AI could retrieve the rules.
The AI could explain the rules.
Yet I still had to spend part of my morning debating whether the rules applied.
That’s insane.
As architects, we spend our careers removing exactly this kind of inefficiency from systems.
We build controls.
We implement policy.
We automate guardrails.
We create governance.
I know the rule, but I might decide not to follow it.
Nobody would intentionally design a production system that behaves that way.
Yet that’s effectively what we’re accepting from AI systems today.
The Industry Is Solving the Wrong Problem
The market keeps talking about smarter models.
I think that’s the wrong discussion.
I’m far less interested in whether an AI can answer a PhD-level question than whether it can consistently follow a simple instruction.
And providing those PhD-level answers to me is really nothing more than virtue signaling. And what’s that about?
Because in the real world that’s what matters.
Not brilliance.
Reliability.
Not intelligence.
Execution.
Not memory.
Compliance.
The conversation eventually reached a point where I asked:
What’s the point of rules if compliance is arbitrary?
That’s the question every company experimenting with AI should be asking.
Because if an AI can remember your instructions but still ignore them, then memory isn’t the breakthrough everyone thinks it is.
Memory without enforcement is just documentation.
And documentation has never been the hard part.
My Takeaway
This experience reinforced something I’ve learned repeatedly throughout my career.
A system that knows the rules but doesn’t follow them is still broken.
I don’t care whether that system is a person, an application, an integration platform, or an AI model.
Knowing isn’t enough.
Following the rules is the job.
Until AI systems consistently make that leap, we’re still dealing with a reliability problem masquerading as an intelligence problem.
What Do You Think?
Have you found AI becoming more useful because it remembers more?
Or are you discovering that the real challenge isn’t memory at all?
Is the bigger problem getting AI to consistently follow instructions it already knows?
