We have been working with AI for several years. Not only with the large models, but with our own small ones too.
It started with an object-recognition model for Apple that we had to get down to 80 MB to get it onto an iPhone. That is how you learn what every megabyte and every percentage point costs: performance and energy of the iPhone. Today we build, for example, a model that maps company descriptions to a catalogue of around 900 activities. Embeddings for the shortlist, an LLM for the decision, a feedback loop for the cases that go wrong.
Until the model was usable we needed 30 to 50 training runs. Each run with around 50,000 examples, one to two hours on an A100 or H100. Together that is 40 to 80 GPU hours. In the cloud, at around 3 dollars an hour, that is 150 to 250 dollars of raw compute. In production we retrain monthly, another 12 to 24 GPU hours a year. For a single model like this, compute is not the problem.
Only we do not always have just one model. We currently keep around 50 of these micro-models. That is 600 to 1,200 GPU hours a year, still manageable, a few thousand dollars. But 100 datasets, 100 evaluations a month, 100 times the question whether the new version is really better than the old one. Without automation that is not sustainable. That is exactly why we built NeoCoder, more on that below.
The problem is the 50,000 examples per model. Someone has to collect them, check them, expand them with synthetic data and hard negatives, and re-evaluate them after every run. Part of that runs through LLM APIs, and that quickly costs a four-figure amount per pass. The larger part is the time of people who understand the 900 categories.
Now scale it up. Our small model: 80 GPU hours. A large open model with 400 billion parameters: around 30 million GPU hours, Meta published that number itself. Factor 400,000. Frontier models sit even higher.
Fact is: anyone who trains and optimises models themselves, and does not just read about it, sees quickly what is happening at the AI companies and around them.
Our model has a clear task. You test. It makes mistakes. You improve the data, retrain, test again. It gets better. Not perfect, and sometimes a mistake you thought was gone comes back in the next round. But across iterations the direction is unambiguous.
We now do exactly the same thing with agents.
An agent gets a task and works. It writes code, analyses, runs several steps on its own. And it makes mistakes: it forgets things. It misreads requirements or reinterprets them, despite clear instructions; the smallest mistakes lead to large deviations. It builds something twice even though a similar function already exists. Or it solves the problem cleanly in technical terms, but not in a way that fits our architecture. As I said, despite guardrails.
Then we correct. More context, different rules, new tests. The next version is better.
Anyone who has been through this cycle a few times themselves understands why there is so much talk about AGI and superintelligence. More on that further down. First, what we see every day.
In programming, it is already here
We come from software architecture. Banks, telecoms, legacy systems, systems that have grown over ten or fifteen years. We have seen many large systems from the inside.
Today we give a coding agent a task and have, in a few minutes, code that used to take a developer hours or days. And we are only at the beginning.
The consequence is clear: development teams will get smaller. Where we used to need 20 developers, five very good people with several agents will soon be enough. Smaller, faster, and the cost per feature drops massively. Nobody is stopping that.
But that is exactly where the next problem comes from.
More code is not better software
An agent gets a task and solves it. Then the next. Then another. If nobody is looking at the whole system, after a few weeks we have three or five similar solutions for almost the same problem.
Duplicate code. A new service even though one already exists. New helper classes, new abstractions, another API, another data structure.
Everything works. But the amount of code grows, and with it the complexity.
Today an agent produces thousands of lines in minutes. The ballast does not show at first, because it costs nothing. It costs later, when someone has to understand it.
The model knows design patterns. Not the decision.
A modern LLM knows every design pattern. Say: a strategy pattern here, a factory, an adapter, it implements it cleanly. That is not the problem.
The hard decision is not how to code a pattern. It is: where do we need which pattern, and why? And once we have decided: how do we make sure the decision is kept across the whole system, not only in the module the agent currently sees?
A coding agent sees only its task. An architect has to see further. He knows we already solved this problem six months ago somewhere else. He knows why an interface exists. Why certain data must not flow directly between two systems. Why we deliberately do not want a new dependency in one place.
And sometimes he has to say: no. We do not need any new code here.
That is something entirely different from generating code.
“Then we just rewrite everything”
The objection comes immediately: if AI programmes almost for free, it does not matter. Then we rewrite the system.
There is something to that. AI does not only change how we build software, but also how long software lives. Systems we currently maintain for 15 or 20 years we may replace after five years. By then the requirements are different, the technology is different, better models are available. So we rebuild large parts. If implementation costs only a fraction, that pays off.
The business logic is still there. The data is there. The interfaces to other systems, security, performance, regulatory requirements. And in large companies there are always decisions made ten years ago for a specific reason. Decisions that still stand despite many changes. You will not find that reason in any Java class. An experienced specialist knows it.
Anyone who regenerates everything and does not take that knowledge along very quickly gets a new system that looks beautiful and is built past reality.
What we built from this
That is why we built our own agent system: "NeoCoder". Not because there are no coding agents. But because we wanted to know what the whole thing costs.
Which prompt costs how much? What does it cost to index a repository? Answer: more than most people think. Where does the money actually go? You only see that in detail, and while adjusting, if you hold the pipeline yourself. And the second reason: all the input that runs through the system, tasks, corrections, reviews, is training material. We use it to train our own small models. To get even better, to make even better predictions.
One thing must not be forgotten: training needs hardware, and it consumes a lot of resources. That is extremely large and expensive. The numbers above are for a model with 900 categories, not a language model. Nvidia almost gives GPUs away today, to OpenAI for example, in its own interest. That will not last. Anyone who does not know what a prompt, an index run or a training run costs will notice it very clearly at some point.
From the mistakes we saw, concrete rules in NeoCoder followed. A few of them:
An architect agent first writes the specification and the contract. Only then do the coding agents work on backend and frontend. The two do not see each other’s code; they only work against the contract. That ends “I quickly added something in the other module”.
A coding agent may not mark its own task as done. It sets “ready for QA”. Whether it is finished or goes back is decided only by the QA agent. Agents that sign off on themselves are unreliable. We learned that.
QA checks deterministically first: build, tests, rules, duplicates. Only then does the LLM judge. That is cheaper and, above all, more consistent.
Structured artefacts move between agents, not a chat history. Every task records what it produces and what it consumes. That keeps the origin traceable, weeks later and independent of the session.
None of this is rocket science. It is the work of an architect, only now in a form that agents can work with.
Who stays
We do not believe “AI replaces all developers”. We equally do not believe that everything stays as it is.
Five people will work on a system with 20 or 50 specialised agents. But those five have to know very precisely what they are doing and where they want to go (the system goal).
The architect no longer explains to the AI how to write a Java class or build a REST endpoint. He runs the system. He defines architecture and rules. He decides which patterns apply where. He makes sure five agents do not build five solutions for the same problem. He puts domain knowledge into a form AI can work with. And he decides when the AI is wrong.
The same applies to specialists. If we build a banking system, it is not enough that the AI is excellent at Java. Someone has to understand banking. A medical system needs people who understand medicine. Telecoms needs people who know those processes.
AI takes an enormous amount of work off our hands. But it has to know the frame it is working in. Someone else sets the frame.
Value is moving
We currently talk a lot about how well AI programmes. Which model writes better code, which agent closes more tickets, who hits which benchmark. Interesting, but in a few years no longer the decisive question.
When every good model writes excellent code, code is a commodity. Then value moves: away from implementation, toward architecture, experience and domain knowledge. Toward the ability to really understand a complex problem. To know what must be built, and what must not. And to make sure that thousands of generated components become a system that works, stays intelligible, and can still be developed in five years.
Smaller teams. Much higher speed. Far more generated code. And clearly more responsibility with the few who really understand architecture and domain.
And superintelligence?
Back to the beginning. How can a company say it has created superintelligence when we are not agreed on what the word means? We cannot even define human intelligence cleanly. We can measure individual abilities: mathematics, programming, language, logic, planning. A model is already better than almost any human in individual areas. From when is that superintelligence?
Gravity was similar. People could observe it and calculate it very precisely long before anyone understood what was behind it. We build something, measure its abilities, see that it gets better with every iteration, and do not yet understand where that leads.
Until then we should talk less about how much AI can produce. And more about who makes sure that something good comes of it.
This is not a strategy paper. These are notes from the workshop, from people who build this every day. If you see it differently: welcome. But please with your own models, not with someone else’s slides.
Written by me. The thoughts, the values, the learnings, the mistakes: all mine. Grammar and spelling are corrected by our own twin model, trained on my texts. Sometimes a stumble stays in. That is mine too.