Wer langsam baut, kommt schneller ans Ziel

Slow is smooth, smooth is fast

Seit LLMs plausiblen Code ausgeben, stürzt sich die Softwareindustrie in die KI-Adoption. Vorhersagen wie die von Dario Amodei („90 % des Codes wird KI schreiben“) oder Boris Chernys Aussage („Programmieren ist ein gelöstes Problem“) wurden schnell zu Memes. Doch auch wenn nun nahezu aller Code durch ein LLM geschrieben worden ist: Das Programmieren selbst ist längst nicht gelöst.

Mir kommt es so vor, als erwachen wir langsam aus der KI-Euphorie. Projekte wie OpenJDK und Zig verbieten Contributions die mittels LLMs erstellt worden sind, komplett. Das Linux-Kernel-Team hat strenge Regeln eingeführt.

Ich leite eine Software-Agentur. Das bedeutet: Ich jongliere täglich zwischen handwerklichem Anspruch und dem Zeitdruck meiner Kunden.

Im Herzen bin ich Entwickler. Ich liebe es, zu entwickeln und Dinge zu „craften“. Im Agenturalltag aber zählt Effizienz, da oft viele Kunden gleichzeitig auf Feedback warten. Das Versprechen der KI kommt da wie gerufen. Doch schnelle Lösungen ersetzen oft die wertvolle Lernerfahrung der manuellen Umsetzung und produzieren Technical Debt.

Oracle bringt es auf den Punkt: „LLMs schreiben Code und Tests, die korrekt aussehen, aber bei näherem Hinsehen schlecht gestaltet sind.“

Unsere ersten Versuche mit Cloud-basierten Coding-Agents enttäuschten uns. Die Ergebnisse waren derart schwach, dass wir den Ansatz komplett verworfen haben. Ich widersprach sogar Amodeis Behauptung, dass KI einmal 90% des Codes schreiben wird.

Diese Zahl mag für die allgemeine GitHub-Statistik nun stimmen, in echten Kundenprojekten, bei denen es wirklich auf die Qualität ankommt, sieht die Welt jedoch anders aus.

Als Unternehmer bin ich überzeugt: Die Kernfunktionen eines Unternehmens dürfen nicht ausgelagert werden. Da Coding-Agents heute wichtig sind, will ich die Technologie in-house nutzen.

Die Abhängigkeit von externen Plattformen macht uns verwundbar gegenüber Service-Änderungen oder Lock-outs. Die Fable-Posse hat gezeigt, wie schnell man abgeschnitten werden kann. Diese Erkenntnis führte mich zu lokalen Modellen. Bereits Ende 2025 merkte ich, dass lokale LLMs unterschätzt werden. Seit Mitte 2026 teste ich einen Workflow, der ausschließlich auf lokalen Modellen und den neuesten Apple Chips basiert.

Ein lokales LLM ist kleiner und langsamer als die Cloud-Modelle der großen Anbieter. Man könnte meinen, es sei weniger leistungsfähig. Das kommt darauf an. Ein kleines, spezialisiertes Modell arbeitet mit dem richtigen Kontext und Prompt ähnlich effektiv wie ein Frontier-Modell.

Der Unterschied: Der Nutzer muss wissen, welches Modell er wählt und ob die Aufgabe überhaupt lokal lösbar ist.

Ein „One-Shot-Prompt“ wie „Baue mir ein 3D-Spiel wie Die Sims – ohne Fehler!“ funktioniert lokal nicht. Frontier-Modelle sind Alleskönner; lokale Modelle sind aufgrund ihrer Größe weniger universell.

Der Verlust ist ein Gewinn

Lokale Modelle schaffen etwa 11 bis 60 Tokens pro Sekunde – Frontier-Modelle hingegen über 100.

Ich kritisiere die aktuelle Herangehensweise an die Softwareentwicklung mittels Frontier-Modelle scharf. Diese Modelle spucken Code schneller aus, als ein Mensch ihn lesen und begreifen kann. Die Flut an Code überfordert den Entwickler beim Review.

Ein Frontier-Modell erstellt in zehn Minuten hunderte Dateien. Es ist unmöglich, die Architektur-Entscheidungen in dieser Lösung enthalten sind, zu verstehen oder zu korrigieren. Das echte Code-Review verkommt zu einem floskelhaften „Looks good to me“, solange der manuelle Test funktioniert.

So schleicht sich „Slop“ (minderwertiger KI-Müll) in eine Codebase ein.

Vergleichen Sie das mit einem Workflow der auf einem lokalen LLM basiert.

Lokale Modelle erzwingen Disziplin. Da sie an die Leistungsfähigkeit der eigenen Hardware gebunden sind, können sie keine riesigen Lösungen mit nur einem Prompt ausspucken.

Aufgaben müssen klein, klar definiert und mit präzisem Kontext versehen sein. Durch diese Limitierungen erhöht sich automatisch der menschliche Einfluss im Entwicklungsprozess.

Man kann schlichtweg wieder mithalten. Aufgaben werden vor der Umsetzung gründlich geplant. Der generierte Code ist klein genug für ein ordentliches Review. Da man früher und öfter prüft, kann die Architektur noch angepasst werden. Dieser Workflow verkürzt die Implementierungszeit und schafft gleichzeitig wartbare Lösungen.

Nur noch lokale LLMs?

Nein. Frontier-LLMs haben ihren Platz. Die Rechenpower von Rechenzentren ist sinnvoll, wenn die Code-Qualität zweitrangig ist.

Für ein neues Projekt oder einen MVP, den man dem Kunden demonstrieren will, ist ein Frontier-Modell ideal. Dieser „Wegwerf-Code“ muss nicht wartbar sein. Er verkürzt die Discovery-Phase und verbessert die Kommunikation. KI liefert einen testbaren MVP in Minuten statt in Tagen. Das senkt die Time-to-Market massiv.

KI senkt die Kosten für die Erstellung von Code nahezu auf Null. Aber sie senkt nicht die Kosten für gute Architektur.

Ich glaube, dass architektonisches Denken zur wichtigsten menschlichen Fähigkeit im Software Engineering wird.

Die nächste Generation von Entwicklern wird nicht danach bemessen, wie schnell sie Code schreiben oder Edge-Cases lösen. Sie werden anhand ihrer Fähigkeiten zur Softwareplanung bemessen: Wissen, was zu bauen ist, wie das System zusammen passt, welche Trade-offs nötig sind und was in Jahren noch wartbar bleibt.