The CEO doesn't want an AI writing better code than you. They want an AI writing code for cheaper than you.
That's the part most developers get wrong when they think about the AI threat to their careers.
The Fear Is Backwards
We keep debating whether AI can match a senior engineer's output. If it can have a real understanding of architecture. If it can think through edge cases.
None of that matters to the person approving headcount. The question in the boardroom isn't "Is this AI as good as Sarah?" It's "Is this AI good enough to skip hiring Sarah's replacement?"
Those are two completely different questions. However, only one of them determines your future.
Meet "Vibe Debt"
There's a term gaining traction in developer circles: vibe debt. It describes the specific flavor of technical debt that AI-generated code creates — code that looks right, passes a cursory review, maybe even works today, but carries hidden rot.
It's the kind of code that makes you say "this feels off" without being able to immediately point to why. That's how it got its name.
Here's the thing about vibe debt: it doesn't show up on a quarterly report. You know what does show up? The salary line item that just got eliminated.
→ AI slop ships on Tuesday
→ The bug surfaces in October
→ The dev who could've caught it was laid off in March
→ A contractor gets hired at 2x the cost to fix it
This situation has been happening since the beginning of outsourcing. The only difference is that now we have a new type that creates pull requests.
Cost-Cutters Don't Optimize for Quality
Business incentives favor cost-cutting over code quality. This isn't cynicism. It's just how quarterly earnings work.
A Vice President doesn't receive a promotion because they "maintained excellent code health across the platform." It's because they "reduced engineering spend by 40%." What drives people are the rewards they seek.
So when a mediocre AI tool can generate a feature that mostly works, that's not a failure to the person holding the budget. It’s considered successful. Ship it, file the bugs later, let the remaining skeleton crew deal with the fallout.
I have seen this happening before with offshore outsourcing, with no-code tools, with every "developers are too expensive" trend. The process is always identical:
→ Replace skilled people with a cheaper alternative
→ Declare victory for two quarters
→ Quietly hire specialists to clean up the mess
→ Never acknowledge the total cost was higher
AI just makes the first step more convincing. 🎯
Why This Should Change Your Strategy
If the threat isn't brilliant AI but mediocre AI in the hands of aggressive cost-cutters, then your defense isn't "be slightly better than GPT at writing functions."
You are defending being the individual who "gets" the why of broken things. The person who can enter a repository full of vibe debt and reliably determine it. The person the suits phone after their AI-first approach begins spewing production incidents.
The skills that matter most in this world:
→ Systems thinking — understanding how components interact, not just how to generate them
→ Debugging intuition — the AI can write code but it can't feel the wrongness in a stack trace at 2 AM
→ Organizational trust — being the person a team actually believes when you say "this will break"
A cost-cutter can't replace any of those with a $20/month subscription.
The Bottom Line
The developers who are in the most danger are not the ones who can’t keep up with AI. It’s the ones who work at organizations where the leadership sees engineering as an expensive cost to be cut, rather than an essential capability to be grown.
The AI isn't the threat. The spreadsheet is.
So here's my question for you: Have you seen this pattern emerge within your company — not AI replacing devs outright, but AI being used by leadership as a reason to shrink teams below what they should be? And what happened next?
Top comments (6)
I think the way you characterise boardrooms is polarised; it may be true in some businesses, I grant you. The CEOs I know are not focused on the cost of headcount; they are focused on the cost of developing feature X or product Y to a point where it is valuable and saleable. If feature Z becomes attainable because we can do a lot more work using AI, then spend the money on inference. If feature Z is a failure because it is broken or won't scale, it's the CEO's neck on the line; they don't want that - so right now they want the people who can ensure it isn't broken.
Could these CEOs one day decide not to hire replacements because AI was cheaper, yes they could. Today, they still need architects and thinkers; they need fewer code monkeys. Maybe tomorrow the AI will cover those bits too. Who knows. This is progress, I guess...
As software engineers, we've been the agents of progress in areas. Software solutions and applications have replaced lots of jobs - just ask how many mailmen you need now, how many switchboard operators? The answer to enhanced efficiency (e.g. cut out some cost, frequently human) used to be: "hire some great programmers, have a great idea, build it". Were those solutions really good as the personal touch that was there before: "no", were they good enough: "yes".
the cost calculation shifts the moment cheap AI ships something broken. whoever approved headcount still needs a human who owns the blast radius - that accountability doesn't get automated away as easily as the code itself.
What I see on the consulting side maps to your thesis, but the failure mode is more mundane than bad AI. Most companies don't actually buy 'replacement'. They buy a Copilot license, push it across the org, and call it transformation. Vibe debt then comes from nobody owning the tool: no eval, no policy on what ships with assistance, no review of what broke. The license alone produces the slowdown, no headcount decision required.
"Vibe debt" is the right name for something I keep running into. Code that passes review and tests, looks solid, and still feels wrong when you trace through it. You read a function, it does what the name says, but you can't figure out why the author chose that approach. Then you realize there was no author. Someone generated it, accepted the output, and moved on.
I saw the same pattern with offshore teams in the early 2010s. A company would ship with cheaper labor, report the savings for two quarters, then quietly re-hire when the codebase got unmaintainable. AI-generated code runs through that same loop faster. Offshore code had a human who understood the intent, even if the execution had gaps. AI-generated code has no one who remembers the constraints or the reason a function exists. When it breaks, you start from zero.
I've seen this split in my own SaaS platform. AI handles data transformation and API integration well because I can describe those tasks precisely. It fails at anything that requires knowing the business domain, like why a workflow branches at a specific point or why an edge case matters to a particular customer segment. I got those answers from conversations with customers, not from training data.
That spreadsheet threat you named is where careers get killed. A VP who earns a promotion by cutting engineering headcount 40% and declaring the AI "good enough" creates a problem that takes 18 months to surface and three years to fix.
The framing nails the actual risk. The org doesn't lose to a competitor's better model, it loses to its own internal team adopting the cheap default and shipping it before anyone has a chance to evaluate alternatives. Most 'bad AI' is just unevaluated AI under deadline pressure.
AI should be a partner, not a cheap replacement. Give us tools that amplify skill, catch mistakes, and ship responsibly. Cheap, buggy AI hurts teams—invest in quality and people.