Menschen denken, KI erledigt den Rest: Wie wir unseren Entwicklungsprozess auf KI umgestellt haben

Im Februar haben wir zugegeben, dass wir keine Zeile von Metapads Code von Hand geschrieben haben. Im Mai haben wir beschrieben, wie wir Metapads Modelle bauen, indem wir mit ihnen sprechen. Seitdem ist der Prozess einen Schritt weiter gegangen, und es lohnt sich, klar zu sagen, was aus ihm geworden ist:

Wir arbeiten auf der konzeptionellen Ebene. KI erledigt den Rest.

Die Menschen im Team entscheiden, was gebaut wird, warum, und wie es sich anfühlen soll. Alles darunter – die Arbeitspakete schreiben, Code und Tests, Mergen, Bauen, Deployen, den Regressionslauf auswerten, Hilfeseiten und Changelog schreiben – erledigen KI-Agenten, mehrere gleichzeitig. Wir steigen von der konzeptionellen Ebene nur dort herab, wo wir vorab entschieden haben, dass ein Mensch hinschauen muss.

Das klingt nach einer Aussage über KI. Es hat sich als Aussage über etwas anderes herausgestellt: dafür zu sorgen, dass alle – Mensch wie Maschine – mit demselben Bild arbeiten. Darum geht es in diesem Beitrag.

---

Auf einen Blick

• Menschen denken, KI erledigt den Rest. Ein Mensch arbeitet an Konzepten und Entscheidungen. KI-Agenten (Claude Code) schreiben die Issues, den Code und die Tests, führen das Release durch, werten den Regressionslauf aus und schreiben die Dokumentation.
• Seit Januar 2026 haben wir 334 Versionen von Metapad gebaut: mehr als eine pro Kalendertag, jede gefolgt von einem vollständigen Regressionslauf.
• Die Codebasis ist beträchtlich: Bei Image 334 sind es rund 355.000 Zeilen Rust, davon rund 60.000 reiner Testcode, dazu rund 77.000 Zeilen in unseren beiden Python-Testsuiten für End-to-End- und API-Tests.
• Der Plan, jede Entscheidung, jedes Testergebnis und jedes Review liegen in einem Metapad-Modell: heute 3.975 Elemente, darunter 946 Arbeitspakete, 1.328 automatisierte End-to-End-Tests und 344 Testszenarien.
• Die Dokumentation liegt in einem zweiten Metapad-Modell, zweisprachig, von Claude geschrieben, mit automatisch erzeugten Screenshots und automatisch erzeugtem Changelog.
• Jedes Projekt bekommt sein eigenes Modell, geforkt aus einer gemeinsamen Vorlage. KI-Agenten, die mit mehreren Modellen zugleich verbunden sind, arbeiten modellübergreifend.
• KI bestimmt die Roadmap mit. Agenten nutzen Metapad über dieselbe MCP-Schnittstelle wie unsere Kunden und finden Probleme, die wir selbst nicht gefunden hätten.
• Hinter den Agenten stehen Menschen bei transentis und bei unseren Kunden, die jeden Tag mit Metapad arbeiten. Ihr Feedback bestimmt die Roadmap ebenfalls.
• Der Engpass ist nicht die KI. Es ist menschliche Aufmerksamkeit – deshalb budgetieren wir sie, Release für Release.
• Dasselbe Muster funktioniert für jede Organisation, die Veränderung liefert: Ihr Lieferprozess ist ein Unternehmenssystem, und er verdient einen digitalen Zwilling.

---

1. Zwei Ebenen der Arbeit

Es hilft, die Grenze ausdrücklich zu ziehen, denn um genau diese Grenze ist der ganze Prozess gebaut.

Menschen arbeiten auf der konzeptionellen Ebene. KI-Agenten erledigen den Rest, sie lesen aus einem gemeinsamen Modell und schreiben hinein. Menschen werden nur dort ins Detail zurückgeholt, wo das Review-Budget es vorsieht.

