Manual coding keeps the skill alive. Systems thinking is needed. Long term you need to leverage AI and leverage your brain. Not outsource thinking.
Definition
AI-assisted development creates a divergence risk: developers who outsource reasoning to AI lose the cognitive muscles that make them valuable, while developers who use AI as a power tool for implementation while retaining ownership of system understanding become dramatically more effective. The skill that matters is not typing code. It is reasoning about systems.
Mental Model
Programming has two cognitive layers:
| Layer | What it covers | AI capability | Atrophy risk |
|---|---|---|---|
| Layer 1: Mechanical implementation | Syntax, loops, CRUD, wiring functions | Excellent | Low risk if outsourced |
| Layer 2: System reasoning | Architecture, invariants, failure modes, debugging, state transitions, performance | Weak | High risk if outsourced |
AI is extremely good at Layer 1. Layer 2 is where engineering actually lives.
The danger is when developers let AI replace both layers.
The Muscle You Do Not Use Decays
There is a simple cognitive rule:
skill = f(repetitions of hard thinking)
Five years of prompt, paste, accept means five years of not exercising:
- Reasoning about state
- Tracing bugs through systems
- Mentally simulating execution
- Writing code from first principles
That mental model slowly weakens. Same reason people who rely on GPS lose their internal map of a city.
Debugging Ability Collapses First
The biggest signal of a strong engineer is not how fast they write code. It is how they debug unknown systems.
AI-heavy workflows create a specific failure mode: the developer understands the prompt but not the generated system. When something fails they cannot answer:
- Why this architecture exists
- What invariant was violated
- Where the state mutation happened
Weak pattern:
Bug → ask AI to fix → patch → repeat
Strong pattern:
Bug → reason about state → isolate cause → fix root problem
That difference compounds massively over time.
Abstraction Blindness
Great engineers build a mental hierarchy: CPU behaviour, memory, language runtime, data structures, system architecture. This stack lets them predict behaviour before running code.
Developers who never build systems manually miss the chance to develop those internal models. They become tool operators, not engineers.
The Paradox of Leverage
The best engineers will use AI more, not less. But they use it differently.
Weak usage:
AI → writes system → human accepts
Strong usage:
Human → designs system → AI implements pieces → human verifies invariants
AI becomes a power tool, not a brain replacement.
The 3-5 Year Divergence
Two developer populations are forming:
| Group | Characteristics | Outcome |
|---|---|---|
| AI operators | Fast initial coding, shallow system understanding, weak debugging, prompt-dependent | Struggle with complex systems |
| AI-amplified engineers | Deep architectural reasoning, strong debugging, uses AI for speed, owns system understanding | Dominate senior roles |
This has already happened before. Calculators replaced manual arithmetic. People who only used calculators lost the ability to reason about numbers. Strong mathematicians used calculators for computation and experimentation but still developed number intuition.
The Self-Test
Use AI for generation, but never outsource understanding. A good mental check:
Can you answer these questions about your system without asking AI?
- Why does this architecture exist?
- What invariant protects the state?
- Where does failure propagate?
- What are the performance limits?
If you can answer those, AI is just a multiplier.
The Status Theatre Problem
Twitter/X optimises for status signalling, not knowledge transfer. The ranking algorithm boosts:
- Bold claims
- Hot takes
- “I just built X in 10 minutes”
- Vague intellectual flexing
Pattern you see constantly: “Most developers don’t understand X.” No explanation. Just a dominance display. It works because people respond emotionally, both agreement and disagreement increase reach. The equilibrium becomes performative expertise.
This creates a distorted view of the industry. You see a tiny minority of highly online developers and conclude everyone is AI-powered. The reality: most teams use Copilot for autocomplete, some use chat assistants, very few run fully agentic workflows.
A useful filter for any tweet
| Signal | Value |
|---|---|
| Showing work (open source, production lessons, bug reports) | High |
| Showing results (shipped product, real metrics) | High |
| Showing status (hot takes, vague claims, intellectual flexing) | Theatre |
Three layers of Twitter
| Layer | % | Description |
|---|---|---|
| Status theatre | 90% | Performers optimising for attention |
| Interesting ideas | 9% | Worth scanning |
| Real builders sharing work | 1% | Your actual signal |
Your job is to find the 1%. The builders, not the performers.
A subtle sign of a builder: their posts are by-products of work, not the goal. “Just open-sourced X.” “We tried Y architecture, here are the results.” They use X as distribution, not validation.
The deeper someone goes into serious systems work, the less time they spend posting. Because high-level engineering requires long concentration blocks, reading papers, debugging weird systems. Those activities produce months of silence and then a big release.
Some of the best engineers in the world read Twitter but almost never post. They treat it like a noisy RSS feed, not a stage. That is usually the healthiest relationship with it.
The Filming Distortion
Teaching (Udemy, courses) creates a temporary cognitive distortion. You spend weeks explaining fundamentals and simplifying concepts, which can feel like “I am teaching, not advancing.” But teaching forces you to understand fundamentals deeply, structure knowledge, and explain abstractions clearly. Many elite engineers teach because it sharpens thinking.
The danger is comparing yourself to the visible frontier (the 0.1% posting about autonomous coding loops) instead of the correct comparison group: senior engineers building real products.
The Next Elite Skill
The next differentiator might not be writing code at all. It might be writing extremely precise system specifications that AI can implement correctly. This connects directly to formal verification (TLA+, Z3) and spec-driven development.
The value chain is shifting:
Writing code (commoditising)
→ Designing systems (current leverage point)
→ Specifying systems formally (emerging leverage point)
The Builder’s Ratio
For founders, a small amount of posting is useful. Not for status. For distribution, recruiting, customer discovery, and learning from others.
Build: 95%
Post: 5%
Real builders regain confidence the moment they ship something real.
Gotchas
- Feeling behind is almost always exposure bias from Twitter, not an actual skills gap.
- Junior developers who skip manual coding entirely are in the real danger zone for skill atrophy.
- Speed of code generation is not the bottleneck. Correctness of system design is.
- The urge to analyse workflows endlessly is itself a form of procrastination. Ship the thing.
Related Concepts
Sources
- Personal reflection, March 2026
- Claude Code conversation on TLA+, Z3, and agent orchestration
