The New Problems AI Gave Engineers

Every generation of tooling solves a problem and invoices you with a new one. Compilers freed us from assembly and gave us dependency hell. The cloud freed us from racking servers and gave us a monthly bill nobody can explain. AI coding tools freed us from typing boilerplate and gave us a whole new job description that nobody agreed to.

I use these tools every day and I’m not going back. But the conversation is dominated by what AI removed from the job, so let’s talk honestly about what it added.

You Are a Manager Now, Congratulations

The core skill of the job used to be writing code. Now it’s delegating it.

When you run two or three agentic coding sessions in parallel - one refactoring a service, one writing tests, one chasing a bug - you are not programming anymore. You are managing a small team of very fast, very confident junior engineers who never push back, never say “I’m not sure” and will happily produce five hundred lines of plausible-looking wrongness if your instructions were ambiguous.

Everything that makes a good engineering manager now applies to you at the keyboard: writing clear specs, scoping work so it can fail safely, checking output instead of trusting the confident summary. The engineers getting real gains from AI already had those skills. The ones struggling are discovering that management is hard, even when the reports are software.

Nobody trained us for this. The industry spent twenty years telling engineers that the management track and the IC track were separate careers. Turns out the IC track quietly merged into management and nobody sent the memo.

The Expectation Ratchet Only Turns One Way

Once your employer believes AI makes you faster, that speed becomes the new baseline. It doesn’t matter whether the belief is accurate. The sprint gets sized for it, the roadmap assumes it and “I was fighting the agent all afternoon” is not a status update anyone wants to hear.

Fair enough, honestly. The tools do compress a lot of work and pretending otherwise is its own kind of dishonesty. The problem is that expectations ratchet up on the visible part of the job - shipping features - while the invisible parts grew. Review load grew. Verification load grew. The time spent writing good prompts and good specs grew. None of that shows up in a velocity chart, so none of it gets budgeted.

The result is a squeeze: the fun part of the job got faster and the unglamorous parts expanded to fill the savings.

What AI Is Actually Good At, and the Uncomfortable Part

Here’s the claim you’ll hear from experienced developers: AI is pattern matching, it’s repeating what it has seen before, so it falls apart on genuinely novel work.

I wanted to know if that holds up, so I checked. The honest answer: directionally right, with a caveat. “Just repeating” undersells what these models do - they compose patterns across domains in ways that go beyond retrieval, which is why they can write a Kafka consumer in a codebase they’ve never seen.

But the direction is correct: performance tracks training data density. A systematic survey published in ACM TOSEM reviewed the research on LLM code generation for low-resource and domain-specific languages and found exactly what practitioners suspected - models that are excellent at Python and TypeScript degrade sharply on languages and domains that are thin in the training data. Specialized syntax, niche industries, proprietary frameworks, hardware-adjacent work: the model has seen less of it, so it produces more confident garbage per token.

This is why greenfield work in a niche domain feels so different from adding a CRUD endpoint to a Next.js app. If your industry’s problems don’t look like GitHub’s problems, your gains will be smaller and your verification burden larger.

And this is the uncomfortable part: the METR randomized trial took experienced open-source developers, gave them AI tools on real tasks in mature codebases they knew well, and measured them completing tasks 19% slower with AI - while those same developers estimated afterwards that AI had made them 20% faster. The tools have improved since early 2025 and METR themselves now treat the result as historical, but the perception gap is the durable lesson: you cannot trust your own felt sense of AI productivity. It feels fast because you’re not typing.

The takeaway isn’t “don’t use AI.” It’s: don’t use it as a substitute for learning your tools and your domain. The engineers getting the most out of these models could do the work without them - they’re the only ones who can tell when the output is wrong. AI as a multiplier on top of competence works. As a replacement for competence it’s a loan against your future self, and the interest rate is brutal.

More Code to Review Than Any Point in History

Generation got cheap. Review didn’t. That asymmetry is quietly reshaping the whole job.

The numbers here are grim. Faros AI’s 2026 telemetry across 22,000 developers found median time in PR review up 441% year over year, pull request size up 51.3% and 31% more PRs merging with no review at all. Read that last one again. The review queue got so long that teams started routing around it.

That’s the failure mode: when review becomes the bottleneck, the pressure doesn’t produce better reviewers, it produces skipped reviews. And AI-generated PRs are uniquely miserable to review because the code looks right. Human sloppiness has tells - weird naming, inconsistent style, a TODO confessing uncertainty. AI output is uniformly polished at every quality level, so the reviewer gets no cheap signals and has to actually verify the logic.

The Security Bill Is Arriving

Speed versus quality used to be a philosophical debate. Now it has data, and the data is not flattering.

Veracode has been running the same security test suite against every major model since 2025, and their Spring 2026 update found the number hasn’t moved: AI coding assistants introduce known security vulnerabilities in 45% of test cases, even as syntax correctness passed 95%. The models keep getting better at writing code that runs, not code that’s safe. Meanwhile the Cloud Security Alliance is tracking a surge of CVEs directly attributable to AI coding tools and estimates the true count runs well beyond what’s been catalogued.

Maintainability is on the same trajectory. GitClear’s analysis of 623 million code changes found code duplication up 81%, refactoring down 70% and copy-paste climbing every year since assistants went mainstream. We are generating more code and understanding less of it, which is the textbook setup for the incidents of 2027 and 2028.