Die oberste Ebene ist die, auf der Menschen am meisten beitragen und KI am wenigsten: Es geht um Absicht, Geschmack und Verantwortung. Auf den Ebenen darunter ist KI inzwischen schneller und gründlicher als wir. Der Pfeil zurück nach oben ist so wichtig wie die Ebenen selbst: Ein Mensch wird nur dort ins Detail zurückgeholt, wo das Review-Budget es vorsieht, und dieses Budget wird festgelegt, wenn die Arbeit geplant wird – nicht, wenn etwas schiefgeht.

2. Das Problem mit mehr als einem Agenten

Mit einem KI-Assistenten in einem Gespräch lässt sich leicht arbeiten: Beide sehen denselben Verlauf. Lassen Sie drei parallel laufen, und dieser gemeinsame Verlauf ist weg. Agent A weiß nicht, dass Agent B vor einer Stunde das Datenformat geändert hat. Der Agent, der morgen einen Fehler behebt, weiß nicht, dass wir heute entschieden haben, ihn nicht auf diese Weise zu beheben. Und der Mensch in der Mitte – ich – wird zum menschlichen Nachrichtenbus, der Kontext von einem Fenster ins nächste wiederholt. Das ist das Gegenteil von Arbeit auf der konzeptionellen Ebene.

Wir haben die naheliegenden Mittel ausprobiert: längere Prompts, gemeinsame Notizdateien, sorgfältigere Übergaben. Sie alle verfallen. Eine Notizdatei ist veraltet, sobald jemand vergisst, sie zu aktualisieren, und man kann ihr keine Frage stellen.

Was wir brauchten, war ein gemeinsames Gedächtnis, das jeder Beteiligte liest und beschreibt, das den Unterschied zwischen einem Konzept, einem Plan, einer Entscheidung und einem Urteil kennt und das Fragen beantworten kann wie „Was wartet noch auf ein Review?“, ohne dass jemand alles durchlesen muss.

Wir hatten schon eines. Es ist das Produkt, das wir bauen.

3. Das Release ist ein Graph

Metapads eigene Entwicklung ist in einem Metapad-Modell beschrieben. Seine Struktur ist bewusst einfach:

Knotentyp	Was er enthält
Phase	Die Roadmap: eine grobe Reihenfolge von Themen, jedes mit einem Haupt-Track und parallelen Tracks
Konzept	Designideen und die Begründung dahinter
Umsetzungsplan	Für die größeren Vorhaben: Phasen, betroffene Teile, Migrationsschritte, Test-Checkliste
Issue	Ein Arbeitspaket: was zu tun ist, woran wir erkennen, dass es erledigt ist, wie viel menschliche Aufmerksamkeit es braucht
Image	Ein Build der Anwendung, nummeriert – „Image 334“
Testszenario	Was ein Test beweisen soll, in einfacher Sprache beschrieben
Test und Testlauf	Jeder automatisierte Test und jeder Regressionslauf gegen einen Build

Die konzeptionelle Ebene lebt in den obersten drei Typen. Wenn wir eine Idee durchsprechen, ist das Ergebnis ein Konzept: was wir wollen, warum, was wir stattdessen erwogen haben und in welche Phase der Roadmap es gehört. Viele Konzepte liegen eine Weile, bevor jemand sie im Detail ausarbeitet – mit Absicht. Gute Ideen werden besser, wenn sie Zeit haben, anderen Ideen zu begegnen.

Claude schreibt die Issues. Ein Fehlerbericht, eine Idee aus einem Kundengespräch oder eine Lücke, die beim Testen auffällt, wird zu einem Gespräch. Claude liest den relevanten Code, schlägt Ursache und Lösung vor und schreibt das Issue ins Modell, mit den betroffenen Dateien, einem Testhinweis und Verknüpfungen zu den Konzepten, die es berührt. Ich bestätige die Entscheidungen; das Ticket tippe ich nicht.

Wir planen Releases für die jeweilige Woche, rollierend, in einer Metapad-Grid-Ansicht: Issues als Zeilen, kommende Images als Spalten. Ein Issue einem Release zuzuordnen ist ein Klick; es auf ein späteres zu verschieben, wenn etwas sich verzögert, ein weiterer.

