I have been using coding agents in several of my projects. Most of the time, the process was fairly simple: describe a task, let the agent work on it, review the changes, and decide what to do next.
That worked reasonably well for tasks with a clear expected result.
But I started wondering how much more I could safely delegate. Not just writing code, but also checking the result, finding problems, and deciding whether a small correction was worth trying.
A puzzle game became a useful place to explore that question.
Starting with a small game
One Shot Chaos is a small game built around a simple idea: the player gets one shot to trigger a chain reaction and clear enough targets to complete a stage.
The project gave me something different from my usual .NET work.
There was still ordinary engineering involved: application state, collision detection, validation, and testing. But the result also depended on things that were harder to measure automatically.
Did the game feel satisfying? Was the screen readable? Did the visual feedback make sense?
A test could tell me whether a projectile hit the expected target. It could not tell me whether the impact felt good.
That distinction became important as I started giving the agent more responsibility.
The agent needed to see what it changed
At first, a coding agent could modify the game and run technical checks, but I still had to inspect the visual result myself.
This created a gap.
The code might work. The validators might pass. But a change to the interface or an animation could still look wrong when the game was running.
I wanted to see whether the agent could observe the actual application instead of relying only on the code it had written.
The first experiment was deliberately small.
I introduced a way to capture a known state of the running game deterministically. The same state could produce a screenshot that could be compared across runs.
That did not make the agent capable of judging visual quality. But it gave the agent something concrete to inspect.
The next experiment went a little further: find a known local presentation problem, make a correction, and observe the result again.
For a small change like that, part of the visual feedback loop no longer depended entirely on me opening the game and checking the result myself.
Giving it a little more responsibility
Once the observation process worked, I tried extending it.
Instead of always specifying the exact correction, I wanted to see whether the agent could examine a small area, find a few possible improvements, and choose one small change to try.
The scope remained intentionally narrow.
It could investigate a local presentation issue, make one reversible change, run the relevant checks, and compare the result.
It could not redesign the game, change its rules, or treat a successful technical check as proof that the result looked good.
The process gradually became something like this:
Investigate
↓
Propose
↓
Try one small change
↓
Observe and validate
↓
Keep, revise, or stop
Later experiments extended the observation to different game states, including aiming, reactions, progression, and completion.
That made the agent more useful, but it also made the limits of its responsibility clearer.
A reproducible screenshot could show that two runs produced the same image. It could not tell me whether the image looked good or whether a player would enjoy the game.
Those decisions still needed a different kind of judgment.
When more changes were not the answer
Separately, the visual development of One Shot Chaos gave me another useful lesson.
Several early experiments improved individual parts of the presentation. Targets became more expressive, reactions gained additional effects, and the interface became more consistent.
The changes worked, but I was still not satisfied with the overall visual quality.
Continuing to polish individual elements did not seem likely to close the gap.
I tried a more complete visual treatment of one representative screen. That made a more noticeable difference, but the result was still some distance from the reference I wanted to approach.
Eventually, a different direction using illustrated raster assets produced a much stronger result.
The important part was not that the agent had finally found the right answer.
It was that the experiments helped me see when an approach was producing diminishing returns.
A successful implementation was not automatically a reason to continue in the same direction.
Sometimes the useful result of an experiment was deciding to stop.
What I still needed to decide myself
As the experiments progressed, I became more comfortable delegating small parts of the work.
But I did not want the agent to have unlimited freedom simply because it had completed several tasks successfully.
The responsibility it earned was specific.
It could observe known states, investigate a local issue, make a small reversible correction, and check that the relevant behaviour still worked.
If the problem was unclear, a check failed, or the proposed change affected gameplay or the broader visual direction, the agent was expected to stop and ask.
I also learned to distinguish between different kinds of successful results.
A technical check passing was one result.
A deterministic visual comparison was another.
My approval of how the game looked and felt was something else again.
They were all useful, but they did not mean the same thing.
This made it easier to decide what I could delegate next without treating every successful task as evidence that the agent was ready for a much larger one.
Still an experiment
One Shot Chaos is still in development.
I have not demonstrated that an agent can independently design, build, and release a complete game. I also do not know whether the same approach would work equally well in a different project.
What I have seen is that autonomy can grow through small, verifiable steps.
The agent first needed a reliable way to observe the result of its work. Then it could make a limited correction and check it. Only after that did it make sense to let it choose between small alternatives.
I have started thinking about this as autonomy earned through evidence rather than granted in advance.
It has not removed my responsibility for the result. It has changed where I spend some of my attention.
I can sometimes leave a small, well-defined change to the agent and focus instead on the decisions that the available checks cannot make for me.
I am still learning where that boundary should be.