Today, programming — the act of instructing a computer to correctly perform a desired procedure — has been accelerated to the point where writing code is no longer the scarce resource it once was. Increasingly, code generation is becoming a commodity. The interesting question isn't what's been lost, but what remains valuable.
The Commodity and What Remains
The enduring value of programming has never been mastery of a particular language, framework, or technology stack. It lies in understanding the abstractions that generations of engineers have built in the form of domain-specific languages, libraries, frameworks, and architectural patterns. These aren't merely tools for producing software. They're attempts to reconcile some portion of the real world with the computational model of a machine.
Every abstraction encodes experience. It captures lessons learned, trade-offs discovered, and assumptions about how people interact with systems. The more deeply we understand these abstractions, the more capable we become of reasoning about complex systems, recognizing recurring structures across domains, and designing software that fits naturally within the problems it seeks to solve.
Programming as Martial Form
In that sense, programming isn't so different from the practice of martial arts. Modern warfare has rendered martial arts largely obsolete as methods of combat. Yet their practitioners rarely study them for fighting alone. The value lies in cultivating discipline, awareness, precision, and clarity of thought. The forms, drills, and katas are exercises in developing judgment through repetition — not because the movements are useful in every circumstance, but because they shape the practitioner.
Programming has always offered the same opportunity.
Writing software is only the visible artifact of a much deeper practice: learning how to decompose problems, construct abstractions, recognize patterns, and reason precisely. This dimension has always existed, but AI-assisted development has made it impossible to ignore. When code itself becomes cheap to produce, the value shifts toward the quality of thinking that guides its production.
What Katas Actually Are
This is also why I think we've misunderstood what effective practice even is.
Algorithmic interview problems and LeetCode-style exercises are often treated as the programming equivalent of martial arts katas. While they undoubtedly build certain technical muscles, they are narrow approximations of the craft. Real programming practice is less about repeatedly solving isolated puzzles and more about approaching familiar problems through unfamiliar frameworks.
Consider something as commonplace as building a web API. There are dozens of mature frameworks capable of accomplishing the task, each expressing a different philosophy of how software should be organized. As you work with them, patterns begin to emerge. Some are explicit conventions enforced by the framework itself; others are implicit, living only in the culture of the communities that built them.
These patterns are rarely about technology alone. More often, they're accumulated solutions to human problems: reducing the cost of refactoring, making systems easier to understand, establishing clearer boundaries between components, allowing teams to collaborate without stepping on each other. They're responses to frustration as much as they're responses to computational complexity.
Good software architecture is often an expression of organizational wisdom disguised as code.
The Side Project Principle
This is why I've always told anyone asking how to become a better programmer the same thing: build side projects.
The value of a side project is almost never the code you produce. It's the opportunity to wrestle with a problem, compare your thinking against the perspectives of others, and gradually internalize why certain abstractions exist. Nearly every software problem is a variation of one that someone's already encountered. Growth comes from recognizing these recurring structures and learning how principles from one domain can be transferred into another.
That process develops something difficult to teach explicitly: intuition.
Experienced engineers aren't valuable because they've memorized APIs or language syntax. They're valuable because they've accumulated a library of mental models. They develop an instinct for which abstractions fit which problems, when conventions should be followed, and when they should be discarded. This tacit knowledge is the product of sustained exposure — to ideas, to failures, to repeated refinement.
AI Doesn't Replace the Craft
Interestingly, this doesn't disappear in the age of AI.
Used well, AI can dramatically accelerate the acquisition of knowledge. By questioning its outputs, challenging its assumptions, exploring alternative implementations, and treating it as a collaborator rather than an oracle, you can compress the feedback loop that once required years of experience. AI becomes another perspective — one that can expose unfamiliar patterns, explain abstractions, and suggest designs you might not have considered.
But there's an important distinction between acceleration and replacement.
If AI becomes a substitute for thinking rather than a catalyst for it, the process that develops intuition never occurs. You may produce working software, but you won't become a better engineer. The tacit knowledge that allows someone to evaluate trade-offs, recognize hidden assumptions, and design coherent systems can't be copied from generated code alone. Ultimately, that tacit knowledge is the real discipline of programming.
If programming is becoming commoditized, the discipline isn't disappearing. It's simply moving up a level of abstraction. The future belongs less to those who can produce syntax quickly and more to those who can cultivate sound judgment, understand the ideas embodied in the abstractions they inherit, and continually refine the mental models that allow them to build systems in harmony with the world they represent.