Der Wert liegt in den Beziehungen. Ein Issue wird ausgeliefert in einem Image: Vor dem Build ist das der Plan, danach das Release-Manifest. „Was ist in 334?“ ist eine einzige Frage an den Graphen. Ein Testlauf lief gegen ein Image, und jeder Test, der von Rot auf Grün gesprungen ist, ist mit dem Lauf verknüpft, in dem er umsprang. „Was hat dieser Build behoben, und was hat er kaputt gemacht?“ ist also ein Gang über den Graphen, kein Nachmittag mit Logdateien.

Zwei Eigenschaften an jedem Issue tragen den Großteil der Disziplin:

• Ein Gate. Eine Zeile, die die Bedingung nennt, unter der das Issue geschlossen wird – prüfbar von jemandem, der den Code nicht geschrieben hat: „dieser End-to-End-Test ist grün“, „diese Logzeile erscheint nach dem nächsten Lauf“, „Oliver entscheidet“. Jede Prüfung hält fest, ob die Bedingung erfüllt ist oder noch nicht.
• Ein Review-Budget. none (ein automatisierter Test genügt), glance (ein Mensch muss es sehen – Layout, Formulierung, ein gerendertes PDF) oder judgment (ein Mensch muss es ausprobieren und entscheiden). Das ist der Pfeil zurück nach oben im Bild oben.

Die Agenten verbinden sich über Metapads MCP-Schnittstelle mit diesem Modell, genauso wie Ihre eigenen KI-Werkzeuge es können. Wenn ein Agent fertig ist, schreibt er seine Ergebnisse ins Issue. Wenn ich etwas entscheide, wird die Entscheidung ebenfalls ins Issue geschrieben. Nichts Wichtiges lebt nur in einem Chatfenster.

4. Ein Release-Tag: Image 334

Hier ist ein Tag, mehr oder weniger so, wie er abgelaufen ist.

Morgens – Konzepte. Der Tag begann mit einem Issue, das wir wochenlang von Release zu Release verschoben hatten, weil wir nicht sicher waren, was wir wollten. Im Gespräch stellte sich heraus, dass es die eine Hälfte einer größeren Idee war, nach der unsere Kunden gefragt hatten: ein Modell forken, im Fork eine große Änderung vornehmen, während kleine Korrekturen weiterhin die veröffentlichte Version erreichen, und den Fork anschließend zurückführen. Daraus wurde ein neues Konzept, mit seinen Stufen, der Überlegung, wo es auf der Roadmap steht, und dem einen kleinen Schritt, der sich jetzt lohnt, damit sich die Forks von heute später zusammenführen lassen. Das ursprüngliche Issue schrumpfte auf etwas, das wir in wenigen Tagen ausliefern konnten. Nichts davon hatte mit Code zu tun. Alles davon landete im Modell.

Später Vormittag – Planung von Image 334. Das Hauptthema war, Multiplayer-Spiele an einen Plan zu binden: Eine Spielsitzung zu hosten wird zu einer Funktion des Team-Plans mit einem monatlichen Kontingent. Der Release-Manager – selbst ein Agent – las die Issues des Images, markierte die noch offenen Entscheidungen und brachte mir jede davon mit einer Empfehlung. Zwei Punkte passten nicht und wurden verschoben. Einer wurde auf den Teil reduziert, den wir tatsächlich brauchten. Dann bündelte er den Rest in drei Themen-Branches und briefte für jeden einen Umsetzungsagenten.

Mittags – drei Agenten parallel. Jeder Agent arbeitet in seiner eigenen isolierten Kopie des Codes, mit eigener Datenbank und eigenem Server, und schreibt und startet die Tests für sein eigenes Feature, bevor er zurückmeldet. Einer von ihnen traf eine bessere Designentscheidung als die, die ich vorgeschlagen hatte: Das Briefing sah vor, die Eingaben der anderen Spieler anzuzeigen, indem der Server jedem Spieler mehr Daten schickt; der Agent erkannte, dass die Entscheidung eines Spielers eine Eingabe ist, die in den berechneten Ergebnissen des Servers nie vorkommt, und lieferte die Entscheidungen stattdessen aus dem Entscheidungsprotokoll des Spiels – und nur für bereits abgeschlossene Runden, damit niemand einen Zug sieht, bevor die Runde festgeschrieben ist. Die Einstellung, die er gebaut hat („Für andere Spieler sichtbar“), erweist sich als nützlich für eine ganze Klasse von Szenarien: dasselbe Spiel einmal mit und einmal ohne Transparenz gespielt.

