AI-first-Softwaredesign aus ersten Prinzipien: ein Leitfaden für die Praxis

Die meisten Teams haben KI eingeführt, ohne eine einzige Annahme darunter zu überarbeiten, und deshalb wurde die Ausgabe schneller und die Systeme wurden schlechter.

Hier ist die Frage, die die meisten Entwicklungsteams noch nicht laut gesagt haben: wenn das Modell den Code schreiben kann, worin genau sollen wir jetzt gut sein?

Die Antworten, die ich höre, sind meist defensiv. Prompt-Handwerk. KI-Ausgaben prüfen. Wissen, zu welchem Werkzeug man greift. Alles echte Fähigkeiten, alle nachgelagert zur eigentlichen Verschiebung, und keine erklärt das, was ich in der Praxis immer wieder sehe: Teams, die dieselben Werkzeuge im selben Quartal mit denselben Modellen eingeführt haben und an völlig verschiedenen Orten landen. Eine Gruppe liefert schneller, und die Software hält. Die andere liefert schneller und verbringt das folgende Quartal damit, herauszufinden, was sie zerbrochen hat.

Dieselben Werkzeuge. Entgegengesetzte Ergebnisse. Dieser Unterschied liegt nicht am Modell.

Der Verstärker, den niemand eingerechnet hat

DORAs Bericht zum Stand der KI-unterstützten Softwareentwicklung 2025 hat dazu Zahlen geliefert. 90 Prozent der Fachleute in der Technologie nutzen inzwischen KI bei der Arbeit, und mehr als 80 Prozent glauben, dass sie ihre Produktivität erhöht hat. Beides ist nicht überraschend. Der Befund, der zählt, ist der dritte: eine höhere KI-Nutzung geht mit einer Zunahme des Liefer-Durchsatzes und mit einer Zunahme der Liefer-Instabilität einher, gleichzeitig.

Lesen Sie das noch einmal, denn es ist das ganze Argument. Das Werkzeug hat Teams schneller beim Ausliefern und schlechter darin gemacht, Dinge am Laufen zu halten. Nicht das eine oder das andere. Beides.

DORAs Rahmung ist, dass KI ein Verstärker ist: sie vergrößert die Praxis, auf die sie trifft. Starke Systeme werden stärker. Schwache Systeme werden schneller schwach.

Das heißt, die interessante Frage war nie „wie führen wir KI ein”. Sie war „was verstärkt KI in uns”. Und um das zu beantworten, muss man weiter zurückgehen als bis zu irgendeiner Werkzeugentscheidung.

Vom Problem her denken, nicht vom Werkzeug

Denken aus ersten Prinzipien ist eine dieser Wendungen, die in die Bedeutungslosigkeit wiederholt wurden, deshalb will ich genau sagen, was ich damit meine und was nicht.

Denken nach Analogie ist, wie die meiste KI-Einführung aussah. Wir hatten einen Entwicklungsablauf. Eine neue Fähigkeit kam. Wir fragten, wo die Fähigkeit in den Ablauf passt, fügten sie an der Stelle des geringsten Widerstands ein, meist beim Schreiben von Code, und ließen alles andere gleich. Tagesbesprechungen, Tickets, Sprints, Reviews, alles erhalten. Der Ablauf wurde als gegeben behandelt und das Werkzeug ihm angepasst.

Denken aus ersten Prinzipien stellt eine härtere Frage. Reduzieren Sie den Prozess auf das, was über das Bauen von Software tatsächlich und physisch wahr ist. Fragen Sie dann, welche dieser Wahrheiten das Modell geändert hat und welche es nicht berührt hat. Bauen Sie aus dem wieder auf, was übrig bleibt.

Tun Sie das ehrlich, und Sie finden, dass KI genau eine Sache geändert hat, und es ist nicht die, die die Kategorie verkauft.

