Die Software-Factory.
Wenn Agenten den ganzen Zyklus übernehmen.

Ich saß kürzlich mit einem der großen Tech-Unternehmen zusammen, das aus seinen Erfahrungen berichtet hat. Aber das ist längst nicht mehr nur deren Thema. Es ist ein Trend, der gerade durch viele Unternehmen zieht, uns eingeschlossen. Ein Satz aus dem Gespräch ist hängengeblieben: Die Software-Factory gibt es längst. Bisher war sie nur mit Menschen besetzt.

Die Fabrik gab es schon, nur mit Menschen

Denk an eine typische Softwareabteilung. Jemand schreibt ein Ticket. Jemand definiert die Spezifikation. Ein Produktverantwortlicher und ein Entwickler drehen ein paar Runden Feedback. Eine Analystin prüft die Anforderung, das Design gibt seinen Senf dazu, am Ende läuft alles durch eine Qualitätssicherung, bis Tests grün sind und das Ergebnis zum Entwurf passt. Das ist die Fabrik. Tickets rein, Software raus, mit vielen Menschen an den Stationen dazwischen.

Das teure Problem daran ist nicht die Programmierung. Es sind die Schleifen zwischen den Rollen. Zwischen Idee, Design und Bau vergehen in großen Organisationen Monate. Die Analyse liefert eine Spezifikation, das Design meldet Bedenken zurück, die Anforderung wird neu geschnitten, der Bau merkt, dass das Design nicht trägt, und alles geht eine Station zurück. Das lässt sich nur begrenzt optimieren, weil Menschen an genau der Stelle schwach sind, an der es zählt.

Der Mensch validiert, statt zu tippen

Die erste Stufe ist harmloser, als es der Begriff „Fabrik" vermuten lässt. Es entsteht kein geschlossener Automat, der ohne Zutun Software ausspuckt. Stattdessen bekommt jeder Mensch an jeder Station eine KI-Schicht an die Seite gestellt. Ein zweites Augenpaar, das mitliest, gegenprüft und Tempo reinbringt.

Das passt zu einer Stärke, die wir Menschen haben: Wir sind gut darin, zu beurteilen. Wir erkennen, ob eine Eingabe Sinn ergibt und ob das Ergebnis brauchbar ist. Genau da bleibt der Mensch im Loop, nicht als Tipper, sondern als Prüfer. Wer diese Rolle unterschätzt, baut schnell und wirft danach die Hälfte wieder weg.

Die Spezifikation wird zum Bauplan

Softwareentwicklung war schon immer eine Reihe von Abstraktionssprüngen. Erst haben Menschen in Maschinencode gedacht, dann kamen Hochsprachen, damit niemand mehr mit Nullen und Einsen hantieren muss. Der nächste Sprung nimmt auch die Programmiersprache aus dem Bild. Nicht Python oder Java sind dann der Text, den man pflegt, sondern die Spezifikation selbst.

Das ist der Kern von Spec-Driven Development: Die Beschreibung dessen, was gebaut werden soll, wird zur einzigen Quelle der Wahrheit für den gesamten Ablauf. Der Code ist nur noch das Ergebnis. Für dich als Entscheider heißt das etwas Angenehmes und Unbequemes zugleich. Was du klar beschreiben kannst, lässt sich bauen. Was du nicht klar beschreiben kannst, wird auch keine KI für dich retten. Wir haben das schon länger unter Vier Wege, Software zu bauen eingeordnet.

Wo Menschen an ihre Grenze kommen

Es gibt eine Sache, die Menschen im Fabrik-Modell schwerfällt. Wir denken hervorragend über einzelne Punkte nach und diskutieren gern jedes Detail. Beim langen Bogen tun wir uns schwer. Wenn wir Feature für Feature bauen, verlieren wir leicht den Blick auf das ganze Produkt. Der Gesamtscope rutscht aus dem Bild, während wir uns in einem Baustein festbeißen.

Genau hier liegt das Versprechen der Modelle. Sie halten den kompletten Umfang gleichzeitig im Blick, ohne müde zu werden. Das ist kein Ersatz für menschliches Urteil, sondern eine Ergänzung. Die Maschine hält das große Ganze zusammen, der Mensch entscheidet, ob es das Richtige ist.

Werkzeuge, die für Menschen gebaut sind

Es gibt eine unbequeme Wahrheit hinter all dem. Unsere Werkzeuge sind für Menschen gemacht, nicht für Agenten. Versionsverwaltung, Code-Reviews, das Auflösen von Konflikten beim Zusammenführen von Änderungen: Das alles ist auf einzelne Menschen zugeschnitten, die nacheinander an einem Projekt arbeiten.

Sobald viele Agenten parallel am selben Projekt und an denselben Zweigen arbeiten, passt dieses Modell nicht mehr. Aufgaben wie Review, das Finden von Fehlern und das Auflösen von Konflikten wandern dann von der letzten Station nach vorne, in die Grundlage. Und der Ausblick geht noch weiter: Agenten, die sich ihre eigenen Abläufe bauen, eigene Schritte definieren und sich merken, was schon einmal funktioniert hat. Ob das so kommt, wird sich zeigen. Die Richtung ist erkennbar.

Einordnung: Meckern auf hohem Niveau

Damit das nicht falsch klingt: Wenn wir über fehlende Struktur bei kurzen Zurufen an einen Agenten reden, dann meckern wir auf hohem Niveau. Es geht hier um Softwareentwicklung in ihrer besten Form, um den Goldstandard. Das Ambitionsniveau hinter diesen Aussagen ist enorm hoch.

Denn natürlich baust du auch mit einem einzigen Prompt echte, funktionierende Software. Ein schneller Zuruf bringt dich oft erstaunlich weit. Das war in der klassischen Entwicklung nicht anders. Ein Entwickler, der sich nicht sklavisch an jeden Schritt des Software-Lebenszyklus hält, schreibt deshalb noch lange keinen schlechten Code. Struktur ist kein Selbstzweck.

Die richtige Frage ist deshalb nicht „Erreiche ich überall den Goldstandard?", sondern „Wie viel Struktur verdient dieses Projekt?" Für ein kleines internes Tool reicht der kurze Weg. Für das System, das nächstes Jahr einen Teil deines Umsatzes trägt, lohnt sich die Sorgfalt. Der Aufwand sollte zum Einsatz passen, nicht umgekehrt.

Was das für den Mittelstand heißt

Große Unternehmen bauen sich gerade ihre eigenen Software-Factories, und der Trend ist eindeutig. Die gute Nachricht: Du musst diese Größe nicht mitgehen, um vom Prinzip zu profitieren. Es skaliert nach unten. Die eigentliche Arbeit passiert nämlich vor dem Code: sauber beschreiben, was gebaut werden soll, und nach jedem Schritt abnehmen. Das Tempo kommt dann fast von allein.

Für uns ist das keine Tool-Frage, sondern eine Haltung. Die Maschine übernimmt die Fleißarbeit, das Urteil bleibt beim Menschen. Genau das meinen wir mit Handarbeit. Wenn du intern anfängst, mit Agenten zu arbeiten, reicht oft schon dieser Rahmen: eine Seite klare Regeln, Spezifikation vor Code, Abnahme nach jedem Feature. Und wenn du das nicht selbst aufsetzen willst, bauen wir genau so, mit dir statt an dir vorbei.