Was wir früh über KI-Entwicklung gelernt haben

Es gibt dieses Muster, das ich in Projekten immer wieder beobachte: Kunden kommen mit einer Anforderung – meist klar in der Absicht, aber selten zu Ende gedacht. Man macht Kick-offs, nimmt auf, klärt, und trotzdem bleiben Lücken. Nicht weil jemand nachlässig wäre, sondern weil viele Fragen erst dann sichtbar werden, wenn man anfängt, wirklich tief in ein Feature einzusteigen.

Ich erinnere mich an einen dieser Momente: Der Start eines wichtigen Features musste erneut verschoben werden, weil im Refinement wieder Anforderungen unklar waren. Nicht weil wir kein Anforderungsmanagement hatten – das hatten wir. Sondern weil bestimmte Fragen, Edge Cases, Abhängigkeiten erst dann auftauchten, wenn das Entwicklungsteam konkret wurde. Und dann mussten wir zurück zum Kunden, klären, warten, von vorne.

Ich habe das nicht als Versagen gesehen, sondern als ein strukturelles Problem – und angefangen, darüber nachzudenken, wie sich dieser Loop verkürzen ließe. Nicht durch mehr Meetings, sondern durch bessere Vorbereitung.

Die Idee, die alles verändert hat: KI stellt die besseren Fragen.

Mein erster Ansatz war unspektakulär: Ich habe begonnen, KI für Featurebeschreibungen zu nutzen. Anfangs mit ungenauen Eingaben und entsprechend ungenauen Ergebnissen. Mit der Zeit wurden die Prompts präziser, das Ergebnis besser – bis ich schließlich einen eigenen Skill aufgesetzt habe, der genau das tut, was ich brauchte: Ich gebe eine kurze Beschreibung des Features rein, die Anforderungen die ich kenne – und bekomme Fragen zurück.

Der Ansatz dahinter heißt „grillme“ – ursprünglich aus der Prompting-Community – und beschreibt genau das: KI nicht als Antwortmaschine nutzen, sondern als kritischen Gegenüber, der Lücken aufdeckt, bevor sie zum Problem werden.

Was mich nach wie vor überrascht, ist die Qualität dieser Rückfragen. Edge Cases, die niemand auf dem Schirm hatte. Abhängigkeiten, die erst durch die Fragen sichtbar wurden. Formulierungen, die zeigen, wo eine Anforderung noch nicht zu Ende gedacht ist. Plötzlich stellen wir Kunden Fragen, auf die sie selbst nicht gekommen wären – und die Anforderungsqualität steigt erheblich.

Der Zeitgewinn entsteht nicht beim Schreiben von Code. Er entsteht dadurch, dass das Entwicklungsteam im Refinement mit einem vollständigen Bild arbeiten kann, statt Lücken erst im Gespräch zu entdecken. Unser Prinzip seither: Je mehr Klarheit in die Vorbereitung fließt, desto schneller und sicherer läuft die Umsetzung.

Die Qualität der Aufgabe entscheidet – nicht das Modell.

Eines der frühesten und hartnäckigsten Missverständnisse beim Einstieg in KI-Entwicklung: dass das Modell selbst der entscheidende Hebel ist. In der Praxis ist es das nicht. Was zählt, ist die Qualität der Eingabe.

Wer einer KI eine vage Anforderung gibt, bekommt eine vage Antwort zurück – schnell und überzeugend formuliert, aber inhaltlich unzuverlässig. Wer strukturierte, vollständige Inputs liefert, bekommt verwertbare Outputs. Das klingt trivial, ist es aber nicht: Es erfordert eine andere Arbeitsweise. Nicht einfach schneller tippen, sondern klarer denken, bevor man überhaupt anfängt.

Das hat Konsequenzen für Teams. Der Übergang zu KI-gestützter Entwicklung ist kein Tool-Wechsel. Es ist ein Prozess-Wechsel.

Wo wir vorsichtiger geworden sind.

Ehrlichkeit gehört dazu: KI-Output ist nicht automatisch verlässlich, und es hat eine Weile gedauert, das wirklich zu verinnerlichen – nicht als abstrakte Warnung, sondern als Arbeitsprinzip.

Das Tückische ist nicht, wenn KI offensichtlich falsch liegt. Das fällt auf. Das Tückische ist, wenn KI-Output täuschend plausibel klingt, gut strukturiert ist, professionell formuliert – und trotzdem substanzielle Fehler enthält, die erst unter genauem Hinsehen sichtbar werden. Wir haben gelernt, den Prüfschritt nicht als optionale Nachkontrolle zu behandeln, sondern als festen Bestandteil jedes Outputs. Kein KI-generierter Code, kein KI-generiertes Konzept geht ohne menschliche Prüfung weiter. Die Frage ist nicht ob – sondern wie strukturiert dieser Schritt ist.

Was sich an der Arbeit wirklich verändert.

Viel wird darüber diskutiert, ob KI Entwickler ersetzt. Unsere Beobachtung ist eine andere: Die Arbeit verändert sich, sie verschwindet nicht.

Was weniger wird: repetitiver, klar abgrenzbarer Code, der nach bekannten Mustern entsteht. Was mehr wird: Anforderungen klären und schärfen, KI-Output beurteilen, Architekturentscheidungen treffen, Qualität sichern. Das verlangt nach Menschen, die verstehen, was sie beurteilen – technisches Urteilsvermögen wird nicht weniger wichtig, es verlagert sich.

Das gilt auch für die Rolle, die ich selbst in diesem Prozess spiele. Weniger Koordination von Informationsflüssen, mehr Arbeit an der Qualität der Fragestellungen, die wir an KI-Systeme stellen.

Wo wir heute stehen.

Was 2024 als Experiment begann, ist heute Arbeitsweise. KI ist in nahezu jede Phase unseres Entwicklungsprozesses eingebunden – von der ersten Anforderungsstruktur über Refinement und Tickets bis zu Code und QA. Ausschlaggebend für uns war nicht ein bestimmtes Modell oder Tool, sondern die Entscheidung, den Prozess neu zu denken – und dann konsequent zu testen, was funktioniert.

Die nächste Ausbaustufe sind für uns Agentic Workflows: KI-Systeme, die nicht nur einzelne Aufgaben übernehmen, sondern mehrstufige Prozesse eigenständig durchlaufen, prüfen und anpassen. Was das konkret bedeutet und wo wir es bereits einsetzen, erklärt unser Artikel Agentic Workflows einfach erklärt.

Das Ehrlichste, was ich nach dieser Zeit sagen kann: Es ist mehr Arbeit als erwartet – und es lohnt sich mehr als erwartet. Wer ernsthaft einsteigt, lernt schnell. Wer auf den perfekten Moment wartet, lernt gar nicht.