Not so long ago, if you could write clean, working code, you had real leverage. It didn’t matter if you were building a website, a mobile app, or an internal business tool, knowing how to code well was a scarce skill and it paid off. That is changing fast, and I don’t think it’s controversial to say it out loud anymore: code is turning into a commodity.
Table Of Content
I want to be precise about what that claim means, because it gets misread a lot. It doesn’t mean knowing how to code stopped mattering, and it doesn’t mean engineers are becoming irrelevant. It means the raw act of producing working code, the syntax, the boilerplate, the glue between libraries, has stopped being the scarce part of the job. A coding agent like Codex or Claude Code can generate more working code per minute than any human ever existed. Easier to produce, though, is not the same thing as easier to trust.
This isn’t just a feeling from staring at my own terminal too long. JetBrains’ 2025 State of the Developer Ecosystem survey found that 85% of developers now regularly use AI tools for coding, and 62% rely on at least one AI coding assistant, agent, or AI powered code editor (source). Stack Overflow’s 2025 developer survey lands in a similar range, with 84% of developers using or planning to use AI tools in their process, and 51% of professional developers already reaching for one daily (source). Whatever you make of where this ends up, the adoption curve itself isn’t really up for debate anymore.
What Actually Makes Something a Commodity
In economics, a commodity is a good or service that becomes interchangeable across suppliers. Nobody cares who produced it, only that it clears a baseline of quality and shows up at the right price. Electricity is the textbook case. You don’t ask which power plant generated the electrons coming out of your wall socket, you just want the lights on and the bill reasonable. Once something reaches that state, competition stops being about differentiation and becomes almost entirely about price, availability, and reliability.
Programming has been through something similar before, just from a different angle: not suppliers becoming interchangeable, but the skill of producing software moving up a level of abstraction, and getting cheaper and more accessible each time it did. Assembly gave way to high level languages like Java or Python, trading raw control over the machine for speed of development, and suddenly a lot more people could build software than before. There’s arguably one more rung above that now, plain language prompts to an LLM sitting a level above even high level code, and it’s this latest step that makes it possible to generate code instead of writing it by hand, line by line.
Once code can be generated with enough quality and correctness, everything downstream starts to behave like commoditization: it matters less and less who or how a piece of code actually got produced, only whether it works, ships fast, and costs little to get. The old pattern of being almost emotionally attached to your own code, proud of a clever solution, precious about your own style, is fading fast too, and that quiet shift is part of what commoditization actually feels like from the inside.
Whenever this kind of change happens, the old skill rarely disappears completely, it just stops being what sets people apart. The real question is where that value ends up instead.
Where the Value Actually Went
Here’s what I find genuinely interesting about commoditization: somebody still gets paid well for it, just not for the same part of the job anymore. With code, that shift has moved toward things that are much harder to automate than writing the code itself, like knowing what should get built in the first place, choosing an architecture that ages well under real load, and reviewing output closely enough to actually trust it.
Since a model can produce far more code than a person ever could, the bottleneck isn’t production anymore, it’s judgment, and curation has quietly become a core skill rather than a lesser one.
Orchestration Over Typing
There’s also a shift in how people approach the problem itself. A lot of energy right now goes into writing the agentic skill or workflow that solves an entire class of problem, rather than solving one instance of it by hand, since building the skill once means the model applies it every time after. That turns orchestration, giving a model the right context and constraints, into its own competence, separate from writing code line by line. And the tool itself is about to stop being any kind of moat at all.
Local models are likely to push this even further. In the near future, models good enough for real coding work will run on everyday hardware, so cloud based services won’t be the only option anymore. Once that happens, generation gets close to free, since running a model on your own machine carries none of the per token costs a cloud hosted model bills you today, and differentiation can’t come from access to the tool anymore, because everyone will have it.
More Code, Not Less Work
There’s a matching effect on volume worth mentioning. Cheaper production doesn’t mean the same output for less money, it means a lot more output, which is basically the Jevons paradox applied to software: more services, more internal tools, more integrations built in an afternoon because it suddenly felt easy enough to justify.
All of that still has to run, get secured, and get maintained by somebody, and there aren’t more humans available for that job than there were last year. GitHub’s own numbers tell the same story: repositories, commits, and pull requests have all been climbing year over year, and the growth curve tracks closely with when coding assistants went mainstream.
Code Is Turning Into a Black Box
This is the part of the shift that matters most. As more code gets generated rather than written, fewer people on a team can honestly say they understand the whole system. Large chunks of it were produced by a model, accepted because the tests passed, and never actually read line by line with intent. That’s a very different situation from a codebase where every file has an author who could explain, from memory, why a particular decision was made. The extreme version of this has a name, vibe coding, a term Andrej Karpathy popularized in early 2025: you describe what you want in plain language, let the model write it, and accept the result without really reading it.
The practical risk is auditability. You run git blame on a file and find out it was authored in a single commit, and the person who committed it doesn’t fully remember the reasoning either, because there wasn’t much reasoning on their end to begin with, just an accepted suggestion. A codebase nobody reads closely is a codebase where nobody notices when something is quietly wrong until it breaks in production.
Why You Still Need to Know How to Code
And this is exactly why you still need to actually know how to code, not as a sentimental argument but as a security one. If you can’t read what the model handed you, you can’t catch the string that got concatenated into a query instead of parameterized, the auth check that only covers the happy path, or a dependency pulled in without anyone confirming what it does.
If you can’t read code, secure code and code that merely runs look exactly the same to you.
This is also why testing and a well defined process matter more than ever, not less. When you can’t assume a human read every line with intent, the safety net has to be structural: real test coverage, clear review standards, and a pipeline that actually blocks something from shipping when it fails those checks. Real change in how teams work is slow, and it shows up in boring places like review policy and security sign off, not in a keynote demo.
Two Layers of Competence
I think this is where two layers of competence stop being the same thing. Knowing how to code is still the base layer, and it still matters, because it gives you the vocabulary to question what a model hands you, to notice when something is subtly wrong, inefficient, or about to fail under load. But the real differentiator now sits one level above that: understanding what’s actually happening underneath, the architecture, the trade offs, where the failure modes are hiding. It’s not that complex code somehow resists commoditization. It’s that only someone who understands the fundamentals can tell when the generated code is too shallow to hold up the problem it’s supposed to solve.
What Is Left
Put together, the pattern is clear enough. Writing code is becoming cheap and widely available, and that trend isn’t reversing. What stays scarce is context: understanding the actual business problem, having enough taste to know which solution will still make sense a year from now, knowing which question is even worth asking before you start generating anything. As code generation keeps getting cheaper for everyone, that’s exactly where the differentiation has to live. Not in who can type the syntax the fastest, but in who knows what to build, why, and what happens after it ships.
None of this depends on the AI market staying hot, though. The broader AI industry might well be a bubble in the financial sense, valuations and funding running well ahead of actual revenue is a fair concern, but the specific gains in coding assistance look like a separate question, and those seem here to stay regardless of how the funding story eventually plays out.
There’s a personal adjustment buried in all of this too, and I don’t think pretending otherwise helps anyone. Coders who don’t adapt are going to end up slower and less effective than the ones who do, whether we like how it happened or not. The reward of writing code by hand looks different than it used to, and I won’t pretend that shift doesn’t sting a little. But the parts of this work that actually mattered, the judgment, the curiosity, the taste for a good solution, are still entirely ours. That’s worth holding onto.
No Comment! Be the first one.