Die Kosten für die Erzeugung von Code sind auf nahezu null gefallen. Die Kosten der Entscheidung, was der Code sein soll, haben sich nicht bewegt.

Alles Nützliche folgt aus dieser einen Asymmetrie. Unten stehen die vier Folgen, die jede Person in der Praxis aus dem Gedächtnis nennen können sollte.

Eins: das Datenmodell ist das Produkt

Der Bildschirm ist der flüchtigste Teil jeder Anwendung und der verlockendste Ort zum Anfangen, weil es der Teil ist, den man sehen kann. Er ist auch der Teil, dessen Wegwerfen am günstigsten sein sollte.

Das Datenmodell ist das Gegenteil. Es entscheidet, was Sie fragen können, was Sie indexieren können, was Sie später ändern können, ohne eine Migration, die alle erschreckt. Jede nachgelagerte Fähigkeit ist durch Entscheidungen begrenzt, die auf dieser Ebene getroffen oder improvisiert wurden.

Als Code teuer war, erzwang sich diese Reihenfolge selbst. Niemand schrieb hundert Bildschirme von Hand gegen ein Schema, über das er nicht nachgedacht hatte, weil hundert Bildschirme von Hand ein Quartal dauerten. Die Generierung hat diese natürliche Schranke entfernt. Sie können jetzt eine ganze Oberfläche gegen ein Datenmodell erzeugen, das kein Mensch je geprüft hat, und sie wird fertig aussehen.

Die Reihenfolge muss also bewusst werden. Modell zuerst, dann Vertrag, dann Oberfläche. Nicht weil es traditionell ist, sondern weil es die einzige Reihenfolge ist, in der die teuren Entscheidungen getroffen werden, solange sie günstig zu ändern sind.

Zwei: eine aufgeschobene Entscheidung wird trotzdem getroffen

Das ist die Sache, die Menschen in der Praxis unterschätzen.

Jede Entscheidung, die Sie nicht ausdrücklich treffen, wird trotzdem getroffen. Sie wird vom Generator getroffen, zum Zeitpunkt der Generierung, aus einem Kontext, der Ihr Geschäft, Ihre Konformitätsanforderungen, Ihre Migrationsgeschichte und Ihre Pläne für das nächste Quartal nicht enthält. Das Modell lehnt es nicht ab zu entscheiden. Es wählt etwas Plausibles und macht weiter.

Was darf ein Nutzer mit gekündigtem Abonnement noch sehen? Was passiert, wenn zwei Menschen denselben Datensatz bearbeiten? Ist eine E-Mail-Adresse eindeutig, und eindeutig innerhalb welcher Menge? Niemand hat diese Fragen geprompted, also hat niemand sie beantwortet, und die Anwendung hat jetzt auf alle drei eine Antwort, durch Schlussfolgerung gewählt und nur dadurch entdeckbar, dass man in der Produktion dagegen läuft.

Das ist der Mechanismus hinter dem, was Entwickler-Communities das 70-Prozent-Problem genannt haben. Der Fortschritt stockt nicht, weil die verbleibende Arbeit schwer ist, sondern weil sie von Entscheidungen blockiert wird, die mehrere hundert Generierungen früher stillschweigend getroffen wurden und nicht mehr geändert werden können, ohne das Ganze auseinanderzuziehen.

Die Praxis, die das behebt, hat jetzt einen Namen: spezifikationsgetriebene Entwicklung. Schreiben Sie zuerst die Anforderungen, die Einschränkungen und die Erfolgskriterien auf. Behandeln Sie dieses Dokument als Quelle der Wahrheit. Lassen Sie den Agenten dagegen bauen. GitHub veröffentlichte Spec Kit, AWS veröffentlichte Kiro, und die Konvergenz ist kein Zufall.

Drei: wenn Generierung gratis ist, müssen Einschränkungen aufgeschrieben werden