Nachmittags – Reviews als Galerie. Von den sieben Issues im Image brauchten zwei mich, beide glance. Die Agenten hängten Screenshots auf Englisch und Deutsch an die Issues, der Release-Manager sah sie sich zuerst an, und mein Review dauerte ein paar Minuten. Der Release-Manager schrieb das Review in jedes Issue, denn ein Review, das nicht festgehalten ist, hat nicht stattgefunden.

Abends – Merge, Build, Deploy, Regression. Der Release-Manager führte jeden Branch erst zusammen, nachdem der zusammengeführte Code die vollständige Testsuite bestanden hatte, denn zwei Branches, die einzeln grün sind, können sich gegenseitig trotzdem kaputt machen. Der Build läuft auf einer eigenen Build-Maschine in der Cloud; dann folgen ein Deployment in unsere Testumgebung und ein vollständiger Regressionslauf: jeder automatisierte Test, gegen genau den Build, der in Produktion gehen wird. Ausgewertet wird der Lauf von einem weiteren Agenten, in seiner eigenen Kopie des Codes.

Und nebenbei. Ein instabiler Datenbanktest, dem einer der Agenten nachging, erwies sich als Symptom von etwas Strukturellem darin, wie unsere Entwicklungsumgebung eine gemeinsame Datenbank erreicht. Zehn Minuten Gespräch später war daraus ein neues Konzept mit einem klaren ersten Schritt geworden, eingeplant ins nächste Image. Das ist die konzeptionelle Ebene bei der Arbeit: Der Agent hat das Problem gefunden; der Mensch hat entschieden, was es bedeutet.

5. Mehr als ein Projekt

Metapad ist nicht unser einziges Projekt. transentis betreibt mehrere: Manche ändern sich jeden Tag, manche nur ein paar Mal im Jahr. Wir geben jedem Projekt sein eigenes Modell, alle geforkt aus einer gemeinsamen Vorlage, die die Lieferstruktur aus Abschnitt 3 enthält – Phasen, Konzepte, Issues, Releases, Testszenarien, Gates und Review-Budgets.

Warum nicht ein großer Graph für alles? Weil sich Projekte im Rhythmus unterscheiden, darin, wer Zugriff hat, und darin, wie viel Rauschen sie erzeugen. Ein Projekt, das sich zweimal im Jahr ändert, sollte nicht in einem leben müssen, das jeden Tag ausliefert, und ein Kundenprojekt sollte oft nicht für alle sichtbar sein. Getrennte Modelle halten das Bild jedes Projekts sauber.

Was sie verbindet, ist die KI. Ein Agent kann mit mehreren Modellen gleichzeitig verbunden sein, sodass eine projektübergreifende Frage – „Was bedeutet der neue Account-Service für jede App, die ihn nutzt?“ – von einem Agenten beantwortet wird, der alle beteiligten Modelle liest, und das Ergebnis wird in jedes davon zurückgeschrieben. Die gemeinsame Vorlage hält die Modelle vergleichbar: dieselben Typen, dieselben Gates, dieselben Review-Budgets, sodass jemand, der das Modell eines Projekts kennt, jedes andere lesen kann.

6. Auch die Dokumentation ist ein Modell

Metapads Hilfeseiten, Funktionsbeschreibungen und Blog – einschließlich dieses Beitrags – liegen in einem zweiten Metapad-Modell, auf Englisch und Deutsch. Claude schreibt und pflegt es auf dieselbe Weise wie den Code: Es schlägt Änderungen vor, die wir prüfen, bevor etwas veröffentlicht wird. Aus diesem einen Modell erzeugen wir die Website, die In-App-Hilfe und das Wissen, auf das unser In-App-KI-Assistent zurückgreift.

Zwei Teile davon laufen von selbst:

