A few years ago, someone could understand a problem deeply and still be far from a solution. Between the idea and the system stood a barrier: someone had to translate that intent into a language a computer could execute.
That translation required time, specialized professionals and many intermediate steps.
Today, someone can describe what they need, receive a first version, test it, ask for changes and follow the system as it evolves through a conversation. Code appears in seconds.
The change looks technical, but its consequences are economic.
Code is becoming a commodity. Software is not.
What is becoming cheap is producing parts of the implementation. Value remains concentrated in understanding the problem, making good decisions, connecting systems, protecting data and making the solution work inside a real operation.
Vibe coding is the symptom
The term vibe coding gained attention in 2025 to describe a way of creating software in which a person guides artificial intelligence in natural language, runs the result and keeps adjusting it based on what they observe. The expression was popularized by Andrej Karpathy, who described a practice built around conversation, execution and feedback (AP News).
The expression matters because it shows a visible change: manual writing is no longer the only gateway to programming.
But the important phenomenon is not the name of the technique. It is the lower cost of turning intent into implementation.
For a long time, the question was: how can we make programmers write code faster? Now another question appears: what happens when millions of people who did not program can create software?
A logistics professional can describe a delivery flow. A finance professional can explain a reconciliation routine. A doctor can describe a clinic workflow. An engineer can explain the constraints of a maintenance operation.
Before, that knowledge had to pass through a development team to become a tool. With AI agents, part of that distance becomes smaller.
This does not remove engineering. It makes the difference between describing a need and building something reliable easier to see.
What does it mean to say code is becoming a commodity?
Commodity does not mean that all code has lost value. An activity begins to commoditize when supply becomes abundant, cost falls and execution alone differentiates providers less.
This is already happening in parts of development: forms, landing pages, CRUDs, conventional APIs, dashboards, scripts, interface components, basic tests, prototypes and common integrations.
These elements remain necessary. But when several competitors can produce them quickly, they stop being a competitive advantage by themselves.
The customer does not buy a screen because it was written manually. The customer buys a better way to work, sell, serve, control or decide.
Implementation becomes a cheaper stage inside a larger chain.
Code is not software
Producing code is only one part of producing useful software. A real system involves understanding the problem, defining business rules, modeling data, choosing an architecture, integrating services, protecting access, handling failure, shaping the user experience, deploying, observing, correcting, maintaining and evolving.
A demo can work in an afternoon. A system used by an organization must keep working when exceptions appear, priorities change, data is incomplete, permissions differ and new people join the process.
AI lowers the cost of generating code. It does not remove the cost of being wrong.
That cost appears in a rule applied in the wrong place, excessive permissions, exposed data, a fragile integration, a report that leads to a bad decision or an automation that accelerates the wrong process.
The cheaper code generation becomes, the more visible the bottlenecks around it become.
Value moves up a layer
The first consequence is that value tends to move toward layers that are harder to copy.
The question stops being only “who can build?” and becomes “who knows what should be built?” Then comes a third: who has the context, data, distribution and operating ability to make it produce results?
Scarcity may move toward domain knowledge, problem framing, proprietary data, architecture, integration, security, user experience, distribution, reputation, maintenance and governance.
A team can generate five versions of a system in a few days. It still has to decide which one represents the right process, which risks are acceptable, which rules cannot be violated and how to measure whether the operation improved.
Everyone can build. Few know what to maintain
The democratization of software creation is a major shift. For decades, knowing how to program meant having access to a rare capability: turning an idea into an executable system.
That capability is spreading. It can bring problems closer to solutions. It can also produce a large number of small, fragile and abandoned tools.
One department creates an internal app to solve an urgent need. Another builds its own automation. For a while, everything appears to work. Then simple questions arise: who maintains it? Where is the data? Who can access it? What happens when its creator leaves? Which system is the source of truth?
The entry barrier fell. Responsibility remains.
Niche software can grow
Many problems stay in spreadsheets not because spreadsheets are ideal, but because building a specific system never justified the investment.
When creation costs fall, that economic boundary changes. Custom applications start to make sense for inspections, equipment management, small logistics operations, internal approvals, contracts and administrative routines.
AI may enable an explosion of niche systems. Small companies can build tools that were once viable only for larger organizations. Domain experts can participate more directly in the build.
Quantity, however, is not quality. The risk is replacing software scarcity with an abundance of systems without ownership, standards or integration.
What happens to software houses?
Many software companies still price work around hours, professionals and project duration. That logic makes sense when implementation is the main cost.
If implementation productivity rises sharply, the model comes under pressure. A customer may ask: if something that took three weeks can now be done in three days, why am I paying for the same number of hours?
Value tends to move from the ability to write code to the ability to deliver an outcome. This increases the importance of clear projects, continuous evolution, domain knowledge and responsibility for the solution’s operation.
A software house may look less like a screen factory and more like an engineering company that enters the problem, understands the process, organizes decisions and builds what is needed.
The developer’s new role
If AI absorbs more implementation, human work can move toward architecture, validation, review, integration, security, modeling, observability, requirements, trade-offs, business understanding and agent supervision.
The developer is no longer only someone who writes instructions for computers. The developer designs systems that turn intent into reliable results.
DORA’s 2024 report found an association between AI use and perceived gains in developer productivity, flow and satisfaction, while also pointing to organizational trade-offs and the need for trust, stable priorities and user focus (DORA).
The tool improves the execution of people who know how to guide, review and measure. It does not replace judgment.
The new bottleneck is judgment
When execution becomes cheap, deciding correctly becomes more valuable.
It is relatively easy to generate five solutions. It remains difficult to choose which one should exist, understand the consequences, know which rules cannot be broken and distinguish a demo that works from a system that can operate for years inside an organization.
That judgment depends on context: how work happens, who makes decisions, where data is produced, which exceptions appear and which error can cause the most harm.
Arxon’s place
Arxon works in the space between intent and system.
We enter the operation to understand the work, recognize repetition and noise, find the point that limits the result, improve the flow and only then build the technology required.
The industry changes. The principle remains:
process first. Code second.
AI can make implementation faster. Arxon uses that speed to reach the right problem earlier, test hypotheses better and build systems that make sense beyond the screen.
When everyone can build, competitive advantage is no longer only knowing how to build. It is knowing what deserves to be built.
Comments
No comments yet. Start the conversation.