Over the last couple of years, AI coding assistants have gone from novelty to daily workflow. Tools like GitHub Copilot, ChatGPT, Claude, Cursor, and others have fundamentally changed how many developers write software. Code that once took an hour can now be generated in minutes. Boilerplate can be produced almost instantly. Documentation, tests, and even infrastructure-as-code can often be created with a few prompts.
As impressive as these capabilities are, I’ve noticed something interesting while using these tools myself and observing how other developers use them.
The developers who were highly effective before AI tend to become even more effective with AI.
The developers who struggled before using AI often produce more code, but not necessarily better software.
This observation reinforces something I’ve believed for a long time: tools don’t make you great.
More than a decade ago, I wrote about this idea in Tools Don’t Make You Great. While the tools have changed dramatically since then, the principle remains surprisingly relevant today.
AI is one of the most powerful tools our industry has ever seen. But it is still a tool.
Tools amplify existing capability more than they create it.
The Difference Between Productivity and Capability
One of the biggest misconceptions in today’s AI discussions is the tendency to confuse productivity with expertise.
These are not the same thing.
AI can dramatically improve productivity. It can help you write code faster, generate tests more quickly, produce documentation in seconds, and automate repetitive tasks that previously consumed hours of your day.
What AI cannot do is instantly provide years of experience.
It cannot give you the lessons learned from production outages. It cannot give you intuition developed through maintaining systems over multiple years. It cannot give you the architectural judgment that comes from seeing both successful and failed software designs.
The result is that AI often acts as a force multiplier.
A developer who understands architecture, software design, testing strategies, maintainability, security, and operational concerns can leverage AI to accomplish significantly more work in less time.
A developer who lacks those skills can also generate more code—but generating more code is not the same thing as creating better software.
The distinction matters.
The 10x Developer Doesn’t Disappear
For years, the software industry has debated the idea of the “10x developer.” Whether you believe the number is accurate or not, most teams have experienced some variation of the concept.
Some developers consistently produce exceptional outcomes. They solve complex problems efficiently. They create maintainable architectures. They reduce technical debt instead of increasing it. They elevate the teams around them.
AI doesn’t eliminate that difference.
If anything, it may increase it.
Imagine two developers using the exact same AI coding assistant.
One developer understands system design, architecture patterns, scalability concerns, security implications, and long-term maintainability. The other developer has less experience and relies heavily on generated code without fully understanding the tradeoffs.
Both developers can generate code quickly.
However, the experienced developer can evaluate AI suggestions, identify flaws, refine requirements, guide the solution, and integrate the generated code into a coherent architecture.
The less experienced developer may generate the same volume of code, but the resulting system may accumulate complexity, duplication, and technical debt.
The productivity increase exists for both developers.
The quality increase is not necessarily equal.
AI Writes Code. Developers Design Systems
One of the most important distinctions in modern software engineering is understanding that writing code is only one part of the job.
The difficult part is often deciding what code should exist in the first place.
When designing software systems, we constantly make decisions about:
- System boundaries
- Service responsibilities
- Data ownership
- API design
- Security models
- Scalability requirements
- Operational complexity
- Long-term maintainability
These decisions rarely have a single correct answer.
They involve tradeoffs.
A large language model can generate multiple architectural options. It can explain patterns and identify common approaches. It can even produce surprisingly sophisticated designs.
But determining which design is appropriate for your organization requires context and judgment.
That’s where experience matters.
I’ve seen AI generate perfectly functional solutions that were completely wrong for the long-term needs of a project.
Not because the AI failed.
Because the requirements, constraints, and architectural goals weren’t sufficiently understood or communicated.
The quality of the outcome was directly tied to the quality of the guidance provided by the developer.
AI is only as good as the context and direction provided by the developer using it.
Elegant Software Requires Human Judgment
One area where this becomes particularly visible is software elegance.
Most developers have encountered systems that technically work but feel unnecessarily complicated. The code may compile. The tests may pass. The deployment may succeed.
Yet the design feels awkward.
Responsibilities are scattered. Abstractions are unclear. Complexity leaks across boundaries. Every new feature requires touching multiple unrelated components.
AI can generate those systems remarkably quickly.
Creating elegant software is different.
Elegant software emerges from understanding where complexity belongs and where it doesn’t. It comes from recognizing patterns, simplifying abstractions, and making deliberate tradeoffs.
An AI assistant can help implement elegance.
It generally cannot define elegance on its own.
If you don’t recognize a poor abstraction, you won’t know to ask the AI for a better one.
If you don’t understand why a service boundary is problematic, you won’t know to challenge the generated architecture.
If you don’t recognize technical debt as it’s being introduced, you’ll likely accept it.
In many cases, AI amplifies architectural judgment more than coding ability.
AI Is the Ultimate “Work Smart” Tool
Back in 2013, I wrote an article called Work Smart, Not Hard.
The central idea was simple: productivity isn’t about working more hours. It’s about finding better ways to accomplish meaningful work.
AI is perhaps the most powerful example of that principle we’ve seen in software development.
Used effectively, AI allows developers to eliminate repetitive tasks, automate routine work, explore ideas faster, and spend more time focused on solving valuable problems.
That’s working smarter.
However, working smarter has never meant eliminating the need for expertise.
A power tool can help a skilled carpenter build faster.
It doesn’t automatically make someone a master craftsman.
The same principle applies to software engineering.
AI allows us to accomplish more within the same amount of time.
It does not eliminate the need to develop skills.
The Mistake Teams Should Avoid
Perhaps the biggest mistake organizations can make is measuring AI success purely by output volume.
More pull requests.
More lines of code.
More generated tests.
More completed tickets.
These metrics may improve dramatically while software quality declines.
A better question is whether AI is helping teams produce better outcomes.
Are systems becoming easier to maintain?
Are architectural decisions improving?
Are developers spending more time solving business problems and less time writing repetitive code?
Are teams learning faster?
The goal should not be maximizing code generation.
The goal should be maximizing value creation.
Sometimes those are the same thing.
Often they are not.
Practical Guidance for Developers Using AI
As AI becomes a permanent part of software development workflows, I believe the most effective developers will focus on strengthening the skills AI cannot easily replace.
That includes:
| Focus Area | Why It Matters |
|---|---|
| Software Architecture | AI can generate implementations, but architecture requires judgment. |
| System Design | Understanding tradeoffs remains a human responsibility. |
| Domain Knowledge | Context often determines the correct solution. |
| Communication | Clear requirements produce better AI-assisted outcomes. |
| Debugging | Someone still needs to understand why systems fail. |
| Technical Leadership | Teams need guidance, not just code generation. |
The developers who thrive in the AI era will likely be those who become better problem solvers, better architects, and better communicators.
Not just faster typists.
Final Thoughts
AI is transforming software development. There is no question about that.
It is helping developers move faster, experiment more freely, automate tedious work, and increase productivity in ways that would have seemed impossible just a few years ago.
But we should be careful not to mistake acceleration for expertise.
AI does not magically create great developers.
It amplifies the capabilities developers already possess.
A skilled engineer can use AI to create more value. A thoughtful architect can explore more solutions. A strong technical leader can help teams move faster with greater confidence.
The fundamentals still matter.
Experience still matters.
Judgment still matters.
And perhaps most importantly, time still matters.
AI can help you write code faster.
It cannot compress years of learning into an afternoon.
