The autonomy decade

For most of the last century, defence capability was measured in things you could point at. Range, payload, armour, speed. Procurement cycles were organised around delivering objects, and an advantage, once built, tended to last for years because the object itself was hard to reproduce.

That logic is breaking down. Increasingly, the decisive difference between two similar platforms is not the platform — it is what the platform can do on its own. And that lives in software.

The advantage moved

Consider two aircraft with identical airframes, sensors and engines. One requires a trained operator giving continuous input. The other can be given an objective and left to pursue it, reporting back only what matters. These are not two versions of the same capability. They are different capabilities entirely, and the difference is entirely software.

This has an uncomfortable implication for how defence organisations buy things. A software advantage does not behave like a hardware advantage. It can be improved continuously rather than at refit intervals. It can be copied and deployed across a fleet at negligible marginal cost. And it decays quickly if it is not maintained, because the state of the art moves underneath it.

An advantage you cannot modify is an advantage with an expiry date attached.

Why sealed systems are a trap

If the decisive component is software, then the ability to inspect, understand and change that software is not a procurement nicety. It is the capability itself. A force that operates autonomous systems it cannot examine has outsourced the most consequential part of its own decision-making to a supplier.

This is the reasoning behind our position that defence users should be able to own the autonomy they depend on. Not necessarily to write it themselves, but to understand it, adapt it, and improve it on their own terms and timeline rather than someone else's.

What this means for how systems are built

If software is where the advantage lives, the engineering priorities change. Three consequences follow, and they have shaped how we build:

• The core matters more than the platform. An autonomy core that works across unmanned aerial, humanoid and tactical systems compounds: an improvement made for one benefits all three. Building three bespoke stacks does not.
• Iteration speed is a capability. How quickly you can test, learn and improve determines where you end up. That is why we develop simulation-first — a scenario that takes a day in the field can run thousands of times overnight in software.
• Modularity is strategic, not aesthetic. Clean interfaces mean the autonomy can integrate with existing platforms and command arrangements rather than demanding everything be replaced around it.

The uncomfortable part

There is a version of this argument that becomes triumphalism about software eating defence. We would resist that. Hardware still decides what is physically possible; an autonomy stack cannot give an aircraft endurance it does not have. Systems engineering, ruggedness and manufacturing remain genuinely hard, and are where most promising prototypes actually die.

The honest claim is narrower: the marginal advantage has moved. Between two competent platforms, the one that thinks better wins — and thinking is improvable in a way that airframes are not.

Where we sit

Rewind Dynamics was founded in 2020 on this thesis, and we have spent the years since building the core rather than rushing a product to market. Our systems remain in research and development; our first end-to-end mission test is planned for December 2026. We would rather state that plainly than imply more.

If the thesis is right, the next decade of defence capability will be decided by organisations that treat autonomy as something to own and improve continuously — not as a feature to purchase once. That is the bet we are making.