Jahrzehntelang wurde Korrektheit teilweise von den Kosten des Codeschreibens getragen. Eine Person, die eine Regel umsetzte, musste die Regel im Kopf halten. Stilles Wissen in einem menschlichen Kopf war ein akzeptabler Ort, um eine Einschränkung zu speichern, weil immer ein Mensch in der Schleife war.

Dieser Speicherort funktioniert nicht mehr. Wenn eine Einschränkung nicht irgendwo maschinenlesbar ausgedrückt ist (als Schema-Einschränkung, als Typ, als Validierungsregel, als Test, als ausdrückliche Zeile in einer Spezifikation), existiert sie für den Generator nicht. Sie existiert nur im Gedächtnis derjenigen Person, die gleich überrascht wird.

Das ist der praktische Kern des AI-first-Designs, und er ist unglamourös. Drücken Sie Invarianten hinunter in die Schicht, die sie durchsetzen kann. „Nicht null” und „eindeutig” in der Datenbank statt in einem Formular-Handler. Typen an den Grenzen statt in einem Codekommentar. Autorisierung als Richtlinie, die das System auswertet, statt als Bedingung, die jemand in einen Endpunkt zu schreiben gedacht hat.

Jede Einschränkung, die Sie nach außen verlagern, ist eine Entscheidung, die das Modell nicht mehr falsch treffen kann.

Vier: Sie bauen jetzt für zwei Konsumenten

Der letzte Punkt ist der neueste und derjenige, den die meisten Teams überhaupt nicht verinnerlicht haben.

Ihre Anwendung hat jetzt zwei Arten von Nutzern. Der eine ist ein Mensch, der auf einen Bildschirm schaut. Der andere ist ein Agent, der eine API aufruft, Ihre Oberfläche nie sieht und von gutem Design nicht überzeugt werden kann. Wenn eine Fähigkeit in Ihrer Oberfläche existiert, aber nicht in Ihrer API, dann existiert sie nicht, soweit es die Wirtschaft der Agenten betrifft.

Das hat eine Entwurfsfolge: Parität ist kein wünschenswertes Extra. Alles, was ein Mensch über die Oberfläche tun kann, sollte über eine definierte, dokumentierte, auffindbare Fläche erreichbar sein. Deshalb passt auch GraphQL besser als REST für den Konsum durch Agenten: ein sich selbst beschreibendes Schema ist etwas, das eine Maschine erkunden kann, ohne dass zuerst ein Mensch Integrationsnotizen schreibt.

Bauen Sie für den Agenten, und die menschliche Oberfläche wird als Nebenwirkung einfacher. Bauen Sie nur für den Menschen, und Sie werden unter Termindruck eine API nachrüsten, was der schlechtestmögliche Zeitpunkt ist, eine zu entwerfen.

Wie es in den Daten aussieht, wenn man das überspringt

GitClear hat 623 Millionen Codeänderungen von 2023 bis 2026 analysiert, und das Bild der Pflegbarkeit passt zu allem oben Gesagten.

Gegenüber der Basislinie von 2023 sind duplizierte Codeblöcke um 81 Prozent gestiegen. Kopieren und Einfügen innerhalb eines Commits stieg von 9,4 Prozent im Jahr 2022 auf 15,7 Prozent im ersten Halbjahr 2026. Fehlerverdeckende Konstrukte sind um 47 Prozent gestiegen. Gleichzeitig sind Funktionsaufrufe über Dateigrenzen hinweg, das klarste verfügbare Signal für Wiederverwendung, um 35 Prozent gefallen, und die Refactoring-Aktivität ist von 21 Prozent der Änderungen im Jahr 2022 auf bislang 3,8 Prozent im Jahr 2026 eingebrochen.

Menschen in der Entwicklung kopieren und fügen inzwischen etwa fünfmal wahrscheinlicher ein, als dass sie refaktorieren. 2022 lief dieses Verhältnis in die andere Richtung.