• Der Changelog wird aus dem Release befüllt. Weil das Modell weiß, welche Issues in welchem Image ausgeliefert wurden, schreibt die KI die Changelog-Einträge eines Releases aus genau dieser Liste, und ein Mensch gibt sie frei, bevor sie hinausgehen.
• Screenshots werden erzeugt, nicht aufgenommen. Jeder Screenshot in der Hilfe ist ein Rezept im Modell: welches Modell geöffnet wird, was angeklickt wird, was erfasst wird. Ein Skript erzeugt ihn in beiden Sprachen, und ein Agent prüft jedes Bild, bevor es veröffentlicht wird. Wenn sich die Benutzeroberfläche ändert, ziehen die Screenshots nach.

7. Wer die Roadmap bestimmt: Menschen – und KI

Agenten können ein Feature bauen. Allein können sie uns nicht sagen, welches Feature zählt. Das kommt von Menschen, die Metapad für echte Arbeit nutzen – bei transentis und bei unseren Kunden.

Modelliererinnen und Modellierer arbeiten jeden Tag mit Metapad: an den 16 umfangreichen Showcase-Vorlagen in unserer Vorlagenbibliothek und an mehr als 20 umfangreichen Produktivmodellen, unseren eigenen und denen unserer Kunden. Sie sind unsere anspruchsvollsten Nutzer. Wenn etwas umständlich ist, bei einem großen Modell langsam oder auf Deutsch verwirrend, erfahren wir davon – meist am selben Tag und meist zusammen mit dem Modell, in dem es passiert ist. Das Fork-und-Merge-Konzept aus Abschnitt 4 hat genau so angefangen, mit Kunden, die eine große Änderung vorbereiten müssen, ohne das bereits Veröffentlichte zu stören.

Es gibt aber eine zweite Quelle, von der wir nicht erwartet hatten, dass sie so wichtig wird: KI, die das Produkt nutzt, das sie baut. Die meisten dieser Modelle werden ebenfalls mit KI gebaut, über dieselbe MCP-Schnittstelle, die unsere Kunden nutzen. Ein Agent, der echte Modelle baut, abfragt und simuliert, stößt auf Probleme, auf die kein menschlicher Tester stoßen würde, weil er das Produkt anders nutzt, häufiger und wörtlicher. Ein Beispiel aus der Woche von Image 334: Bei der Vorbereitung einer Demo ließ ein Agent über MCP eine Simulation eines übersetzten Modells laufen und bemerkte, dass der deutsche Lauf andere Zahlen lieferte als der englische – ohne Fehlermeldung, nur plausibel aussehende falsche Ergebnisse. Ein Mensch hätte die beiden mit ziemlicher Sicherheit nicht verglichen. Die Korrektur wurde im selben Image ausgeliefert.

Deshalb haben wir Metapad MCP-first gebaut: Jede Fähigkeit, die ein Agent brauchen könnte, steht ihm über dieselbe Schnittstelle zur Verfügung, von Anfang an. Das erlaubt es Agenten, das Produkt zu bauen, das Produkt zu nutzen und über das Produkt zu berichten. Und es ist ein Muster, von dem wir erwarten, dass es weit über Metapad hinaus gilt: Geben Sie KI die Werkzeuge, mit den Produkten zu arbeiten, die sie erschafft, und sie bekommt ein besseres Bild vom Produkt, als jede Spezifikation es ihr geben könnte. Produkte, deren KI nur Code schreiben, aber nicht nutzen kann, was sie geschrieben hat, werden langsamer lernen.

8. Was wir gelernt haben

Ziehen Sie die Grenze zwischen den Ebenen, und halten Sie die Menschen darüber. Die Aufgabe der Menschen ist die konzeptionelle Ebene: Absicht, Abwägungen, Verantwortung. Sobald ein Mensch anfängt, Kontext zwischen Agenten weiterzureichen oder Tickets zu tippen, ist der Prozess verrutscht.

Der Mensch ist der Engpass – also setzen Sie ihn bewusst ein. KI-Agenten produzieren Code und Tests schneller, als irgendjemand sie prüfen kann. Ohne Budget wartet jede Änderung auf einen Menschen, und das Release kommt ins Stocken. Mit Budget werden die meisten Änderungen durch automatisierte Tests nachgewiesen, und die Zeit des Menschen geht in die Handvoll Dinge, die nur ein Mensch beurteilen kann.

