How software is changing

Most discussion of AI and software stops at "developers write code faster". That's real, and it's the smaller half of the story. Two distinct shifts are happening, and they land in different parts of an organisation.

Shift one: development became fluid

Software used to arrive as concrete blocks. You chose from a catalogue of pre-formed shapes, and whichever you picked, your process bent to fit it. The block was expensive to cast and harder to recast, so the fit you got on day one was roughly the fit you lived with. The alternative — building exactly what you needed — cost quarters and a team, so it was reserved for whatever was genuinely core.

That trade-off is what changed. Software now behaves more like water: it flows into the shape of the need. A tool for how your warehouse actually sequences picking, with the exception your operations lead has been handling by hand for two years, is no longer a business case. It's an afternoon, and next month when the process changes, the software changes with it.

Three consequences follow, and they compound:

• Fit stops being a compromise. The reason internal tools are disliked is usually that they encode someone else's process. When the tool is shaped to yours, adoption stops being a change-management project.
• Small needs become worth serving. The team of four with a specific workflow problem was never a viable customer for custom software. Now they are, which means whole categories of "we just use a spreadsheet" become real systems.
• Change stops being a release. If adapting costs hours, software follows the business instead of lagging two planning cycles behind it.

And a consequence people miss: the constraint moves. When construction is cheap, the scarce thing is no longer the ability to build — it's knowing what should be built, and governing what the result is allowed to do. That's why the rest of these docs spend more words on guardrails than on syntax.

Shift two: operations moved inside the software

This is the half that changes headcount and margins, and it's newer.

Traditionally, software presents work to people. A dashboard shows 40 orders needing review; a human reviews them. A queue fills; a person drains it. The software is a surface for human labour, and scaling the operation means scaling the people.

An agent lives inside the app and does that work. Not answering questions about it — doing it. It reads your data through your own code, calls the tools you granted, writes through operations that enforce your rules, and stops for a human on the things you decided need a human.

The shape of the job changes rather than disappearing. People move from processing the flow to setting the policy and handling the exceptions — which is both better work and a different scaling curve, because volume no longer maps to headcount.

Concretely, in a commerce operation: order triage, inventory watch and restock proposals, promotion drafting against a margin floor, first-line support across every channel, catalogue quality audits, vendor application review, dispute evidence gathering, and the morning exception digest. Worked examples with the mechanisms behind them: Backoffice run by agents.

What this changes about buying software

The historical case for buying was arithmetic: building took quarters, so you bought unless the thing was core. Compress building to days and the arithmetic changes — but not uniformly, and pretending otherwise is how people get this wrong.

The pattern: buy the things that are hard because of the domain; build the things that were only hard because building was expensive.

What gets harder

Being straight about the cost, because "everything is easy now" is not a useful claim:

• Governance becomes the real work. Cheap software plus autonomous agents means the question shifts from "can we build it" to "what is it allowed to do". Business rules belong in code where they bind every caller, not in a prompt a model can be argued out of — see Consistency and correctness.
• Review matters more, not less. Output arrives faster than anyone can read it. The discipline is knowing which changes need a human eye — schema, money, auth, anything customer-facing.
• Verification beats trust. An agent that says it checked inventory and an agent that checked inventory produce identical prose. The trace is what distinguishes them; see Observability and audit.
• Sprawl is a genuine risk. When anyone can produce a tool, you can accumulate fifty of them with no owner. Environments, version control, and an audit trail are what keep this from becoming shadow IT with better production values.

Which is the honest summary of what a platform should provide in this era: not the ability to generate code — models do that — but the guarantees around it. Isolation, audit, rollback, approval gates, least-privilege credentials, and the operational surface to run what you built.

Next

• From one person to a marketplace — the same app at four stages of scale.
• Backoffice run by agents — the operational scenarios, with mechanisms.
• What is Spikefrost — the platform, and what it commits to.