Should CEOs Fire Their Software Developers? | Spicer Matthews
A big part of my week is spent advising CEOs on software development. And lately, almost every one of them has been<br>AI-pilled. They've spun up Claude Code,<br>YOLO'd a few of their own features, watched it work, and arrived at a question that's getting harder for me to answer:
"Why am I paying software developers so much money when Claude can just do it? Why do I have to wait weeks for something AI did in minutes?"
Here's the uncomfortable part: I'm struggling to defend us.
The good software developers I know have effectively retired from writing code. We're all driving AI agents to produce our<br>software masterpieces now. So what actually makes me better than a CEO who's YOLO-ing it on a Friday afternoon? In certain<br>cases, honestly, it's tough to justify our existence.
But "in certain cases" is doing a lot of work in that sentence. After having this conversation dozens of times, I've landed on<br>a framework. It isn't "developers are obsolete" and it isn't "you'll always need us." It's it depends—and it depends on<br>one thing more than anything else.
The 70/20/10 Reality of AI Coding
Before we get to who should hire and who should fire, you have to be honest about how good AI actually is at building software<br>today. Here's the split I see when a non-technical person hands me a task and I run it through Claude Code:
70%
AI just nails it
I copy and paste the task in with little extra context, and the result is exactly what was needed. No developer required.
20%
It needs reshaping
I have to work through technical details—be specific about how to do something, or whether logic belongs on the<br>backend or the frontend. AI isn't always great at that call.
10%
It goes off the rails
AI genuinely messes things up. These are the moments where you need real technical expertise to drag it back on track.
If you're a CEO, that top number looks like a green light. Seventy percent of the time you don't need me at all. And you're<br>right—you don't.
The problem is the other 30%. Because of the non-deterministic nature of AI, you never know in advance which bucket<br>you're in. The same prompt that worked perfectly on Tuesday can quietly produce something subtly broken on Thursday.<br>You can't schedule the 10%. It just shows up.
What Great Developers Actually Do Now
Here's the shift that most CEOs miss. A good developer in 2026 may not be writing every line of code—but they're the one<br>watching AI's progress and stepping in at exactly the right moment. The job moved up a level.
The best developers I know have traded code writing for code review. They're constantly updating the<br>governance of the product—the CLAUDE.md files and conventions that keep AI doing things the way the business<br>actually needs them done. I wrote about how I run my own<br>AI-first development workflow<br>this way: the human leads the project with excellence; the AI does the typing.
So the real question isn't "can AI write the code?" It obviously can. The question is: in your business, does it matter<br>who's minding the 30%?
It All Comes Down to One Question: How Expensive Is a Bug?
This is the whole framework, and it's the first thing I ask any leader who's thinking about cutting their engineering spend:<br>how mission-critical is your software, and what does a single bug actually cost you?
Answer that honestly and the right move becomes obvious. Let me walk through the three companies I see most often.
Three Companies, Three Answers
1. The company where a bug is a catastrophe
I know a CEO who runs millions of dollars in ad spend across every channel you can name. If a bug slips into the funnel and<br>quietly drops conversion, the losses are enormous. In a business like that, avoiding a single mistake can pay a senior<br>developer's salary for an entire year.
My advice: keep your senior developers.
When the downside of a mistake is measured in real dollars per hour, higher-paid, slower, careful engineers managing the code<br>pay for themselves many times over. This isn't a cost center—it's insurance with a positive ROI.
2. The funded startup that needs speed and competence
Now picture a SaaS product doing hundreds of thousands of dollars in revenue. Bugs aren't the end of the world here—customers<br>never love them, but a bug here and there is survivable. Sometimes it even triggers a useful conversation with a customer. As<br>long as you don't break the product every day or lose customer data, you'll be fine.
This startup can't afford a team of highly paid engineers. It also can't afford to move slowly. In the AI era, that's no longer<br>a contradiction.
My advice: go hybrid.
Pair a skilled (often overseas) development team driving the prompts with non-technical teammates who can still contribute in<br>Claude Code. You slash the cost of developers, keep genuine technical competence in the loop for the 30%, and move fast. When<br>a blunder slips through, it's manageable.
3. The bootstrapped founder with little...