Was macht einen guten AI-Workflow aus?

ai
development
german
Author

Werner Schiller

Published

October 27, 2026

There is an automated translation to english at What makes a good AI workflow? (part 1). I did not yet have time to build multilanguage support into my quarto-based blog.

Dies ist der erste Teil einer mehrteiligen Folge von Blog-Posts darüber, wie KI und agentic coding den bisherigen “optimalen Arbeitsflow” verändert bzw. ergänzt. Ich glaube, grundsätzlich hat sich nicht viel geändert. Die Details sind aber durchaus interessant und die Gewichtungen der einzelnen Abschnitte - sowohl im Aufwand als auch in der Wichtigkeit - ändern sich.

🤔 Why?

KI verändert das Denken von uns Entwicklern. Das Problem ist, dass es nur allzu einfach ist, den Verlockungen von KI nachzugeben und das, was uns an Transpiration (also harter Arbeit, d.h. das Schreiben von Code an sich) erleichtert wird, mit der Inspiration (also der Denkarbeit, die man in die Verwendung von KI steckt) gleichzusetzen - und letztere dann auch gleich der KI zu überlassen. Coding? Kann die KI. Dann also Architektur? Kann die KI auch - überraschend gut. Testing! Kann die KI, und die mühsame Plackerei ist nun endlich vorbei. Dokumentation vielleicht? Kann die KI - oftmals deutlich besser als der Mensch. Abnahmekriterien definieren. Auch das kann die KI.

Im Grunde kann die KI so ziemlich jeden Schritt der Software-Entwicklung. Sollte sie das auch? Oder trifft wieder der klassische Spruch “Just because you could doesn’t mean you should.” zu?

Ich selbst bin eigentlich der Meinung, dass die KI tatsächlich so viel wie möglich übernehmen sollte. Aber - mit einem Aber.

👨‍🏭 How?

Die Frage ist - was kann der Mensch, was die KI (noch?) nicht kann?

Die Antwort ist einfach: Regeln brechen. Auch die eigenen. Widersprechen und generell einfach alles in Frage stellen.

Ich bin auch recht überzeugt davon, dass die KI das noch lange nicht können wird, weil der KI der Antrieb fehlt - die Motivation - der Widerspruchsgeist.

KI hingegen kann sehr gut Regeln befolgen. Darauf wurde sie trainiert. KI kann außerdem super gut programmieren - als eines der wenigen Dinge, wo beim Training die Verifikation des Ergebnisses absolut automatisierbar ist, ist Programmieren an sich auch eines der ersten Dinge, welche die KI mehr oder minder perfektionieren wird.

Wie können wir nun also diese Umstände für uns nutzen und so anwenden, dass wir das Maximum an Produktivität herausholen?

Selbst bei einem perfekten Workflow brauchen wir also einen human-in-the-loop. Aber - und das ist die entscheidende Frage - wo? Wo ist der Sweet Spot, was muss man alles berücksichtigen?

Psychologie spielt auch eine Rolle - wenn ein Mensch nur alle halbe bis ganze Stunde ein paar Fragen gestellt bekommt, wird er sich sicher nicht so sehr mit der Thematik und dem Problem auseinandersetzen, wie wenn er diese Stunde daran gearbeitet hätte. Noch dazu, wenn - um die Zeit sinnvoll zu nutzen, während die KI im Hintergrund arbeitet - diese Fragen dann aus unterschiedlichsten Projekten kommen und damit einen völlig anderen Kontext haben. Auf diese Fragen habe ich auch keine Antwort, aber ich werde versuchen, ein paar eher technische Umstände zu beleuchten.

Noch ein Problem ist die Geschwindigkeit, mit der sich die KI-Welt gerade dreht. Ein Beispiel: Kaum hatte ich einen recht zufriedenstellenden Workflow (hier und hier und hier), der ziemlich zuverlässig funktioniert (wobei die Modell-Auswahl permanent angepasst werden muss, aber auch das habe ich in der Zwischenzeit gelöst - dazu gibt’s später vermutlich auch einen Post) - da bringt TypeSafe AI Jev heraus.

Mit Jev - oder generell mit Decision-Models - eröffnen sich ganz neue Möglichkeiten für Workflows. Ich plane demnächst, meinen Workflow neu zu überarbeiten, dabei Jev oder ein ähnliches Decision-Model zu verwenden. Darüber wird es dann auch wieder einen Post geben.

Oder LiteLLM - das ich für Routing1 verwende - und das gefühlt jede Woche ein neues, großes Feature einbaut, das eigentlich der Erforschung und des Einsatzes bedarf. Immerhin mache ich das Ganze nicht nur zum Spaß, sondern auch um mein Skillset zu erweitern.

