Von der Idee bis zur funktionsfähigen Software: So sollte der gesamte Entwicklungszyklus aussehen

Eine Studie von GitHub ergab, dass Entwickler, die Copilot nutzten, Aufgaben 55 % schneller erledigten als diejenigen, die darauf verzichteten. Tools wie GitHub Copilot und Cursor, die auf großen Sprachmodellen wie Claude oder GPT basieren, sollen die mühsamen Teile der Programmierung automatisieren, damit sich Entwickler auf schwierigere, kreativere Probleme konzentrieren können. Dank dieser Tools entstehen jede Woche neue Repos. Das Versprechen wird eingehalten.

Aber wo sind die Produkte?

Der Schwerpunkt hat sich vom Programmieren auf alles drum herum verlagert: den gemeinsamen Kontext, die Überprüfung, die Zusammenarbeit und eine Feedbackschleife, die dir sagt, ob das, was veröffentlicht wurde, tatsächlich funktioniert hat. 

Wie Fabien Potencier, CTPO bei Upsun und Autor der „8 Stufen der Reife im KI-Engineering“, es ausdrückt: „Es geht um die Arbeit vor dem Programmieren und die Arbeit danach.“ Kateryna Dvornichenko, die das Produkt Upsun Dispatch™ leitet, ergänzt, was das in der Praxis bedeutet: „Mehr Code zu veröffentlichen bedeutet nicht, ein besseres Produkt zu veröffentlichen.“

Wie muss also der gesamte Entwicklungslebenszyklus aussehen, um diese Lücke tatsächlich zu schließen?

Absicht vor Ergebnis

Die erste Phase des Lebenszyklus ist die, die KI komplett überspringt. Bevor ein Entwickler auch nur eine Zeile schreibt, muss jemand wissen, was entwickelt werden soll und warum. Das klingt selbstverständlich. In der Praxis überspringen die meisten Teams diesen Schritt jedoch in ihrer Eile, etwas zu erstellen.

Die Absicht ist keine Spezifikation. Sie ist die Antwort auf die Frage, ob es sich überhaupt lohnt, die Idee umzusetzen. Upsun Dispatch™ versucht letztendlich, die Zahl der gescheiterten Startups zu verringern, weil Teams früher erkennen, dass eine Idee schlecht ist, und sie verwerfen, bevor sie viel Geld dafür ausgeben, etwas zu entwickeln, das von Anfang an zum Scheitern verurteilt ist. Diese Art der Erkenntnis erfordert menschliches Urteilsvermögen und echte Nutzerforschung, keinen schnelleren Code-Generator.

Hier setzt auch das „Context Engineering“ an. Fabiens Beschreibung des „Amplifier“-Problems trifft es genau: „Wenn du eine saubere, gut getestete und gut dokumentierte Codebasis hast, ist das LLM besser. Wenn du ein schlampiges Projekt hast, das ein Chaos ist, produziert es noch mehr Chaos – und das schneller.“ 

Die Qualität der Ausgabe eines Agenten hängt vollständig davon ab, was als Eingabe dient. Schlechter Kontext, vage Absichten oder eine schwache Codebasis im Vorfeld führen zu schlechten Ergebnissen im Nachgang – und zwar schneller, als es ein menschliches Team geschafft hätte. Geschwindigkeit verstärkt das, was bereits vorhanden ist – egal ob gut oder schlecht.

Das bedeutet, dass es heute wichtiger denn je ist, die Absicht richtig zu verstehen. Das Überspringen der Erkundungs- und Spezifikationsphase spart keine Zeit. Es bedeutet nur, dass das Team später – und mit höheren Kosten – feststellt, dass es das Falsche entwickelt hat.

Individuelle Geschwindigkeit führt nicht automatisch zu Teamleistung

Die meisten aktuellen KI-Tools machen einen einzelnen Entwickler auf seinem eigenen Rechner schneller. Die Vorteile sind real. Sie bleiben aber auch auf diesem einen Laptop.

