Künstliche Intelligenz verändert Softwareentwicklung vor allem an einer Stelle sehr deutlich: Die Umsetzung wird schneller. Code kann in kürzerer Zeit entstehen, Tests lassen sich automatisiert erzeugen, Anforderungen strukturieren, Dokumentation ergänzen und ganze Arbeitsschritte an spezialisierte Agenten übergeben. Was bislang Stunden oder Tage beansprucht hat, kann dadurch teilweise erheblich schneller erledigt werden.
Das klingt zunächst uneingeschränkt positiv. Mehr Geschwindigkeit bedeutet allerdings nicht automatisch bessere Produktentwicklung, denn eine Organisation profitiert nur dann von zusätzlicher Umsetzungskapazität, wenn auch die übrigen Teile des Systems damit umgehen können.
Genau darin liegt eine zentrale Herausforderung. Wenn Anforderungen unklar bleiben, Prioritäten ständig wechseln, Entscheidungen lange dauern oder nach einer Auslieferung kaum überprüft wird, ob eine Änderung tatsächlich etwas verbessert hat, beschleunigt KI nicht automatisch den Fortschritt. Sie erhöht zunächst nur die Geschwindigkeit, mit der Ergebnisse produziert werden.
Im ungünstigsten Fall werden dadurch bestehende Schwächen lediglich verstärkt.
Der Engpass verschiebt sich
Über viele Jahre lag ein großer Teil der Aufmerksamkeit in der Softwareentwicklung auf der Frage, wie schneller entwickelt werden kann. Prozesse wurden optimiert, Deployments automatisiert, Entwicklungsumgebungen verbessert und Teams dabei unterstützt, mehr Arbeit in kürzerer Zeit umzusetzen.
Mit KI verändert sich diese Ausgangslage.
Wenn die eigentliche Umsetzung deutlich günstiger und schneller wird, liegt der Engpass zunehmend an anderer Stelle. Entscheidend wird dann weniger, wie schnell eine Lösung gebaut werden kann, sondern wie schnell klar wird, welche Veränderung überhaupt sinnvoll ist, wie diese sauber beschrieben werden kann und woran anschließend erkennbar wird, ob sie tatsächlich die gewünschte Wirkung erzielt.
Softwareentwicklung lässt sich deshalb weniger als lineare Produktionskette und stärker als Folge kurzer Rückkopplungsschleifen verstehen.
Genau hier setzt LoopsWork an.
Im Mittelpunkt stehen drei miteinander verbundene Loops: Build, Value und Learning. Sie bilden gemeinsam einen Kreislauf aus Umsetzung, Wirkungskontrolle und Anpassung.
Build Loop: Kleine Änderungen statt großer Aufträge
Im Build Loop wird aus einer Idee eine möglichst kleine und überprüfbare Veränderung.
Gerade bei der Zusammenarbeit mit KI ist diese Begrenzung besonders wichtig. Große, unscharfe Arbeitsaufträge benötigen viel Kontext, lassen mehr Interpretationsspielraum und erschweren anschließend die Bewertung des Ergebnisses. Kleine Specs reduzieren dagegen den notwendigen Kontext und machen klarer, was konkret erwartet wird.
Statt beispielsweise lediglich eine neue Login-Funktion zu beauftragen, beschreibt eine kleine Spec möglichst konkret, welche Endpunkte betroffen sind, welche Parameter erwartet werden, welche Fehlerfälle berücksichtigt werden müssen und anhand welcher Tests die Umsetzung überprüft wird.
Dadurch sinkt nicht nur die technische Komplexität. Auch der Kontext für KI-Agenten wird kleiner, die Ergebnisse werden nachvollziehbarer und Änderungen lassen sich leichter überprüfen oder zurücknehmen.
Mehr Umsetzungskapazität sollte deshalb nicht automatisch zu größeren Arbeitspaketen führen. Gerade das Gegenteil kann sinnvoll sein: Je günstiger Änderungen werden, desto kleiner können sie zugeschnitten werden.
Value Loop: Eine Änderung ist nicht fertig, wenn sie ausgeliefert wurde
Eine der größten Schwächen klassischer Entwicklungsprozesse liegt häufig darin, dass Arbeit mit der technischen Fertigstellung endet.
Ein Ticket wird geschlossen, ein Feature ausgeliefert und das Team beginnt mit dem nächsten Thema. Ob die Änderung anschließend tatsächlich die erwartete Wirkung erzeugt, bleibt oft deutlich weniger sichtbar.
Mit zunehmender Entwicklungsgeschwindigkeit wird dieses Problem größer.
Wenn innerhalb kurzer Zeit deutlich mehr Änderungen ausgeliefert werden können, steigt gleichzeitig die Gefahr, dass zwar viel Output entsteht, aber kaum noch verstanden wird, welche dieser Änderungen tatsächlich einen Nutzen erzeugen.
Der Value Loop setzt deshalb unmittelbar nach der Umsetzung an. Für relevante Änderungen sollte bereits vorher feststehen, welche Wirkung erwartet wird und wie diese beobachtet werden kann.
Eine einfache Scorecard kann beispielsweise festhalten, welche Veränderung erwartet wird, welche Kennzahlen oder Beobachtungen darauf hinweisen, welche unerwünschten Nebenwirkungen möglich sind und wann eine Bewertung erfolgen soll.
Damit verändert sich auch die Bedeutung von „fertig“. Eine Änderung ist nicht deshalb abgeschlossen, weil sie technisch funktioniert und deployed wurde. Wirklich abgeschlossen ist der Loop erst dann, wenn nachvollziehbar geworden ist, was die Änderung bewirkt hat.
Learning Loop: Erkenntnisse müssen das System verändern
Die Bewertung einer Änderung liefert nicht immer das erwartete Ergebnis.
Vielleicht war die ursprüngliche Annahme falsch. Vielleicht war eine Spec unklar, ein wichtiger Randfall wurde übersehen oder ein Agent hatte nicht den notwendigen Kontext. Vielleicht funktioniert die technische Lösung einwandfrei, löst aber das zugrunde liegende Problem nicht.
Genau diese Erkenntnisse sind wertvoll.
Sie sollten allerdings nicht ausschließlich in Retrospektiven, Notizen oder persönlichen Erfahrungen verbleiben. Ein Learning Loop ist erst dann vollständig, wenn das Gelernte wieder in das Arbeitssystem einfließt.
Das kann bedeuten, Specs anzupassen, Tests zu ergänzen, Agentenprofile zu verändern, Prompts zu verbessern, neue Monitoring-Anforderungen aufzunehmen oder Arbeitsregeln weiterzuentwickeln.
Damit entsteht aus einer abgeschlossenen Änderung nicht einfach die nächste Aufgabe, sondern ein verbessertes System für zukünftige Aufgaben.
Klare Verantwortlichkeiten werden wichtiger
KI kann viele Aufgaben übernehmen, aber sie beseitigt keine unklaren Verantwortlichkeiten.
Wenn nicht eindeutig ist, wer eine Priorität festlegt, wer eine fachliche Entscheidung trifft oder wer beurteilt, ob ein Ergebnis ausreichend gut ist, wird ein leistungsfähiger Agent diese Lücke nicht zuverlässig schließen.
Im Gegenteil: Je größer die technische Umsetzungskapazität wird, desto wichtiger werden klare Entscheidungen.
LoopsWork trennt deshalb bewusst zwischen Unterstützung und Verantwortung.
Agenten können analysieren, programmieren, testen, dokumentieren, überwachen und Vorschläge vorbereiten. Verantwortung für Ziele, Prioritäten, Qualität, Zusammenarbeit und Entscheidungen verbleibt bei Menschen.
Diese Trennung verhindert, dass technische Automatisierung mit organisatorischer Verantwortung verwechselt wird.
Mehr Geschwindigkeit darf nicht zu mehr paralleler Arbeit führen
Eine naheliegende Reaktion auf zusätzliche Kapazität besteht darin, mehr Arbeit gleichzeitig zu starten.
Wenn ein Team durch KI theoretisch deutlich mehr Themen bearbeiten könnte, erscheint es zunächst sinnvoll, diese zusätzliche Kapazität auch vollständig auszunutzen. Genau daraus kann allerdings ein neues Problem entstehen.
Mehr parallele Arbeit erzeugt zusätzliche Abhängigkeiten, erhöht den Abstimmungsbedarf, vergrößert die kognitive Belastung und erschwert die Bewertung einzelner Veränderungen. Gleichzeitig steigt die Zahl der Änderungen, die beobachtet, betrieben und verstanden werden müssen.
Deshalb gewinnt die Begrenzung von Work in Progress sogar an Bedeutung.
Nicht die reine Umsetzungskapazität ist der knappste Faktor, sondern Aufmerksamkeit, Entscheidungsfähigkeit, Produktverständnis und die Fähigkeit einer Organisation, aus Veränderungen tatsächlich zu lernen.
Ein schneller Build Loop bringt wenig, wenn Value und Learning anschließend überlastet sind.
Von Push zu Pull
Auch die Art, wie neue Arbeit entsteht, verändert sich dadurch.
In vielen Organisationen wird Arbeit weiterhin stark nach einem Push-Prinzip verteilt. Initiativen, Anforderungen und Projekte werden gestartet und anschließend an Teams übergeben. Sobald zusätzliche Kapazität entsteht, wächst häufig auch die Menge der eingeplanten Arbeit.
KI kann dieses Muster deutlich verstärken.
Eine sinnvollere Konsequenz wäre deshalb ein stärkerer Pull-Mechanismus. Neue Arbeit beginnt erst dann, wenn ausreichend Fokus vorhanden ist, das Problem klar beschrieben werden kann und eine realistische Möglichkeit besteht, die Wirkung anschließend zu beobachten.
Die zentrale Frage lautet dann nicht mehr, welche zusätzliche Arbeit noch begonnen werden könnte, sondern welche nächste Veränderung den größten Erkenntnis- oder Nutzwert liefert.
Damit verschiebt sich der Schwerpunkt von maximaler Auslastung hin zu möglichst kurzen und vollständigen Lernzyklen.
Kleine Änderungen werden durch KI attraktiver
Wenn Entwicklung günstiger wird, verändert sich auch die Wirtschaftlichkeit kleiner Experimente.
Früher musste eine Änderung möglicherweise groß genug sein, um den Aufwand für Planung, Umsetzung und Deployment zu rechtfertigen. Wenn ein kleiner Versuch heute deutlich günstiger realisiert werden kann, entsteht eine andere Möglichkeit: Statt lange darüber zu diskutieren, ob eine Annahme richtig ist, kann eine begrenzte Änderung umgesetzt und ihre Wirkung beobachtet werden.
Damit sinkt der Bedarf, vorab möglichst viel Sicherheit zu erzeugen.
Entscheidend wird stattdessen, Unsicherheit möglichst günstig und schnell zu reduzieren.
Kleine Specs, begrenzter Kontext und kurze Feedbackschleifen werden dadurch nicht nur zu technischen Optimierungen, sondern zu einem organisatorischen Vorteil.
Geschwindigkeit braucht Beobachtbarkeit
Je schneller Software verändert wird, desto wichtiger wird zu verstehen, was nach einer Änderung tatsächlich passiert.
Dazu gehört nicht nur die fachliche Wirkung. Auch technische Stabilität, Fehlerraten, Performance und die Verfügbarkeit wichtiger Komponenten müssen beobachtet werden können.
Monitoring und Alerting sind deshalb kein nachgelagerter Betriebsaspekt, sondern Bestandteil der Feedbackschleife.
Ohne Beobachtbarkeit bleibt ein wesentlicher Teil des Value Loops unsichtbar. Eine Änderung kann technisch erfolgreich ausgeliefert worden sein und trotzdem neue Fehler verursachen, zentrale Komponenten belasten oder Nutzerverhalten negativ beeinflussen.
Ein schneller Entwicklungsprozess benötigt deshalb ebenso schnelle Rückmeldungen aus dem laufenden System.
Weniger Prozess, mehr Feedback
Viele Diskussionen über agile Softwareentwicklung konzentrieren sich noch immer stark auf Prozesse, Meetings und Frameworks.
Die wichtigere Frage könnte künftig jedoch lauten, wie schnell eine Organisation einen vollständigen Kreislauf durchlaufen kann.
Eine kleine Änderung wird umgesetzt, ihre Wirkung beobachtet, daraus entsteht eine Erkenntnis und diese Erkenntnis verändert die nächste Spec, den nächsten Test oder die nächste Entscheidung.
Genau darin liegt der Kern von LoopsWork.
Nicht möglichst viel KI in bestehende Prozesse einzubauen, sondern die Arbeitsweise so zu gestalten, dass die höhere Umsetzungsgeschwindigkeit tatsächlich in schnellere Lernfähigkeit übersetzt werden kann.
Gute Organisationen werden schneller lernfähig
Die zugespitzte These bleibt damit bestehen:
KI macht schlechte Organisationen schneller schlecht.
Unklare Ziele, langsame Entscheidungen, zu viel parallele Arbeit und schwache Feedbackmechanismen verschwinden durch KI nicht. Werden lediglich mehr Aufgaben automatisiert, können diese Probleme sogar schneller sichtbar werden oder sich weiter verstärken.
Für gut aufgestellte Organisationen gilt allerdings die andere Seite derselben Entwicklung.
Klare Verantwortlichkeiten, kleine Arbeitspakete, begrenztes Work in Progress, gute Beobachtbarkeit und kurze Feedbackwege ermöglichen es, zusätzliche Geschwindigkeit tatsächlich produktiv zu nutzen.
Der entscheidende Vorteil liegt dann nicht darin, möglichst viel Code zu erzeugen oder möglichst viele Features zu veröffentlichen.
Er liegt darin, schneller einen vollständigen Loop zu durchlaufen:
Build → Value → Learn.
Nicht die höchste Produktionsgeschwindigkeit entscheidet, sondern die Fähigkeit, Veränderungen schnell umzusetzen, ihre Wirkung zu verstehen und das Gelernte unmittelbar in die nächste Entscheidung einfließen zu lassen.