I've spent the last few weeks using LIOS to build LIOS.
There is something pleasingly recursive about that sentence, and something slightly dangerous too. Any system that evaluates itself has at least the possibility of becoming very sophisticated at agreeing with its creator. But the experiment has exposed a problem I think a lot of organisations are about to encounter.
The bottleneck isn't writing software any more. Or at least, it isn't mine.
The economics changed
I've been building and leading software organisations for a long time. Long enough that my first professional systems were built when deploying software involved considerably more ceremony than asking an AI agent to investigate a problem, implement the change, write the tests, open a pull request and report back.
I've also spent a good portion of those decades annoying product people, stakeholders and occasionally entire businesses by asking what we're actually trying to achieve and why. At Askott and FansUnite there wasn't a separate "product person" sitting between the business and engineering. There was me. Priorities, value, understanding the problem and getting clarity about intent have always been part of the job.
For most of that time, though, execution was expensive. You could have more ideas than engineers, and considerable organisational machinery grew around deciding what deserved some portion of that capacity and then making sure it actually got delivered.
Then the economics started to change.
There is plenty of argument about exactly how much faster AI makes software development. GitHub measured developers completing a controlled coding task 55% faster with Copilot. At the other end, a 2025 METR study found experienced open-source developers working on their own mature codebases were actually 19% slower using the AI tools available at the time, despite believing they were faster.
Both results are useful. AI capability, the task, the developer and the surrounding system all matter. What seems much harder to dispute in 2026 is that increasingly capable coding agents can now perform substantial pieces of engineering work that previously required a human sitting at a keyboard.
Linas Beliūnas recently described the "agentic transition" as the move from AI assisting an engineer inside an editor to fleets of agents writing, testing and shipping software while humans decide what should be built and verify what comes back.
That description feels increasingly familiar from where I'm sitting.
Steering the ship
I currently work with multiple AI agents playing different roles. A Strategist investigates intent, constraints and possible approaches. A Builder works against an approved contract and implements it. I sit in that loop as the human Gatekeeper, for now at least.
The change isn't that I've suddenly started thinking about priorities, value, intent and outcomes. That's been the job for decades. The change is how much less attention execution itself demands from me.
I've come from the world of execution and spent much of my career trying to lead execution well. That traditionally means continually looking both ways: towards the horizon to make sure you're going somewhere worthwhile, and back into the engine room to make sure the machinery and people can actually get you there.
AI is shifting that balance.
I can spend much more of my time looking at the horizon, choosing direction, clarifying intent and steering. The implementation machinery hasn't become irrelevant, and it certainly hasn't become infallible. But I no longer need to spend the same proportion of my attention keeping it moving.
That creates another problem: what should I point it at next?
The backlog fights back
You might assume that if software becomes dramatically faster to produce, the backlog gets shorter.
Mine didn't. It grew.
The faster I built LIOS, the better the process became at exposing things worth building. One piece of work uncovered an authentication weakness. Fixing that exposed inconsistencies in authorisation. Investigating those showed that application permissions, identity-provider roles and internal service credentials were overlapping in ways nobody could confidently explain.
But plenty of the work has been less about finding defects and more about discovering what becomes possible next.
LIOS gained durable agent sessions that can survive a cold restart and reconstruct authoritative context rather than relying on chat history. I added external read-only agent access so somebody outside the organisation can let their own AI explore LIOS without giving it authority to change anything. The exchange system gained explicit human and agent identities, decisions, approvals and per-participant reading positions. More recently I've been working on establishing one canonical answer to what knowledge is actually current, rather than allowing different parts of the system to quietly answer that question differently.
Every capability makes another capability conceivable.
Some of this is ordinary software development. Build things and you find both problems and opportunities.
But something else is happening too. The agents aren't only accelerating implementation. They're accelerating investigation. They can inspect more code, follow more paths, compare more evidence and raise more possibilities. Making implementation ten times faster doesn't solve much if the same system generates twelve times as many things worth considering.
At that point the scarce resource isn't code. It's judgement.
A system for the judgement
LIOS stands for Living Intelligence Operating System. The name may be grander than the thing currently sitting on my servers, but names are allowed to contain ambition.
At its centre is a knowledge base intended to hold organisational knowledge as something more structured than a folder full of documents. It contains strategy, principles, process standards, vocabulary, architecture and decisions. Knowledge is versioned. Supersession matters. Rationale matters. Rejected decisions matter. What the organisation currently believes should be distinguishable from what it believed six months ago. So bitemporal modelling really matters here, along with several other dimensions.
LIOS Core observes signals from the outside world and evaluates them against that knowledge. One of those signal sources is now LIOS's own GitHub repository. Changes can be evaluated against engineering principles, process standards and product architecture, with the system explaining why it believes the activity is aligned or drifting.
The score itself isn't truth. A system capable of saying "GREEN, 94%" while the company drives off a cliff would be a particularly expensive form of reassurance. The useful part is the relationship between what the organisation says matters and what it actually does.
LIOS Works deals with the other direction: what we intend to do about it.
Work is organised into milestones with explicit contracts. Investigation happens before implementation. Agents discuss findings on durable exchange threads. This has a pleasing echo of my vBulletin developer days, except this time the data and the actors involved stay fully visible, immutable and usable, rather than disappearing off to Coventry with Tacky.
Decisions and approvals have identities. Human authority is different from agent authority. Dependencies are explicit. Sessions preserve context without pretending conversational memory is organisational memory.
This has occasionally felt bureaucratic while building it. Then an agent does something unexpected and I remember why the "good" bureaucracy in this world exists.
There is some external evidence for this wider problem. Google's DORA research describes AI as an amplifier of the organisation around it: strong systems benefit, while existing dysfunction can also be amplified. Their conclusion is that the largest returns come from improving the underlying organisational system, rather than treating the AI tool itself as the transformation.
That is increasingly what LIOS has become an experiment in.
What did I do last week?
A few days ago I took advantage of all this record keeping and asked an AI to tell me what I'd done over the previous ten days.
There wasn't a purpose-built function for the question. Instead it walked the Works milestones and reconstructed the history. During that period I'd completed work around repository discipline, identity and authorisation, operating-system isolation for agents, knowledge integrity, external read-only AI access and durable agent sessions. Another milestone was establishing one canonical answer to the deceptively simple question of what knowledge is current.
The summary was useful, but what happened next was more interesting.
I vaguely remembered "0.4.5, something about authority". That was enough for the AI to identify the work and remind me that we'd discovered three overlapping mechanisms governing authority: application permissions, identity-provider roles and service credentials.
I then asked what had been difficult about it and what was better now.
Answering that isn't the same as finding a ticket. It requires the investigation, the things the Builder discovered, the arguments, the decisions, what became durable knowledge, what was implemented and what was deliberately deferred.
In other words, it requires some record of the thinking that happened while doing the work.
Most organisations throw an astonishing amount of this away.
Maybe the meeting is the workaround
This led me somewhere I'm deliberately pushing the system to go.
Take a fairly ordinary Kanban team. There are meetings to decide priorities, replenish the board, coordinate active work, clarify requirements, review delivery and eventually reflect on what was learned.
I'm not anti-meeting. I'm anti pointless ceremony and wasting people's time synchronously while pretending that synchronisation is the same thing as work.
I'm very much in favour of humans spending time together. Have lunch. Talk nonsense. Argue around a whiteboard. Go for a drink. Build relationships. Those things matter enormously, particularly as more of the mechanical work moves to machines.
But let's be honest about which thing we're doing. Sitting in an office because "culture" requires everyone to be there, then spending the day on Teams calls with people sitting twenty metres away, isn't culture. It's commuting with extra steps.
A daily stand-up exists partly because the organisation needs to synchronise its understanding of reality: what changed, where work is stuck and where somebody needs attention. If the work system already has that state, gathering eight humans every morning so they can reconstruct it verbally starts to look peculiar.
The same applies to much of status reporting, and perhaps parts of the retrospective.
Imagine beginning a retrospective with evidence that seventeen items completed, four had significant rework, three shared an underlying cause, blocked time increased and several potentially durable lessons never made it into organisational knowledge.
Now there is something worth talking about. The humans can spend their time on the bit that matters: what does this mean?
Not only that, but with a system that can reason from your questions, focus, position, priorities, whatever... you can get your own personally relevant daily, weekly, hourly, whateverly update. More importantly, it's one you can interact with and question. Yes, the Jarvis moment: "Morning, what happened yesterday?" Then, "Oh yes, tell me more about item two... and let me know when it's completed with a summary."
The Jira question
This inevitably raises the dangerous question of whether you still need Jira.
Probably.
At least, I'm nowhere near arrogant enough to conclude that because one human and a collection of AI agents can operate without a conventional ticket tracker, fifty humans across several departments can (well it's likely, "but" ...).
Jira has accumulated decades of answers to real coordination problems: ownership, scheduling, visibility, releases, permissions, reporting and all the wonderfully inventive ways organisations manage to make themselves complicated.
Rebuilding Jira would be an excellent way to spend several years not building LIOS.
I'm interested in a different question. What happens if you make some of the reasons for Jira disappear?
I've used "Now, Next and Later" to prioritise work for years and rarely needed anything more sophisticated. LIOS Works is gaining those horizons, alongside optional labels for things like bugs, security or UI work. Dependencies, history, authority and evidence still exist underneath, but the human doesn't necessarily need to spend their life administering representations of them.
The interesting question isn't how to build a better AI-native work tracker. It's what the work tracker was compensating for in the first place.
The organisation becomes the software
When execution was expensive, organisations evolved around managing scarce human execution capacity. We built queues, hand-offs, management layers, planning cycles, reporting structures and meetings to coordinate it.
Now imagine execution becoming abundant.
Not free, not infallible, and certainly not trustworthy without controls. But abundant enough that the constraint moves elsewhere.
Clarity of intent becomes more important. So does judgement, verification and authority. Eventually the constraint becomes whether the organisation can learn quickly enough that its agents don't repeat yesterday's mistakes at tomorrow's speed.
This is where I think some of the more breathless claims about AI productivity miss the interesting part. Making an engineer ten times faster while leaving the rest of the organisation unchanged doesn't produce a ten-times-faster organisation.
DORA's research points in much the same direction. AI amplifies the system it enters. The interesting opportunity isn't simply making the worker faster; it's redesigning the system around work that can now happen very differently.
That's what using LIOS to build LIOS has become for me.
It isn't an attempt to build an AI programmer. There are companies with several more GPUs than I own taking care of that problem.
And despite the fact that I'm currently using LIOS to build software, I don't think this is fundamentally a software-development problem.
An organisation has some understanding of what it is trying to achieve. It has knowledge about its world, principles it wants to follow and decisions it has already made. Work emerges from that intent. Humans and increasingly agents perform that work. Evidence comes back. Decisions are made along the way. Reality changes. Things are learned.
Software development happens to be an unusually good environment in which to build and test that loop because agents are already capable enough to do substantial real work.
But there is nothing inherently software-specific about clarifying intent before acting, deciding who has authority, maintaining evidence of why something happened, verifying outcomes, detecting drift or learning from execution.
A legal team does that. A marketing team does it. Operations does it. Compliance does it. An executive team does it. Any organisation that has intent and uses humans and agents to get things done has some version of the same problem.
Today those interactions are scattered across meetings, email, Slack, Teams, Jira, documents, people's heads and increasingly a collection of AI conversations that disappear into separate context windows.
I think there needs to be somewhere else.
Somewhere the organisation's intent meets its execution. Somewhere humans and agents can operate against the same state, with explicit authority and durable reasoning. Somewhere the result of today's work can improve tomorrow's starting point.
Building a system with itself is about as biased an experiment as I could design. Software development by one experienced human working with AI agents is also a very particular environment.
So the next interesting test isn't whether LIOS can build more LIOS.
It can.
The interesting test is whether a team doing something else can work this way and, after a while, look back at some of the machinery we currently consider essential and ask:
Why did we used to do that?
A while ago we had a revolution, set the horses free and got into cars. Now it's time for another step and the rest of the organisation got into the spaceship, not just the engineers.