Ein Review, das nicht festgehalten ist, hat nicht stattgefunden. Ein Review, das vor Wochen gemacht, aber nie aufgeschrieben wurde, stand noch als offen in der Liste – also wurde „Review erledigt“ zu einer Eigenschaft, die ein Werkzeug lesen kann, und das Release-Tooling warnt jetzt, wenn sie fehlt. Ein Schritt, der zweimal vergessen wird, wird zur Aufgabe eines Werkzeugs.

Testen Sie das Feature vor dem Build; testen Sie den Build auf Regressionen. Der Test jedes Features wird zusammen mit dem Feature geschrieben, vom selben Agenten, und ist grün, bevor irgendetwas gemergt wird. Der vollständige Regressionslauf auf dem Build ist dazu da, das Unerwartete zu finden – nicht, um herauszufinden, ob das neue Feature funktioniert.

Geben Sie den Agenten Ihre Produktionslogs. Unsere Server melden an einen Cloud-Logging-Dienst, und Claude kann ihn direkt abfragen. Statt zu raten, warum ein Test nur unter Last fehlschlug, legt der Agent den fehlschlagenden Test neben das, was der Server in genau diesem Moment aufgezeichnet hat, und kommt mit Belegen zurück statt mit einer Theorie.

Machen Sie das gemeinsame Gedächtnis zum Weg des geringsten Widerstands. Agenten schreiben ins Modell, weil sie dort ihre Anweisungen bekommen und dort ihre Ergebnisse ablegen. Wäre das Schreiben ins Gedächtnis ein zusätzlicher Schritt, würde er übersprungen.

9. Warum das über uns hinaus zählt

Nichts in Abschnitt 3 ist spezifisch für Software. Ersetzen Sie „Image“ durch „Release“, „Quartalsplan“ oder „Änderungsantrag“ und „Test“ durch „Abnahmeprüfung“, und Sie haben die Struktur fast jeder Organisation, die Veränderung liefert.

Das ist der Punkt, auf den wir in diesem Blog immer wieder zurückkommen. Metapad ist eine Plattform für digitale Zwillinge von Unternehmen, gebaut auf berechenbaren Knowledge Graphs. Ein Lieferprozess ist genau die Art von Organisationssystem, die von einem solchen Zwilling profitiert. Er hat einen Zustand (was geplant ist, was erledigt ist), Verantwortung (wer entscheidet, wer prüft) und Veränderung über die Zeit (was jedes Release behoben und kaputt gemacht hat). Ihr Versionskontrollsystem, Ihr Ticket-Werkzeug und Ihre CI-Pipeline sind die Detailsysteme; jedes ist maßgeblich für seinen eigenen Ausschnitt. Der Zwilling ist das Gesamtbild, das sie verbindet und die Fragen beantwortet, die keines von ihnen allein beantworten kann: Worauf wartet dieses Release? Wer muss sich was ansehen? Haben wir das Versprechen gehalten, das wir mit dieser Entscheidung gegeben haben?

Und wenn KI-Agenten Ihrem Team als Kollegen statt als Werkzeuge beitreten, ist es genau dieses gemeinsame, abfragbare Gedächtnis, das Ihre Menschen auf der konzeptionellen Ebene hält – und die KI den Rest erledigen lässt.

10. Wie geht es weiter?

Möchten Sie es ausprobieren? Metapad können Sie kostenlos nutzen, unter app.metapad.ai. Verbinden Sie Ihren KI-Assistenten über MCP und modellieren Sie Ihren eigenen Lieferprozess.

Möchten Sie schneller starten? Forken Sie unsere Liefervorlage – dieselbe Struktur, die wir für jedes Projekt verwenden: Phasen, Konzepte, Arbeitspakete, Releases, Testszenarien, Gates und Review-Budgets, mit einem Einstiegsleitfaden, wie Sie Ihre KI-Agenten anbinden.

Möchten Sie es in Aktion sehen? Nehmen Sie an einem unserer kostenlosen Webinare teil, unter academy.transentis.com.

Menschen denken. Die KI erledigt den Rest. Der Graph merkt sich, warum.