Originally published on tamiz.pro.
Two years ago, I could not make a Copilot suggestion pass code review without rewrites. Today, half my PRs ship with AI-generated code that I barely edited. The tooling genuinely got better. The question nobody asks honestly is whether I got worse at the underlying engineering — and whether my colleagues, juniors especially, are being quietly hollowed out by an assistant that answers every question before they struggle through it.
This is not an anti-AI rant. It is a developer's technical audit of what has changed, what has been genuinely replaced, and what has been quietly eroded. The distinction between those two categories is the entire argument.
What AI Actually Replaced (And We Should Accept That)
There are real, measurable categories of work that AI coding assistants have genuinely automated. These are not losses. They are wins.
Boilerplate and scaffolding. Generating a React component from a spec, writing a CRUD endpoint, creating a Dockerfile, setting up a test fixture — these were never intellectually interesting. They consumed time and attention that could have gone to architecture decisions or debugging. AI handles these well now. A junior developer who spends twenty minutes on a boilerplate template can instead spend that time understanding the system's data flow.
Documentation and API lookups. Before AI, I spent more time reading TypeScript type definitions than writing code. I would open a library's docs, search for the right overload, and discover that the function signature I remembered was from two versions ago. AI assistants now answer these questions in context, with accuracy that has improved dramatically. This is pure time savings with zero cognitive cost.
Regex, date parsing, and string manipulation. These were the tax developers paid for working with text. AI writes regex patterns, date formatting utilities, and string transformations that work on the first try. This is a genuine replacement — not because the task was hard, but because the cognitive overhead of getting it right was disproportionate to its value.
Test generation for straightforward cases. Unit tests for pure functions, snapshot tests, and integration test scaffolding are now reliably generated. The generated tests are not always meaningful, but the structural work of writing them is done.
If your daily work is dominated by these categories, AI has made you more productive. That is unambiguous. I am not arguing against that.
What AI Made Lazy (And This Is the Real Problem)
The concerning trend is not replacement. It is the substitution of understanding with suggestion. Let me be specific about what I have observed in my own work and in the work of junior developers on my teams.
Debugging has become search-and-paste. When an error occurs, the reflex is no longer "let me trace through the call stack and understand why this happened." It is "let me ask the AI what this error means and what to change." This works — until the AI gives you a plausible but wrong explanation, and you apply it without verifying. I have seen this happen repeatedly on my team. A developer pastes an AI-suggested fix for a race condition, it appears to work in testing, and then it manifests in production under load because the AI suggested adding a setTimeout instead of properly understanding the async flow. The fix was syntactically correct and semantically wrong.
Type safety is being bypassed. TypeScript exists to make invalid states unrepresentable. When you are typing code from scratch, you engage with the type system — you ask "what does this function actually accept?" When you paste AI-generated code, you skip that engagement. The code compiles. The types are wrong. The error appears three layers down in production. I have reviewed PRs where the AI generated a any cast to make a type error go away, and the developer merged it without questioning why the cast was needed.
Architecture decisions are being outsourced to autocomplete. This is the one that worries me most. When a junior developer asks "how should I structure this module?" and the AI returns a pattern, they adopt it without evaluating whether it fits the system. The AI has no context of your team's conventions, your deployment constraints, your performance requirements. It gives you a textbook answer, and textbook answers fail in production because production is not a textbook. I have seen this with state management choices, database schema designs, and API contract decisions. The AI's suggestion was reasonable in isolation. It was wrong for the system.
The struggle is being skipped, and the struggle was the learning. This is the philosophical core of my argument, but I will ground it in engineering. When you write a function from scratch and it fails, you learn why it failed. You learn the language's semantics, the library's behavior, the system's constraints. When you generate code from a prompt and it works, you learn nothing. You have a working feature. You do not have understanding. Six months later, when that feature needs modification under different constraints, you cannot modify it because you never built the mental model. You can only regenerate it and hope the new prompt produces something compatible.
This is not hypothetical. I have a team member who has been on AI-assisted development for eighteen months. Their code output is high volume and generally functional. But when I ask them to explain the reasoning behind a non-obvious design decision in their own code, they cannot. They ask the AI to explain it to them. The AI gives a plausible explanation. They nod. They do not understand.
The Pattern I Am Watching
I am not arguing that AI should not be used. I use it daily. I am arguing that there is a spectrum, and we are sliding toward the wrong end of it without noticing.
The productive pattern: You understand the task. You write the code. You ask the AI to review it, suggest improvements, or catch edge cases. The AI is a second pair of eyes. You remain the primary author. This pattern preserves skill development while accelerating output.
The lazy pattern: You describe what you want. The AI generates code. You paste it. You test it. If it works, you ship. The AI is the primary author. You are the delivery mechanism. This pattern produces output while degrading capability.
The difference is not visible in the code that ships. It is visible six months later when the system needs to change, or when a bug appears that requires understanding rather than pattern matching. In the first case, you have the mental model. In the second case, you do not.
What I Have Changed in My Workflow
I have made deliberate adjustments based on this audit. These are not rules. They are practices.
I write first, then ask. For anything non-trivial — any function with business logic, any architectural decision, any code that touches shared state — I write the initial version myself. Then I ask the AI to review it. I ask it what I might have missed, what edge cases exist, whether my approach has a better alternative. This keeps me in the author seat while using the AI as a collaborator.
I ask "why" before "what." When the AI suggests a fix, my first question is not "should I apply this?" It is "why does this error happen, and why does this fix address the root cause?" If the AI's explanation does not match my own understanding of the system, I investigate further. If the explanation reveals something I did not know, I learn. If it reveals that the AI does not understand the system, I ignore the suggestion.
I audit generated code for type safety and assumptions. Every AI-generated code block gets a review pass specifically looking for any casts, implicit type coercion, unvalidated inputs, and hidden assumptions about the environment. The AI does not know your deployment target, your data constraints, or your team's conventions. It optimizes for code that looks correct, not code that is correct in context.
I protect junior developers' learning curve. On my team, we have a practice of "write it yourself first" for the first three months of a new hire's tenure. After that, AI-assisted development is encouraged, but code review explicitly asks the developer to explain their understanding of the code they pasted. If they cannot explain it, the code does not ship. This is non-negotiable for us.
The Honest Assessment
AI has not made developers dumber. AI has made it possible for developers to be dumber while still producing functional output. The tooling is genuinely better. The productivity gains are real. The replacement of boilerplate work is a net positive.
But the erosion of foundational understanding is also real, and it is not visible in metrics. It is visible when the system needs to evolve, when a novel problem appears, and when a developer encounters a bug that does not match any pattern in the AI's training data. At that point, the developer who has been generating code for two years without writing it themselves has no fallback. They have no mental model. They have only the tool.
The developers who will thrive are not the ones who use AI the most. They are the ones who use it correctly — who write first and ask second, who understand before they paste, who treat the AI as a collaborator rather than a replacement for their own reasoning.
The AI got better while I was away. I do not think we got dumber. But I think some of us are getting lazier, and laziness in engineering is a slow, invisible failure mode that compounds until the system breaks. The question for every developer is not "should I use AI?" It is "am I using AI to augment my understanding, or to replace it?"
The answer to that question is not visible in your PRs. It is visible in your ability to debug, to architect, and to explain why the code works the way it does. If you cannot answer that last question for your own code, the AI has not helped you. It has delayed the reckoning.
For more analysis on AI's impact on developer workflows and engineering practices, see Tamiz's Insights for ongoing coverage of the tools and trends shaping modern software engineering.
Frequently Asked Questions
Should I stop using AI coding assistants entirely?
No. That would be a poor trade. AI assistants genuinely improve productivity for boilerplate, documentation, and routine tasks. The risk is not using AI — it is using AI in a way that prevents you from building understanding. The productive pattern is to write first, ask second, and always audit what you generate.
How do I tell if I am in the "lazy pattern" vs. the "productive pattern"?
The simplest test: can you explain the code you wrote to another developer without referencing the AI? Can you debug a modification to that code from first principles? Can you explain why you chose a particular approach over alternatives? If the answer to any of these is "I would need to ask the AI," you are in the lazy pattern for that task.
Does this apply to AI tools beyond coding assistants?
Yes. The same dynamic applies to AI-generated documentation, AI-assisted architecture design, and AI-generated test suites. The pattern is universal: when the tool produces the answer before you have built the understanding, you skip the learning. The fix is the same: engage first, ask second, audit always.
Top comments (0)