Building autonomy before the domain was ready.
We didn’t build a boat, we built a floating computer. Autonomy is not achieved by automating actions.
Think of a lunar landing. You don’t just build bigger rockets. You need to design a system necessary to survive the mission – and draft a plan how to get there. I spent a lot of time at the Air&Space Museum in Washington D.C. during my scholarship. And many meetings with ex-NASA Engineers really left an impact on me. „You are facing the impossible and try to make it work. Step by step.“
ZeroOne began with a fairly uncompromising idea:
We were not building a remotely controlled vessel. We were building an autonomous vehicle. On the water.
That distinction shaped almost everything that followed.
Autonomy meant autonomy
On the road, nobody would seriously design a vehicle whose fundamental capability disappeared the moment mobile coverage did. Cities alone make that assumption questionable: buildings create radio shadows, multipath happens, networks become congested and coverage changes. At scale, even very good availability numbers eventually turn into real vehicles without connectivity.
I had already spent years dealing with exactly that problem at Audi and within the Volkswagen Group.
What happens when there is no coverage?
One dispute around connected vehicle behaviour lasted roughly two years. The proposed logic sounded reasonable when viewed one vehicle at a time: if connectivity disappears, stop the action. In the extreme case, park the vehicle immediately.
That becomes considerably less elegant when you imagine many vehicles doing it at the same place – at the same time.
Cars would begin to pile up precisely where the network became unavailable. And the same outage that caused them to stop would also prevent them from using that network to warn others about the situation ahead of them.
The dependency was striking: the protective behaviour depended on the infrastructure whose failure had triggered it.
But all network providers loved the idea of network depency. At some point my answer became simple: fine — then give us the SLA. If a vehicle function is required to depend on a mobile network, network availability is no longer just a telecom KPI. It becomes part of the system architecture and potentially part of the liability model.
I used an intentionally ridiculous picture: if the cells around Ku’damm in Berlin fail and our vehicles all have to stop because of it, we are effectively organising a flash mob. And if the network caused the party, perhaps the network provider should pay for it.
Oddly enough, that picture helped settle a disagreement that abstract arguments had failed to resolve for roughly two years.
Connectivity may extend capability. It should not silently become a dependency that destroys it.
Years later, ZeroOne inherited that thinking. A remote link could provide supervision, information and services. But it could not be the nervous system of the vehicle.
Interfaces create room for change
There was another lesson I carried over from automotive: an explicit boundary creates room for a new technology – it is enforcing innovation. Limitations spark innovation. Because you cannot enforce the entire surrounding system to adapt.
That lesson returned with ZeroOne. Water is not a lab environment.
We did not want individual components, integration choices or supplier-specific assumptions to dictate the architecture around them. We worked toward explicit interfaces and modularity as design properties, so that the system could evolve without every change becoming a redesign of everything else.
The public lesson is deliberately simple: limitations and environmental constraints enforce innovation.
Public architecture lens · deliberately incomplete
A vehicle loop, not a remote-control chain.
Remote-control is easy. It is unmanned. But not autonomous.
The public view is intentionally abstract. It shows the architectural reasoning without exposing implementation-sensitive topology or decision logic.
- 01
Senseobserve vehicle and environment
- 02
Understandbuild trustworthy state
- 03
Decideturn intent into action
- 04
Guidetranslate decisions into motion
- 05
Actuateexecute locally on the vehicle
An amphibious vehicle without wheels
We borrowed aggressively from domains that had already accumulated painful lessons. ISO 26262. ASIL thinking. MISRA. And concepts from DO-178B and airborne software assurance.
We did not claim that a maritime vehicle was certified under those standards. We gave those disciplines internal design authority because much of the regulatory framework for the kind of autonomy we were building simply had not caught up yet.
Our thought experiment was intentionally excessive:
If we could launch this thing into space — a literal space-ship — or put it onto a public road, what would we still be willing to neglect merely because it happened to operate on water?
In some ways, ZeroOne became an amphibious vehicle without wheels.
That made development harder. Sometimes substantially harder. Reduction came later through focus — not by pretending constraints did not exist, and not by violating regulation.
When reality exists before the category does
That gap between engineering and regulation became very tangible.
ZeroOne had already received an approval that enabled international operation. And I still ended up being formally summoned to a hearing by the German Waterways and Shipping Administration (WSV) in Kiel.
The hearing lasted hours.
The contradiction I experienced was almost comical: this was not supposed to be possible.
Except ZeroOne existed. It had been built. It had been approved. And it operated.
The point was never that regulation did not matter. Quite the opposite. If the rulebook for your exact technical domain does not yet exist, you carry more responsibility for deciding what good engineering should look like — not less.
The system had reached reality before some of the categories intended to describe it had caught up.
Reliability was structural
Redundancy was structural rather than decorative.
But the primary motivation was not safety.
It was reliability.
An autonomous vehicle that becomes incapable because a single component fails is not particularly autonomous. The architectural objective was therefore not merely to fail safely. Wherever reasonably possible, it was to keep useful capability alive.
That did not mean preserving every original path. It meant asking what the system still needed to be able to do when conditions changed or components disappeared.
A resilient system does not protect its original path. It protects its purpose.
Redundancy is not the same as independence
Two apparently redundant sources can still fail for the same underlying reason.
That made independence of evidence an architectural concern, not just the number of components drawn in a diagram.
The important public lesson is not which sensors, mechanisms or implementation choices we used. It is that redundancy only helps when the relationships between failures are understood. I called it ‚graceful degradation‘.
The details of how we implemented that principle remain part of the confidential technical record.
And then reality happened
Architectures look extraordinarily tidy in diagrams.
Boats do not.
Hardware fails. Sensors lie. Mechanical tolerances become software problems. Software assumptions become mechanical problems. Water gets somewhere it absolutely should not be. A supposedly local design decision suddenly affects three other systems. Suppliers change things. Interfaces behave differently outside the laboratory.
We failed often.
Some failures were small. Some were spectacular.
And some sent me back to one particular chair in the yard.
We called it the sighing chair.
It was the chair reserved for thinking: when something had failed again, when an architectural decision revealed consequences nobody particularly enjoyed, or when staring at the boat was more useful than staring at another diagram.
I spent many hours in that chair.
I think that is how innovation actually happens. Not by avoiding failure. By understanding enough of it to make the next iteration better.
We gave him a personality
There was another design decision that had very little to do with engineering assurance.
We gave ZeroOne a personality. Deliberately.
And yes, we gave him a face too.
One of the people involved in developing his character came from LEGO.
We were creating a machine that would move through public space without someone visibly sitting at the controls. People would meet him in harbours. Children would see him. Sailors would pass him. People working on the waterfront would have to interpret what this strange machine was.
We did not want him to feel hostile. Or anonymous. Or accidental.
So yes: there is a reason ZeroOne looks rather cute.
Not entirely because of me. But perhaps not entirely not because of me either.
And yes, I talk to my boats.
Before AI coding assistants became available
There is another part of the development context that is easy to forget now.
This was before ChatGPT. Before today’s Codex. Before Claude Code.
We had AI engineers – humans, running on coffee, not tokens. What we did not have were generative AI coding assistants.
If we wanted AI in the system, humans had to build and integrate it. Sweat, blood and tears. It reads like ancient times. Just 5 years ago. There was no generative AI sitting beside us producing scaffolding, reviewing an interface, writing test code or explaining an obscure compiler problem at 0200am in the morning. Peer programming meant talking to each other. Not an LLM.
The architecture and much of the software close to the hardware were created the old-fashioned way: humans thinking, coding, drinking coffee, seating, swearing building, testing, failing, debugging, changing assumptions, building again — and going back onto the water.
Real engineers. Real code. Quite a few real nerds.
There is still quite a bit hidden inside ZeroOne. That is intentional.
Architecture is intellectual property too.
Where is the Diagram? I can talk publicly about the principles: autonomy rather than remote dependence; reliability under failure; explicit boundaries; disciplined engineering; and lessons learned under real operating conditions.
I deliberately do not publish component topology, interface mechanisms, failover or degradation logic, timing assumptions, control algorithms, supplier strategies or proprietary hardware implementation choices.
There is a difference between explaining how you think and publishing the design decisions that make a system work.
A brother in Tallinn
Then, years later in 2025, I saw another autonomous vessel floating in a harbour in Tallinn.
I stopped. The resemblance was striking.
My immediate reaction was not about copying or competition. It was delight:
Awwwww. Cute. Tallinn built itself a ZeroOne. He is getting brothers and sisters.
ZeroOne had been there in 2021. I saw this vessel four years later.
I congratulated them. ZeroOne, at least in my head, simply welcomed another member of the family.
I would genuinely love to know what his Baltic brother has experienced since.
Perhaps that is one of the nicer things about building early. At first, an idea can look rather lonely. And then one day it does not.
What remains
Today we see many more autonomous systems on the water. And some questions that created enormous friction for us then are gradually becoming ordinary industry questions.
How autonomous is autonomous? What remains when connectivity disappears? How much availability is enough? What constitutes trustworthy evidence? Where does responsibility sit? How much external dependency should an architecture tolerate? When should a system degrade? When should it stop? And which capabilities must survive?
ZeroOne did not give us every answer. We failed far too often for me to claim that.
But perhaps that is precisely why the lessons are valuable.
They were not generated in a workshop. They were learned in hardware. In software. In negotiations. In regulation. In a shipyard. And on the water.
Sometimes from the sighing chair.
And when I look at today’s autonomous vessels, some of those old lessons still put a smile on my face.
We did not know every answer. But we were asking some of the questions very early.