From a coding buddy to a software factory

At the end of 2025 I got an opportunity to build software in a fully agentic way. The goal for the software was to support cross-sales in our group between group companies and advisors. A general look at the requirements meant it should have a lightweight CRM, lead management and a sales pipeline, and mobile apps for both iOS and Android. Initial ideas revolved around customising an existing open source solution, but the limits of this approach were found quite fast. In January 2026 I decided to do a fast tech spike with Claude just to find out what it would mean to do all this from scratch. I presented this spike to key people in the project and got extremely positive feedback and approval to go full steam on this new approach. The very first production code was committed at the end of January. And I was not ready for what was about to be built.

My little coding buddy

Agentic development started with planning. Specifications and requirements were documented. I wanted to get as much architectural design, decisions and functionalities ready as was needed to get this thing started. After a clear first iteration was documented, the work was split into manageable work chunks and coding was good to go. This all was done with the help of agents. Me, my Mac, the command line, and a couple of agents as a team ready to work. I was using an agent to design and specify the next work while a few other agents were generating code. Lovely and easy process, for a while.

Tommi & Agents

February came and we got our first development release out. First users got access to the product and feedback started coming in. At this stage I also stumbled on the first larger issue with agentic development. The quality of the generated code was not what I wanted it to be. Also the agents, being very helpful, started to steer away from the task and do things outside their assigned scope. Purely UI related changes could pull them into changing the database schema. I felt I was moved from application designer to agent nanny. This is something I needed to solve. Research on the current state of agentic orchestration revealed that there were some tools available, but all in very early stages. One of them was a concept called Ralph-loop, where the agent is given a goal and it is run in a loop until the goal is achieved. But none of these existing solutions suited this case. So I started building my own.

The art of wonder working

At the end of February I started using the tool I built, named Thau. The name comes from a short session with Claude and ChatGPT. It is a shorthand from thaumaturgy, which means the art of wonder working. This was one of the reasons I picked it. The other is that it’s quite easy to write on the command line, although pronunciation for a Finn is a bit tough.

From the start Thau allowed me to verify the quality of agentic work. Every code change went through a project-defined quality gate pipeline that included code linting and testing before it was reviewed by other agents, by human eyes (that’s me), and released. Overall, throughput and productivity were about four times higher compared to the Tommi & Agents setup, which typically produced a few approved changes a day. This also moved me from the nanny position back to a designer and planner level.

Born to be Wild / Life in the Fast Lane

March was about acceleration, and Thau enabled that. Which caused me to stumble on another issue. I could parallelise agentic code generation to a new level, so I did. When 10 agents work on 10 different things in the same code base, there will be merge conflicts. In this case more than half of what was done ended up in that situation, which in turn created more work for agents to resolve the conflicts. As I owned the tooling, I quickly added new functionality to improve work management and blast radius planning. Thau got a dedicated planner agent named Archon and an operator agent named Familiar. Familiar made sure all worker agents were working and not on a break. Archon was my interface to planning and designing the work. Agentic code review got another layer at the architectural level. This ensured that what was implemented followed the overall architectural design.

The cross-sales project had very good velocity and in June we released version 1.0. It took around 5 months from zero to release. At the same time I built and improved Thau to match the needs and wants of the project. It got a graphical UI, a few new agents, improvements to agent prompts, and limitations on what different agents can actually do. Sure, there were also bugs, like the one that caused 100 worker agents to spawn at the same time. Nothing major happened in that instance, but my Anthropic subscription’s 5-hour limit was used up instantly.

Agentic software factory and the future

If you are still reading my ramblings, thank you. I’ll share some findings from this journey. Like it says in the title, Thau turned out to be a software factory. This was by accident. I did not plan this from the start and every piece was built from necessity. If I’d known from the start what I was about to build, I probably wouldn’t have built it. For me it was always about improving quality even when throughput increased with agentic development. I also thought a lot about token efficiency, and Thau had lots of tools from the start that helped and improved agentic work without using any tokens. Observability was one of the key features for improving agent guidance and prompts in Thau, and for improving the cross-sales project documentation. I didn’t want to deliver a vibe-coded project but one that I could be proud of and return to when bug fixes or new features are needed.

What about the future of Thau? It helped to deliver a production-ready project. Will it be a part of my or Ikoni’s tooling? No, I don’t think so. In all its glory it is quite a flawed tool, mainly because of my ignorance. It was built to solve my issues on this single project, even though it has lots of things where I was thinking about other users. But this has given me some new ideas I’m trying out.

One thing is clear from this experiment. Quality from agentic development doesn’t need a factory behind it. For every project there’s a suitable pattern to work on. It might be a coding buddy, it might be a factory, it might be something in between.

Tommi Pääkkö