Beim Testen von Tools der Konkurrenz stellte Kateryna fest: „Der Einsatz von KI ist ein sehr einsamer Prozess, und wir sind noch nicht an dem Punkt angelangt, an dem Teams sie auf angenehme Weise nutzen können.“ 

Die Lücke in der Zusammenarbeit war bei jedem Tool vorhanden, das das Team evaluierte. Ein Entwickler richtet ein Setup ein: benutzerdefinierte Prompts, optimierte Skills, eine sorgfältig gepflegte Kontextdatei. Dieses Setup funktioniert gut für ihn, aber für niemanden sonst, weil niemand anderes es sehen kann. Wenn er das Team verlässt, ist, wie Fabien bemerkt, „alles weg“.

Das ist ein strukturelles Problem. Die Fähigkeiten, Prompts, das Agent-Speicher und der gemeinsame Kontext, die ein KI-Setup effektiv machen, sind allesamt persönlich, bis sie bewusst in eine gemeinsame Ebene verschoben werden, die das ganze Team sehen und nutzen kann. Solange das nicht geschieht, führt die individuelle Arbeitsgeschwindigkeit eher zu einem Koordinationsproblem als zu einem Produktivitätsgewinn für das Team.

Die konkreten Probleme, die auftreten, wenn KI auf einzelnen Rechnern bleibt:

• Die Rückverfolgbarkeit geht verloren. Wenn ein Mensch und mehrere Agenten jeweils über verschiedene Tools hinweg einen Teil des Codes bearbeitet haben, wird das Verständnis, wie dieser in der Produktivumgebung angekommen ist, zu einer archäologischen Aufgabe. Ein gemeinsamer, protokollierter Workflow löst dieses Problem von vornherein.
• Die Überprüfung wird zum Engpass. Wenn nur die Person, die die Agenten ausgeführt hat, den nächsten Schritt genehmigen kann, bricht der Geschwindigkeitsvorteil paralleler Agenten bereits an der ersten menschlichen Kontrollstelle zusammen. Die Überprüfung muss im Team verteilt sein und darf nicht in der Hand einer einzigen Person liegen.
• Die Kosten sind unsichtbar. Teams, die einzelne Abonnements nutzen, haben keinen Einblick darin, was die KI tatsächlich pro Feature, pro Workflow oder pro Team verbraucht. Die Rechnung kommt am Monatsende. Bis dahin sind die Entscheidungen, die dazu geführt haben, längst getroffen.

Programmieren ist immer noch die Hauptaufgabe. Nur der Autor hat gewechselt.

Die letzte und folgenreichste Phase ist die, die die meisten Teams am schlechtesten bewältigen.

• Die Verantwortung bleibt unverändert. Fabiens Formulierung ist klar: „Wenn du ein LLM bittest, eine Codezeile zu programmieren, liegt die Verantwortung nicht beim LLM. Die Verantwortung liegt bei dir.“ Symfony ist seit mehr als zwanzig Jahren wartbar geblieben, weil jede Zeile – unabhängig davon, wer sie geschrieben hat – mit diesem Verständnis überprüft wurde. Dass ein Agent den Code programmiert, ändert nichts an dieser Verpflichtung.
• Wozu dient die Überprüfung bei Änderungen? Die zeilenweise Syntaxprüfung übernimmt zunehmend ein Modell. Was ein Mensch einbringt, ist Geschmack. Wie Fabien es ausdrückt: „LLMs haben keinen Geschmack. Du bekommst etwas, das bestenfalls durchschnittlich ist. Du willst aber nichts, das nur durchschnittlich ist.“ Geschmack ist das Urteilsvermögen, das ein Programm unterscheidet, das Tests besteht, von einem Programm, das auch in zwei Jahren noch Sinn ergibt. Es kann nicht an den Agenten delegiert werden, der die Ausgabe geschrieben hat.
• Vertrauen muss man sich verdienen, es wird nicht einfach gewährt. Zu Beginn jedes Workflows gibt es bei jedem wichtigen Schritt menschliche Kontrollpunkte – nicht, weil man Agenten grundsätzlich nicht vertrauen kann, sondern weil das Vertrauen in einen bestimmten Workflow noch nicht aufgebaut ist. Wenn sich der Workflow als korrekt erweist, werden die Kontrollpunkte nach und nach aufgehoben. Die Autonomie ist real, aber sie wird durch Beweise aufgebaut und nicht durch Richtlinien aktiviert.
• „Fertig“ bedeutet, dass es funktioniert, nicht, dass es eingemergt wurde. Die Rückkopplungsschleife, die die Überprüfung abschließt, lautet nicht „der Build war erfolgreich“. Vorschauumgebungen, die auf einer produktionsähnlichen Kopie der Infrastruktur, der Dienste und der Daten laufen, verändern die Bedeutung von „fertig“. Ein Produktmanager kann prüfen, ob die Funktion seinen Vorgaben entspricht. Ein Designer kann sehen, ob die Benutzeroberfläche sinnvoll ist. Eine Verschlechterung der Performance wird vor der Produktion aufgedeckt, nicht erst bei einer Nachbetrachtung nach einem Vorfall.

