Wie ich arbeite

Warum das der interessanteste Teil ist

Ich bin kein Programmierer. Trotzdem sind in kurzer Zeit ein Büro, ein Chat, ein Agenten-Baukasten und eine Modell-Architektur entstanden. Das liegt nicht daran, dass KI-Werkzeuge zaubern — sie tun genau das, worum man sie bittet, und wenn man schlecht bittet, bekommt man zügig sehr viel schlechtes Ergebnis.

Was den Unterschied macht, ist die Ordnung drumherum. Der Ablauf ist bei jedem Projekt derselbe.

1. Planen — und den Plan vorlegen lassen

   Bevor eine Zeile entsteht, kommt ein Plan: Was wird geändert, welche Dateien betrifft es, wie prüfen wir hinterher, ob es funktioniert. Ich lese den Plan und nicke ihn ab. Strukturelle Eingriffe — neue Bausteine, verschobene Zuständigkeiten, gelöschte Teile — passieren nie ohne diese Zusage.

2. Entscheiden — und die Entscheidung aufschreiben

   Jedes Projekt führt ein fortlaufendes Entscheidungs-Buch. Jeder Eintrag hat eine Nummer, ein Datum, den Anlass, die Entscheidung und die Begründung. Nichts wird nachträglich geändert, es kommt nur hinten etwas dazu.

   Auch verworfene Wege stehen darin. Eine aufwendige Erweiterung der Recherche wurde nach dem Ausprobieren wieder gestrichen, weil sie bei gleichem Aufwand die gleichen Ergebnisse brachte. Ohne Eintrag hätte ich das in einem halben Jahr noch einmal gebaut.

3. Bauen — in kleinen Schritten

   Eine Etappe, ein abgeschlossener Stand, weiter. Keine Umbauten, die drei Wochen offen liegen. Zu jedem Stand gehört die Dokumentation dazu — nicht später nachgezogen, sondern im selben Zug, sonst passiert es nie.

4. Prüfen — automatisch, nicht durch Hinsehen

   Jedes Projekt hat eine Sammlung automatischer Prüfungen, die vor jedem Abschluss durchlaufen muss. Beim Office und beim Studio sind das inzwischen mehrere tausend Einzelprüfungen, beim Recherche-Teil allein rund 150.

   Jeder gefundene Fehler wird zu einer neuen Prüfung. So kann derselbe Fehler kein zweites Mal unbemerkt zurückkommen.

5. Nachsehen, ob es in echt funktioniert

   Bestandene Prüfungen sind kein Beweis. Am Ende wird der ganze Weg einmal in echt gegangen — durch die Oberfläche, wie ein Benutzer es täte. Mehr als einmal war alles grün und die Sache trotzdem kaputt.

Vier Regeln, die aus Fehlern entstanden sind

Erst die Ursache belegen, dann reparieren

Solange ich nur vermute, woran etwas liegt, gibt es keinen Reparaturvorschlag. „Wahrscheinlich" ist kein Befund. Wer bei einer Diagnose feststellt „es ist kein Speicherproblem" und im nächsten Satz „gib ihm mehr Speicher" vorschlägt, hat sich selbst widersprochen und wird die nächsten Stunden am falschen Ende suchen.

Messen statt schätzen

Als eine Recherche zu lange dauerte, war der erste Reflex, an den offensichtlichen Stellen zu drehen. Stattdessen wurde erst gemessen, wo die Zeit tatsächlich hingeht — und es war ein einzelner Prüfschritt, der über ein Fünftel der gesamten Laufzeit verbrauchte. Seitdem bringt jeder Lauf seine eigene Zeitabrechnung mit. Und was nur geschätzt ist, wird als Schätzung gekennzeichnet, nicht als Ergebnis.

Sicherheitsnetze brauchen einen Aufpasser

Ein Lauf war einmal nach 62 Sekunden „erfolgreich fertig" — mit leerem Inhalt. Ein benötigter Dienst war noch nicht bereit, und die vielen kleinen Sicherheitsnetze hatten jeden Einzelfehler brav abgefangen. Jedes für sich richtig, zusammen ein stiller Totalausfall, der sich als Erfolg meldete. Aufgefallen ist es nur am Tempo.

Die Lehre: Wer Fehler einzeln abfängt, braucht zusätzlich jemanden, der merkt, wenn alles fehlschlägt.

Wer Dateien schreibt, wird zweimal aufgerufen

Ein Programm, das eine Datei anlegt oder ändert, muss man zweimal hintereinander laufen lassen können, ohne dass sich das Ergebnis unterscheidet. Klingt banal, deckt aber eine ganze Fehlerfamilie auf: Listen, die bei jedem Lauf einen Eintrag doppeln, Leerzeilen, die wachsen. Prüfungen, die nur die Bildschirmausgabe ansehen, übersehen das vollständig — die Bilder auf diesen Seiten sind mit einem solchen Programm aufbereitet worden, und die Prüfung dazu gehört dazu.

Wo die KI steht — und wo nicht

Der Zuschnitt ist über die Zeit klarer geworden:

• Ich entscheide die Struktur. Wie ein Problem zerlegt wird, was wohin gehört, was bewusst nicht gebaut wird — das ist die eigentliche Arbeit, und sie lässt sich nicht abgeben.
• Die KI setzt um. Schnell, ausdauernd, und ohne sich über die zwanzigste Wiederholung zu beschweren.
• Ich prüfe das Ergebnis. Nicht durch Danebenstehen, sondern durch automatische Prüfungen und einen echten Durchgang.
• Bei Zahlen hat die KI nichts verloren. Fristen, Beträge, Kennzahlen setzt Programmcode wörtlich ein. Ein Sprachmodell formuliert gut — aber „ungefähr richtig" ist bei einer Frist einfach falsch.