AI agents are getting very good at producing software.
What interested me was what happens after the code exists.
A generated project can compile and still be wrong. A port can launch while losing important behaviour. An agent can make a convincing change without knowing how that change actually behaves on the machine that has to run it.
I wanted the software project to continue beyond generation.
The same project should be able to change, run on a real Xbox Series X, produce evidence about what happened there, return that evidence to the development side, receive another correction, become a new version, and run again.
That eventually became XCP.
But it started somewhere much smaller: with a virtual machine inside the Xbox application sandbox.
The project should not disappear after generation
A lot of AI-assisted development still has an implicit shape:
prompt
↓
agent
↓
source files
↓
build
↓
done
I wanted a loop instead.
AI agent / developer
↓
XCP project
↓
create / modify / adapt
↓
target candidate
↓
XBOX SERIES
↓
execute + observe
↓
structured evidence
↓
correct / evolve
↓
next version
↺
The agent does not run unrestricted on the console.
It works from the PC side, where the project can be inspected and modified. Xbox executes the prepared candidate. XCP records what happened and brings that information back into the project lifecycle.
The next iteration can therefore start from real target behaviour, not only from what the agent expected the software to do.
That distinction became the core of XCP for me.
XCP turns an AI agent from a one-shot code generator into a participant in an ongoing software lifecycle.
The project survives the generation.
Its versions have identities. Executions belong to specific versions. Evidence belongs to specific executions.
That makes continued work possible without treating every new generation as an unrelated pile of files.
Create, adapt, and keep going
XCP currently enters that lifecycle in two main ways.
A project can start from an idea.
In the public creation programme, an AI-driven, human-directed workflow completed 28/28 lifecycle operations across an interactive project and a utility.
The interesting part was not that an AI produced code. We already know models can do that.
The interesting part was that the work continued through the wider lifecycle: project creation, preparation, execution and subsequent decisions.
The second path starts from existing authorized software.
That is substantially harder because a real project is more than source files. It has state, input behaviour, timing, scenes, persistence, assets, engine conventions and interactions between systems.
The first public real-source case uses Minilens, an authorized Godot 2 project.
That case completed 14/14 lifecycle operations and 5/5 declared semantic acceptance checks on Xbox.
I am deliberately not describing that as “Godot compatibility”.
It is a narrower and more useful result: real source software crossed the full path from source observation to an Xbox execution and a measured decision.
And then the project can continue.
One of the public lifecycle sequences is:
1.0.0 → 1.1.0 → 1.0.0
A later version was produced, exercised, and the lifecycle retained the ability to return to the earlier known version.
That is a small example, but it captures an important idea: evolution is part of the system, not an afterthought.
The software is expected to be changed again.
The Xbox became part of the development loop
The Xbox is not only the place where the final result gets deployed.
It is an execution target inside the loop.
Consider a simple behavioural change.
An agent modifies movement. XCP prepares the next candidate. The candidate runs on Xbox. Target observations are recorded. Those observations are compared against the behaviour the project was supposed to preserve. The result becomes evidence attached to that version.
The next correction can then work from that result.
This pattern can repeat.
That is very different from asking a model to generate another implementation after someone manually reports that “movement feels wrong”.
The target itself contributes information to the next development step.
This is also why I became less interested in “AI-generated software” as a category.
Generation is one operation.
Maintaining an evidence-bearing relationship between an agent, a software project and a real execution target is a much larger problem.
The virtual machine that made this possible
The Xbox side began as a separate research problem.
I wanted programmable execution on a retail Xbox Series console while staying inside the public application environment.
That produced XVM, a deterministic virtual machine used by the current reference runtime.
XVM v2 currently has 26 admitted opcodes, 16 registers, typed memory, bounded control flow, static execution budgets, deterministic snapshot/resume, a canonical CPU path and GPU differential execution paths.
Those details deserve their own article.
For XCP, the more important property is simpler:
new bounded work can be submitted to the execution target without every new behaviour becoming a completely new native application.
The VM gives XCP a programmable target.
It also gives the target the ability to reject work that does not fit its current execution contract.
That is enough to keep a useful separation between the software producer and the machine executing what it produced.
XVM does not remove the Xbox sandbox.
It creates a programmable layer inside it.
Running the software was not enough
Once the VM worked, another problem became much more important.
Real software does not begin as VM instructions.
It begins as behaviour.
A player moves. A collision fires. A value survives a restart. An input changes some state. A scene transition happens.
The implementation of those behaviours can be completely different on another runtime.
This forced XCP to separate three things:
source behaviour
↓
semantic representation
↓
target implementation
The current reference source family is Godot, while Xbox/XVM is the first reference target.
Those environments do not share the same engine, scripting model, APIs, scene implementation or runtime assumptions.
So XCP cannot simply copy structure and call the result equivalent.
The source side has to expose enough meaning for the target side to reason about what can actually be preserved.
And then the result still has to be measured.
That produces another distinction which now runs through the project:
execution is not fidelity.
A candidate can launch successfully and still behave incorrectly.
A movement path may work while collision semantics changed. A scene may look right while persistence is broken. A playable subset can still contain behaviour that was never observed.
XCP therefore keeps operability, fidelity and stronger equivalence claims separate.
This is not mainly about being conservative with wording.
It makes the evidence useful to the next iteration.
If the system can say where behaviour diverged instead of merely returning “build succeeded”, an agent has something concrete to work on. Xbox is the first target, not the definition of XCP
Today the concrete path looks like this:
Godot → XCP → Xbox / XVM
But that is not the architecture I want to stop at.
The source side and target side are being separated deliberately.
The future model is closer to:
Godot ─────┐
Unity ─────┤
Unreal ────┤
Custom ────┘
↓
XCP
↓
target contract
↙ ↘
Xbox / XVM other runtimes
Only the first path has public research evidence today. The other arrows are directions for the architecture, not current compatibility claims.
This is where XCP becomes much more interesting.
The long-term value is not moving one Godot project to one Xbox. It is making source systems and execution targets independently extensible.
If another developer can eventually write an adapter for a different engine without rewriting the core, that tests the semantic boundary.
If someone can implement another XVM runtime from the same contract, that tests the execution boundary.
If another target can consume XCP projects while preserving the evidence model, Xbox has done its job as the first forcing function rather than becoming a permanent limitation.
The next test is other developers
Most XCP development still lives in a large private research repository.
That repository is useful as a laboratory, but it is not what I want to publish as the platform.
It contains years
So I am preparing a clean open-source extraction instead.
The current model is roughly:
spec
runtime
semantic
adapters
evidence
conformance
sdk
examples
Godot would begin as the reference source adapter.
XVM would begin as the reference execution substrate.
Xbox Series would remain the first reference target.
XCP Studio is the product environment around that platform.
The experiment I care about after that is not another demo produced by me.
It is somebody else building the next adapter, runtime or verifier.
That will expose very quickly whether the abstractions are actually general.
From a VM on Xbox to a continuous software lifecycle I originally wanted to see how far programmable execution could be pushed on Xbox.
That produced XVM.
XVM made repeated target execution possible.
Repeated execution made it possible to return structured information from the hardware.
That information made a continuous agent loop possible.
And that loop became XCP.
AI agent
↓
software project
↓
real execution
↓
evidence
↓
next decision
↺
The VM is still an important part of the system.
Xbox is still the first real target.
But the project is no longer mainly about either one.
It is about keeping software alive after the AI finishes writing the first version.
AI builds. Xbox executes. XCP verifies.
Then the project continues.
Current public work
XCP Studio: xcpstudio.com
XCP Research: github.com/Daniele-Cangi/XCP-Research XCP-Research currently contains the architecture description, the public XVM model, selected bounded Xbox evidence and offline verification tooling. The implementation remains private while the active research branches are consolidated and the open-source platform boundary is extracted cleanly.
Writing note: I used AI as an editorial assistant to help restructure and edit this article. The project, experiments, technical claims and final publication decisions are mine.