Nichts davon ist ein Problem der Modellqualität. Duplikation statt Wiederverwendung, Fehlerbehandlung, die verschluckt statt sichtbar zu machen, Refactoring, das aufhört zu geschehen: das erhält man, wenn Generierung günstig ist und Struktur ausdrücklich niemandes Aufgabe. Die Ausgabe ist lokal plausibel und global unzusammenhängend, und genau dieses Fehlermuster kann ein Ablauf, der beim Bildschirm beginnt, nicht erkennen.

Wie man ab dieser Woche so arbeitet

Nichts davon erfordert eine Umstrukturierung. Es erfordert, die Reihenfolge von vier oder fünf Gewohnheiten zu ändern.

1. Schreiben Sie das Datenmodell vor dem ersten Bildschirm. Entitäten, Beziehungen, Kardinalität, was eine Zeile eindeutig macht, was beim Löschen weitergegeben wird. Eine Stunde hier ist die wirkungsvollste Stunde des Projekts, und es ist die, zu deren Überspringen die Werkzeuge aktiv einladen.
2. Machen Sie die Spezifikation zum Artefakt, das Sie prüfen, nicht das Diff. Wenn die Spezifikation richtig ist und die Generierung ihr treu folgt, ist das Prüfen tausender Zeilen generierten Codes Theater. Prüfen Sie das Dokument, das sie erzeugt hat. Streiten Sie über die Spezifikation, solange Streiten noch günstig ist.
3. Verlagern Sie jede Einschränkung nach außen, die Sie benennen können. Listen Sie vor dem Generieren die Regeln auf, die niemals verletzt werden dürfen, und legen Sie jede dorthin, wo das System sie durchsetzt. Alles, was im Gespräch bleibt, wird irgendwann von etwas verletzt, das dem Gespräch nie beigetreten ist.
4. Entwerfen Sie die API als die Produktfläche. Behandeln Sie die menschliche Oberfläche dann als einen Konsumenten davon. Das ist mehr eine Entscheidung über die Reihenfolge als eine technische, und sie spät einzuordnen macht sie teuer.
5. Messen Sie Instabilität, nicht nur Durchsatz. DORAs Befund lautet, dass Geschwindigkeit und Zerbrechlichkeit gemeinsam gestiegen sind, wenn Sie also nur Geschwindigkeit messen, sehen Sie die gute Hälfte Ihres eigenen Trends. Die Fehlerrate von Änderungen und die Zeit bis zur Wiederherstellung sind die Zahlen, die Ihnen sagen, ob der Verstärker für Sie arbeitet.

Was das kostet

Ich will bei der Abwägung offen sein, statt zu behaupten, es gäbe keine.

So zu arbeiten ist in der ersten Woche eines Projekts langsamer und in jeder Woche danach deutlich schneller. Das sind echte Kosten, im Voraus bezahlt, genau in dem Moment, in dem Schwung am wertvollsten erscheint und ein Wettbewerber etwas Sichtbares ausliefert. Es wird Sprints geben, in denen das Team, das all das übersprungen hat, wie der Gewinner aussieht.

Es ist auch nicht kostenlos an Disziplin. Einschränkungen aufzuschreiben ist weniger vergnüglich, als eine Oberfläche erscheinen zu sehen. Eine Spezifikation zu prüfen ist weniger befriedigend, als Code zu prüfen. Diese Gewohnheiten verfallen unter Termindruck, und das ist derselbe Druck, der sie wichtig macht.

Und manches davon gilt wirklich nicht. Wenn Sie dieses Wochenende eine Idee validieren und das Ergebnis wegwerfen wollen, werfen Sie es weg: für Software mit zwei Tagen Lebensdauer lohnt sich nichts vom Obigen. Das Argument hier gilt für Anwendungen, die ihre Demo überleben.

Der Teil, der nie automatisierbar war

