A senior developer recently announced on LinkedIn that he was considering leaving software development because AI had made his 22 years of experience irrelevant. He was not alone. I have seen the same complaints repeatedly: AI is “taking the art out of software development.” Developers are “losing a feel for the code.” Others say, “I just don’t feel like I’m doing what I was hired to do.”
I have 25 years in this profession, and I have reached exactly the opposite conclusion. AI has made my experience more valuable than it has ever been because I can apply what I know across more work, more developers, and more simultaneous decisions.
If AI makes decades of experience worthless, I have to question what kind of experience those decades produced.
For some, apparently, the art of software development lived in the keyboard. AI is definitely bad news for anyone whose value came from typing syntax faster than the person beside them. It is excellent news for people whose experience taught them how to identify the right problem, design a maintainable solution, recognize risk, guide other developers, and tell when technically correct code is still the wrong answer.
The Business Commissioned a Solution
When developers complain that AI is removing the art from software development, they often confuse the medium with the work. We were never paid for lines of code. Nobody ever received a bonus for producing the most artisanal for loop. I’ve never heard someone review a pull request and comment on the way it was typed. We are paid to create functioning solutions to business problems. Artistry may live in brushstrokes. It does not live in keystrokes.
Architecture matters because it affects whether the solution can perform, change, and survive contact with reality. Clean code matters because someone has to understand and maintain it later. Tests matter because the business needs to know that the software still works when changes are made. Those are properties and practices that lead to a successful solution. Their value comes from what they enable.
The business did not commission your elegant architecture. It commissioned a functioning product.
At a financial services SaaS provider, a senior architect was tasked with creating a proof of concept application for a customer-facing dashboard. Two months later, he delivered a beautifully engineered application that did almost nothing and was virtually impossible to bring to production. Ultimately, the team rewrote the entire thing and simplified it dramatically in the process.
Being a work product does not make the work less creative. Leonardo da Vinci painted The Last Supper under commission from Ludovico Sforza. Pope Julius II entrusted Michelangelo with the ceiling of the Sistine Chapel. Both works began with a patron, requirements, and an intended outcome. Even the Mona Lisa may have begun as a commissioned work. The artistry is evident in how each artist solved the problem.
Software works the same way. The business provides an objective, a set of constraints, and a reason for the work to exist. Our craft appears in how well we understand the problem and how effectively we turn those requirements into a useful, durable product. Clients appreciate the artistry when the site delivers a beautiful user experience, the system scales to ten times its original needs, or the software withstands the latest cyberattack.
AI changes the tools available in the process of development. It does not eliminate the need for judgment.
The Work Keeps Moving Up the Stack
I made part of this case in Software Development Has Always Been Moving in One Direction. Software development has spent decades moving developers farther from raw mechanics and closer to business intent. Machine code gave way to assembly. Assembly gave way to compiled languages. Frameworks replaced large amounts of repeated infrastructure. ORMs abstracted routine data access. Cloud platforms turned physical provisioning into configuration. Each transition allowed developers to direct more capability with less mechanical effort.
Each transition also produced people who argued that the new abstraction weakened the profession. Apparently, real programmers should remain close enough to the metal to burn themselves. Linus Torvalds recently mocked this attitude by proposing a new rule: “don’t use compilers for any of your kernel submissions.” His point was deliberately absurd. Understanding the work and taking responsibility for the result matter. The tool used to produce it is not a reliable measure of skill.
You do not need to personally author every implementation detail. You remain responsible for understanding the system well enough to evaluate its behavior, risks, and fitness for purpose.
The Three Cs of the Code-pocalypse
If compilers did not destroy programming, Claude, Codex, and Copilot probably will not finish the job.
AI is another move up the abstraction ladder. It lets a developer spend less time manually producing implementation and more time defining intent, establishing boundaries, reviewing results, and correcting direction. The valuable work remains. The allocation of time changes.
In 2006, at a woodworking tool manufacturer, I was developing a full e-commerce platform. I spent the better part of six months designing and coding the database that would underpin that system. Today, with the AI models I have available to me, I’m sure I could deliver the same database foundation in a week and change. The data model would still require thought and planning. Writing all that SQL would consume far less time.
Michelangelo spent roughly three years carving David. The artistry was in the form he envisioned and the decisions he made while revealing it. His skill controlled the chisel. The labor was every strike of the mallet required to make the idea manifest.
Software works the same way. The art is in understanding the problem, shaping the solution, and making good decisions while building it. Technical skill turns that idea into a functioning system. Keystrokes are the mallet strikes.
The art was always in the idea. AI automates more of the mallet strikes. The developer remains responsible for the form.
Value and Satisfaction Are Different Questions
Cody Williamson identifies a complaint I take more seriously. In Satisfaction is Futile, he writes that “being in the weeds was where the fun stuff was.” He misses the intimacy of knowing a system deeply, owning work end to end, and polishing it through implementation. That loss is real. I feel it at times, too, although I am more removed from direct implementation since transitioning into management.
AI can make a senior developer more valuable while making the daily work less satisfying. Those are different questions. Moving up the abstraction ladder gives the developer more reach, but it can also remove the immersion that made software development enjoyable.
If you loved the work because it kept you deep in the technical details and problem-solving, directing agents can feel like losing the part of the profession that mattered most to you. That is dissatisfaction, not irrelevance.
The response should be deliberate. You can choose which work to delegate and reserve hands-on implementation for problems where it maintains skill or provides satisfaction. Good judgment means deciding, case by case, when delegation creates leverage and when direct implementation creates value.
Experience Is the Multiplier
AI can generate code for someone with six months of experience and someone with twenty-five years of experience. That does not make their results equivalent.
The experienced developer has seen migrations stall halfway through. They have watched a reasonable shortcut become permanent architecture. They have learned that a database query can be functionally correct and still bring production to its knees. They know where security problems hide, which abstractions tend to leak, when a requirement is underspecified, and when a clean-looking implementation has misunderstood the business.
AI supplies implementation capacity. Experience determines where that capacity goes.
That distinction has become obvious in my own work. I can ask an agent to implement a workflow and receive a competent answer. I can also recognize that the workflow itself is wrong, redesign it, and cut its processing time in half. The agent had enough technical capability to build the first design. My experience supplied the orientation required to build the right one.
The business does not need my keystrokes. It needs my judgment about architecture, risk, performance, maintainability, and what should be built. AI allows me to apply that judgment across far more work.
At this point, I contribute surprisingly few keystrokes myself. For the last few months, I have used Wispr Flow to dictate my instructions to agents at least half the time. The keyboard is no longer the center of my work in either the literal or figurative sense. I have reached a point where my intent can move almost directly into the tool performing the implementation. Much of the mechanical work has disappeared from my side of the process. Clear communication and planning have become the essential skills. The art remains the same.
More Than One Keyboard
One reason I moved into management was leverage. As an individual contributor, my knowledge could shape the work coming from one keyboard. As a manager, I could develop people, establish standards, and apply what I knew across an entire team.
AI extends that leverage again.
I regularly run two to four agents. My developers commonly run two and are ramping up to three apiece. Across seven developers, that creates 14 to 21 simultaneous agent workstreams. Add mine, and the system can support 16 to 25 active implementation workstreams, all following the same playbook.
That playbook turns raw capacity into useful leverage. The agents receive our coding standards, architectural guidance, workflow instructions, code maps, story definitions, and definitions of done. Each artifact captures lessons from my experience and gives every workstream the same architectural expectations, quality bar, and definition of success. Humans still review the pull requests, QA validates the completed work, and final acceptance remains human-gated. The result is more implementation capacity operating inside one coherent system.
That system also changes how experience can move through a team. I can hire a developer who has less experience than I do, give that developer access to the same standards and tools, and use my judgment to shape the system in which they work. The developer still has to think, learn, review, and take responsibility. They simply begin with more leverage than I had at the same point in my career.
The economics can become dramatic. Imagine seven developers earning $100,000 each. That is $700,000 in salary. If those developers, supported by agents and a strong engineering operating model, can sustain work that once required something closer to twenty conventional development seats, the comparable salary capacity approaches $2 million.
No agent is equivalent to one human developer, and I do not expect every team to achieve the same result. The operating model is real. The salary comparison is illustrative.
The implementation cost has fallen. The value of knowing what deserves implementation has not.
What Decades Should Produce
Twenty-five years in software should give you more than familiarity with old syntax and a collection of keyboard shortcuts. It should produce judgment.
You should know how to break down an ambiguous problem, distinguish a requirement from a proposed solution, recognize familiar failure patterns, and understand which tradeoffs the business is actually making. You should know how to teach, review, prioritize, and say no. You should know when the team is polishing the wrong thing.
Those abilities become more valuable when implementation gets cheaper because cheap implementation creates more opportunities to build the wrong thing quickly. Senior developers who learned only to quickly produce code or implement algorithms may reasonably feel threatened by a machine that produces code quickly and knows every algorithm. Senior developers who learned to create systems, develop people, evaluate tradeoffs, and deliver outcomes have just been given an extraordinary force multiplier.
Refusing leverage does not make you a craftsman. It makes you slower. I am directing the work that made my experience valuable through a larger workshop, with enough hands to extend the reach of the judgment I spent decades accumulating.
You can mourn the loss of the keyboard as the center of the profession. I would rather see what becomes possible when my experience is no longer gated behind a single keyboard.
Receipts
- The historical direction: Software Development Has Always Been Moving in One Direction traces the movement from lower-level mechanics toward abstraction, intent, architecture, and orchestration.
- Measured team results: This Is What Agentic Efficiency Looks Like documents the cost, throughput, review process, and escaped-defect measurements behind my current operating model.
- Satisfaction and technical immersion: In Satisfaction is Futile, Cody Williamson describes the loss of ownership, deep system familiarity, and enjoyment he has experienced as agents move him away from implementation details.
- Torvalds on tool choice: In an October 2026 Linux kernel mailing-list response, Linus Torvalds used a deliberately absurd compiler ban to challenge the idea that competence can be inferred from whether a contributor used AI.
- Leonardo’s commission: The official Museo del Cenacolo Vinciano history says Ludovico Sforza commissioned Leonardo to paint The Last Supper.
- Michelangelo’s commission: The Vatican Museums records that in 1508 Pope Julius II entrusted Michelangelo with the Sistine Chapel ceiling.
- Michelangelo’s David: The Galleria dell’Accademia records that Michelangelo received the commission in August 1501 and that the statue was unveiled in September 1504.
- The Mona Lisa commission: The Louvre says the portrait may have been commissioned by Francesco del Giocondo, Lisa Gherardini’s husband.