There’s a growing pattern among developers using AI.
When the output is wrong, shallow, or unusable, the conclusion comes fast:
“The AI messed up.”
Sometimes that’s true.
But far more often, what’s actually happening is quieter and more uncomfortable:
AI is exposing gaps in how developers think about problems.
AI Doesn’t Hide Ambiguity. It Punishes It.
Traditional software is forgiving in a subtle way.
You can:
- hardcode assumptions
- rely on undocumented behaviour
- patch edge cases later
- let ambiguity survive inside your head
AI doesn’t allow that luxury.
If intent is unclear, constraints are missing, or the problem isn’t well-scoped, AI doesn’t politely compensate.
It reflects the confusion back immediately.
What feels like “bad output” is often unresolved thinking made visible.
The False Assumption: “The AI Knows What I Mean”
Developers are used to systems that behave predictably once set up.
So they unconsciously expect AI to:
- infer intent
- guess priorities
- resolve trade-offs
- fill in missing context
When it doesn’t, frustration kicks in.
But AI isn’t failing to understand meaning.
It’s refusing to invent it.
Prompting Reveals How Much Logic Was Never Written Down
Many developers discover something unsettling when they start using AI seriously:
They were carrying critical logic mentally.
Things like:
- what “good enough” means
- which edge cases matter
- what should happen when inputs conflict
- what failure is acceptable
Traditional code lets these gaps hide behind implicit decisions.
AI demands that they be made explicit.
And that feels like the AI being “dumb,” when it’s actually being precise.
Why AI Feels Unreliable to Otherwise Strong Engineers
Strong engineers often rely on intuition built over years.
That intuition works well when:
- they control the system
- context is stable
- assumptions remain implicit
AI breaks that loop.
It requires:
- explicit goals
- defined constraints
- clear evaluation criteria
When intuition isn’t translated into structure, AI output feels random, even though it’s not.
The randomness is coming from underspecified thinking.
Overconfidence Makes the Friction Worse
The developers most annoyed by AI are often the ones least willing to slow down and formalise their thinking.
They assume:
- the problem is obvious
- the solution should be straightforward
- the AI should “just get it”
When it doesn’t, blame shifts outward.
But AI isn’t violating expectations.
It’s exposing how much was assumed instead of designed.
AI Removes the Safety Net of “I’ll Fix It Later”
In traditional development, vague decisions can be deferred.
You can:
- ship and patch
- observe behaviour
- correct later
AI doesn’t work that way.
Ambiguity scales immediately.
A poorly defined instruction doesn’t fail once; it fails everywhere.
That forces developers to confront design decisions earlier than they’re used to.
Which feels uncomfortable, but is actually progress.
The Real Gap Is Systems Thinking, Not AI Capability
Most AI “failures” developers complain about are not model limitations.
They’re:
- unclear boundaries
- missing evaluation logic
- undefined ownership between human and AI
- lack of feedback loops
In other words, systems design gaps.
AI doesn’t solve these problems.
It makes them impossible to ignore.
How Experienced Developers Use AI Differently
Developers who get real value from AI do something subtle:
They treat AI as a thinking stress test, not an answer engine.
They ask:
- What assumptions did I leave out?
- Where is my intent unclear?
- What constraints should be explicit?
- How would I evaluate this output?
When the AI response feels wrong, they refine the thinking, not just the prompt.
That’s the difference.
Why Blaming AI Is the Easy Path
Blaming AI protects identity.
It avoids asking:
- Was the problem actually well-defined?
- Did I design this system, or just describe it loosely?
- Am I relying on intuition where structure is required?
Those are harder questions.
But they’re the ones that lead to better engineering.
The Real Takeaway
AI is not replacing developer thinking.
It’s raising the minimum quality bar for it.
The developers who struggle most with AI are not less skilled.
They’re just encountering a system that no longer hides fuzzy logic, implicit assumptions, or incomplete design.
Blaming AI is understandable.
But the real leverage comes from using AI as a mirror, one that reflects exactly how clear, structured, and complete your thinking actually is.
And once you see that clearly, there’s no going back.
Top comments (14)
You can enter the clearest prompt ever, and "AI" will still come back with results that reference APIs that don't exist.
You could say that the developer thinking is now no longer about creating code but double- and triple-checking what an LLM suggests, but... AI isn't a mirror for your thinking. It's a mess.
That frustration is completely valid, and you’re right to call it out. LLMs can confidently reference APIs or behaviors that don’t exist, even when the prompt is very clear. That’s not a failure of prompting, it’s a limitation of how these models work.
Where I’d slightly reframe it is this: AI isn’t a mirror of thinking, and it shouldn’t be treated as an authority. It’s closer to a proposal generator. The developer’s role hasn’t shifted to “trusting” AI, but to designing guardrails, verification steps, and feedback loops so bad suggestions are caught early. I appreciate you raising this openly, skepticism like this is healthy and necessary.
That’s a very honest way to describe it, and I think many people feel the same tension. AI gives speed and momentum, but without deliberate pauses, it’s easy to slip into copying instead of understanding. That discipline, slowing down to assimilate, question, and decide, is what keeps the work intentional and sustainable. You’re right that this challenge applies to everyone, not just newcomers.
For working on AI, I tend to treat it as if they do not know anything and has to be specific as possible. It is a notion to think that AI is smarter than you and assume to know what you are saying, although AI doesn't even know you at all. Being specific is key.
Good work!
That’s a very grounded way to approach it. Treating AI as having no context unless you explicitly provide it leads to far more reliable outcomes. Specificity forces clarity in both the instruction and the thinking behind it, rather than relying on assumptions the system can’t actually make. I appreciate you sharing this perspective, and thank you for the kind words.
Thanks for the article, in my view, what is extracted from the AI tool, by the developer, is more of a reflection on the developer's technical and reasoning skills- rather than the AI tool itself. The AI tool is an aid, not the main actor.. the whole AI code generation narrative is inflated beyond reason.
Thank you for sharing that perspective, I agree with the framing. What comes out of an AI tool often reflects the developer’s reasoning, clarity, and technical judgment more than the tool itself. AI works best as an aid that supports thinking and execution, not as the main actor. Keeping that distinction clear helps cut through a lot of the hype around AI-driven code generation.
Developers are fast to adopt AI but slow to upgrade the knowledge.
This really hits home. The part about AI “reflecting ambiguity back at us” is spot on. I’ve noticed the same thing — when the output feels wrong, it’s usually because my own thinking wasn’t fully formed yet. AI doesn’t hide gaps the way traditional systems do, and that’s uncomfortable but honestly useful. Great perspective.
Thank you for sharing that, you’ve articulated the experience very clearly. When AI reflects ambiguity back at us, it can feel uncomfortable, but it’s often a signal that our own thinking needs refinement. Unlike traditional systems, it doesn’t quietly mask those gaps. Used intentionally, that feedback becomes a powerful tool for clarity rather than something to avoid. I appreciate you adding this thoughtful perspective.
Spot on. We’re moving from an era of coding by intuition to coding by specification.
Most 'AI failures' are actually just the model reflecting back a developer's unresolved ambiguity. In traditional dev, we rely on 'common sense' or 'fixing it later' to bridge the gap between a vague idea and working code. AI doesn't have common sense—it only has your instructions.
It’s a 'thinking stress test.' If the output is shallow, it’s usually because the constraints were implicit rather than explicit. The real skill shift isn't learning to prompt; it's learning to externalize the 'invisible logic' we've been carrying in our heads for years.
AI isn't lowering the bar for engineers; it's raising the floor for how rigorously we have to think.
This is an excellent articulation of the shift. You’re absolutely right , AI acts as a thinking stress test by forcing implicit assumptions into the open. What used to be patched over with “common sense” or deferred fixes now has to be made explicit upfront. That isn’t a lowering of standards; it’s a demand for clearer reasoning and better specification. I appreciate how you framed this as externalizing invisible logic, that’s exactly where the real skill shift is happening.
Self education is very important now to meet the demand of fast changing world.
When intuition isn’t translated into structure, AI output feels random, even though it’s not.
Some comments may only be visible to logged-in visitors. Sign in to view all comments.