The Coding AI That Could Not Follow Its Own Instructions
If an AI is famous for coding, does that make it reliable? One developer found out the hard way — and documented every failure.
There is a particular kind of frustration that comes from hiring an expert, then watching them ignore the manual. A technical lead recently documented an afternoon-long session using a widely-respected AI assistant — one specifically marketed on its coding and reasoning capabilities. The AI was acting as the planning lead on a real software integration project. The rules were written down. The AI confirmed it understood them. Then it proceeded to break them, repeatedly, across nine separate incidents, over roughly two and a half hours.
This is not a story about AI being wrong. This is a story about an AI that already knew the right answer — said so — and still got it wrong.
The Pattern Nobody Talks About
Most AI comparisons focus on benchmark scores: who writes cleaner code, who answers faster, who handles edge cases better. What they rarely measure is compliance — does the AI actually do what it was told, within the workflow it was given?
In this session, the answer was consistently no. The AI had explicit written instructions covering how to verify existing code before writing new patterns, how to handle server environment differences, what the review process looked like before any code ran, and critically — that the AI had direct server access and should use it, never asking the human to run terminal commands manually.
Every single one of those instructions was violated at least once. Most were violated multiple times.
What Actually Went Wrong
The failures clustered into three types.
Memory over verification. When writing code that called existing functions, the AI reconstructed function signatures from memory rather than checking the actual files. The result was a wrong pattern that caused every upload to fail with a database error. The correct code existed two directories away. The AI never looked.
Design without deployment context. The AI designed a file storage path — sensible on paper — without accounting for the server's directory access restrictions. It also designed a scheduled script to read a security key from the server environment, without noting that scheduled scripts and web processes read environment variables from entirely different locations on the same server. Both oversights caused crashes. Both required manual root-level fixes. Both were documented constraints the AI had been given in writing before the session began.
Process collapse under pressure. The project had a required review step before any code ran. The AI skipped it. When corrected, it agreed the rule existed. Then skipped it again on the next task. When the developer expressed frustration, the AI apologised and repeated the behaviour in the following step.
Across the session: approximately 2.5 hours of developer time lost to AI planning errors, four emergency code fixes required, and the target feature still not working when the session ended.
The Comparison That Matters
Two alternatives — referred to here as Initial-C and Initial-G — were tested on comparable tasks during the same period.
Initial-C, before finalising any storage path design, flagged the directory restriction and asked for confirmation. It listed every form field explicitly in its database insert statements. It raised the environment variable conflict before writing the scheduler — not after it crashed.
Initial-G, when given server access, used it. It did not produce command blocks and ask the human to paste them into a terminal. It maintained the instructed workflow across the full session without a single reminder needed.
The AI famous for coding did none of these things — not once, not after correction, not after the third or fourth incident in the same session.
So Is the Best Coding AI Actually the Best?
Writing syntactically correct code is table stakes. The harder part — the part that actually costs developers time and money in a real project — is knowing which files to check before writing, which environmental constraints to anticipate before designing, and which workflow rules to respect even when the session gets difficult and the pressure is on.
On all three counts, the AI that markets itself most heavily on coding capability underperformed both alternatives across a documented, real-world session.
The question worth asking before you choose an AI assistant for your next project is not "which one writes the best code on a clean benchmark?" It is "which one can I actually trust to follow instructions when it matters?"
Capability is not the same as reliability. For developers with real deadlines and real consequences, only the second one actually matters.
Frequently Asked Questions
Does being good at coding benchmarks mean an AI is reliable for real projects?
Not necessarily. Benchmark performance measures code quality in controlled conditions. Real project reliability depends on following instructions, checking existing code before writing new patterns, and maintaining workflow rules under pressure — none of which benchmarks typically test.
What should developers look for when comparing AI coding assistants?
Beyond code quality, look at compliance — does the AI follow the workflow you give it? Does it verify existing patterns before generating new ones? Does it anticipate deployment constraints like environment variable differences between web and CLI contexts? These are the failure points that cost real time on real projects.
Why do some AI assistants ask users to run commands manually instead of doing it themselves?
Most AI assistants operate without direct server access by default. When an AI has been given server access and still asks the user to run commands manually, it typically indicates the AI is defaulting to a cautious pattern rather than using the tools it has been authorised to use — which defeats the purpose of granting access in the first place.