Der vollständige Zyklus

Die drei oben genannten Phasen sind kein Wasserfallmodell. Sie sind voneinander abhängig. Eine klare Absicht schafft den Kontext, der die Ergebnisse der Agenten überprüfenswert macht. Eine gute Überprüfung, kombiniert mit einer Rückkopplungsschleife, die unter realen Bedingungen testet, schafft das Vertrauen, durch das sich die menschliche Aufsicht schrittweise reduzieren lässt. Jede Phase hängt von der vorherigen ab.

Die Teams, die das richtig hinbekommen, sind nicht diejenigen mit den besten Modellen oder den schnellsten einzelnen Entwicklern. Es sind diejenigen, die den gesamten Entwicklungslebenszyklus als System betrachten, in dem Entdeckung, Kontext, Zusammenarbeit, Überprüfung und eine echte Feedbackschleife alle zusammenwirken.

 Die KI hat den mittleren Teil dieses Systems beschleunigt. Der Rest erfordert nach wie vor denselben Aufwand wie zuvor.

So sieht das in der Praxis aus

Genau dieses Problem soll Upsun Dispatch™ lösen.

Anstatt Agenten auf einzelnen Laptops zu betreiben, wo ihre Ergebnisse, Kosten und der Kontext für den Rest des Teams unsichtbar sind, führt Upsun Dispatch Workflows in einer gemeinsamen Ebene aus, die das gesamte Team einsehen und steuern kann. Jede von einem Menschen oder einem Agenten durchgeführte Aktion wird protokolliert und ist nachvollziehbar. Die Kosten sind pro Workflow sichtbar, bevor ein Durchlauf beginnt – und werden nicht erst am Monatsende festgestellt.

An jedem wichtigen Schritt gibt es zu Beginn menschliche Kontrollpunkte. Sobald sich ein bestimmter Workflow als korrekt erweist, werden diese Kontrollpunkte nach und nach aufgehoben. Die Autonomie wächst durch Beweise, nicht durch Annahmen. Und wenn Upsun Dispatch zusammen mit Upsun Cloud läuft, erhält jede Änderung eine Vorschauumgebung: eine produktionsnahe Kopie der Infrastruktur, der Dienste und der Daten – sodass „fertig“ bedeutet, dass das Team sehen kann, wie es funktioniert, und nicht nur, dass der Build erfolgreich war.

Das Ergebnis ist, dass die Geschwindigkeit, die KI auf individueller Ebene erzeugt, zu etwas wird, auf dem das gesamte Team aufbauen kann. 

• Neu hier? Lies die Einführung zu Upsun Dispatch.
• Möchtest du beim Aufbau mithelfen? Bewirb dich für die Kohorte der Gründungs-Design-Partner.