Why the Age of AI Makes Human Capability More Valuable Than Ever
People often ask whether AI has changed the way I think about software engineering. It has. Just not in the way I expected.
When large language models first appeared, I assumed I would spend the next few years learning an entirely new way of building software. I expected many of the principles I’ve taught for the past thirty years to become less relevant. If AI could generate code, perhaps the practices that helped us write code would fade into the background.
Instead, the opposite happened.
The more I collaborate with AI, the more convinced I become that nothing has changed about what makes great software engineers great.
Everything has changed about how we practice it.
The biggest surprise isn’t that AI can generate code. We all know that by now. The real surprise is that AI has reinforced almost everything I’ve believed about software development throughout my career.
The faster code becomes to produce, the more valuable fast feedback becomes. The more software AI can generate, the more important automated tests become. The easier it is to create complexity, the more valuable simplicity becomes. The cheaper code becomes, the more expensive poor decisions become.
For years our industry focused on increasing the speed at which we could produce software. Better languages. Better frameworks. Better IDEs. Better libraries. Every advance made writing software faster. AI continues that trend, but it also changes something fundamental.
The bottleneck has moved.
Writing code is no longer the hardest part. Understanding the problem is.
Making good design decisions is. Verifying behavior is. Helping a team develop a shared understanding is. Exercising judgment is.
That’s why I don’t believe AI is replacing software engineering. I think it’s exposing the parts of software engineering that mattered all along.
For decades I’ve taught Extreme Programming, Test-Driven Development, refactoring, and design patterns. Sometimes people ask whether these practices still matter in the age of AI.
I think they’re asking the wrong question. XP wasn’t designed to help us type code faster. It was designed to help us learn faster.
Think about what XP actually optimizes. Small batches. Fast feedback. Continuous integration. Pair programming. Collective ownership. Refactoring. Automated tests.
Every one of those practices shortens the learning cycle. Every one reduces the cost of discovering we’re wrong. Every one helps us adapt before mistakes become expensive.
That’s exactly what AI needs. When AI can generate ten different implementations in a minute, the limiting factor is no longer generation. It’s learning.
Which implementation is simplest? Which is easiest to change? Which assumptions are hidden? Which one actually solves the right problem?
Those aren’t questions AI answers for us. Those are questions AI invites us to ask more often. Perhaps that’s why I’ve stopped thinking about AI as a coding tool. I increasingly think of it as a thinking partner. Not because it thinks like we do. But because it constantly reflects the quality of our own thinking.
One of the biggest lessons AI has taught me is that it acts like a mirror.
If I’m vague, the results are vague. If I skip important assumptions, AI happily builds on those assumptions. If I rush, it rushes. If I fail to verify, it confidently produces answers that sound plausible but may not be correct.
The quality of the collaboration depends far less on the intelligence of the model than on the clarity of the human.
That realization changed something important for me. The conversation isn’t really about prompting. People often ask me how to write better prompts. Prompting matters. But prompting isn’t the capability. It’s the visible expression of deeper capabilities.
Seeing the system before trying to solve it. Asking better questions.
Recognizing patterns. Testing assumptions. Reflecting on what we’ve learned. Those capabilities improve every prompt we’ll ever write because they improve the thinking behind the prompt.
The same thing happened while I was building Prompt Studio, a project that’s helping me explore AI-assisted workflows. Originally I thought I was designing software. Instead, I found myself designing collaboration.
One of our recent experiments involved automating part of my video editing workflow. My first instinct was to automate the editing itself. That turned out to be the wrong problem.
Before we could automate anything, we had to understand the workflow. We needed a shared vocabulary. We needed a domain model. We needed to separate human decisions from AI reasoning, repetitive scripts, and editing tools. Only after we understood the work could we begin automating it.
That lesson extends far beyond video editing. Before we automate a process, we need to understand it. Before we optimize a workflow, we need to model it. Before we ask AI to generate solutions, we need to become clear about the problem.
Automation without understanding simply scales confusion. The same principle applies to organizations. Many leaders hope AI will improve productivity. Sometimes it does.
But I’ve noticed something else. AI doesn’t fix unclear requirements. It exposes them. It doesn’t eliminate inconsistent standards. It amplifies them. It doesn’t solve communication problems. It makes them impossible to ignore.
In many ways, AI is revealing the quality of our systems just as clearly as it reveals the quality of our individual thinking. That’s one reason I’m becoming less interested in productivity and more interested in capability.
Productivity helps us finish today’s work more quickly. Capability changes the kind of work we’re able to do tomorrow. Capability compounds. It changes how we observe. How we think. How we collaborate. How we design. How we learn.
Those capabilities transfer from one programming language to another. From one technology stack to another. From one AI model to the next.
Technology will continue to evolve. Today’s breakthrough models will eventually be replaced. Frameworks will change. Languages will change. Tools will change.
The engineers who thrive won’t necessarily be the ones with the newest tools. They’ll be the ones who continually develop their ability to learn, reason, communicate, simplify, and exercise judgment.
The more I work with AI, the less I believe this transformation is primarily about artificial intelligence. I think it’s about human capability. That’s the conversation I want to have over the next few years. Not because technology isn’t changing.
It clearly is.
But because the qualities that make us effective engineers—and effective collaborators—have never mattered more. AI hasn’t made those qualities obsolete. It has made them visible.
And perhaps that’s its greatest gift.
