> For the complete documentation index, see [llms.txt](https://weekly-essay.mikey.wang/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://weekly-essay.mikey.wang/de/2025/w50-what-should-the-team-do-next-year-in-ai-coding.md).

# W50-Was das Team nächstes Jahr bei KI-Programmierung tun sollte

Diese Woche las ich [„State of AI“](https://openrouter.ai/state-of-ai) von a16z und OpenRouter. Die empirische Untersuchung beruht auf realen Nutzungsdaten der OpenRouter-Plattform in der Größenordnung von 100 Billionen Tokens. Schon am Anfang verlor ich kurz das Zeitgefühl: Die endgültige Version von o1 erschien am 5. Dezember 2024, also erst vor genau einem Jahr. Der Tokenanteil von Reasoning-Modellen stieg 2025 fortlaufend und liegt inzwischen über der Hälfte.

Wenn Modellfähigkeiten in den nächsten Jahren weiter wachsen, etwa bei Multimodalität, Gedächtnis und Agenten, sollte unser Kernziel nicht nur darin liegen, einige Werkzeuge einzuführen und Prompts zu sammeln. Wir brauchen eine KI-bereite technische Grundlage. Je stärker die Modelle werden, desto mehr unserer Lieferfähigkeit soll dadurch nutzbar werden.

Die folgenden fünf Bereiche erlauben dauerhafte Arbeit in der Hauptrichtung und bauen aufeinander auf.

**1) Architektur**

In einem Projekt, das sich kaum erklären lässt, kann auch KI wenig ausrichten. Es verbraucht viele Tokens, und übersehene implizite Abhängigkeiten erzeugen leicht Regressionen. Die Hauptprobleme im Frontend sind vermischte Ansicht und Geschäftslogik, verflochtene Logik und Seiteneffekte sowie mangelnde Trennung zwischen Veränderlichem und Stabilem. MVVM oder MVC allein lösen das nicht.

Ein Projekt sollte klar beantworten können, was sein Kerncode ist. Dieser trägt die gesamte Geschäftslogik und Zustandsentwicklung. Im Idealfall besteht er aus reinen Funktionen, ist unabhängig vom Framework, hat keine Umgebungsabhängigkeiten, lässt sich isoliert testen und liefert bei festen Eingaben feste Ausgaben. Der Rest behandelt Netzwerk-I/O, Seiteneffekte und UI-Rendering. So erhält KI einen stabilen Ansatzpunkt, und Änderungen werden kontrollierbarer.

**2) Kontext ausdrücklich machen**

Ohne Vorgeschichte versteht auch KI nicht, warum seltsame Hacks im Code stehen. Dokumentation und Kommentare dienen nicht mehr nur dem Bewahren von Wissen, sondern beeinflussen unmittelbar die Qualität erzeugten Codes.

Geschäftsdomäne, Architekturgrenzen, Stackpräferenzen und Engineering-Regeln sollten ausdrücklich festgehalten werden. Am besten in Formen, die KI leicht nutzen kann, etwa ADRs, Listen von Einschränkungen und unverletzliche Regeln im README. Eine passende Werkzeugkette bringt diesen Kontext zum Modell.

**3) Einschränkungen früh prüfen**

Ich halte viel davon, Probleme durch Compiler und statische Analyse früher zu erkennen. Rust ist ein bekanntes Beispiel für strenge Kompilierung. Die meisten Frontend-Szenarien brauchen aber nicht zwingend Rust, um Vorfälle zu vermeiden. Das eigentliche Problem ist, dass wir die Stärken von TypeScript nicht ausschöpfen. Um TS schneller zu verbreiten, erlaubte man historisch eine sehr lockere Nutzung. Viele Projekte aktivieren deshalb nicht alle Typ- und Compilerprüfungen.

Der strict-Modus ist eine unverhandelbare Grundlage. Bedeutungslose Typen wie any müssen entschlossen ausgeschlossen werden. Einheitliche eigene Lint-Regeln sind nötig. Mit benutzerdefinierten ESLint-Regeln können wir Architekturgrenzen erzwingen und den Stil vereinheitlichen, etwa die Composition API vorschreiben und schichtenübergreifende Abhängigkeiten verbieten.

**4) Programmatische Prüfung**

Codegenerierung wird billiger. Teuer bleibt die Prüfung, ob der Code korrekt ist. Günstige Prüfungen sollten zuerst stattfinden. Das folgt TDD und entschärft zugleich dessen bisher hohe Umsetzungskosten.

Gute Architektur macht den Kerncode klar erkennbar. Unit-Tests dafür werden dann sehr lohnend. Frontend und Backend arbeiten anhand von Verträgen zusammen. Deshalb ist eine Laufzeitprüfung von Schemas mit Zod sinnvoll. Frontend und QA kooperieren über Testfälle. Vor der Umsetzung Abnahmekriterien oder Testfälle in natürlicher Sprache zu formulieren wirkt langweilig, könnte aber sehr wirksam sein.

**5) Beobachtbarkeit und Diagnose**

Mit wachsender Organisation und feinerer Arbeitsteilung werden Reaktionen auf Kundenbeschwerden und Produktionsdiagnosen ineffizienter. Logs liegen über Dienste verstreut. Schon das Hin- und Hersammeln von Fakten in Chats kann Stunden kosten.

Wir müssen Logs und Beobachtbarkeit verbinden, damit KI vollständige Daten vor- und nachgelagerter Dienste sehen kann. Mindestens brauchen wir strukturierte Logs, einheitliches Tracing und nachvollziehbar wiederholbare zentrale Abläufe. Erst wenn die Faktensammlung automatisiert ist, können Ingenieure schneller reagieren. Das ist zugleich eine notwendige Grundlage für automatische KI-Diagnosen.