Wir arbeiten seit einigen Jahren mit AI. Nicht nur mit den grossen Modellen, sondern auch mit eigenen kleinen.
Angefangen hat es mit einem Object-Recognition-Modell für Apple, das wir auf 80 MB bringen mussten, um es auf ein iPhone zu bringen. Da lernt man, was jedes Megabyte und jeder Prozentpunkt kostet: Performance und Energie des iPhone. Heute bauen wir zum Beispiel ein Modell, das Firmenbeschreibungen einem Katalog von rund 900 Tätigkeiten zuordnet. Embeddings für die Vorauswahl, ein LLM für die Entscheidung, ein Feedback-Loop für die Fälle, die schiefgehen.
Bis das Modell brauchbar war, haben wir 30 bis 50 Trainingsläufe gebraucht. Jeder Lauf mit rund 50'000 Beispielen, ein bis zwei Stunden auf einer A100 oder H100. Zusammen also 40 bis 80 GPU-Stunden. In der Cloud sind das bei rund 3 Dollar pro Stunde 150 bis 250 Dollar reine Rechenzeit. Im Betrieb trainieren wir monatlich nach, das sind nochmal 12 bis 24 GPU-Stunden pro Jahr. Die Rechenzeit ist bei so einem einzigen Modell nicht das Problem.
Nur haben wir nicht immer nur ein Modell. Wir halten rund 50 solcher Micro-Modelle aktuell. Das sind 600 bis 1'200 GPU-Stunden im Jahr, immer noch überschaubar, ein paar tausend Dollar. Aber 100 Datensätze, 100 Evaluierungen pro Monat, 100 Mal die Frage, ob die neue Version wirklich besser ist als die alte. Ohne Automatisierung ist das nicht zu halten. Genau dafür haben wir NeoCoder gebaut, dazu unten mehr.
Das Problem sind die 50'000 Beispiele pro Modell. Die muss jemand sammeln, prüfen, mit synthetischen Daten und Hard Negatives erweitern und nach jedem Lauf neu bewerten. Ein Teil davon läuft über LLM-APIs, und das kostet pro Durchgang schnell einen vierstelligen Betrag. Der grössere Teil ist Arbeitszeit von Leuten, welche die 900 Kategorien verstehen.
Und jetzt rechne das hoch. Unser kleines Modell: 80 GPU-Stunden. Ein grosses offenes Modell mit 400 Milliarden Parametern: rund 30 Millionen GPU-Stunden, die Zahl hat Meta selber veröffentlicht. Faktor 400'000. Bei den Frontier-Modellen liegt man nochmal darüber.
Fakt ist: Wer selber Modelle trainiert und optimiert und nicht nur darüber liest, sieht schnell, was gerade passiert bei den KI-Unternehmen und in deren Umfeld.
Unser Modell hat eine klare Aufgabe. Man testet. Es macht Fehler. Man verbessert die Daten, trainiert nach, testet wieder. Es wird besser. Nicht perfekt, und manchmal taucht in der nächsten Runde ein Fehler wieder auf, den man schon erledigt glaubte. Aber über die Iterationen ist die Richtung eindeutig.
Genau dasselbe machen wir inzwischen mit Agenten.
Ein Agent bekommt eine Aufgabe und arbeitet. Er schreibt Code, analysiert, führt mehrere Schritte selbständig aus. Und er macht Fehler: Er vergisst Dinge. Er interpretiert Anforderungen falsch oder neu, trotz klaren Anweisungen; kleinste Fehler führen zu grossen Abweichungen. Er baut etwas doppelt, obwohl eine ähnliche Funktion schon existiert. Oder er löst das Problem technisch sauber, aber nicht so, wie es in unsere Architektur passt. Wie gesagt, trotz Guardrails.
Dann korrigieren wir. Mehr Kontext, andere Regeln, neue Tests. Die nächste Version ist besser.
Wer diesen Zyklus ein paar Mal selbst durchlaufen hat, versteht, warum gerade so viel über AGI und Superintelligenz geredet wird. Dazu weiter unten mehr. Vorher zu dem, was wir täglich sehen.
Beim Programmieren ist es schon da
Wir kommen aus der Software-Architektur. Banken, Telekommunikation, Legacy-Systeme, Systeme, die über zehn oder fünfzehn Jahre gewachsen sind. Wir haben viele grosse Systeme von innen gesehen.
Heute geben wir einem Coding Agent eine Aufgabe und haben in wenigen Minuten Code, für den ein Entwickler früher Stunden oder Tage gebraucht hat. Und wir stehen ja erst am Anfang.
Die Konsequenz ist klar: Entwicklungsteams werden kleiner. Wofür wir früher 20 Entwickler gebraucht haben, reichen bald fünf sehr gute Leute mit mehreren Agenten. Kleiner, schneller, und die Kosten pro Funktion sinken massiv. Das hält niemand mehr auf.
Aber genau daraus entsteht das nächste Problem.
Mehr Code ist nicht bessere Software
Ein Agent bekommt eine Aufgabe und löst sie. Dann die nächste. Dann noch eine. Wenn niemand auf das Gesamtsystem schaut, haben wir nach ein paar Wochen drei oder fünf ähnliche Lösungen für fast dasselbe Problem.
Duplicate Code. Ein neuer Service, obwohl es schon einen gibt. Neue Helper-Klassen, neue Abstraktionen, noch eine API, noch eine Datenstruktur.
Alles funktioniert. Aber der Codeumfang und damit die Komplexität wächst.
Heute erzeugt ein Agent in Minuten tausende Zeilen. Der Ballast fällt zunächst nicht auf, weil er nichts kostet. Er kostet erst später, wenn ihn jemand verstehen muss.
Design Patterns kann das Modell. Die Entscheidung nicht.
Ein modernes LLM kennt jedes Design Pattern. Sagen wir: hier ein Strategy Pattern, eine Factory, ein Adapter, dann implementiert es das sauber. Das ist nicht das Problem.
Die schwierige Entscheidung ist nicht, wie man ein Pattern programmiert. Sie ist: Wo brauchen wir welches Pattern, und warum? Und wenn wir uns entschieden haben: Wie stellen wir sicher, dass die Entscheidung im ganzen System eingehalten wird, nicht nur in dem Modul, das der Agent gerade sieht?
Ein Coding Agent sieht nur seine Aufgabe. Ein Architekt muss weiter sehen. Er weiss, dass wir dieses Problem vor sechs Monaten an einer anderen Stelle schon gelöst haben. Er weiss, warum eine Schnittstelle existiert. Warum bestimmte Daten nicht direkt zwischen zwei Systemen fliessen dürfen. Warum wir an einer Stelle bewusst keine neue Dependency wollen.
Und manchmal muss er sagen: Nein. Hier brauchen wir gar keinen neuen Code.
Das ist etwas völlig anderes als Code generieren.
„Dann schreiben wir eben alles neu"
Der Einwand kommt sofort: Wenn AI praktisch kostenlos programmiert, ist das doch egal. Dann schreiben wir das System neu.
An dem Gedanken ist etwas dran. AI verändert nicht nur, wie wir Software bauen, sondern auch, wie lange Software lebt. Systeme, die wir heute 15 oder 20 Jahre pflegen, ersetzen wir neu vielleicht nach fünf Jahren. Dann sind die Anforderungen anders, Technologie anders, bessere Modelle vorhanden. Also bauen wir grosse Teile neu. Wenn die Implementierung nur noch einen Bruchteil kostet, rechnet sich das.
Die Businesslogik ist noch da. Die Daten sind da. Die Schnittstellen zu anderen Systemen, Security, Performance, regulatorische Anforderungen. Und in grossen Unternehmen gibt es stets Entscheidungen, die vor zehn Jahren aus einem bestimmten Grund getroffen wurden. Und die trotz vieler Veränderungen noch immer Bestand haben. Diesen Grund findet man in keiner Java-Klasse. Ein erfahrener Spezialist kennt ihn.
Wer alles neu generiert und dieses Wissen nicht mitnimmt, bekommt sehr schnell ein neues System, das wunderschön aussieht und an der Realität vorbeigebaut ist.
Was wir daraus gemacht haben
Aus diesem Grund haben wir unser eigenes Agenten-System gebaut: «NeoCoder». Nicht weil es keine Coding Agents gäbe. Sondern weil wir wissen wollten, was das Ganze kostet.
Welcher Prompt kostet wieviel? Was kostet es, ein Repository zu indexieren? Antwort: mehr, als die meisten denken. Wo geht das Geld tatsächlich hin? Das sieht man im Detail und während der Anpassungen nur, wenn man die Pipeline selber in der Hand hat. Und der zweite Grund: Der ganze Input, der durch das System läuft, Aufgaben, Korrekturen, Reviews, ist Trainingsmaterial. Damit trainieren wir unsere eigenen kleinen Modelle. Um eben noch besser zu werden, noch bessere Predictions zu machen.
Dabei darf man eines nicht vergessen: Training braucht Hardware, und es werden viele Ressourcen verbraucht. Das ist extrem gross und teuer. Die Zahlen von oben gelten für ein Modell mit 900 Kategorien, nicht für ein Sprachmodell. Nvidia verschenkt die GPUs heute fast, zum Beispiel an OpenAI, aus eigenem Interesse. Das bleibt nicht so. Wer nicht weiss, was ihn ein Prompt, eine Indexierung oder ein Trainingslauf kostet, wird das irgendwann sehr deutlich merken.
Aus den Fehlern, die wir dabei gesehen haben, sind konkrete Regeln in NeoCoder geworden. Ein paar davon:
Ein Architekt-Agent schreibt zuerst Spezifikation und Contract. Erst dann arbeiten die Coding Agents für Backend und Frontend. Die beiden sehen sich gegenseitig nicht in den Code, sie arbeiten nur gegen den Contract. Damit ist Schluss mit „ich habe mir schnell was im anderen Modul dazugebaut".
Ein Coding Agent darf seine Aufgabe nicht selber als erledigt markieren. Er setzt „bereit für QS". Ob es fertig ist oder zurückgeht, entscheidet ausschliesslich der QS-Agent. Agenten, die sich selbst abnehmen, sind unzuverlässig. Das haben wir gelernt.
Die QS prüft zuerst deterministisch: Build, Tests, Regeln, Duplikate. Erst danach kommt das LLM zum Urteil. Das ist billiger und vor allem konsistenter.
Zwischen den Agenten wandern strukturierte Artefakte, kein Chat-Verlauf. Jede Aufgabe hält fest, was sie erzeugt und was sie konsumiert. So bleibt nachvollziehbar, woher was kommt, auch Wochen später und unabhängig von der Session.
Nichts davon ist Raketentechnik. Es ist die Arbeit eines Architekten, nur dass sie jetzt in einer Form vorliegt, mit der Agenten arbeiten können.
Wer bleibt
Wir glauben nicht an „AI ersetzt alle Entwickler". Wir glauben genauso wenig, dass alles bleibt, wie es ist.
Es werden fünf Menschen mit 20 oder 50 spezialisierten Agenten an einem System arbeiten. Aber diese fünf müssen sehr genau wissen, was sie tun und wohin sie wollen (Systemziel).
Der Architekt erklärt der AI nicht mehr, wie man eine Java-Klasse schreibt oder einen REST-Endpoint baut. Er führt das System. Er definiert Architektur und Regeln. Er entscheidet, welche Patterns wo gelten. Er sorgt dafür, dass nicht fünf Agenten fünf Lösungen für dasselbe Problem bauen. Er bringt Domainwissen in eine Form, mit der AI arbeiten kann. Und er entscheidet, wann die AI falsch liegt.
Dasselbe gilt für Spezialisten. Bauen wir ein Bankensystem, reicht es nicht, dass die AI hervorragend Java kann. Jemand muss Banking verstehen. Bei einem medizinischen System braucht es Menschen, die Medizin verstehen. Bei Telekommunikation Menschen, die diese Prozesse kennen.
AI nimmt uns enorm viel Arbeit ab. Aber sie muss wissen, in welchem Rahmen sie arbeitet. Den Rahmen setzt jemand anderes.
Der Wert verschiebt sich
Wir reden gerade viel darüber, wie gut AI programmiert. Welches Modell schreibt besseren Code, welcher Agent löst mehr Tickets, wer schafft welchen Benchmark. Interessant, aber in ein paar Jahren nicht mehr die entscheidende Frage.
Wenn jedes gute Modell hervorragenden Code schreibt, ist Code Massenware. Dann verschiebt sich der Wert: weg von der Implementierung, hin zu Architektur, Erfahrung und Domainwissen. Zu der Fähigkeit, ein komplexes Problem wirklich zu verstehen. Zu wissen, was gebaut werden muss, und was nicht. Und dafür zu sorgen, dass aus tausenden generierten Komponenten ein System entsteht, das funktioniert, verständlich bleibt und in fünf Jahren noch weiterentwickelt werden kann.
Kleinere Teams. Viel höhere Geschwindigkeit. Sehr viel mehr generierter Code. Und deutlich mehr Verantwortung bei den wenigen, die Architektur und Domain wirklich verstehen.
Und die Superintelligenz?
Zurück zum Anfang. Wie kann eine Firma sagen, sie habe Superintelligenz geschaffen, wenn wir uns nicht einig sind, was das Wort bedeutet? Wir können nicht einmal menschliche Intelligenz sauber definieren. Einzelne Fähigkeiten können wir messen: Mathematik, Programmieren, Sprache, Logik, Planung. Ein Modell ist in einzelnen Bereichen schon besser als fast jeder Mensch. Ab wann heisst das Superintelligenz?
Bei der Gravitation war es ähnlich. Menschen konnten sie beobachten und sehr genau berechnen, lange bevor jemand verstanden hat, was dahintersteckt. Wir bauen etwas, messen seine Fähigkeiten, sehen, dass es mit jeder Iteration besser wird, und verstehen noch nicht, wohin das führt.
Bis dahin sollten wir weniger darüber reden, wie viel AI produzieren kann. Und mehr darüber, wer dafür sorgt, dass daraus etwas Gutes entsteht.
Das ist kein Strategiepapier. Das sind Notizen aus der Werkstatt, von Leuten, die das jeden Tag bauen. Wer es anders sieht: gerne. Aber bitte mit eigenen Modellen, nicht mit fremden Folien.
Geschrieben von mir. Die Gedanken, die Werte, die Learnings, die Fehler: alles meins. Grammatik und Rechtschreibung korrigiert unser eigenes Twin-Modell, das auf meinen Texten trainiert ist. Manchmal bleibt ein Hüpfer drin. Das ist dann auch von mir.