Wir sind im KI-Tooling noch lange nicht am Ende, und daher ist es wichtig, sich grundsätzliche Gedanken zu machen - natürlich geht das nur mit dem Wissen, das wir jetzt haben, aber wenn wir akzeptieren können, dass sich unsere heutige Sichtweise bald wieder ändern kann, können wir schon ein paar Meter machen.

🚧 Execution

Überlegen wir uns das Thema systematisch, so müssen wir zuerst ein paar Fragen beantworten:

  1. Welche Stellen/Vorgänge in der Entwicklung können wir überhaupt identifizieren?
  2. An welcher Stelle müssen wir den Menschen MINDESTENS einsetzen?
  3. An welcher Stelle müssen wir die KI MINDESTENS einsetzen?
  4. Welche Stellen können wir identifizieren, wo es egal ist, ob der Mensch oder die Maschine es macht?

Danach können wir die Antworten von 2-4 in die Antwort von 1 einsetzen und haben zumindest schon mal eine erste Annäherung.

Welche Stellen/Vorgänge in der Entwicklung können wir identifizieren?

Ansätze der Beantwortung dieser Frage haben wir in der klassischen Entwicklung eigentlich schon gesehen. Wenn es darum geht, die Anforderungen des Kunden, die oftmals schwammig, widersprüchlich und unvollständig sind, in konkrete Tasks für die Entwicklung zu übersetzen, ist das ein ähnlicher Vorgang. Nur müssen wir das nun verallgemeinern und auf den gesamten Entwicklungsprozess anwenden.

Was sind Voraussetzungen?

  • Es gibt jemanden, der weiß, was das Ergebnis des Entwicklungsprozesses sein soll
    Die Übersetzung und Vervollständigung der Kundenanforderung wurde bereits durchgeführt und ein Pflichtenheft - in welcher Form auch immer - wurde erarbeitet.

  • Es gibt eine Mensch-Maschine-Schnittstelle, welche die Übersetzung des Pflichtenhefts in konkrete technische Teile durchführen kann
    Das o. a. Pflichtenheft muss in konkrete technische Schritte übersetzt werden können. Meiner Meinung nach ist das auch noch die Aufgabe eines Menschen, weil dieser Schritt ganz besonders anfällig dafür ist, implizite Voraussetzungen zu übersehen. Ich würde ihn auch logisch vom Pflichtenheft trennen, auch wenn die Verlockung groß ist, das zusammenzufassen - aber die target audience ist hier bereits eine Maschine, im Gegensatz zum Pflichtenheft, daher macht eine Trennung Sinn.

  • Es gibt einen Menschen, der beurteilen kann, ob eine Lösung gut oder schlecht ist
    Der Mensch, der für die Abnahme von Lösungsvorschlägen zuständig ist, hat die Kompetenz, das zu beurteilen.
    Das ist durchaus ein kritischer Punkt, der vielleicht von manchen überbegeisterten Vibe-Codern manchmal außer Acht gelassen wird.

  • Es gibt ein flexibles System, mit dem wir die konkreten Lösungen, die wir finden, technisch umsetzen können
    Ein oder mehrere AI-Harnesses mit Breakpoints (für Human Interaction), die so verknüpfbar sind, dass die Lösung, an der wir hier arbeiten, auch umsetzbar ist.
    Beispiel: Ein Harness, der ausschließlich mit Modellen eines einzigen Anbieters funktioniert, ist u. a. aus diesem Grund kein geeignetes Tool. Wir wollen die Kontrolle haben - nicht abgeben.

Versuch einer Übersicht

Diese Liste ist zum Verständnis - konkrete Arbeitsschritte folgen später und sind hier teilweise noch zusammengefasst.

