The Comfortable Lie About AI and Programming
AI already applies patterns and best practices better than most humans. The engineer of the future will stand out for something else: managing the context given to the AI.
Originally published on LinkedIn on February 10, 2026.
In this article
I see many developers, CTOs, and technical leaders repeating the same idea over and over:
"AI won't replace programmers. A good engineer, with strong knowledge of architecture, design patterns, and best practices, will always be needed to guide AI. Human judgment is irreplaceable."
Based on real, hands-on experience building software with and without AI, I'm here to say something uncomfortable:
They are wrong. EVERY SINGLE ONE OF THOSE WHO CLAIM IT.
Not partially. COMPLETELY.
AI already outperforms us in best practices and architecture
AI is already better than most humans at applying:
- Design patterns
- Best practices
- Architectural decisions based on the problem
Not because it reasons. Not because it "understands" the business.
But because it was trained on millions of real-world examples and knows exactly when to apply what, with a level of consistency most humans simply don't have.
Those who claim this is "our advantage" usually fall into one of two categories:
- They haven't seriously programmed with AI
- Or they haven't programmed without AI in a very long time
Often, both.
The real problem is not technical, it's contextual
The software engineer of the future will not stand out for knowing more patterns or architectures.
They will stand out for something far more critical:
Their ability to manage the context given to the AI.
Code context. Domain context. Constraint context. Goal context.
This is not prompting. This is not writing better natural-language instructions.
This is a new discipline.
The new role: Context Architect
The real software engineer of the future will need to master:
- What context to provide and what to omit
- How to reduce the AI's decision space
- How to avoid hallucinations without over-specifying
- How to get correct code without wasting compute
- How to guide AI without leaving room for wrong solutions
We are entering a phase where too much context is just as harmful as too little.
And today, almost no one knows how to do this well.
Give the AI the four kinds of context the article names, then try adding context it doesn't need. Watch what happens to the decision space and to the noise.
Relevant context
Unnecessary context
Wide decision space: the AI fills the gaps with guesses, which leaves room for wrong solutions and hallucinations.
Narrower, but still ambiguous: every missing kind of context is a decision the AI will make on its own.
Focused: enough context to get correct code without over-specifying and without wasting compute.
Too much context is just as harmful as too little: the extra material wastes compute and widens the error surface.
New patterns that don't exist yet
We are witnessing the emergence of something new:
AI-oriented development patterns. Patterns of context, not code.
They are not formalized yet. They don't have names yet. But they will become the foundation of the next era of software development.
Code stops being the center. Context becomes the primary artifact.
Corollary: IDEs are also behind
There is an inevitable consequence that few are talking about:
Current IDEs are not designed for programming with AI.
They were built for humans writing code:
- Files
- Classes
- Functions
- Local autocomplete
Programming with AI inside these tools today feels forced, clumsy, and unnatural.
The problem is not AI. The problem is that IDEs don't understand context, only files.
The inevitable pivot
IDEs will have to pivot. Hard.
Because the real AI-driven workflow is not: "I write code and AI helps me."
It is: "I design the context, AI writes the code."
"I write code and AI helps me"
- Code is the center
- The IDE understands files
- AI as local autocomplete
"I design the context, AI writes the code"
- Context is the primary artifact
- The tool understands context
- The engineer as Context Architect
That requires IDEs that:
- Treat context as a first-class artifact
- Allow context versioning and auditing
- Control exactly what the AI can and cannot see
- Measure cost, risk, and error surface
- Make context explicit and inspectable
None of this exists today.
A clear symptom
If programming with AI feels uncomfortable, it's not because "it's still early."
It's because we're using tools designed for a paradigm that is already broken.
An uncomfortable closing
Sorry to say this, but this is not a future prediction.
This is not "what will happen."
It is what is already happening.
And the sooner we accept it, the sooner we can start playing the right game.
