Let AI Write Code, Beyond the “Waouh” Effect, the IApocalypse?
“The code works!” — but at what cost?
⚖️ Every Choice in IT Is a Trade-off
If there’s one thing that experienced engineers learn, sometimes the hard way it’s that there are no perfect solutions in software. Only trade-offs.
- Microservices or monolith? Trade-off.
- SQL or NoSQL? Trade-off.
- Moving fast or staying stable? Trade-off.
We don’t choose the best solution. We choose the least worst one, given our constraints, our context, and the moment we’re in.
Using AI to write code is no different. It is a trade-off we consciously accept. We trade some control, some depth, some craftsmanship, in exchange for speed, volume, and reduced friction. And for many situations, that’s a perfectly reasonable deal. Nobody seriously argues you should hand-craft every line of boilerplate nowadays.
But here’s the thing about trade-offs: you have to know what you’re giving up.
⚠️ A trade-off you don’t understand isn’t a trade-off, it’s just a loss.
The “Waouh” effect that jaw-dropping moment when the AI materializes a complete implementation from a plain prompt is real and intoxicating. It feels like a superpower. And in some ways, it is. But once the dopamine fades, a more sober question lingers: what exactly are we trading, and are we tracking the full cost?
This article is not an argument against AI-assisted development. It’s an argument for going in with open eyes. 👀
📖 You Spend More Time Reading Code Than Writing It
This is perhaps the biggest hidden shift, and nobody talks about it enough.
Before AI, the bottleneck was writing. Now the bottleneck is reviewing. When a developer uses an AI agent to generate a feature, they can receive 200–400 lines of code in seconds. The problem? That code now needs to be read, understood, validated, and contextualized by a human who didn’t write it and who often has no mental model of why it was written that way.
This is precisely what senior developers are reporting in the field. The time saved in initial generation often gets “consumed, often with interest, during maintenance and debugging.”
The 2024 DORA report, based on nearly 3,000 tech workers, found a troubling paradox: a 25% increase in AI adoption came with a 7.2% drop in delivery stability even as individual developers reported feeling more productive.
Reading someone else’s code is hard. Reading an AI’s code which has no memory, no architectural vision, and no business context can be even harder.
📝 Specifying Becomes the New Coding
Here’s an irony nobody anticipated: the better you want the AI’s output, the more time you spend writing prompts.
Prompting is a skill. Getting an AI to produce code that fits your architecture, respects your conventions, handles edge cases, and doesn’t introduce security vulnerabilities requires precise, detailed, context-rich instructions. You have to describe not just what you want, but how you want it structured, why certain constraints exist, and what the AI should avoid.
This shifts the developer’s role from builder to specifier and that’s not necessarily bad. But it’s a different kind of cognitive work, and one for which many developers aren’t trained. When the specification is vague, the output is a mess. When the specification is precise and complete… you may as well have thought it through deeply enough to write the code yourself.
The friction of writing code is not pure overhead. It forces you to think. When you remove that friction, you also remove the thinking.
🔍 You Lose the Refactoring Instinct
One of the most underrated skills in software engineering is noticing when things should be factored differently. That moment when you’re halfway through writing a function and you realize, “wait this already exists somewhere else, I should extract a utility here.” Or “this pattern keeps appearing, maybe it’s time for an abstraction.”
AI doesn’t do this. It solves the stated problem. Period.
Research backs this up. GitClear’s analysis of over 211 million changed lines of code shows a 60% decline in refactored code between 2020 and 2024. For the first time in history, copy/paste has overtaken deliberate code reuse. AI-assisted coding has been linked to a 4x to 8x increase in duplicated code blocks.
The AI doesn’t know your codebase has three other places doing something similar. It doesn’t think about DRY. It generates a working solution and moves on. And if you’re reviewing 300 lines of generated output at a time, you’re not in the right headspace to notice the refactoring opportunity either. You’re just trying to make sure it doesn’t break anything.
Over time, the codebase becomes a patchwork “architecturally incoherent”.
🏕️ The Boy Scout Rule Gets Abandoned
The Boy Scout Rule is simple: always leave the codebase cleaner than you found it. It’s a discipline that, when practiced consistently, keeps codebases healthy without requiring massive dedicated refactoring cycles.
AI-assisted development makes this harder to practice. When you’re vibe-coding a feature, you’re in generation mode, not gardening mode. You’re looking at new code, not at the surrounding context. And since the AI doesn’t know what “clean” looks like in your project, it won’t suggest small improvements to adjacent code.
The result? Technical debt doesn’t just accumulate it compounds at machine speed. Some analysts project that by 2026, 75% of technology decision-makers will face moderate to severe technical debt.
GitClear data shows that “code churn” code discarded less than two weeks after being written is increasing dramatically with AI adoption. You’re writing more, throwing away more, and the codebase is getting harder to navigate.
🔐 Security Debt Is the Silent Crisis
According to the Veracode 2025 GenAI Code Security Report which tested over 100 LLMs across 80 real-world coding tasks 45% of AI-generated code introduces known security vulnerabilities.
Put differently: when an LLM has to choose between a secure and an insecure implementation, it gets it wrong nearly one time in two. And the most unsettling finding? This rate has remained flat over time. Newer, bigger models are not generating more secure code than their predecessors.
Why? Because AI optimizes for working code code that runs without immediate errors not for secure code. An AI generating an admin dashboard will create a beautiful UI and don’t care about the authentication middleware.
There’s also the hallucinated dependency problem. AI models sometimes reference packages that don’t exist. Attackers have learned to register these hallucinated package names on NPM or PyPI and when an unsuspecting developer runs npm install, they install a malicious payload. This is not theoretical. It's happening.
We’re generating 75% more code per developer than we did three years ago. If ~45% of that code has security issues, we’re accumulating vulnerabilities at a pace that traditional review processes cannot keep up with.
🌱 Junior Developers Are Losing Their Training Ground
This might be the most systemic long-term problem.
Junior development used to be an apprenticeship. You wrote boilerplate. You fixed small bugs. You struggled with a CSS layout for a day. And through that struggle slow and frustrating as it was you built mental models. You learned what the box model actually does. You learned why certain patterns break at scale. You developed instincts.
AI is quietly eliminating this training ground. An Anthropic study found that developers using AI assistance scored 17% lower on code comprehension tests when learning new libraries. Those who used AI to actually generate code scored below 40%, while those who used it only for explanations scored above 65%.
A recurring observation among experienced developers: mastering the fundamentals isn’t just about writing code, it’s what gives you the vocabulary to direct AI effectively. You can’t ask for what you can’t imagine.
Meanwhile, job market data is already reflecting this. We’re creating a generation gap: senior developers who can validate AI output because they earned their fundamentals the hard way and a new generation that never will.
🛠️ The Lost Art of Doing It by Hand
There’s something that doesn’t show up in any productivity metric: the quiet satisfaction of building something yourself, from scratch, and fully understanding every line of it.
Before AI, developers had a craftsman’s relationship with their code. You’d spend an afternoon wrestling with a tricky algorithm, not because you had to, but because figuring it out yourself was the point. You’d refactor a module until it felt elegant. You’d name a variable three different ways before settling on the right one. That friction wasn’t waste it was craft.
AI removes that friction almost entirely. And with it, something subtle disappears: the accumulated intuition that only comes from doing things the hard way. The developer who has hand-rolled an authentication system once even imperfectly will forever read AI-generated auth code differently. They’ll spot the missing edge case. They’ll notice the assumption that only holds in the happy path.
This isn’t nostalgia for the pre-AI era. It’s a warning about what we risk losing if we never practice the craft at all. The best engineers of the next decade won’t be the ones who prompt the fastest. They’ll be the ones who still know how to build with their hands when it matters and who use AI as an amplifier of their craft, not a replacement for it.
🧠 You may Stop Understanding Your Own Codebase
Here is perhaps the most philosophical concern: ownership.
When a developer writes code even imperfect code they have a relationship with it. They know why a particular decision was made. They can predict where bugs are likely to hide. They can explain it to a teammate.
When an AI writes code and a developer rubber-stamps it, that relationship evaporates. The developer may become a manager of code they don’t fully understand.
Comprehension debt the growing gap between what exists in the codebase and what the team actually understands may be the most expensive long-term cost of all.
🎯 So What Do We Do?
Remember the trade-off framing from the start? Here it is applied concretely. None of this means you should stop using AI.
The productivity gains for the right tasks are real. The democratization of prototyping is genuinely valuable.
But a trade-off you don’t manage becomes a debt you can’t repay.
A few principles worth adopting:
- 📚 Preserve writing time for learning. Don’t let AI generate the code you’re trying to understand. Use it for what you already know well.
- 🔎 Make code review a first-class activity. Budget more time for it, not less. Treat AI-generated PRs with structured skepticism not just “does it work?” but “does it belong here?”
- 🎓 Protect junior developers’ learning paths. Not every task should be AI-delegated. Struggling with a bug for two hours builds instincts that no prompt can replicate.
- 🤖 Ask an AI to review the output. Prompt it explicitly for security vulnerabilities, refactoring opportunities, and missing edge cases it won’t do this unless you ask.
- 📝 Feed AI your standards, not just your intent. Share your architecture rules, coding conventions, and design patterns directly in your prompts. AI doesn’t know your system, you do. The more context and expertise you bring to the prompt, the less cleanup you’ll do on the output.
- 🏛️ Own the output. Every line of AI-generated code that gets merged is your code. You are responsible for understanding it, maintaining it, and explaining it at 2am when it breaks in production.
The “Waouh” effect is real. But software engineering is a long game. The teams that will win in five years are not the ones who generated the most code in 2026.
They’re the ones who understood what they were building and made their trade-offs deliberately. ⚖️
I’m Smaïne, Thanks for reading! If this resonated with you, feel free to share it and let me know your experience with AI-assisted development in the comments 👇
