Systeme im Dialog mit KI entwerfen

8 Min. Lesezeit

Der Agent ist nicht Ihre Nachtschicht

Die Werkzeuge wurden besser. Die Fantasie nicht.

Im März 2026 hatte sich KI-gestützte Entwicklung klar in einige Familien aufgespalten.

Da waren IDE-Copiloten, die dicht an der Datei blieben, Terminal-Agenten, die ein Repository untersuchen und Befehle ausführen konnten, und länger laufende Agenten, die über Branches, Tickets und Pull Requests hinweg arbeiteten. GitHub Copilot, Cursor, Windsurf, Claude Code, Aider, Cline, OpenHands und ihre Verwandten schoben alle grob in dieselbe Richtung: weniger Tipparbeit, schnelleres Feedback, breiterer Kontext, mehr Autonomie.

Dieser Teil ist real. Diese Werkzeuge können mehr Code lesen, als die meisten Menschen lesen wollen, schnell ein Feature skizzieren, Migrationen vorschlagen, Tests schreiben, alte Module erklären und jene repetitiven Änderungen abarbeiten, die früher einen ganzen Nachmittag aufgefressen haben.

Die populäre Erzählung darüber blieb trotzdem kindisch. Leute taten weiter so, als würde der richtige Prompt plus eine ausreichend lange Spezifikation einen Agenten in eine vertrauenswürdige Nachtschicht verwandeln. Das wird nicht passieren. Man delegiert keine abgeschlossene Aufgabe an einen zuverlässigen Spezialisten. Man führt ein Design-Gespräch mit einem System, das schnell, hilfreich, probabilistisch und gefährlich bereit ist, auf einer schlechten Annahme einfach weiterzubauen.

Die Fähigkeiten sind nicht verschwunden

Das ist gerade das Missverständnis mit dem größten Schadenspotenzial. Menschen sehen, dass Code schneller erscheint, und schließen daraus, dass die zugrunde liegenden Fähigkeiten obsolet seien. Sind sie nicht. Die Werkzeuge haben einen Teil manueller Arbeit entfernt. Sie haben nicht den Bedarf entfernt zu verstehen, was ein System zusammenhält.

Jemand muss immer noch über Grenzen, Zustand, Transaktionen, Fehlerbehandlung, Beobachtbarkeit, Sicherheit, Leistung, Testbarkeit und Veränderung über die Zeit nachdenken. Jemand muss immer noch wissen, warum eine saubere Demo ein verrottetes Design verdecken kann. Jemand muss immer noch bemerken, wenn der generierte Code den lokalen Prompt löst und dabei still das größere System beschädigt.

Darum holen erfahrene Entwickler deutlich mehr Hebelwirkung aus KI als unerfahrene Nutzer. Erfahrung ist nicht nur die Fähigkeit, Syntax aus dem Gedächtnis zu schreiben. Sie ist Mustererkennung, aufgebaut aus Vorfällen, Regressionen, misslungenen Deployments, hässlichen Migrationen, Race Conditions und Design-Entscheidungen, die clever wirkten, bis die Realität mit abstimmte.

Der Agent kann in einer Minute zehn Optionen erzeugen. Erfahrung sagt Ihnen, dass acht davon Fallen sind.

Im Dialog zu entwerfen ist der Punkt

Der gute Einsatz von KI-gestützter Entwicklung ist nicht: „Sag ihr, was sie bauen soll.” Der gute Einsatz ist: „Nutze den Dialog, um das Design offenzulegen.”

Ein produktives Gespräch mit einem Agenten hinterlässt Artefakte. Keine Vibes. Kein Vertrauen. Artefakte.

• Ein Glossar geschäftlicher Begriffe, damit nicht alle dasselbe Wort für fünf verschiedene Dinge benutzen.
• Ein Zustandsmodell, das gültige und ungültige Übergänge explizit macht.
• Schnittstellenverträge und Beispiel-Payloads.
• Tests, die Verhalten festschreiben, bevor die Implementierung wegdriftet.
• Einen Migrationsplan, einen Rollback-Plan und Monitoring-Prüfungen.
• Eine kurze Liste von Entscheidungen, die weiterhin einen menschlichen Verantwortlichen brauchen.

Genau diesen Teil übersehen viele, wenn sie über Prompting sprechen. Prompting ist der uninteressanteste Teil daran. Der eigentliche Gewinn liegt darin, dass man das Design aus mehreren Blickwinkeln befragen kann, ohne die alte Abschreibsteuer zu zahlen.

