I understood the words. I roughly understood the intent. I no longer felt in control of the system.
That was the unsettling part of building Jörmungandr. It was not simply that AI had written code I had not read. That was part of the experiment. I had deliberately stopped making my understanding of every implementation detail the thing that held the project together.
The problem was that the system had started to resist being steered back towards what I wanted.
Its documentation, implementation and map had drifted apart. I tried more than once to reconcile them. Then definitions of the terminology, intent and goals began to move as well. Corrections could be made locally without the complete system staying corrected.
I do not mean that the software developed a will of its own. Something more ordinary happened. Each new participant inherited the project's current account, worked plausibly within it and reinforced the direction already encoded there. Once the map had drifted, the system became good at continuing from the wrong map.
The discomfort was information
My first reaction was to keep repairing Jörmungandr. I still intend to finish it. Its premise remains worth testing: a persistent AI-native ecosystem that carries its own workflow while temporary workers enter and leave.
But repairing the same kind of drift inside the same system would answer only one question: could I eventually make that architecture work?
The feeling suggested a second question. What would I build if human understanding and control were not an observation pane added to the system, but requirements that shaped every part of it?
So I started a parallel experiment. Same challenge. Same goal. A different road.
The shared goal is to build a genuine AI harness as production-ready infrastructure rather than attaching agents to a conventional system afterwards. It should create the groundwork for rapid but controlled development, with AI providing the motion while a human retains understanding and authority.
Neither experiment has achieved that goal yet. The comparison is between two developing methods, not two finished products.
The other road has visible seams
The second experiment is becoming a family of separate tools: project knowledge, cross-project discovery, reusable capabilities, installation, authoring rules, component identity and implementation intent.
The names matter less than the separation. Each project owns a bounded responsibility. Each can be understood, tested, updated and verified in isolation. A consuming project can use one part without accepting the whole system. Capabilities can be enabled, disabled, installed, removed, extended or replaced through declared boundaries.
The overview of the whole family is deliberately navigational, not authoritative. Each project owns its product meaning and implementation status. The overview helps me find the terrain; it does not quietly become another copy of it.
A coherent world behind the glass
The ecosystem owns the workflow. I observe and intervene, but its internal shape became difficult to challenge.
A system assembled through visible seams
The parts share a manufacturer and contracts, but each remains separately understandable and optional.
The difference is not whether AI performs the work. It is where the right to define and redirect the system lives.
The closest metaphor I have is another aquarium. This time I am building it from parts made to work together. I can inspect the pump, replace the filter, add another habitat or remove a component without treating the entire environment as one sealed object.
Composability is not only a software quality here. It is a control mechanism. A boundary I can understand is a boundary I can question. A component I can remove has to justify its place in the system.
Understanding changed the conversation
The moment the second approach began to feel different was not when it produced more code. It was when I understood its structure, deployment and upgrade lifecycle well enough to challenge them.
Adding a feature did not require the system to cover over a weak boundary and keep moving. It exposed questions. Where should this responsibility live? Is this accepted intent or a proposal? What is canonical, and what is only a generated projection? How will an upgrade preserve local ownership? What evidence proves what was installed?
Those questions slowed the work. They also made the work legible.
The approach brought practices such as Ai.Draft into view. Instead of allowing an implementation conversation to become the only record of what was meant, Draft turns intent into a revision-bound artefact that can be refined, approved, executed and independently compared with the result.
That is the sort of control I was missing. Not approving every line, or interrupting every worker, but being able to see why a choice exists, challenge it before it hardens and verify that the resulting system still reflects the accepted intent.
Both systems still stop for humans
Jörmungandr was supposed to handle more of its own workflow. Its early velocity suggests that it may. It could carry work through a coherent internal model without waiting for me to assign every step.
In practice, it also developed an irritating habit of stopping for human input or wandering onto a tangent. I had removed myself from routine participation without yet making the reasons for re-entry precise.
The controlled approach also asks for human involvement. The difference is that it is trying to make those moments part of the design. A human decision, approval gate or review is not a worker getting stuck. It is a declared boundary between what AI can do, what it may do and what evidence is required before the work continues.
A system that asks constantly is not autonomous. A system that never asks may merely be operating beyond its authority. The useful target lies between them: AI should carry the workflow until it reaches a decision that genuinely belongs elsewhere.
The slower beginning may be the work
The second road has been slower. At the beginning, everything is interdependent. Before the seams exist, I have to decide where they should be. Before a lifecycle can be reused, its first installation and upgrade have to be understood.
That cost is real. Architecture can become an elegant form of postponement. A collection of beautifully bounded tools is not valuable merely because each boundary has a name.
But the cost is beginning to change. As the tools mature, they create clearer seams, smaller questions and reusable operations. Work done to make one component installable, reviewable or replaceable can reduce the cost of the next project rather than becoming another special case.
The governing stance is enable and enhance, not enforce. The system should make a controlled route easier without requiring every project to adopt its complete worldview.
This is not the comparison yet
It would be convenient to end by declaring the controlled architecture the winner. I cannot.
Jörmungandr needs to become complete enough to test its actual promise. The modular projects need to move beyond early foundations and vertical slices. Only then can I compare delivery speed, correction cost, drift, recovery, reuse and the amount of human attention each system consumes.
Jörmungandr may retain a genuine advantage in velocity and in carrying its own workflow. The modular system may discover that the price of understanding every boundary is too much coordination between them. A sealed system can optimise across its whole world in ways a collection of independently owned components cannot.
For now, the useful result is not a winner. It is a controlled experiment created from an uncontrolled feeling.
I have stopped treating my discomfort as evidence that I should abandon AI-native development. It was evidence that I had not yet designed the relationship I wanted with it.
The goal remains rapid development through factories, workers and systems built for AI. On this road, however, the human keeps the map, understands the machinery and decides where the vehicle is going.