For a while it looked like software development was done for, at least according to Paul Ford. How could developers compete with tireless robots? But the industry is slowly realizing that making truly cutting-edge software still requires humans to think and work together, to maximize their skill sets and practice their crafts.

AI can write very good software, Ford argues. But it also makes it easy to do someone else’s job badly, which is part of why all those projects fail. Now that everyone can code, the hard part isn’t the syntax. It’s knowing what to build and how it should actually work.

The thing AI is actually good at

AI coding tools are legitimately impressive. ChatGPT can scaffold a React app. Copilot will autocomplete entire functions. Claude can refactor a module and write the tests. If you measure software by lines of code produced per hour, AI wins easily.

The problem is that lines of code produced per hour is a terrible metric. It always has been. We knew this in the ’90s when we stopped measuring developer productivity that way. But AI made it easy to forget.

What AI is good at is writing code that looks right. It understands patterns. It knows what a React component should look like, what a REST API handler needs to do, how to structure a database query. It can produce syntactically correct, idiomatically reasonable code faster than you can type.

What it can’t do is understand why you’re building the thing in the first place.

Doing someone else’s job badly

Ford’s line about “doing someone else’s job badly” cuts deep. AI makes it trivial for a backend developer to ship a frontend that technically works but feels wrong in a dozen subtle ways. Or for a product manager to generate an API that handles the happy path but falls apart under edge cases no one thought to specify.

The code runs. It might even pass tests if the tests were also AI-generated. But it’s not good software. It’s code that sort of does what you asked for, written by something that doesn’t understand the domain, the users, or the constraints that aren’t in the prompt.

This is why companies are running into trouble with AI-generated codebases. The first 80% happens fast. You get a working prototype in days instead of weeks. Then you hit the 80/20 wall, except it’s more like 80/60 because the code wasn’t designed by anyone who understood the problem.

Refactoring AI-generated code is harder than writing it correctly in the first place, because you’re debugging decisions that were never really made. You’re reverse-engineering intent that never existed. The AI didn’t choose that architecture because it had trade-offs in mind. It chose it because the pattern matched its training data.

What actually makes software good

Good software requires judgment. Not just technical judgment about which algorithm or data structure to use. Judgment about what problem you’re actually solving, what matters to users, what can break, what needs to scale, what’s going to change.

That’s the stuff you learn by shipping software, watching it fail, fixing it, and shipping again. AI tools trained on open source repos have seen a lot of code. But they haven’t shipped anything. They haven’t gotten paged at 3am because a edge case no one considered took down production. They haven’t sat in a user interview and realized the feature everyone spent two months building solves the wrong problem.

This is what Ford means by “humans to think and work together, to maximize their skill sets and practice their crafts.” Building good software is still a human activity. It requires understanding context that doesn’t fit in a prompt, making trade-offs between competing priorities, and collaborating with people who have different expertise.

AI can accelerate the mechanical parts of that process. But it can’t replace the thinking.

The new skill floor

The industry is sorting itself into two groups. There are people who use AI as a force multiplier, shipping better software faster because they know what to ask for and how to verify the output. And there are people who use AI as a shortcut, generating code they don’t fully understand for problems they haven’t fully scoped.

The second group is why projects keep failing. Not because the AI wrote bad code, but because the humans didn’t do the parts that AI can’t do. They didn’t think through the problem. They didn’t consider the edge cases. They didn’t design the system. They just prompted and shipped.

The skill floor for software development hasn’t gone down. If anything, it went up. You need all the same skills you needed before, plus the new skill of knowing when to trust AI output and when to ignore it. You need to be able to read generated code and spot the subtle bugs, the architectural problems, the places where it made assumptions that don’t match reality.

What this means for developers

If you’re worried about AI taking your job, Ford’s quote should be reassuring. Sort of. AI hasn’t killed software development. But it has changed what’s valuable.

Writing boilerplate code was never the valuable part. It was just the part we had to do because computers couldn’t. Now they can, so that skill matters less. What matters more is everything else: understanding requirements, designing systems, making trade-offs, debugging production issues, collaborating with non-technical stakeholders.

Those skills don’t disappear when everyone can generate code. They become more important, because they’re the difference between code that works and software that’s actually good.

The developers who treat AI as a tool that handles the mechanical parts while they focus on the hard problems are going to do fine. The ones who thought coding was just typing and now don’t understand why their AI-generated projects keep failing are going to have a rough time.

Ford’s right. Cutting-edge software still requires humans. But not just any humans. Humans who know what they’re doing, who understand the craft, who can tell the difference between code that looks right and software that actually works.

Now that everyone can code, that’s the skill that matters.