Man kann den Agenten bitten, den Ablauf als Zustände zu modellieren. Dann fragen, wo Zustände auslaufen. Dann fragen, welche Übergänge Transaktionen brauchen. Dann fragen, was passiert, wenn der externe Anbieter nach bereits ausgelösten Seiteneffekten ein Timeout wirft. Dann um Tests bitten, die die Invariante beweisen würden. Dann fragen, welche Teile noch unterbestimmt sind. Das ist keine Tipphilfe. Das ist beschleunigtes Systemdesign.

Wie ein guter Dialog klingt

Wenn Sie bessere Ergebnisse wollen, fragen Sie nicht zuerst nach dem polierten Feature. Fragen Sie nach Struktur.

• Modelliere diesen Ablauf als Zustände und Übergänge, bevor du Code schreibst.
• Liste die Invarianten auf. Was darf niemals passieren, selbst bei Retry oder Parallelität?
• Zeige die Fehlermodi, bevor du den Happy Path zeigst.
• Welche Annahmen in diesem Design sind geschäftliche Entscheidungen statt technischer?
• Schlage Tests vor, die eine kaputte Implementierung entlarven würden.
• Erzeuge den dünnsten vertikalen Slice, der beweist, dass das Design tragfähig ist.
• Sag mir, was du aus Repository und aktuellem Prompt immer noch nicht wissen kannst.

Diese letzte Frage ist wichtiger als die anderen. Gute Entwickler wissen, dass unbekannte Faktoren meist dort sitzen, wo der Schaden lauert. Ein Modell, das flüssig antwortet, hat immer noch keinen Kontext über Politik, versteckte Abhängigkeiten, Compliance-Regeln, Kundenverhalten, operative Schmerzen und die kleinen hässlichen Narben, die jedes echte System mit der Zeit ansammelt.

Deshalb schlägt Dialog Delegation. Ein Dialog kann Unsicherheit sichtbar machen. Delegation versteckt sie, bis die Produktion die Enthüllung übernimmt.

Und genau hier bleibt grundlegende Praxis entscheidend. Wenn Sie Tests, modularen Entwurf, Datenintegrität, Versionierung, Auslieferungsrisiken oder das Verhalten verteilter Fehler nicht verstehen, wird der Agent Sie nicht retten. Er lässt Sie nur größere Fehler mit höherer Geschwindigkeit machen.

Der Mythos von Spezifikation plus Übernachtlauf

Die Fantasie vom Übernacht-Agenten beginnt meist mit einem respektablen Instinkt. Menschen merken endlich, dass vages Prompting nutzlos ist, und entscheiden sich, eine ordentliche Spezifikation zu schreiben. Gut. Das sollten sie.

Dann machen sie den fatalen Sprung: Sobald die Spezifikation detailliert genug ist, kann der Agent allein arbeiten.

Nein. Genau dort bricht die Logik.

In Prosa geschriebene Spezifikationen sind voller Fallen:

• Geschäftsbegriffe, die geklärt wirken, bis zwei Stakeholder sie unterschiedlich definieren.
• Abläufe, die linear klingen, bis Retries, Stornierungen und partielle Fehler auftauchen.
• Sicherheits- und Compliance-Anforderungen, die nie aufgeschrieben wurden, weil „das doch jeder weiß”.
• Altlasten, die im Gedächtnis eines Senior-Entwicklers leben und sonst nirgends.
• Operative Realitäten wie Rate Limits, kaputte Daten und Support-Workarounds, die in keinem Product Brief stehen.

Die Spezifikation ist nicht nutzlos. Sie ist der Eröffnungszug.

Die Züge danach sind die entscheidenden: Sprache angreifen, Behauptungen in Tests verwandeln, Abläufe in explizite Zustände übersetzen, Schnittstellen in Beispiele übersetzen, Fehlerbehandlung in beobachtbares Verhalten übersetzen und weiter fragen, wo das Design noch auf Rätselraten beruht. Wenn der Agent hilft, das schneller zu tun, gut. Wenn Sie ihm das Dokument geben und verschwinden, automatisieren Sie keine Entwicklung. Sie automatisieren Verdrängung.

Was der Agent über Nacht tatsächlich tun kann

Nützliche autonome Arbeit gibt es. Nur nicht die magische Version.

Ein Agent kann stundenlang Alternativen erzeugen, eine Codebasis kartieren, Abhängigkeiten zusammenfassen, Tests entwerfen, Wegwerf-Spikes bauen, Schemata vergleichen oder Refactoring-Pläne zur Durchsicht vorbereiten. Das ist hervorragende Hintergrundarbeit. Sie erweitert den Möglichkeitsraum vor dem nächsten Design-Gespräch.

Was er nicht verantwortungsvoll tun kann: entscheiden, mit welchem Trade-off Ihr Geschäft leben soll.

