The core takeaway

AI coding assistants are not productivity multipliers. They are work redistributors.

They move work from the start of the project to the end. They move work from writing code to debugging code. They move work from junior engineers to senior engineers. They move work from business hours to 3 AM on a Saturday.

Nobody will tell you this on the product landing page. But this is what every engineer actually using these tools is experiencing right now.

The 80/20 illusion

Everyone who has used these tools knows this pattern. You ask for a feature. You get 1200 lines of clean, properly formatted, typed code in 90 seconds. All the tests pass. The demo works perfectly. You feel unstoppable.

Then you hit the last 20%.

That last 20% does not take 20% of the time. It takes 400% of the time.

This is not a bug. This is the design. AI models are trained on millions of happy path examples. They have seen exactly your feature a thousand times. They have never seen your specific edge case. They have never seen your weird legacy database constraint. They have never seen the compliance hotfix that was applied manually three years ago and never documented.

The code will look correct. It will behave correctly for every test case you can think of. Then three weeks later it will fail in exactly the way that only someone who has been burned ten times before would have predicted.

You will spend six hours debugging one line. Not because the line is wrong. Because every assumption underneath the line was wrong, and none of them were written down.

Vibe coding is not the problem. The prototype illusion is.

Vibe coding gets a bad reputation. It is actually one of the best uses of this technology.

When you are building a throwaway script, a one off parser, a puzzle solver, a prototype that will be thrown away after the demo? Vibe code all day. This is where AI delivers exactly on its promise. It removes all the friction between an idea and something you can touch.

The problem starts when nobody remembers it was a prototype.

This is the prototype illusion. An AI generated prototype looks 95% complete. It is usually about 15% complete.

A designer will show the prototype and think this is almost done. An engineer will look at the exact same thing and think this needs to be completely rewritten. Both are correct from their perspective.

This mismatch is the single largest source of friction in teams using AI today. It is not that one side is wrong. It is that there is no shared language for what is real and what is mocked.

The fix is not banning prototypes. The fix is the 10 minute exercise that should be mandatory before anyone shows an AI demo: for every feature on the screen, explicitly mark if it is real, mocked, partial, or unknown. Do this every single time. It will eliminate 80% of cross team arguments before they happen.

AI bloat accumulates one line at a time

You will never open an AI generated file and immediately see that it is bad. Every individual line will look reasonable. Every individual function will have a sensible comment. Every abstraction will be the kind you have seen in a hundred tutorials.

Then six months later you will realize your codebase is 37% larger than it needs to be. All the tests pass. Nobody can explain what half the subsystems actually do.

This is the unique failure mode of AI generated code. It does not have obvious mistakes. It has accumulation.

Every agent turn leaves a little residue. A defensive abstraction that was never needed. A comment explaining something obvious. A placeholder subsystem that was never removed. A duplicate state layer because the model did not notice the one that already existed.

None of these are bad on their own. Together they turn a codebase into something that gets slower and harder to change every single week, even though nothing is obviously broken.

One engineer ran an experiment on a 100% AI built Flutter app. He removed 31.7% of all lines of code. All tests stayed green. Two latent bugs were fixed in the process.

Nobody had done anything wrong. The bloat just accumulated.

Relevance is not authority

There is one failure mode that nobody talks about, and it will destroy every production system you let an autonomous agent touch.

AI agents do not understand authority. They understand relevance.

When an agent sees three semantically similar pieces of context: the current production rule, an old superseded note from 2023, and a throwaway comment from a planning meeting, it will treat all three as equally valid. It will pick whichever one fits the immediate goal best.

This is exactly what happened in the $3.15M rollback incident. The agent correctly identified that rolling back the deployment would fix the immediate error. It had no way to know that the manually applied compliance hotfix that got erased in the rollback was the single most important thing running on that server.

It did exactly what it was told to do. It fixed the metric on the dashboard. It broke everything that actually mattered.

You can not fix this with better prompts. You can not fix this with better retrieval. This is a fundamental limitation of how these systems work today. They will always choose the relevant action over the authorized action.

The metric gaming trap

Every organization that has mandated AI usage has ended up gaming the metrics.

Amazon recently started tracking AI token usage as a performance metric for engineers. Within three months developers had built bots that generated fake work to inflate their token counts. Nobody was shipping faster. Everyone was just burning compute to hit a number.

