An Engineer’s Manifesto for Intentional AI Use
The craft of software engineering is worth protecting. These are the principles we need to stop treating as optional.
We did not write this because we are afraid of AI. We wrote this because we love software engineering — the real kind, the kind where you understand the code you ship, where you can debug at 2am without a copilot, where the gap between your output and your understanding is as small as it can be.
Something is eroding that craft. Not quickly, not obviously — but steadily. And the people most worried about it are the ones with the most to lose: senior engineers who have spent fifteen years building judgment that AI is quietly making unnecessary.
This manifesto is not a rejection of AI tools. It’s a rejection of reflexive AI use — the kind that ships code you don’t understand, uses frameworks you couldn’t build, and solves problems you didn’t know you could solve. The kind that makes you faster at your job and slower at your craft.
We’re not anti-AI. We’re pro-deliberate-use. There’s a difference. This is what that difference looks like in practice.
The State of the Craft: 2026
We are living through the fastest disruption in the history of software engineering. In thirty-six months, the tools that engineers use every day changed more fundamentally than they had in the preceding twenty years. Copilot landed in 2021. GPT-4 arrived in 2023. By 2025, AI-assisted coding was the default expectation, not the exception — at least in companies that could afford to move fast.
The productivity numbers are real. Teams shipping twice as much code. Individual engineers moving at velocities that would have seemed impossible in 2020. The output gains are not fabricated — they are measurable and significant.
But something else is happening that the velocity metrics do not capture.
Senior engineers are losing the ability to reason about systems they built six months ago. Junior engineers are generating code they cannot debug. Teams are shipping more features and understanding their systems less. The velocity is real. The understanding is not keeping pace.
This manifesto is about that gap. It is about the difference between moving fast and being good. It is about the craft of software engineering — and why protecting it is not nostalgia, not Luddism, not fear. It is professional responsibility.
What the Industry Gets Wrong
"AI is just a better Google — use it like a calculator."
A calculator gives you an answer. It does not build your mental arithmetic ability. When you reach for AI to solve a problem, you receive a solution — but you do not build the problem-solving pathway. The difference compounds over years, not weeks. By the time you notice the gap, the underlying ability has quietly atrophied past the point you are comfortable admitting.
"Juniors need AI help — seniors can protect their skills."
The Expertise Reversal Effect (Kalyuga et al., 2003) shows that instructional AI is most helpful to novices and most harmful to experts. Senior engineers are actually the most vulnerable to skill erosion from AI assistance — the tools are literally optimized for the cognitive level they are trying to maintain. This is the population that should be most cautious, not most comfortable.
"If the tests pass, the code is good."
AI-written tests pass more reliably than AI-written code is understood. You can ship a feature you cannot debug, a refactor you cannot explain, an architecture you cannot defend — with 100% test coverage. The tests measure what they measure. They do not measure whether you understand what you shipped. The next incident, the next outage, the next complex debugging session will ask questions the tests did not answer.
"Just take breaks — recovery is simple."
AI fatigue is not ordinary fatigue. The problem is not too much work — it is that AI has changed the nature of the work in ways that actively undermine the cognitive mechanisms that make engineering satisfying and meaningful. A weekend off does not rebuild skill atrophy. Rest does not restore judgment you did not exercise. The solution is not rest alone; it is rest plus deliberate practice of the things AI took from you.
"You will just have to adapt — this is how the job works now."
Adaptation is not the same as surrender. Adapting means using AI as a lever while maintaining your capabilities. Surrendering means trading your craft for convenience and hoping the outcomes stay good long enough to matter. The engineers who will thrive in the next decade are not the ones who use AI most — they are the ones who use it most intentionally.
The Competence Illusion
AI tools are particularly dangerous because they generate confidence without generating competence. When you solve a problem with AI, you often feel like you understand it — but the feeling is produced by the AI's explanation, not by your own reasoning. This is the competence illusion: the sense of mastery that comes from reading a correct answer, not from deriving it.
Robert Bjork's research on desirable difficulties shows that learning feels slower when it is harder — and that feeling of difficulty is precisely what signals that encoding is happening. AI removes the difficulty. It also removes much of the encoding. You can feel like you are learning while you are actually consuming.
"We are fooled by ease of processing into thinking we have understood." — Daniel Kahneman
The Preservation Principle
There is a category of skills that are worth preserving even when AI can do them faster: the skills whose regular exercise makes you better at the things AI cannot do. Your ability to reason about a system, to debug a subtle failure, to evaluate an architectural decision, to understand why a piece of code is wrong — these abilities depend on a foundation of lower-level competence that you build by practicing the whole stack, not just the top layer.
If you stop writing algorithms because AI writes better ones, you will eventually lose the ability to evaluate whether the AI's algorithm is right. If you stop reading code because AI explains it, you will eventually lose the ability to read code at all. The skills you preserve are the ones that keep you sharp enough to oversee what AI produces.
The engineer who cannot reason about code cannot know when AI reasoning is wrong.
The Cognitive Offloading Trap
Cognitive offloading — using external tools to reduce mental workload — is a legitimate strategy. Writing things down, keeping notes, using a calculator: these are all forms of offloading that improve outcomes. The problem with AI offloading is not that it reduces mental workload — it is that it reduces mental workload in a way that also reduces the formation of the mental models that make future work possible.
Every time you let AI complete a thought you could have completed, you miss an opportunity to strengthen the neural pathway that would make the next thought easier. The brain is not a container to be filled — it is a muscle to be exercised. AI is very good at being a crutch. Crutches are appropriate when you are injured. They become a problem when you forget you were ever supposed to walk.
"The mind that opened to a new idea never returns to its original dimensions." — Oliver Wendell Holmes Jr.
A Brief History of Craft Disruption
Software engineering has survived previous moments of profound tool change. When high-level languages replaced assembly, there were engineers who worried about losing touch with the machine. When IDEs replaced text editors, there were engineers who worried about losing touch with the build. When version control replaced manual file management, there were engineers who worried about losing the craft of manual merging.
Each transition was disruptive. Each produced engineers who adapted and thrived. Each also produced a cohort who were left behind — not because the tools were bad, but because they responded to the transition by either clinging to the old way or by adopting the new way without understanding what they were trading.
AI is a more profound disruption than any of these, because it threatens not just a tool or a workflow but the cognitive core of what makes an engineer valuable: judgment, reasoning, and the accumulated experience of having solved thousands of problems by hand.
Ship less. Understand more.
The industry has optimized for shipping velocity. That’s a reasonable metric — until you realize that shipping velocity and understanding depth are in direct tension when AI is doing the writing. The more code AI generates for you, the less you understand what it does. Track understanding, not just output.
“I shipped 40 PRs last quarter. I could explain maybe six of them in detail.” — Senior IC, 12 years experience
Before you merge, explain it.
The Explanation Requirement: before accepting any AI suggestion, explain it in one sentence. Not to your team — to yourself. “This fix works because it adds a retry boundary to prevent the race condition.” If you can’t say that sentence, you don’t own the fix. You own the approval. That’s not the same thing.
“The moment I started requiring myself to explain AI output before merging, the useful suggestions and the dangerous ones became immediately obvious.” — Staff Engineer, distributed systems
Struggle first. Then ask.
Cognitive science is unambiguous: productive struggle builds durable mental models. AI removes productive struggle. The 20-minute rule is not about working harder — it’s about protecting the mechanism by which expertise develops. If you never struggle, you never build the thing that makes you an expert. The struggle is not the problem. It’s the point.
“I realized I had stopped thinking about hard problems because I always had a faster way out. The exit had become the default.” — Backend Engineer, 8 years
You are responsible for what ships under your name.
AI generates. You approve. The industry has structured this as a review process. It’s not. It’s an ownership transfer. When that code reaches production and something breaks, it’s your name on the commit, your team that gets paged, your judgment that’s on the line. Accept that responsibility consciously, not by default. If you can’t explain it, you shouldn’t have shipped it.
“At 2am, I was the one who had to fix it. The AI wasn’t on the call.” — SRE, FinTech
Junior engineers need to build without AI first.
This is not a popular thing to say right now. But cognitive science is clear: foundational skill develops through productive difficulty. If you learned to ride a bike with training wheels and never took them off, you would be a worse cyclist. Training wheels help. They are not the destination. Junior engineers deserve a pathway to real expertise, not a high-performance escort to competent output.
“I watched bootcamp grads with 6 months of experience produce code that looked senior. They couldn’t have told you why any of it worked.” — Engineering Manager, Series B startup
The gap between output and understanding compounds.
Skill atrophy from AI use is not linear. It’s slow at first, then fast. The first month you notice nothing. The sixth month you notice you’re slower at things you used to be fast at. The second year you realize you can’t do certain things without AI — things you could do cold before. The compounding is invisible until it isn’t. Treat it accordingly.
“I didn’t notice until it was bad. By then I had been using AI for everything for 18 months.” — Senior Engineer, 10 years
Own your learning curve, even when it’s inconvenient.
There will be weeks where intentional AI use makes you slower. Where your colleagues using AI reflexively ship twice as fast. Where your estimation looks bad because you’re building things from scratch as part of deliberate practice. That gap is the price of maintaining your craft. It is worth paying. The alternative is a slow handover of everything that makes you valuable to a tool you don’t control.
“My teammates used to ask me architecture questions. Now they ask ChatGPT. I noticed the gap before they did.” — Principal Engineer, 15 years
Deliberate use is a competitive advantage, not a constraint.
Engineers who maintain their craft while using AI thoughtfully are not slower — they’re differently fast. They catch architectural mistakes before they become incidents. They debug faster because they understand systems deeply. They make better decisions because their judgment isn’t hollowed out by reflexive delegation. The engineers who will still be excellent in five years are the ones who figured out how to use AI without being used by it.
“The engineers I’d still bet on in 10 years are the ones who are deliberate about this. Not the ones shipping the most code today.” — CTO, Series D
This is not a list of rules. It’s a description of a choice. You can use AI reflexively and optimize for shipping velocity. Or you can use it intentionally and optimize for craft. The tools don’t care which you choose. You should.
In Practice: What Intentional AI Use Looks Like
- Use the 20-minute rule: struggle with a problem for at least 20 minutes before reaching for AI
- Apply the Explanation Requirement: explain every AI suggestion in one sentence before accepting it
- Schedule no-AI blocks: one focused session per week where you build without any AI assistance
- Track your confidence: every Friday, write down one thing you built that week that you fully understood
- Do a quarterly rebuild: pick an AI-resolved problem from three months ago and fix it yourself
- Keep a learning journal: note when AI saves you vs. when it shortcuts your learning
Engineers Who Agree
These are representative profiles of engineers who have taken the stance. All names anonymized.
Take the Stance
Add your name to the engineers who believe the craft is worth protecting. One sentence about what intentional AI use means to you.
We will never sell or share your email. No spam. Unsubscribe anytime.
Frequently Asked Questions
Continue Reading
The AI Fatigue Recovery Guide
A practical path from overwhelmed to intentional — in 30 days.
Mental Models12 Frameworks for Healthy AI Use
The mental models that help you stay sharp while using AI tools.
ResearchThe Slow Erosion of Your Coding Skills
The research behind skill atrophy — and what actually helps.
QuizThe AI Fatigue Quiz
5 questions. 4 severity tiers. A personalized recovery plan.
Start with the Quiz
Not sure where you fall on the spectrum? The AI Fatigue Quiz takes 2 minutes and gives you a personalized breakdown — with a specific recovery plan for where you are right now.
24-Month Projection
Where your AI fatigue takes you if nothing changes →