The 2025 DORA report puts the frame around all of it: AI adoption now correlates positively with delivery throughput but negatively with stability. Teams with strong tests, real review culture and fast feedback loops get faster. Teams without them get faster at shipping incidents. The tooling didn’t change what your team is - it turned the volume up.

The Treadmill of New Models, New Tools, New Everything

A new model every quarter. A new agent framework every month. A new “this changes everything” tool every week. Add token budgets, context window management and prompt optimization to the pile of things you’re now supposed to have opinions about, and the decision fatigue is real.

Here’s the thing though: this is not new. This is just our industry.

Anyone who did frontend work in the 2010s remembers the JavaScript years. Backbone, then Angular, then React, then a new state management library every six months, each arriving with a blog post explaining why everything you knew was obsolete. It felt exhausting then too. The engineers who survived it didn’t chase every release - they learned the underlying ideas, adopted deliberately and let the churn filter itself. Most of those revolutionary libraries are dead. The fundamentals they were built on aren’t.

Same playbook applies now. You need a default stack that works, a quarterly checkpoint to reassess and the discipline to ignore the rest. Adapt or fall behind has always been the deal in software - but adapting means updating your toolkit on your schedule, not letting the release calendar of a dozen AI labs set your attention for you.

Time is the only asset that matters in this career. Every hour spent evaluating a tool you won’t adopt is an hour not spent shipping or learning something durable. Optimizing your time was the meta-skill before AI and it’s the meta-skill now, the stakes just went up.

The Token Bill Nobody Budgeted For

Here’s the hidden cost that’s just now surfacing: tokens are the new cloud spend, and the burn rate is getting executive attention.

Look at Meta. Employees there consumed 73.7 trillion tokens in roughly 30 days, tracked on an internal leaderboard nicknamed “Claudeonomics”, putting the company on track for billions in AI costs this year. The leaderboard backfired: engineers started “tokenmaxxing” - inflating usage to climb the rankings - until CTO Andrew Bosworth had to publicly remind everyone that “token usage alone is not a measure of impact.” Meta is killing the leaderboard, rolling out centralized spend tracking and planning formal token budgets for 2027.

Instagram head Adam Mosseri went further, predicting per-engineer token caps within one to two years and noting that a strong engineer’s burn rate could soon rival their salary. Sit with that: the tooling cost of one engineer approaching the cost of the engineer. And Meta isn’t the outlier - Uber exhausted its entire 2026 AI coding budget in four months and now caps spending at $1,500 per month per tool.

Meanwhile the loudest voice arguing the opposite is the man selling the compute. Jensen Huang said at GTC 2026 that he would be “deeply alarmed” if an engineer paid $500,000 a year wasn’t consuming at least $250,000 worth of tokens, and that Nvidia is “trying to” reach $2 billion a year in token spend for its own engineering team. He’s not entirely wrong that refusing these tools is like designing chips with paper and pencil. But notice whose GPUs every one of those tokens runs on. When the person who profits from every token burned in the industry says your engineers aren’t burning enough, that’s a sales pitch dressed up as a productivity benchmark.

For companies the problem is visibility. Agent workflows consume tokens in ways nobody sees until the invoice lands - a runaway loop, a subagent fanning out over a huge codebase, a context window packed with files the task never needed. Most orgs can’t tell you their AI spend per shipped feature, which means they can’t tell whether the productivity story is real or just expensive.

For engineers, the thing to understand is that token spend measures productivity about as well as lines of code ever did - you can torch millions of tokens re-prompting an agent in circles and ship nothing, which is exactly what Meta’s leaderboard incentivized. The real skill is the ratio. Output per token is the number that matters, and optimizing it is a genuine craft: routing grunt work to cheap models, keeping context lean, caching what repeats and knowing when a problem doesn’t need AI at all. When budgets get capped - and Meta’s trajectory says they will - the engineer who gets results in a fraction of the tokens beats the one who brute-forces every task with the biggest model.

Businesses will want it both ways, of course: all the output of Huang’s $250,000 token budget at a fraction of the price. That’s the same pressure that turned cloud cost optimization into a discipline, and token efficiency is next.

The Problems Businesses Are Just Starting to Feel

For engineering leaders the problem set looks different, and most of it hasn’t fully landed yet.

The junior pipeline is cracking. If AI does the work juniors used to learn on, where do your next seniors come from? Every company optimizing this quarter’s headcount against AI is betting someone else will train the 2030 senior engineers.

Nobody understands the codebase. When a growing share of code is generated rather than written, institutional knowledge stops accumulating. That’s fine until the 2am incident where the on-call engineer is debugging code no human ever actually thought through.

Governance is a mess. What code left the building in prompts? What license does generated code carry? Which model was that written by, and would it pass your compliance review? Most companies are one audit away from finding out they don’t have answers.

The Job Didn’t Shrink, It Moved

None of this is an argument against AI tooling. It’s an argument for seeing the trade clearly. Typing got cheap. Judgment got expensive. The job moved up a level - from writing code to specifying, reviewing and verifying it - and every problem on this list is a version of that shift.

The engineers who will do well over the next five years are the ones treating that shift as the actual work: getting good at delegation, holding the line on review and testing, learning fundamentals deeply enough to catch confident nonsense and being ruthless about where their attention goes.

The tools will keep changing. The skill of knowing what good looks like - and refusing to ship what doesn’t - is the part that compounds.