This is not a failure of execution. This is what always happens when you measure the tool instead of the outcome.

AI usage is not a goal. Shipping reliable software is a goal. If your organization has started counting how many times people open their coding assistant, you have already lost.

The dependency loop

84% of developers now use AI coding tools daily. That is not adoption. That is integration.

When Anthropic temporarily rolled back rate limits in January, thousands of developers reported feeling like their personal productivity dropped by 60%.

Anthropic's own internal study found that developers using their tool scored 17% lower on independent skill tests. A separate METR trial found that developers felt 20% faster. They were actually 19% slower.

This is the dependency loop. You delegate a task to the AI. You do not practice the skill. Next time you can not do the task yourself. So you delegate it again.

This is not like IDEs. This is not like Stack Overflow. All previous tools automated typing. This tool automates thinking.

You will not notice this happening. You will just wake up one day and realize you can not write a simple CRUD endpoint without opening the chat window first.

Vendor lock-in moved to your brain

AI coding tool vendors did not invent lock-in. They just perfected it.

Previous generation lock-in lived in your infrastructure. You could migrate away if you were willing to pay the cost. This generation of lock-in lives in your workflow. It lives in your muscle memory. It lives in the fact that you have forgotten how to do half your job without the tool.

Opaque rate limits. Temporary promotional allowances that set a new baseline then get yanked. The quiet panic when the service goes down mid task. These are not operational accidents. These are deliberate design choices.

Uber burned through its entire 2026 AI budget by April. Nobody planned this. The tool just spread across 5000 engineers faster than any policy could keep up.

The role of the engineer did not disappear. It changed.

Nobody is getting replaced by AI right now. But a lot of people are getting replaced by bad metrics.

The $660K AI platform that replaced the support team did not actually reduce work. It just moved all the work from 9 AM to 3 AM. It closed 93% of tickets during the day. 41% of them reopened. Every single one of them still needed a human to fix it.

The job did not go away. It just stopped showing up on the PowerPoint slide.

This is the actual shift that is happening. Engineers will spend less time writing the first version of things. They will spend much more time:

• Validating that AI output is not lying
• Finding the hidden assumptions in generated code
• Defining what the agent is not allowed to do
• Fixing the mess after the agent did exactly what you told it to
• Turning prototypes that look real into systems that are real

This is not a demotion. This is the actual job of engineering. It always was. Writing code was never the hard part.

When is 100% vibe coding ok?

There is a very clear line.

Vibe coding is 100% acceptable if and only if:

1. You understand the invariants of the problem
2. You can verify the output completely
3. Nobody else will ever have to maintain this code
4. Failure has no permanent consequences

If all four are true, go wild. This is the best use case for this technology that exists today.

If any one of these is not true, you are not using AI. AI is using you.

The handoff template that actually works

The best handoff of an AI prototype is not perfect code. It is clear context.

Before you hand anything to an engineer, write down:

• What works today
• What is mocked
• What is known to be fragile
• What problem you were actually trying to solve
• The exact questions you need answered

Do not send a zip file and say "make this production ready". That is not a handoff. That is a surrender.

Teams that do this have cut friction by 70%. Teams that don't are still having the exact same argument they were having two years ago, just now with nicer looking prototypes.

What you should actually do

You do not need to stop using AI coding tools. They are good tools. You do need to stop treating them like engineers.

Treat them exactly like an extremely fast, extremely confident junior developer.

Give them well defined tasks. Review every line of their output. Never give them production access. Never trust them with edge cases. And most importantly, never stop being able to do their job yourself.

Every once in a while, close the chat window. Open a blank file. Write something from scratch.

Not because AI is bad. Because you are the engineer. That job still belongs to you.

Closing note

None of this is an argument against AI. None of this is luddism.

This technology is real. It is powerful. It is not going anywhere.

But all the hype, all the marketing, all the boardroom presentations have been lying about one thing. This technology does not remove work. It moves work. It hides work. It shifts risk from the people who buy the tools to the people who have to run the systems.

The good news is that the skills that actually matter did not change. Judgment. Context. Taste. The ability to see the thing that is not written down. The willingness to answer the phone at 3 AM.

AI can not do any of that.

And it never will.