By Ion Anghel · April 2026
A CTO called me last quarter. His pitch, roughly: "We're behind on AI. I want every engineer on Copilot by end of month, and I want to see velocity go up." I asked him three questions. Do you have tests? "Some." Do you have CI that blocks bad merges? "Kind of." When was the last time a senior engineer reviewed a junior's PR end-to-end? Long pause.
He didn't have an AI problem. He had a codebase problem, a process problem, and a hiring problem stacked on top of each other. Buying Copilot licenses was going to make all three worse, faster.
I want to be clear up front, because the rest of this is going to read like skepticism and it isn't: I think AI-assisted engineering is one of the most important shifts in our craft in twenty years. I use it every day. I ship more because of it. The point of this article isn't that AI is overhyped — it's that AI is being sold as a solution to problems it doesn't solve, and that confusion is costing teams real money.
AI Is an Amplifier, Not a Repair Tool
Large language models, and the agents built on top of them, do one thing very well: they continue the patterns they see. Give them a clean module with consistent naming, good types, and tests next door, and they will extend it in kind. Give them a 200-line controller with three different error-handling styles, a global mutable singleton, and SQL string-concatenation, and they will faithfully produce more of exactly that. The model isn't going to push back and say "actually, this class has too many responsibilities, let me refactor first." It's going to match the room.
This is the part of the sales pitch nobody dwells on. AI doesn't have taste about your codebase. It has statistics about your codebase. If the statistics are bad, the output is bad — only now there's more of it, and it ships faster.
You can feel this in any reasonably old monorepo. Run an agent through a legacy module and watch what comes out: confidently written code that looks plausible, uses the existing helpers, follows the existing anti-patterns, and passes the existing weak tests. The CI is green. The PR is small. It merges. Six weeks later you're paging someone at 2am because of a race condition the agent had no way to know about, in a system the agent had no way to model.
The fix here isn't to ban the agent. The fix is to admit that the codebase couldn't carry that velocity to begin with.
Security Is Where This Hurts First
Over the years I've audited a fair number of small-to-mid web platforms, and the same handful of issues come up almost every time. API keys committed to git, often discoverable in the public history. .env files served by the web root because someone misconfigured a directory rule. Webhooks that accept any POST because signature verification was "TODO." User input flowing untouched into SQL, or into shell commands, or into template strings the framework happily renders as HTML. GDPR consent flags that exist in the UI but are never actually read on the backend.
None of these issues were created by AI. They predate it by decades. But here is what AI changes: it dramatically lowers the cost of adding new code, and most teams have no corresponding investment in raising the cost of adding unsafe code. So the same patterns get reproduced, faster. The agent sees that the existing controllers don't validate input, and writes a new controller that doesn't validate input. The agent sees that secrets are loaded from a .env that's tracked in git, and confidently uses that pattern in a new service. The agent isn't being reckless. It's being consistent. With a codebase that was already reckless.
I wrote about a specific version of this failure mode in From Vibe Coding to Insecure Keys — a project shipped from prompt to production in a weekend, with credentials sitting in the browser bundle. That's not an AI bug. That's a process gap that AI made cheap enough to expose at scale.
Without Tests and CI, Velocity Is Just Risk
There's a particular conversation I keep having with engineering leaders. They want to measure AI adoption by PR throughput, or by lines of code, or by Jira tickets closed. These are all measurements of one thing: how fast you're putting code into the system. None of them measure whether the code should have gone in.
If you don't have tests, you don't have feedback. If you don't have CI that runs those tests on every change and blocks merges on failure, you don't have a safety net. If you don't have code review where a second human actually reads the diff and pushes back, you don't have a quality filter. Stack an AI agent on top of that and what you've built is a faster route from idea to incident.
The teams who get genuine leverage from AI are not the ones who adopted it most aggressively. They're the ones who already had the boring stuff in place — a test suite that runs in under ten minutes, a deploy pipeline you can roll back from in one click, alerting that pages a human before customers tweet. AI compresses the work between those guardrails. It doesn't replace the guardrails.
"Vibe Coding" Doesn't Scale Past the Demo
There's a mode of working — fast, conversational, mostly trusting the model — that is genuinely wonderful for prototypes, internal tools, weekend projects, learning new stacks. I do it constantly. It is how a lot of useful software gets started.
It is also catastrophically inappropriate for any system that handles real user data, money, or third-party credentials, deployed by anyone who isn't going to personally read every line before it ships. The reason isn't that the model is bad. The reason is that "vibe coding" deliberately turns off the checks — you're not reading the diff carefully, you're not thinking adversarially about inputs, you're not asking "what happens if this fails." Those checks are exactly what production code needs more of, not less.
The mistake some companies are making in 2026 is taking a workflow that's great for a hackathon and trying to run a business on it. You can't.
The Real Problem Is Almost Never Technological
Here's the uncomfortable observation I keep arriving at. When a leadership team buys a fleet of AI tools to "transform" their engineering org, the AI is often not the actual purchase. The actual purchase is the avoidance of three much harder conversations.
The first is about technical debt — the kind that requires saying out loud, in front of the board, that the platform you've been celebrating for five years has rot underneath and someone needs to spend a quarter cleaning it up. The second is about hiring — that the bar slipped, that there are people on the team who should not have been hired or should not have been promoted, and that no amount of tooling fixes a team that doesn't know what good looks like. The third is about standards — that the org never agreed on what "done" means, what testing is required, what a review actually has to catch, and that everyone has been operating on personal taste for years.
AI is being marketed as a way to skip those conversations. It isn't. It's just a way to make their consequences arrive faster.
When AI Actually Earns Its Keep
I want to end on what works, because plenty does.
On a healthy codebase — clean module boundaries, decent types, a real test suite, observability you can actually read — AI assistance is genuinely transformative. Refactoring across dozens of files becomes a half-hour task instead of a sprint. Writing tests for code that's already well-structured becomes pleasant rather than tedious. Documentation that nobody had time for gets generated and then edited down. Code review gets a second pair of eyes that never gets tired and catches the boring class of mistakes humans miss at 5pm. Exploratory analysis on a dataset you've never touched becomes a conversation instead of an afternoon of Stack Overflow.
In every one of those cases, the leverage comes from the same source: the foundation was solid enough for the model to amplify in the right direction. AI didn't fix anything. It accelerated work that was already correct.
What to Do Monday Morning
If you're about to roll out AI tooling across your engineering org, here's the only thing I'd ask you to do first. Open the last three production incidents and read the postmortems honestly. Were they caused by something an LLM could have prevented — a typo, a missing null check, a forgotten import? Or were they caused by something more structural — no test for that path, no alerting on that signal, no review of that PR, a service nobody on-call understood?
If it's the second category — and it almost always is — then the highest-leverage thing you can do this quarter is not a Copilot rollout. It's a test suite that runs on every PR. It's a one-page document that defines what "done" means for your team. It's twenty minutes of pairing between a senior and a junior on code review, every week, until the bar is shared.
Do that, and then bring the AI in. It will pay back tenfold, because it will finally have something worth amplifying.
Disclaimer: I'm bullish on AI. I think most of the rough edges I'm describing will be smoothed in the next few years, and I think the engineers who learn to work alongside these tools will out-ship the ones who don't, by a wide margin. But the path to that future runs through engineering discipline, not around it. The teams that win with AI are going to be the ones that were already winning without it — and the teams that are broken today are going to be broken faster, more expensively, and in front of more customers.