Das Was, das Wie, und das agentische Dass
Alle reden darüber, dass KI inzwischen Code schreibt. Das ist beeindruckend. Es ist aber nur ein Teil von Softwareentwicklung. Bei jedem Softwareprojekt müssen drei verschiedene Fragen beantwortet werden:
- Was soll entstehen?
- Wie soll es konstruiert sein?
- Wie sorgen wir dafür, dass es tatsächlich entsteht?
Oder kürzer:
Das WAS. Das WIE. Und das DASS.
Das WAS
Das WAS beginnt bei Menschen.
Was wollen sie erreichen? Was steht ihnen dabei im Weg? Welches Problem ist wirklich vorhanden – und welches gewünschte Feature ist nur der erste spontane Lösungsvorschlag?
Hier braucht es Human Understanding und Product Thinking.
Ein Nutzer fordert vielleicht ein Dashboard, obwohl er eigentlich nur eine klare Entscheidung braucht. Ein Unternehmen will eine App, obwohl ein kleines internes Tool genügen würde. Ein Team will „etwas mit KI“, weil KI derzeit auf fast jede Frage als Antwort angeboten wird.
Das WAS zu bestimmen heißt, hinter den geäußerten Wunsch zu schauen und zu entscheiden, was tatsächlich gebaut werden sollte.
Agents können dabei Optionen durchspielen. Das Verständnis für die realen Lebenssituationen, die Ideen und die Leitplanken müssen wir selber liefern.
Das WIE
Wenn das Produkt klar ist, braucht es noch eine tragfähige Konstruktion.
Wo liegen die Systemgrenzen? Welche Daten gehören wohin? Was passiert, wenn eine API ausfällt? Wie wird die Software getestet, deployed, überwacht, aktualisiert und später von Menschen verändert, die bei ihrer Entstehung nicht dabei waren?
Das ist das WIE.
Architektur bedeutet nicht, eindrucksvolle Kästchen zu zeichnen. Sie bedeutet, Entscheidungen zu treffen, deren Folgen oft erst Monate oder Jahre später sichtbar werden.
Agents können Architekturen vorschlagen und sie mit erstaunlicher Geschwindigkeit umsetzen. Sie können aber ebenso schnell eine sauber durchgezogene Implementierung einer idiotischen Entscheidung produzieren.
Die Abwägung langfristiger Folgen und Entscheidungen müssen wir liefern. Darum ist auch die verbreitete Idee, dass heute Product Manager vibe-coden sollten, zu einfach gedacht. Pair-Vibe-Coding von Product Manager und Senior Developer trifft es schon eher.
Das agentische DASS
Dann bleibt die Arbeit, das System tatsächlich entstehen zu lassen.
Komponenten schreiben. APIs anbinden. Migrationen erstellen. Tests erzeugen. Fehler beheben. Code refaktorieren. Einen zweiten Ansatz probieren, wenn der erste nicht funktioniert.
Das ist das agentische DASS.
Coding Agents werden darin extrem gut. Sie können klare Produkt- und Architekturentscheidungen schneller in funktionierende Software verwandeln, als es ein Mensch allein durch Tippen je könnte.
Das ist keine kleine Veränderung. Das ist gewaltig. Aber sie macht menschliches Engineering-Urteil nicht überflüssig. Sie verstärkt seine Wirkung: Ein gut durchdachter und formulierter Wunsch kann heute noch vor dem Mittagessen zu sehr viel funktionierendem Code werden.
Der menschliche Rahmen
Für mich ist das die sinnvollste Vorstellung von Agentic Engineering:
Human Understanding und Product Thinking
↓
DAS WAS
Softwarearchitektur
↓
DAS WIE
Agentisch gesteuerte Umsetzung
↓
DAS DASS
Die agentische Ebene ist dann leistungsfähig, wenn sie in einem menschlichen Rahmen arbeitet.
Je besser das WAS und das WIE, desto nützlicher werden die Agents. Je schwächer beide sind, desto schneller produziert ein Projekt das Falsche – nur eben in erstaunlich überzeugender Form.
Damit verändert sich auch, was einen guten Engineer ausmacht.
Tippgeschwindigkeit wird unwichtiger. Ein weiteres Framework auswendig zu kennen wird unwichtiger. Entscheidend ist, von einem menschlichen Problem zu einer guten Produktentscheidung zu kommen, daraus eine tragfähige Architektur zu entwickeln und die Umsetzung anschließend in einem eng geführten agentischen Prozess zu steuern.
Genau diese Art von Engineering finde ich interessant: Nicht menschliche Kompetenz durch Agents ersetzen. Sondern Agents nutzen, um menschlichem Verständnis, menschlicher Kreativität und menschlicher Erfahrung die Siebenmeilenstiefel anzuziehen.