If you still picture the old software and the old software company, you will misread this shift

In a lot of heads, software is still something hard, expensive, and slow. You need specialists. A one-line change needs a ticket. A feature needs a squad. A release feels like a journey. Software is pictured as craft: few people can do it well, it copies badly, and the only way to scale is to pack more craftspeople into the same building.

The software company that comes with that picture is still the same drawing. Raise money. Hire tens or hundreds of engineers. Add product, design, QA, ops. Stitch their output together with process. Make a schedule. Ship, then go find customers. Success first depends on whether you can hire, and whether you can finish on time. If you cannot hire, even a good idea stays an idea.

Those two pictures used to be right. That is why they stick.

Software as a hard, expensive object. The company as a factory that has to pack in people. The two pictures belong together.

The cloud came. Agile came. Outsourcing came. Low-code came. Each round, someone announced that software production was about to change. The tools did change. Building the thing was still hard. While it stayed hard, the company still had to be a factory. The factory was not overturned, and neither was the way we imagined software itself.

This round is not another generation of tools.

Software itself has changed. Companies will change with it. If you still picture the old software and the old software company, you will put the bottleneck in the wrong place.

In After Software I wrote that one person plus AI can already do what used to take a small team. That piece pushed on collaboration and how value gets shared. This one stops one layer earlier, where it is easier to misread: a lot of people think the change is organizational. The production nature of software moved first. The company shape follows.

Software is no longer that craft

Software used to be hard for reasons that were not only the price of people. Interfaces drifted. Hidden dependencies piled up. Quality jumped around. Intent did not travel cleanly to the next person. You could not lift "this part" out and hand it over. What you handed over came with a cloud of context nobody could quite name. It looked like craft: if the master was gone, the work was gone.

That is also why "software factories" kept getting larger. Not because anyone loved meetings. Parts were not standard enough. The only way to sew local pieces into something usable was to pile more people, more review, and more process under one roof.

Computing has actually been doing something else the whole time: wrapping complexity layer by layer. Transistors to instruction sets, to operating systems, to languages and frameworks, to clouds and APIs. Each layer made the next one feel simpler. The stacked whole got more complex and more powerful. The system size one developer could move has been rising for a long time, not falling.

What AI is speeding up is the parts layer.

That is not a claim that all software is already a perfect standard part. Direction, permission models, data models still hide a lot of unnamed decisions. But generating, describing, verifying, and composing can, for the first time, look more like industrial parts. A login page, a docs set, a deploy path, an edge case no longer automatically deserve the prestige of "senior engineering." They are still necessary. Without them the software does not live. They are just no longer noble because they were hard.

What still takes a hand is composition. What changed is whether parts can be made reliably.

Once parts are more generable, checkable, and composable, "getting it built" stops being the main gate. After the gate moves, the hard work climbs: what to build, for whom, where the boundary is, and whether anyone wants it.

A lot of people will hear that as: technology does not matter anymore. I mean almost the opposite. Technology is still there. It just stops being an automatic moat. More people can build. More things will be built that nobody needs.

So the company will not stay that shape either

If software is still craft, the company has to be a factory: hire, manage in layers, stitch craft output together with process. A lot of talk about AI still uses that picture, only with employees swapped for agents. Then the questions become: how do you coordinate five hundred strangers? How do you make a thousand local pieces add up to one whole?

The questions are already old. They assume the future still stuffs a lot of people, or a lot of agents, into one production unit.

What is more likely is not hundreds or thousands of people in one factory. It is many small, fast production units. Each unit has very few people at the center of coordination. A lot of the execution is done by AI. Large, concentrated software factories will not vanish. They will look more like the central kitchens you still occasionally see: worthwhile only when the work is highly standard and highly scaled. Day-to-day needs, and most inventive ones, will be met by many more small units.

People will also have a "bread machine" at home. One person plus a toolchain can finish a lot of work that used to require a factory. That does not kill the bakery. Good restaurants did not collapse into one giant canteen. Once capability is equalized, self-sufficiency gets easier. Specialized supply survives by offering what execution itself does not: judgment, taste, reliability, channels, trust.

Collaboration will still happen. The reason changes. It used to be "I do not have the people, I cannot build it." More often it will be "there is no need to reinvent a wheel that already exists." The coordinating center gets smaller, not larger.

Not a taller version of the old factory. Smaller units, and more of them.

Sales and marketing do not change in kind. They may be huge, or small and sharp. AI will shave some of the cost of reaching people and making content. Trust, hard deals, and long relationships will still support specialists. What moves is their place in the sequence. They are no longer "hire sales after the product is done." They sit closer to whether the product can exist at all.

If you still picture the old company, you will keep reading success as scaled hiring and scheduling. Headcount will grow. Coordination will get heavier. The scarce thing will no longer be in the headcount.

Success falls back on demand, taste, and the market

When building gets easier, experiments multiply, and so does noise. "I want to, but I cannot build it" used to stop a lot of projects. After that wall gets lower, you get more "I refuse to wait, I will start anyway." Most of those still will not be things anyone actually needs.

So the filter changes. From "can you build it" to "will anyone answer the thing you built with real money."

Demand, taste, market, and sales always mattered. When building was expensive, they often had to wait behind "first hire the team, first get a version out." Being able to build came first. Whether anyone wanted it came later. After the gate moves, the order flips. A project with no real demand signal shows up earlier: not "nobody has noticed yet," but "plenty of people could build this, and still nobody will stand up and ask for it."

Contribution also gets easier to measure. Not because we invented a finer timesheet. The opposite. Tokens burned, lines written, hours sat, will almost certainly be gamed. What starts to stand up is how much was accepted and used. Identity and title get lighter. What was merged, what customers actually used, what brought real demand, get heavier.

Writing code still counts as building. Bringing the first customers, turning a vague wish into a checkable need, getting the product actually used, also count. Software success always needed supply and demand at the same time. When supply was expensive, supply stole most of the attention. After supply gets cheap, demand returns to the place it should have had.

Development is still there. It just is not first. In front of it: demand, taste, and the market.

I am not saying companies suddenly fail. Products that need a strong brand, heavy compliance, or continuous operations will often still be best housed in a company. I am also not saying development became manual labor. Complex systems are still complex. A wrong call on direction or structure will be amplified faster.

I am only saying this. If you still picture the old software, you will keep throwing budget at more engineering headcount. If you still picture the old company, you will keep reading success as hiring and scheduling. Both will misread this shift.

Software changed. Companies will change too. What moved is not the slogan. It is where the gate is.