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.
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.