I built a software factory and then gave it a project. That project turned into Rusty Kode, my experimental Rust version of Radon, a Python tool for analyzing code metrics.
I could have shown a friendly demo of the factory. I would explain the problem, create the solution, and run the tests. If everyone agreed, it would seem like a successful outcome.
But Rusty Kode isn’t as friendly as that.
Radon already has defined behaviors, command-line rules, examples, and edge cases. If my port produces different results, I can’t just rewrite the rules and call it a win.
Rusty Kode can actually challenge the factory’s output.
That’s what makes it valuable.
The word factory might give the wrong impression. It sounds like a machine just churning out applications while a person watches a dashboard, more code goes in one end and finished software comes out the other.
That is not what I built.
I wanted to explore a harder question:
How can I use AI for real software work without confusing generated output with finished work?
Rusty Kode is where the factory has to answer it.
What I mean by a software factory
I’m not aiming to define the industry-wide term here.
For this series, I want to keep my definition simple:
A software factory is a reliable way to turn an idea into a reviewed software change, supported by evidence that someone else can inspect.
The agent handles some of the work, while the factory provides the system that surrounds that work.
It’s important that the original intent remains clear. It should offer a basis for comparison and allow space for a human to reject a solution that, although complete-looking, isn’t convincing.
That last point really matters.
Code, tests, documentation, and pull requests can all tell the same story. They might also share the same mistake.
Having agreement is helpful, but it’s not the same as proof.
Why I built it
I want to use AI for more than just creating initial code drafts. I hope it assists in transforming ideas into something that others can review and understand. However, the more an AI handles, the easier it is to confuse busy activity with genuine progress.
A big change might seem impressive, a comprehensive test suite might appear thorough, and a well-polished summary can give a sense of completion. But none of these truly answer the question I care most about:
Did the software change in the way I intended, and what evidence supports that?
That’s the core question behind my work.
The aim isn’t to eliminate judgment from software development but to help clarify it. Sometimes that means approving a change, other times it means sending the work back for more adjustments. Often, the right decision isn’t even about code, it’s about asking an unanswered question that requires human insight.
And I don’t see that as a failure. A confident guess would be far more problematic.
What a full run currently costs
A full run is not a small request to one coding agent. In my current factory runs, I am seeing these approximate averages:
| Measure | Approximate average for one full run |
|---|---|
| Token use | 7 to 8 million tokens |
| Cost | A$4 to A$6 (AUD) |
These are observations from my current runs, not fixed rates or a performance benchmark. The totals can change with the work, models, and amount of iteration involved.
How Rusty Kode started
I was looking for a Python code-metrics library to improve the code-quality signals used by my AI projects.
That search led me to Radon. It measures Halstead metrics, raw metrics, and the maintainability index.
Then I had another idea:
What if I used the software factory to build an experimental Rust port of a real Python tool?
I called it Rusty Kode.
The name was playful. The experiment was not.
I could have built another small application where I controlled the requirements, implementation, and tests. That would have made a neat demonstration. It would also have made it too easy for the factory to agree with itself.
Radon gave me an external reference.
Rusty Kode does not get to invent convenient behaviour and call it compatible. Where it claims compatibility, the behaviour has to stand up to the existing tool.
That makes the project useful even when the result is wrong.
Especially when the result is wrong.
A real project creates friction
Porting a tool between languages is not a translation exercise.
Python and Rust encourage different ways of expressing the same idea. Radon’s visible behaviour may be clear in one place and less obvious in another. A passing Rust test proves only what that test checks.
The planned port spans different kinds of work: command behaviour, file handling, configuration, Python parsing, code metrics, reports, and errors.
That variety creates useful pressure:
- The goal is larger than a single pull request.
- Existing behaviour can challenge a plausible implementation.
- A test can pass at the wrong level.
- Some compatibility questions still require judgment.
- The public claim has to match what is finished today.
This is the kind of friction a prepared demo removes.
I need it to remain.
What Rusty Kode has not proved
Rusty Kode is still in its early stages and not ready for production. The current work doesn’t demonstrate that my factory can reliably build any application, nor does it prove that all runs will succeed, checks are sufficient, or that human oversight will be eliminated. It also doesn’t guarantee that the entire port will function properly.
What I can confirm is that I am using the factory to make incremental progress with Rusty Kode. Each reviewable segment offers an opportunity to compare a claim against observable behavior.
That is the evidence I have so far. The factory remains an experiment, and Rusty Kode serves as the test that keeps it honest.
What I will share
This series will focus on the problem, the experiment, the observable results, and their limitations.
I will not share the factory’s private implementation details, such as its internal architecture, orchestration, prompts, controls, or recovery logic. These specifics reflect the design choices and experiences that shaped my approach.
However, I can still offer valuable insights:
- The distinction between output and evidence.
- The importance of a real project over a mere demo.
- The necessity of keeping uncertainty visible.
- That public claims should never outpace the actual work completed.
You can grasp what I am testing without seeing the detailed blueprint.
Where the series goes next
The upcoming posts will explore what changed when I stopped viewing the coding agent as the entire system, why Rusty Kode presents a tough test, and the insights gained from the experiment so far.
I am not claiming to have a complete platform or a universal solution for software development.
I created a factory.
Then I assigned it a project designed to challenge it.
That’s when the real progress started.