Manche Rollen, die um die Produktion von Code gebaut sind, werden schrumpfen. Manche werden verschwinden. Etwas anderes zu behaupten hilft niemandem bei der Vorbereitung, und die Menschen, die Ihnen sagen, jede Stelle in der Entwicklung sei sicher, tun Ihnen keinen Gefallen.

Aber schauen Sie, was die Asymmetrie tatsächlich getan hat. Sie hat den Ausdruck von Entscheidungen automatisiert und die Entscheidungen selbst völlig unberührt gelassen. Was zu bauen ist. Was nicht zu bauen ist. Welche Invarianten gelten. Was das System niemals tun darf. Wo die Grenzen liegen und wer sie überschreiten darf.

Diese Arbeit war immer der schwere Teil. Sie war nur unter der Mühe des Tippens verborgen, die teuer genug war, um wie die Arbeit auszusehen.

Das Tippen war nie die Arbeit.

Weiterführende Lektüre

Die Praxis im Detail: spezifikationsgetriebene Entwicklung. Wenn Sie ein Werkzeug wählen: die besten KI-App-Builder 2026.

Häufig gestellte Fragen

Was bedeutet „AI-first-Softwaredesign”? Eine Anwendung unter der Annahme zu entwerfen, dass der meiste Code generiert statt von Hand geschrieben wird und dass manche Konsumenten Agenten statt Menschen sind. Praktisch heißt das, dass Datenmodell, Einschränkungen und API-Vertrag vorab ausdrücklich definiert werden, weil das die Entscheidungen sind, die die Generierung nicht für Sie treffen kann.

Wie unterscheidet sich AI-first-Design davon, einfach KI-Werkzeuge für Code zu nutzen? KI-Werkzeuge zu nutzen fügt einem unveränderten Ablauf eine Fähigkeit hinzu. AI-first-Design ändert die Reihenfolge der Schritte im Ablauf: Modell und Vertrag vor der Oberfläche, Spezifikation als geprüftes Artefakt, Einschränkungen in durchsetzbare Schichten gedrückt. DORAs Untersuchung von 2025 fand, dass die KI-Einführung Durchsatz und Instabilität gemeinsam erhöhte, und genau das passiert, wenn das Werkzeug sich ändert und die Praxis nicht.

Was sind die ersten Prinzipien des Softwaredesigns im KI-Zeitalter? Vier halten stand: das Datenmodell ist das Produkt und der Bildschirm eine Ansicht davon; jede Entscheidung, die Sie nicht ausdrücklich treffen, wird implizit vom Generator getroffen; Einschränkungen müssen irgendwo maschinell durchsetzbar leben statt in jemandes Kopf; und Ihre Anwendung bedient jetzt sowohl eine menschliche Oberfläche als auch eine an Agenten gerichtete API, die Parität brauchen.

Bremst diese Art zu entwerfen Teams aus? Sie zieht Arbeit nach vorn, statt sie hinzuzufügen. Die Entscheidungen, die ein Datenmodell und eine Spezifikation erfassen, trifft ohnehin jemand: entweder bewusst am Anfang oder implizit von einem Modell, das später rät. Der zweite Weg ist die Quelle der Nacharbeit, und Nacharbeit ist nicht schneller.

Ist spezifikationsgetriebene Entwicklung dasselbe wie AI-first-Design? Spezifikationsgetriebene Entwicklung ist die Praxis; AI-first-Design ist die breitere Menge architektonischer Folgen. Erstere umfasst das Schreiben der Spezifikation und das Generieren dagegen. AI-first-Design umfasst zusätzlich die Reihenfolge der Datenmodellierung, den Ort der Durchsetzung von Einschränkungen und das Entwerfen für agentische neben menschlichen Konsumenten.

Wann ist es in Ordnung, all das zu überspringen? Bei Prototypen, Demos, internen Einzelstücken und allem, was Sie verwerfen wollen. Der Zusatzaufwand lohnt sich nur für Software, die echte Nutzer, echte Daten und Veränderung über die Zeit überleben muss.