Er kann nicht verantworten, ob Eventual Consistency für Rückerstattungen akzeptabel ist. Er kann nicht entscheiden, ob Ihr Support-Team einen manuellen Fallback überlebt. Er kann nicht ableiten, welches Kundensegment wichtiger ist, wenn zwei Abläufe kollidieren. Er kann nicht zur Verantwortung gezogen werden, wenn das Migrationsfenster zu klein und der Rollback nur Theater ist. Das sind keine Coding-Probleme. Das sind Entscheidungsprobleme.

Das Werkzeug kann helfen, sie zu rahmen. Übernehmen kann es sie nicht.

Der praktische Ablauf, der 2026 funktioniert

Ein vernünftiger Ablauf für KI-gestützte Entwicklung im Jahr 2026 sieht langweilig aus. Genau deshalb funktioniert er.

1. Mit dem kleinsten geschäftlichen Ergebnis beginnen, das relevant ist.
2. Den Dialog nutzen, um Begriffe, Zustände, Invarianten und Fehlermodi zu definieren.
3. Den Agenten nach Tests, Beispielen und einem dünnen Implementierungs-Slice fragen.
4. Die Prüfungen ausführen. Die Diffs lesen. Die Annahmen angreifen.
5. Das Design in einer weiteren kurzen Runde schärfen, statt einen noch größeren Prompt zu schreiben.
6. Die entstehenden Artefakte behalten: Tests, Diagramme, Notizen, Skripte und Entscheidungsprotokolle.

Diese Schleife passt zur tatsächlichen Werkzeuglandschaft vom März 2026. Die Modelle sind gut genug, um in jeder Runde nützlich zu sein. Sie sind nicht gut genug, um die Runden zu überspringen.

Darum sind Tests stärker als Instruktionen für KI-Coding-Agenten und Vibe Coding ist keine Software-Entwicklung beide relevant. Je besser die Modelle werden, desto teurer wird schlampiges Denken, weil die Maschine schlampiges Denken inzwischen sehr schnell in sehr viel Code verwandeln kann.

Das Missverständnis hinter dem Hype

Das ist die eigentliche Verschiebung.

Der alte Ablauf hatte lange Lücken zwischen Absicht und Feedback. Man beschrieb die Änderung, schrieb das Gerüst, durchsuchte die Codebasis, prüfte die Doku, ließ die Tests laufen, beseitigte die offensichtlichen Fehler und kam erst dann zur eigentlichen Design-Frage zurück. KI-gestützte Entwicklung komprimiert diese Lücken.

Diese Kompression ist wertvoll. Sie lässt sich aber leicht falsch lesen. Schnellere Iteration fühlt sich wie fertiges Denken an. Ist es nicht.

Die Menschen, die am meisten aus diesen Werkzeugen herausholen, versuchen nicht, dem Systemdesign zu entkommen. Sie nutzen den Dialog, um mehr davon früher und mit weniger Reibung zu machen. Sie behandeln den Agenten wie einen aggressiv schnellen Mitarbeiter, der Aufsicht braucht, nicht wie einen Ersatz für Urteilskraft.

Die Menschen, die sich daran verbrennen, jagen meist der entgegengesetzten Fantasie nach. Sie wollen den Output ohne das Handwerk. Sie wollen Systemqualität ohne Design-Disziplin. Sie wollen Wartbarkeit ohne Tests. Sie wollen verlässliche Veränderung, ohne zu verstehen, was brechen kann. KI-gestützte Entwicklung schenkt nichts davon. Sie legt vor allem offen, ob es vorher überhaupt vorhanden war.

Der harte Teil hat weiter einen Verantwortlichen

Sie brauchen weiterhin einen Menschen, der eine falsche Vereinfachung riecht, fehlende Randbedingungen erkennt und die Frage stellt, die niemand stellen wollte.

Das ist keine vorübergehende Einschränkung, die mit dem nächsten Modell-Release verschwindet. Das ist die Natur davon, Systeme in Organisationen zu bauen. Systeme leben in Budgets, Gewohnheiten, Anreizen, Kränkungen, Produktionsvorfällen und halb eingehaltenen Versprechen. Der Code ist nur eine Ebene.

Also ja: Nutzen Sie die Werkzeuge, die es im März 2026 gab. Nutzen Sie sie offensiv. Lassen Sie sie das Repository lesen, das Modul skizzieren, den Test entwerfen, das Legacy-Chaos erklären und drei Wege durch den Sumpf vorschlagen.

Verwechseln Sie nur Dialog nicht mit Delegation.

Wenn das Gespräch zu besseren Randbedingungen, besseren Tests und besseren Entscheidungen führt, ist KI-gestützte Entwicklung ein ernsthafter Vorteil. Wenn das Gespräch durch Übergabe plus Wunschdenken ersetzt wird, ist es nur teures Theater.