Also: Jedes Entwicklungswerkzeug, das ich kenne, schaut auf denselben Moment. Jetzt. Der Code, wie er heute ist. Der Build, wie er gerade läuft. Die Abhängigkeiten, wie sie heute im Graphen stehen. Ein Foto. Und ein Foto ist gut, wenn man wissen will, wie etwas aussieht. Es ist nutzlos, wenn man wissen will, wohin es sich bewegt. Software bewegt sich. Jeden Tag. Und das Werkzeug, das diese Bewegung misst, habe ich bisher nicht gefunden. Also probiere ich, eines zu bauen. Ob es geht, weiss ich noch nicht.
Das Foto
Statische Analyse, Linter, Dependency Graph, Test Coverage, Security Scan: alles Fotos. Sie sagen dir, wo es heute klemmt. Zyklomatische Komplexität dieser Klasse, Abdeckung dieses Moduls, diese Bibliothek hat eine Lücke. Gute Werkzeuge, ich nutze sie jeden Tag, und mit Agenten, die in Minuten zweitausend Zeilen schreiben, braucht man sie mehr als je zuvor.
Aber sie haben alle denselben blinden Fleck. Sie kennen keine Zeit. Ein Modul mit Komplexität 40 ist für sie ein Modul mit Komplexität 40. Ob es vor einem Jahr bei 12 war und seit fünf Wochen jede Woche schneller steigt, sehen sie nicht. Das steht nirgends. Man müsste es aus der Historie rechnen, und das tut niemand, weil kein Werkzeug dafür gebaut ist.
Der Film
Software ist ein Film. Ein Modul, das heute gesund aussieht, kann seit fünf Wochen instabiler werden, und zwar beschleunigt. Eine Domäne, die niemand auf dem Schirm hat, zieht seit Monaten immer mehr Abhängigkeiten an, jede einzelne harmlos, zusammen ein Knoten. Zwei Bereiche, die laut Architektur nichts miteinander zu tun haben, werden seit einem halben Jahr fast immer im selben Commit angefasst. Das sind keine Zustände. Das sind Bewegungen. Und Bewegungen sieht man nur, wenn man den Film anschaut, nicht das Foto.
Was der Architekt spürt
Ein erfahrener Architekt spürt das. Er sitzt seit zwei Jahren in dem Projekt, er hat die Pull Requests gesehen, und irgendwann sagt er im Stand-up: Lasst das Billing-Modul in Ruhe, das wird gerade heiss. Oder: Wenn ihr an der Adressprüfung dreht, schaut auch den Export an, das hängt bei uns immer zusammen. Er hat dafür keine Zahl. Er hat ein Gefühl aus tausend Commits. Und wenn er das Projekt verlässt, ist das Gefühl weg, und keines seiner Werkzeuge hat es gespeichert.
Ich habe das im Artikel über den Architekten geschrieben: Die schwierige Frage ist nicht, wie man ein Pattern implementiert, sondern wo man welches braucht, und wie man sicherstellt, dass die Entscheidung im ganzen System gilt. Das hier ist die Fortsetzung. Der Architekt sieht die Bewegung, weil er den Film gesehen hat. Die Frage ist, ob man diesen Film einem kleinen Modell zeigen kann.
Das Experiment
Das ist das, was wir bei NeoCoder gerade probieren, und ich schreibe es so, wie es ist: ein Experiment, kein Feature. Wir nennen es NeoTemporal, und es ist ein kleines, eigenes Modell, das nicht den Zustand eines Projekts lernen soll, sondern seine Dynamik. Das Futter dafür haben wir, weil NeoCoder als Agent die ganze Kette sieht, nicht nur den Code: Zustand, Aktion, Ergebnis, Folgezustand. Dazu Jahre von Git Historie. Aus dieser Folge soll das Modell lernen, wie sich Projekte bewegen. Welche Bereiche zusammen schwingen. Welche Rhythmen sich wiederholen. Wo Veränderung sich beschleunigt.
Und das Wichtige, weil es die Frage ist, die jeder Kunde als erstes stellt: Es lernt nicht aus dem Quelltext. Es lernt aus Strukturdaten. Welche Datei wann mit welcher zusammen geändert wurde, wie gross die Änderung war, was danach passiert ist. Kein Byte Code verlässt dafür das Haus. Das Modell ist klein genug, dass es lokal in Millisekunden läuft, so wie die fünfzig Micro Modelle, über die ich schon geschrieben habe. Klein, eine Aufgabe, und man versteht es.
Was es bringen soll, wenn es geht
Drei Dinge, und ich schreibe bei jedem „soll", weil es noch keines tut.
Der Kontext liegt bereit, bevor du fragst. Wenn das Modell sagen kann, wo die nächste Änderung wahrscheinlich landet, kann der Agent das Wissen für genau diese Bereiche vorher laden. Die erste Antwort käme schneller und kostete weniger, weil die Werkzeuge und Dateien schon da sind. Das ist dieselbe Idee wie beim MCP Artikel: nicht alles in den Kontext, sondern das Richtige.
Warnung vor dem Problem, nicht danach. „Dieses Modul ist gerade heiss, plane Puffer ein." „Auf Änderungen an X folgt in diesem Projekt fast immer eine an Y, und die ist noch offen." Das sind keine Regeln, die jemand pflegt. Das wäre gelernte Erfahrung aus dem eigenen Projekt, so wie sie der Architekt im Kopf hat, nur gespeichert.
Technische Schuld bekommt eine Flugbahn. Die statische Analyse sagt, wo es heute klemmt. Das Modell soll zeigen, was sich in Bewegung verschlechtert, bevor der Zustand kippt. Nicht „Komplexität 40", sondern „Komplexität 40, und in acht Wochen bei diesem Tempo 60".
Wenn davon eines funktioniert, hat sich das Experiment gelohnt. Wenn keines funktioniert, schreibe ich das auch. So wie beim Testdaten Prototyp, wo ich drei Fehler erst mit Abstand gesehen habe.
Die Regeln, bevor es mitspielt
Das ist der Teil, der mir wichtiger ist als die Idee. Ein Modell, das Vorhersagen über dein Projekt macht, ist gefährlich, wenn man ihm glaubt, bevor es sich bewiesen hat. Also gelten dieselben Regeln wie überall bei uns.
Es entscheidet nichts. Es schlägt vor. Das Team entscheidet. Kein Agent nimmt sich selber ab, und ein Modell, das die Zukunft rät, schon gar nicht.
Es muss eine Baseline schlagen. Die dümmste Vorhersage ist: Was zuletzt oft geändert wurde, wird wieder geändert. Das ist die statistische Baseline, und sie ist erstaunlich gut. Das Modell spielt erst mit, wenn es auf eingefrorenen Testdaten messbar besser ist, und zwar auch auf Projekten, die es nie gesehen hat. Sonst hat man nur ein teures Verfahren für „zuletzt geändert".
Jeder Trainingslauf hat ein Budget und eine Frist. Kein Run ohne Kostendeckel. Ein Watchdog, der den Pod beendet, wenn kein Lebenszeichen mehr kommt. Jeder Pod stirbt mit seinem Run. Das ist das Notfallprotokoll aus dem Artikel über die Regeln, hier in der Trainingskonsole.
Jeder Lauf ist reproduzierbar. Dataset, Code Stand, Config: die drei stehen in jeder Model Card. Wer in einem halben Jahr fragt, warum das Modell so entscheidet, kann den Lauf wiederholen.
Die Zahlen kommen, wenn es Zahlen gibt. Nicht vorher. In diesem Artikel steht deshalb keine, und der Screen oben zeigt Beispieldaten. Wenn die Messung da ist, schreibe ich sie hier dazu, mit Baseline daneben.
Was bleibt
Andere Werkzeuge beantworten die Frage: Wie sieht mein Projekt aus? Ich will die andere beantworten: Wohin entwickelt es sich? Ob ein kleines Modell das aus dem Film lernen kann, den ein Projekt über Jahre dreht, weiss ich in ein paar Wochen. Was ich jetzt schon weiss: Die Frage ist richtig. Ich habe zu viele Projekte kippen sehen, bei denen jedes Foto in Ordnung war.
Software ist ein Film, und alle Werkzeuge schauen auf ein Foto. Der Architekt sieht die Bewegung, aber er kann sie nicht zeigen, und wenn er geht, ist sie weg. Ich probiere, ob ein kleines lokales Modell diese Bewegung aus Strukturdaten lernen kann: wo es heiss wird, was zusammenhängt, was kippt. Es schlägt vor, es entscheidet nichts, und es muss eine Baseline schlagen, bevor es mitspielt. Zahlen gibt es, wenn es Zahlen gibt.
Geschrieben von mir. Die Gedanken, die Werte, die Learnings, die Fehler: alles meins. Grammatik und Rechtschreibung korrigiert ein eigenes Twin-Modell, das auf meinen Texten trainiert ist. Manchmal wird daraus ein Mix. Ich lese natürlich alles nochmal, aber niemand ist unfehlbar. Was drin bleibt, ist dann auch von mir.