Open code becomes working material for agents

Why the economics of individuality are changing

For years, standard functions were affordable while every distinctive requirement brought design, development, integration and maintenance costs. Many merchants therefore chose the same building blocks despite needing more. Even a commercially useful idea could fall below the threshold that justified custom implementation.

My thesis is that agent-assisted development moves this boundary. When software can work with tools, data models and existing source code, the same team can investigate and implement more changes. Open source strengthens the effect: a team need not stop at describing what a closed system ought to do. It can inspect the relevant code, change it, test it and reuse the result. Together, these capabilities can make previously unaffordable differentiation commercially viable.

Agents make more ideas possible to build. Lifetime cost determines which of them a merchant should maintain.

The agent can read through to the cause

My expectation for an open core rests on a simple mechanism: a coding agent can read the entire pricing calculation, start the shop locally and try its change along the actual ordering path. It does not have to infer the relationship between a field, a discount rule and an order from a short API description. People can follow the same path.

That helps with a particular kind of work. A merchant describes an industry rule, the agent finds the relevant code and builds an extension. The agency can see early where the proposal affects existing logic. My thesis is that this access increases the range of adaptations a business can afford. The more a task depends on the system’s internals, the more useful that access becomes.

In “When Code Writes Code” in 2025, I described my work shifting from writing towards design and review. Requirements, architecture and acceptance matter more when the first draft arrives sooner. [S77, S78]

Three kinds of openness

Openness helps at different points, with an open protocol providing shared rules for exchange. Open-source software can be read, used, modified and redistributed under its licence. Open model weights make trained parameters accessible, creating additional options for operation and adaptation.

For AI, the Open Source Initiative’s Definition 1.0 describes the relevant freedoms and information. Alongside parameters, it includes code and the necessary information about training data. Businesses gain a reference for assessing releases and their usage rights. [S86]

A merchant can combine these options to suit its needs: an open commerce core, its own agent environment and a commercial model service. Another team may run open weights on its own hardware. The choice depends on the task, data protection needs, available expertise and total cost.

Self-hosting includes hardware, energy, utilization and support. A model service brings questions of price, data handling and switching. A deliberate combination gives the company freedom where its business needs it.

Open commerce already has a foundation

Open source is already infrastructure in commerce. Shopware’s public repository provides its commerce core under the MIT licence and refers to more than 3,100 extensions in the ecosystem. The Shopware CLI provides tools for local development environments and extension validation. Merchants, agencies and their coding agents therefore have substantial material to work with. [S150, S151]

The new momentum comes from combining it with coding agents. My 2026 articles examine open models on commerce tasks and in local development environments. The two merchant cases in the next chapter show the commercial motivation: replacing an old ERP and finding a way to carry out a system migration previously considered too expensive. [S76, S91]

The range of tools is also expanding. Mozilla’s September 2026 report describes open models with different strengths. GitHub’s Octoverse 2025 counts more than 4.3 million AI-related repositories. Merchants gain a wider choice of models and development tools. Which one speeds up an extension depends on their own code and task. [S92, S93]

Architecture in an experiment: VEYNDO

VEYNDO is a self-hostable project with source-available code. It lets me explore adaptable commerce without existing extensions limiting the design. In App Studio, people and coding agents work on an executable manifest. Saving, private preview and immutable releases are separate steps. That makes changes reviewable before they take public effect. [S112]

Nyx connects local models with project knowledge and reviewable changes. Both projects create a workspace in which an agent can read sources, prepare proposals and show people the effect of a change. [S111, S124, S125]

Where the bottleneck moves

The first design for a new spare-parts search may arrive quickly. Product advisers then assess the machine-revision matches, the agency checks the connection to customer pricing, and shop operations deal with later updates. That work determines the value of the faster draft in daily use.

Research shows the importance of context. METR’s study of 16 experienced open-source developers and 246 tasks found that early-2025 tools increased completion time by 19 percent. Selection bias prevented its 2026 follow-up from establishing a dependable current speedup. Teams therefore benefit from measuring their own familiar tasks. [S87, S88]

In an NBER working paper revised in September 2026, Demirer, Musolff and Yang examine data from more than 500,000 GitHub developers. Their observational event study estimates cumulative effects of up to 240 percent more commits, 80 percent more projects and 30 percent more releases. Substantial work still separates more code from more shipped software. [S118]

Calculate the journey from customer problem to maintained solution: idea, implementation, integration, acceptance and updates. This is an opportunity for open platforms and capable agencies. They can turn a quickly built draft into a distinctive feature that remains worthwhile for the merchant.

Shared infrastructure, distinctive value

When a team improves a broadly useful connection or fixes a bug, the change can return to the shared core. Other businesses build on it and contribute improvements of their own. Less foundational work is repeated, leaving more time for the distinctive parts of each business.

People maintain the shared core. Companies strengthen it through care, funding and well-described contributions. Their own offers build on it through specialist knowledge, helpful advice and a distinctive experience.

Two merchants in my network are already using this freedom for very different projects. Their cases move from architecture into the work of running a business.