The bottleneck in creating software has shifted from fingertips to inference. Software's currency, the line of code, is experiencing hyperinflation, and it won't stop anytime soon. A single engineer with a coding agent can ship in a weekend what took a team of ten a quarter. Designing the building blocks that agents compose into software is what decides whether you win or lose.

Get the building blocks right and you can produce custom software at scale, an outcome that was structurally impossible before. Get them wrong and you're left with two options: converging to a consulting shop or building a toy.

This shift changes who wins, how companies are built, and what engineering actually means. Most people in tech are still operating as though the bottleneck is execution. It's not. The bottleneck is architecture. And three very different responses to that reality are emerging.

The scalability-customization tradeoff dissolves

Two Gravitational Forces

Most startups building software today are being pulled toward one of two poles. Those that "do things that don't scale" and iterate fast over customer feedback enjoy immediate revenue and validation, but they have to climb out of the consulting valley: translating what they've learned into scalable primitives before the linear economics crush them. Startups that "think big" and want to make it possible for anyone to build an app enter the AI coding landscape of token reselling, distribution battles, and failing demos, fighting competition from unicorns, big labs, and open-source simultaneously.

These two paths made sense when writing software was expensive. But that premise is falling apart, and with it, the tradeoff between scalability and customization. A third path is opening up: the software factory.

Two poles pull. The factory holds.

Primitives

The word "primitive" comes from the Latin primitivus: the first of its kind. In software, a primitive is a building block that's simple enough to be universal but powerful enough to be composed into complex systems. Booleans are primitives. TCP/IP is a primitive. A REST API is a primitive. The history of software is a history of raising the level of abstraction of its primitives.

What's happening now is the next step: primitives are being designed not just for human developers, but for agents.

Stripe was one of the first to understand this. Before Stripe, accepting payments meant negotiating with banks, handling compliance, managing fraud, writing thousands of lines of integration code. Stripe collapsed all of that into seven lines. That's primitive design: take a complex, universal need and expose it as a clean interface that any agent, initially human agents, can use without understanding the internals.

Shadcn pushed this further in a direction that matters. It's a UI component library, but you don't install it as a dependency; you copy components directly into your codebase. They become yours to modify, extend, compose. This is subtle but important: it makes primitives legible and editable by agents. A coding agent can read a Shadcn component, understand its structure, and adapt it without fighting an abstraction layer.

Convex takes it another step, and points toward where software infrastructure is headed. It's a reactive backend: queries are live subscriptions, mutations are transactions, the entire state model stays synchronized across every client in real-time. Build a collaborative app on Convex and you get Google Docs-like multiplayer for free. Not because you engineered it, but because the primitive handles it. More importantly, Convex's component architecture lets you build isolated, reusable backend modules that compose across projects. Each component is a self-contained unit: its own tables, its own functions, its own logic, deployable independently and composable with others. After enough projects, a new deployment becomes assembly from existing components, not engineering from scratch.

The progression from Stripe to Shadcn to Convex traces an arc: primitives designed for human developers, to primitives designed for agentic modification, to primitives designed for agentic composition. Each step raises the abstraction. Each step shifts the bottleneck further from writing code toward designing the building blocks themselves. As each layer matures, it becomes infrastructure, and the number of defensible positions shrinks.

Kandinsky, Thirty (1937)

The Factory

But primitives alone don't win. What matters is the assembly process.

Tesla didn't win by building the best car; it won by building the best factory. The car is the output. The factory, the design of the assembly line, the choice of components, the tolerances, the automation, is the moat. When everyone can build cars, the factory is what separates the winners from the rest.

The same structural logic now applies to software. When everyone can write code, the code isn't the moat. The assembly line is. Programmers have known this for decades; there's an established design pattern called the Factory Method that encodes the same logic: define an interface, let subclasses decide what gets created. The software factory is that idea, one abstraction level up. The primitives are the interface. The agents are the subclasses. The output is different every time, but the assembly process is the same.

The Tradeoff That Dissolves

The old axiom in software was: you can have scale or you can have customization. Pick one. SaaS chose scale. Agencies chose customization. Well-designed primitives dissolve the choice.

