An AI coding agent once told me to drop my entire database and recreate it to fix a migration conflict. The suggestion was detailed, well-reasoned, and technically correct. It would also have wiped every production record. After a year of using AI coding agents every day, that kind of moment stopped feeling unusual. It became routine. The productivity gains are real. But so are the costs nobody talks about.
The Productivity Illusion: What the Data Actually Shows
Most AI productivity conversations focus on one thing: speed. Pull requests shipped. Tokens consumed. Lines of code per hour. But the research published in 2025 and 2026 tells a more complicated story.
METR ran a controlled study and found that developers overestimate AI’s productivity benefit by more than 40 percentage points compared to what the actual experimental data shows. In some task categories, AI tools made developers slower. Not because the tools were bad, but because the time spent reviewing, correcting, and integrating AI output was never counted as part of the productivity cost.
CodeRabbit’s analysis of 470 open-source pull requests is harder to ignore. AI-authored code had 1.7 times more issues than human-written code. Security vulnerabilities showed up 2.74 times more often. Logic errors were 75% more common. Error-handling gaps were nearly twice as prevalent in AI-generated PRs.
None of this means you should stop using AI. But it does mean the way most teams measure AI value is incomplete. Speed at the moment of code generation is only part of the picture. Maintenance cost, review time, and defect rate are the numbers that tell the full story. And they are almost never tracked alongside token usage.
Around the six-month mark in my own work, I noticed it directly. I was shipping faster. I was also spending a lot more time in code review, catching issues that would not have been there if I had just written the code myself. The net gain was smaller than it looked.
The Over-Commitment Trap
Here’s something I did not expect: AI changed how I said yes to work.
When a proof of concept takes minutes instead of hours, it becomes easy to agree to things. New projects, extra features, side requests. The yes feels reasonable. AI will handle it. It will be quick.
But AI speeds up starting. It does not speed up finishing. Scaffolding an ASP.NET Core API, generating boilerplate command handlers, creating migration scripts — those are real time savings. But the architectural decisions, the edge cases, the integration complexity and security review still take as long as they always did.
By the end of year one, I had more active projects than I had ever managed before. Not because my capacity had grown, but because AI had made it cheap to start things without thinking hard enough about whether they were worth starting. Each new project was just a prompt away. The result was a lot of things in progress, fewer things actually finished, and a growing backlog of half-built work that each needed real attention.
AI does not change the cost of completing something. And it does not change the value of deciding not to build something. It only makes starting cheaper. If you do not account for that gap, you will take on more work than you can actually ship.
Context Switching: The Invisible Tax
More projects means more context switching. And context switching is one of the most expensive things a developer can do. Research puts the cognitive cost of a single task switch at 20 to 40 minutes of lost focus.
AI agents create a new kind of switching. When an agent is running a long task — a test suite, a refactor, a scaffolding job — there is always something to do while you wait. Start something else. Check on another project. Keep a second agent going in another tab.
It sounds productive. In practice, it trains you to never be fully present on one thing. You are always one tab away from splitting your attention. And because agents work asynchronously, your day starts to organise itself around keeping agents busy rather than thinking deeply about problems. That is a real shift in where your cognitive effort goes, and it barely comes up in any conversation about AI productivity.
The Always-On Problem
When you are prompting more than coding, the barrier to working drops significantly. You do not need a quiet space or a focused state to write a prompt. You can do it from your phone, from the sofa, while half-watching something else.
So the agent is always waiting. You could check its output. You could start the next thing while the idea is still fresh. The pull to keep things moving does not stop when you step away from your desk.
This is something I noticed slowly and then all at once: AI coding agents made it harder to stop working. Not because the tools require it, but because they removed the friction that used to act as a natural off switch. When writing code needed focused effort, you stopped when the focus ran out. Prompting does not have that constraint. Those stopping points just disappear.
When AI Code Quality Becomes a Professional Risk
The behavioural costs above are real but manageable. Code quality is where the stakes get higher, especially in regulated environments.
AI coding agents fail in specific, predictable ways.
Logic errors that look correct. The code compiles, the tests pass, and the happy path works fine. But the edge case — the input that should be rejected, the boundary that needs special handling — is missing. Not obviously. It is just not there.
Security patterns from outdated training data. AI reaches for patterns that were common in its training data. In .NET, that can mean deprecated authentication flows, outdated cryptography, or missing input validation that was acceptable three years ago but is not good enough now.
Aggressive fixes to constrained problems. This is the database drop scenario. When an agent sees a problem with a limited set of direct solutions, it sometimes picks the most direct one, even when that path carries serious side effects. It does not understand what “production” means in context. It is solving the problem you described, not protecting what you did not mention.
In a consumer app, a security gap is a bug report. In banking or payments, the same gap is a compliance incident, a customer data risk, and a reputational problem. The agent will not make that distinction for you. You have to build it into your process.
CodeRabbit’s finding of 2.74 times more security vulnerabilities in AI-generated PRs is not something to file away. It is your baseline. Your review process needs to be built around it.
Plan Mode: The Fix That Actually Works
The single most useful change I made to my AI workflow was using plan mode consistently, even on tasks that seemed straightforward. Before any code gets written, the agent produces a plan: what it intends to do, in what order, and why. I read and approve that plan before implementation starts.
This is slower than letting the agent run straight to code. That is the point. The slowness forces a review moment that the default workflow skips entirely. It catches the “drop the database” suggestions before they become actions. It surfaces architectural decisions that would otherwise be buried inside the output. And it gives you something clear to check the final code against.
Plan mode is especially worth using for:
- Tasks touching existing data — migrations, schema changes, data transformations
- Security-sensitive code — authentication, authorisation, input handling, cryptography
- Integration points — external APIs, message queues, third-party services
- Refactoring existing systems — where side effects are hard to predict from a prompt alone
For greenfield scaffolding or isolated utilities, the overhead is less justified. Use your judgement. But for anything that touches production data or security, plan mode is not extra process. It is the minimum you should be doing.
And whatever workflow you use, treat AI output the way you would treat a pull request from a capable junior developer. They may have solved the problem. They may have introduced three new ones. Your job is to know which before the code ships.
Conclusion
A year of daily AI coding agent use has been productive and educational in equal measure. The tools are fast, genuinely useful, and getting better. They are also not a replacement for architectural judgment, security awareness, or the discipline of deciding carefully what is actually worth building.
The METR and CodeRabbit data points in the same direction as what I experienced directly: AI speeds up the parts of development that are already well understood, and adds new risk in the parts that require judgment. The developers getting the most from these tools are not the ones prompting fastest. They are the ones reading AI output critically, planning before they implement, and tracking whether things actually get finished, not just started.
Speed is easy to automate. Judgment is not. What does your process for reviewing AI-generated code look like on your team? Let me know in the comments.
