About two years ago, simply being able to prompt ChatGPT felt extraordinary. You could describe a problem and get code back. That alone changed how I thought about software development.

In early 2025, I started using aider.chat. This small command-line tool was my first experience with an AI that could write and modify code directly in my project.

Then came Claude Code and Codex. These tools could contribute meaningfully to development. But the next important step was access to other tools and interfaces, including MCP servers. The possibilities expanded beyond editing code: an agent could interact with more of the environment around a project.

For me, that was when automating an entire development loop started to feel realistic.

Closing the loop

Some of the first useful loops were relatively simple: check production logs for errors, investigate a problem, and prepare a fix as a pull request. A developer could then review it.

But that review can also be supported—and increasingly performed—by AI. With the right instructions and a sufficiently capable model, the system can keep working through the process.

I initially used this cautiously. The trust wasn’t there yet. Over time, better models and practical experience have increased that trust. My view today is that model intelligence is sufficient to automate many of these processes from end to end, with a human supervising and intervening when needed.

That doesn’t mean we should let a model do everything automatically. The process remains important. A large part of the value lies in choosing the right tasks, setting priorities, and defining how results are checked. A capable model working on the wrong priorities can produce plenty of activity without much progress.

A small experiment: an autonomous browser game

To explore this, I started a simple tower-defense game in the browser. The experiment primarily tests autonomous progress: how far can a project develop if AI keeps working on it with limited human involvement?

Initially, the setup was straightforward. Every five minutes, an AI run would pick the next task from a plan file, implement it, commit and push the changes, and update the plan when needed. Each run was supposed to finish a complete task.

The first results were encouraging. Basic game elements worked, and most changes were clear improvements, although usually small ones. The overall quality was still modest, but the project kept moving.

There were also moments when I needed to intervene. At one point, the AI started inventing all kinds of UI configuration settings. I stopped that direction. My son and I also described a few game elements we wanted, and those were implemented in the next cycle.

So the project was largely autonomous, with occasional direction and corrections from us.

When the process lost momentum

By the evening, the plan file had become somewhat messy. Individual runs were making tiny changes to the codebase, and meaningful progress had slowed considerably.

I used Claude Opus to analyse the situation and improve the setup. After some adjustments to the prompting and a few other details, the system started working reasonably well again. Useful features appeared, including upgrades and a boss in level ten.

This was a useful reminder that the process itself needs attention, especially when its output stops moving the project forward.

From scheduled runs to an orchestrator

On the morning of October 10, I changed the approach more substantially. Instead of scheduled runs independently picking tasks, I put Opus in charge of planning and coordination.

It delegates work to six Haiku workers running in parallel, then checks their results and merges the changes. The workflow is now: human → Opus → six parallel Haiku workers → Opus reviews and merges.

The orchestration brings substantial speed improvements, and I’m getting fairly good results quickly. But in this setup, I have lost the autonomy of the previous loop. Faster progress and autonomous operation are separate properties of the process. I’ll try further variants, including fully autonomous ones.

It also burns through tokens much faster. The experiment is partly a test of how far I can get with a €20 subscription.

One interesting observation is that small models such as Haiku now allow almost continuous work on my €20 plan, while delivering quite decent results. The difference compared with Opus is still very noticeable: Opus gets to the essential points much faster and has a clearer overview. In this experiment, that makes it particularly valuable for planning and coordination.

You can play the version captured at the end of this article, after almost exactly one day of development. This link preserves that snapshot.

Update, October 12: Since writing this article, Alexander and I have made a few more improvements to the game. You can play the latest version here. I will continue having the AI work on the project, so this version will keep evolving.

Where I would start in a real project

I wouldn’t start a real business project with the same approach. There are plenty of smaller, valuable loops to introduce first:

• AI-assisted code reviews.
• Automated security scans with concrete improvement proposals.
• Dependency updates.
• Regular monitoring of production logs.
• Regular analysis of user feedback.
• Scans and investigations across multiple projects.

These are often important tasks that developers struggle to find time for. Work across many repositories is particularly relevant in medium-sized and larger companies, where an individual developer may find it difficult to maintain an overview.

At Jessyworks, we’ve already introduced partial automation in many cases. It has made our work considerably easier.

The opportunity also extends beyond developers. Many recurring tasks performed by other employees can be automated through similar loops. In my view, this has become much easier, and we should be actively exploring it.

What I’m watching next

The tower-defense game is still an experiment. It has shown steady improvement, periods of stagnation, and a noticeable boost after changing how the work is coordinated.

I’m convinced the industry will move in this direction. Feedback can come from all stakeholders, but a central decision-making entity needs to bring it together and decide what happens next. A human in that role is often a bottleneck.

I expect that, in the future, we’ll generally keep AI running and intervene when development starts heading in the wrong direction. I’m also confident that ready-made frameworks and process descriptions will emerge, making these workflows easier to establish.

I’m curious to see how far it goes—and how much human intervention and token usage it takes to get there. I may follow up with another update.

For me, the biggest change over these two years is that I increasingly find myself designing the development process: deciding what matters, giving the system direction, and checking whether its work produces something useful. Setting up a process that turns model capability into progress is becoming a central part of the job.

Building a useful AI workflow for your team

The most useful starting point is a recurring problem in your own team: reviews that pile up, maintenance that gets postponed, or feedback that never becomes an actionable task. My work at Jessyworks and this experiment give me practical experience with both the benefits and the points where these systems need direction.

If you want to introduce a workflow like this in your organisation, get in touch. I can help identify a valuable first loop, design the orchestration and review process, and refine it around the results your team actually needs.