If your building blocks are modular, well-scoped, and composable, then every assembly is custom, tailored to the specific client, domain, and use case, but the process is scalable, because it draws from the same set of primitives every time. The output is bespoke and the pipeline industrial.

This changes the economics. SaaS charges for access to a static product. Agencies charge for hours of human labor. The software factory charges for outcomes: custom software, delivered and running. And its cost structure improves with every engagement. Each deployment enriches the component registry that powers the next one. The tenth deployment takes half the time of the first. The hundredth takes a fraction. Margins widen over time instead of compressing. Neither SaaS nor agencies can replicate that.

Cost drops. Customization stays. Margins compound.

The Freedom Problem

Here is where most people building with agents get it wrong: they think the hard part is making agents more capable. It isn't. The hard part is finding balance between freedom and constraints.

An agent with no constraints hallucinates architecture. It invents abstractions that don't need to exist, makes structural decisions no human would validate, produces software that works once and can't be maintained. An agent with too many constraints is just a templating engine with a language model attached. Congrats, you've added latency and cost for no gain.

The design question is: how much freedom does the assembler get?

This isn't a technical problem. It's a design problem. And it's the one that separates the software factories from the vibe coding toys. The answer is different for every layer of the stack, every type of client, every level of risk. Getting it right requires the kind of intuition that comes from building the same thing many times, noticing which decisions agents make well and which they don't, and encoding those observations into the architecture itself.

The patterns that work are consistent. A smart orchestrating agent makes structural decisions: which components to use, how to compose them, where the boundaries are. Cheap, fast sub-agents do the bulk work: extraction, formatting, execution. The orchestrator has broad context but acts narrowly. The workers have narrow context but act fast. When data conflicts, the system asks the human instead of guessing.

Again, none of this is about making agents smarter. It's about making the environment legible. You're writing constitutions for a species that moves in storms. The constitution doesn't control the weather. It decides what survives it.

And regardless of how capable the models become, this remains a human problem. An LLM can write code. It can even write good code. But the decision about what the building blocks should be, how much latitude the assembler gets, which tradeoffs are acceptable; that's judgment. The kind that comes from building, failing, rebuilding, and noticing which constraints held and which shattered.

The models are the storm. The primitives are the architecture. The constraints are the constitution. The storm has arrived, now it's time to build the other two.

Kandinsky, Network of Above (1927)

What This Means

Zoom out from the engineering and a larger picture emerges. Software supply chains are starting to look like physical supply chains. Raw materials: foundation models, cloud infrastructure, data. Components, or primitives: payments, auth, real-time sync, UI systems, vector search. Factories: the assembly pipelines that compose components into products. Brands: the companies that own the customer relationship and the outcome.

The winners will own their assembly line, not their code. Tiny teams with the right primitives will outperform large teams with the wrong ones — not marginally, but by orders of magnitude. One team feeds raw materials into a factory: client data, meeting transcriptions, domain requirements. The agentic assembly line selects the right primitives, composes them, and delivers a custom product built from maintainable parts. Another team hands the same requirements to twenty engineers who spend three months writing it from scratch. Both products work. One was manufactured. The other was handcrafted.

This is already happening. The first wave of vibe coding platforms launched as fullstack, from-the-ground-up app builders. The IKEA model: control everything, ship the whole thing. But they're quickly discovering that reinventing dozens of wheels simultaneously is near-impossible, so they're partnering with database providers, auth services, security scanners, payment processors. They're building supply chains. The market is telling them the answer before they've finished asking the question.

As the supply chain matures, the middle gets squeezed. You're either a primitive or a factory. If you're a primitive, you're a high-quality building block that factories and other primitives depend on: payments, auth, real-time sync, vector search. That's defensible. If you're a factory, you own the assembly line and the customer outcome. That's defensible too. Everything in between is getting squeezed. The two gravitational poles from the beginning — consulting and commodity — aren't destinations. They're what the squeeze produces when you haven't chosen.

This is true for software today. But software eats the world. Consulting, finance, law, accounting — every field where the work is intake, process, produce, deliver will face the same structural question. Build the primitives, or build the factory. The gravity is already pulling.