Beschreibung Akteur Zusammenfassung
Vollständige Erfassung der Aufgabe Mensch Kundenanforderung erfassen und in ein Pflichtenheft übersetzen - genau wie bisher.
Analyse der Aufgabe und des Environments KI Wichtig: nicht nur die Aufgabe selbst, sondern auch Dinge wie runtime, externe requirements, etc.
Loop: Rückfragen + Beantwortung nach Analyse KI und Mensch Um Lücken zu schließen, die bei der vollständigen Erfassung der Aufgabe offengeblieben sind.
Implementierungsplan, Abnahmekriterien und Test-Plan KI und Mensch Erstellung: KI, Abnahme: Mensch
Zerteilung der Aufgabe in sinnvolle Milestones KI So klein wie möglich, aber groß genug, sodass sinnvolle e2e- oder Integrationstests machbar sind2 - Architektur-Ebene
Verifizierung der Vollständigkeit der Milestones KI oder Mensch Durchführbar von Mensch oder KI - je nachdem, wie misstrauisch oder gewissenhaft der verantwortliche Mensch ist, bzw. wie sehr man dem Modell vertraut. Grundsätzlich aber vermutlich keine schlechte Idee, hier noch mal als Mensch zu überprüfen, ob der eingeschlagene Weg der richtige ist.
Zerteilung der Milestones in implementierbare Tasks KI So groß wie möglich, sodass noch sinnvolle Unit-Tests schreibbar sind3 - Technische Planungs-Ebene
Implementierung KI Tasks der Milestones der Reihe nach durchgehen. Nach jedem Task alle Unit-Tests durchführen. Nach jedem Milestone alle implementierten Integrationstests durchführen.
Fehlerbehebung (Loop) KI, mit Eskalation Bei fehlgeschlagenen Unit- oder Integrationstests: Analyse und Fix durch die KI. Nach mehreren Fehlversuchen (oder bei verdächtigem Verhalten) Eskalation an den Menschen.
Integrationstests (Artefakt) KI und Pipeline “Gehören” den Milestones und sollen deren Funktionalität prüfen und sicherstellen.4 Daher Ausführung nach jedem Milestone.
Unit-Tests (Artefakt) KI und Pipeline “Gehören” zu den Tasks - klassische Unit-Tests
Verifikation KI KI Abnahme an definierten Punkten von umgesetzten Dingen durch die KI. Für Tasks wäre das z. B. ein klassisches Code-Review. Für Milestones eher Abnahmetests mit Funktionalitätsprüfung, Check der Abnahmekriterien, etc. - variabel je nach Größe der Aufgabe
Dokumentation (Code, Tasks, Milestones) KI Erstellung durch die KI parallel zur Implementierung - Überprüfung durch den Menschen.
Abnahme Mensch Mensch Sinnvollerweise ist das die Endabnahme und nicht bereits vorher. Kann beispielsweise ein test-deployment mit QA-Testing sein. Hier an dieser Stelle ist jedenfalls der Mensch in der Verantwortung
Release / Deployment in Produktion Pipeline, Freigabe: Mensch Nach erfolgreicher Endabnahme. Auch hier muss die Freigabe von Menschen kommen - die Verantwortung bleibt immer bei einem Menschen.

Noch ein kurzer Zwischensatz, generell zur Verwendung von KI im Entwicklungsprozess: Ich persönlich hab überhaupt nichts dagegen, KI sehr ausgiebig zu verwenden. KI kann die Produktivität enorm steigern. Aber es ist ein Werkzeug, und die Verantwortung für das Ergebnis eines Werkzeuges liegt bei dem, der es benutzt. Ein Entwickler, der anfängt seine Code-Reviews von KI-Code schlampig zu machen und dann irgendwann etwas sehr kritisches übersieht, ist definitiv verantwortlich für den Fehler, so, als hätte er ihn selbst gemacht. “Die KI hats gemacht, nicht meine Schuld!” wird eine häufige Ausrede sein, die Vorgesetzte hoffentlich sehr schnell sehr deutlich abwürgen.

Zurück zum Thema: Bleiben wir also bei meiner These aus der Einleitung: Grundsätzlich hat sich nicht viel geändert - wir übersetzen weiterhin schwammige Anforderungen in Tasks, lassen implementieren, testen und nehmen ab. Nur die Rollenverteilung ist eine andere, und genau die gilt es jetzt konkret auszuhandeln. Im zweiten Teil beantworte ich die Fragen 2-4, zeige, wo die Breakpoints für den Menschen sinnvoll liegen, und wie aus der Tabelle oben ein Workflow wird, den man tatsächlich so laufen lassen kann. Und warum “MINDESTENS” dabei das wichtigste Wort des gesamten Posts sein könnte.

Footnotes

  1. Noch ein Thema für einen Blog-Post: ein kompletter Vergleich von den bisher von mir getesteten Model-Proxies / Routern (LiteLLM, Bifrost, OmniRoute). Demnächst. Ich bin nur ein Mensch.↩︎

  2. Das ist definitiv nur eine Meinung. Man könnte auch andere Kriterien hernehmen, wichtig ist nur, dass es eine handhabbare, überschaubare aber definierte Größe ist.↩︎

  3. Das ist schwierig genug. Der Punkt ist hier wirklich der Unit-Test, womit der Task nicht wirklich sonderlich groß werden kann.↩︎

  4. Ob “Integrationstest” der korrekte Ausdruck ist, darüber kann man durchaus streiten.↩︎