Erst die Hypothese, dann der Code

AI Agents können heute in kurzer Zeit Code schreiben, Tests erstellen, Fehler analysieren und Dokumentation aktualisieren. Was sie uns nicht abnehmen, ist die wichtigste Entscheidung der Produktentwicklung: Was sollten wir überhaupt bauen – und warum?

Je schneller Software entsteht, desto wichtiger wird deshalb die Klarheit vor der Umsetzung. Denn AI beschleunigt nicht nur gute Entscheidungen. Sie beschleunigt auch Missverständnisse, falsche Annahmen und unnötige Features.

Bei Turing 42 verbinden wir deshalb hypothesengetriebene Produktentwicklung mit Spec-driven Development. Hypothesen geben die Richtung vor. Spezifikationen übersetzen diese Richtung in einen klaren, überprüfbaren Arbeitsauftrag. AI Agents helfen uns, daraus schneller ein funktionierendes Produktinkrement zu entwickeln.

Der Prozess bleibt dabei bewusst lernend:

Spec-driven Development klingt zunächst nach ausführlichen Pflichtenheften und langfristig festgeschriebenen Anforderungen. Genau das meinen wir nicht.

Eine Spec ist für uns kein Versuch, ein komplettes Produkt im Voraus zu beschreiben. Sie definiert den nächsten sinnvollen und überprüfbaren Entwicklungsschritt präzise genug, damit Menschen und AI Agents mit demselben Verständnis daran arbeiten können.

Eine gute Spec beantwortet unter anderem:

• Welches Problem lösen wir für welche Nutzerinnen und Nutzer?
• Auf welcher Hypothese basiert die geplante Lösung?
• Was gehört zu diesem Schritt – und was ausdrücklich nicht?
• Welches Verhalten erwarten wir vom Produkt?
• Welche fachlichen, technischen und regulatorischen Grenzen gelten?
• Woran erkennen wir, dass die Umsetzung korrekt ist?
• Wie messen wir, ob die zugrunde liegende Hypothese stimmt?

Die Tiefe der Spezifikation richtet sich nach dem Risiko. Eine kleine UI-Anpassung braucht weniger Vorarbeit als ein neuer Abrechnungsprozess, eine Migration oder eine Funktion, die personenbezogene Daten verarbeitet.

Entscheidend ist nicht die Länge des Dokuments, sondern die Klarheit der Entscheidungen.

Hypothesengetriebene Produktentwicklung verhindert, dass aus einer Idee sofort eine vermeintlich sichere Anforderung wird. Wir formulieren zunächst, was wir glauben und woran wir erkennen würden, dass diese Annahme zutrifft.

Zum Beispiel:

Wir glauben, dass Nutzer eines B2B-Portals relevante Vorgänge schneller bearbeiten können, wenn sie Informationen nicht mehr in einzelnen Modulen suchen müssen. Das erkennen wir daran, dass die durchschnittliche Zeit bis zum Öffnen des richtigen Vorgangs deutlich sinkt.

Die Hypothese beschreibt Problem, erwartete Wirkung und Lernziel. Sie lässt bewusst offen, ob die zuerst gedachte Lösung tatsächlich die beste ist.

Die Spec macht daraus anschließend einen umsetzbaren Produktschritt. Sie beschreibt beispielsweise die relevanten Suchobjekte, Berechtigungen, Zustände, Interaktionen, Qualitätsanforderungen und Akzeptanzkriterien. Außerdem hält sie fest, welche Nutzungsdaten oder welches Feedback wir benötigen, um die Wirkung zu überprüfen.

In klassischer Softwareentwicklung können erfahrene Entwickler viele Unklarheiten während der Umsetzung erkennen, nachfragen und durch Produkt- oder Domänenwissen ausgleichen.

AI Agents besitzen diesen gemeinsamen Erfahrungshintergrund nicht automatisch. Sie arbeiten mit dem Kontext, den wir ihnen zur Verfügung stellen.

Ein unklarer Auftrag führt deshalb häufig zu Code, der auf den ersten Blick plausibel aussieht, aber am eigentlichen Bedarf vorbeigeht. Eine gute Spec bildet den gemeinsamen Arbeitskontext für Product, UX, Engineering und die beteiligten Agents.

Sie schafft Leitplanken, ohne jede technische Entscheidung vorzugeben. Sie macht gewünschtes Verhalten testbar und verhindert, dass der Agent stillschweigend zentrale Annahmen ergänzt. Gleichzeitig bleibt genügend Raum für technische Urteilskraft, sinnvolle Lösungsalternativen und neue Erkenntnisse während der Umsetzung.

Spec-driven Development ist für uns daher kein zusätzlicher Dokumentationsprozess. Es ist die Voraussetzung dafür, AI Agents verlässlich in professionelle Produktentwicklung einzubinden.

Zurück zum B2B-Portal: Die Hypothese war nicht „wir brauchen eine globale Suche“, sondern eine Wirkung – kürzere Zeit bis zum richtigen Vorgang.

Die Spec für den ersten Schritt war bewusst eng. Auszug aus dem Arbeitsauftrag:

• Zielgruppe: Innendienst mit Zugriff auf Aufträge und Tickets
• In Scope: übergreifende Suche über Aufträge und Tickets, inkl. Berechtigungsfilter
• Out of Scope: Volltext über Anhänge, KI-Ranking, Mobile
• Erwartetes Verhalten: Treffer öffnen den Vorgang in maximal zwei Klicks; leere Zustände und Fehlermeldungen sind definiert
• Akzeptanz: automatisierte Tests für Berechtigungen und Trefferlogik; manuelles Review der kritischsten Flows
• Messung: Zeit vom Einstieg bis zum Öffnen des relevanten Vorgangs in einer Pilotgruppe

Agents setzten auf dieser Basis Suche, Filter, Tests und Doku-Entwurf in kurzen Loops um. Menschen prüften Domäne, Security und UX – und gaben frei, was tragfähig war.

Die Messung zeigte: Die Zeit sank, aber weniger als erwartet. Interviews erklärten warum – viele Nutzer starteten nicht mit Suche, sondern mit einer Favoritenliste unvollständiger Vorgänge. Die Hypothese war also nur teilweise richtig.

Genau das ist der Punkt: Ohne Spec hätten Agents schnell „eine Suche“ gebaut. Mit Hypothese, Spec und Messung entstand stattdessen ein lernbares Ergebnis – und die nächste Spec galt der Favoritenliste, nicht dem Ausbau der Suche.

In der Umsetzung arbeiten unsere Senior Engineers mit AI Agents in iterativen Loops – oft als Ralph Loop bezeichnet: verstehen, vorbereiten, prüfen, weiter. Ein Agent bekommt nicht einmal einen Prompt und liefert „fertig“. Er plant, implementiert, führt Tests aus, bewertet Ergebnisse und verbessert die Lösung in begrenzten Durchläufen.

Ohne Spec driftet dieser Loop. Der Agent optimiert dann, was lokal plausibel wirkt – nicht unbedingt, was die Hypothese prüfen soll. Mit Spec und Akzeptanzkriterien bleibt jeder Durchlauf an denselben Leitplanken ausgerichtet.

Wie Direction, Loop und Review im Alltag zusammenspielen, beschreiben wir im Beitrag zu AI Agents im Entwicklungsprozess. Hier geht es um den vorgelagerten Grund: ohne überprüfbaren Auftrag wird Tempo zum Risiko.

Agents verändern die Verteilung der Arbeit. Verantwortung übernehmen sie nicht.

Menschen bleiben verantwortlich für Produkturteil, Priorisierung, Architektur, Compliance und die Interpretation von Wirkung. Engineers orchestrieren den Prozess: sie schaffen Kontext, treffen Entscheidungen und sichern Qualität – statt nur Prompts einzugeben.

Die operative Arbeitsteilung zwischen Mensch und Agent gehört in den Beitrag zum AI-Entwicklungsprozess. Für Spec-driven Development zählt vor allem: die Spec ist menschlich verantwortete Klarheit, bevor Tempo entsteht.

Der größte Vorteil von Spec-driven Development mit AI Agents ist für uns nicht, möglichst viel Code in möglichst kurzer Zeit zu produzieren. Mehr Code ist kein Produktziel.

Der eigentliche Gewinn liegt in kürzeren und zuverlässigeren Lernzyklen. Annahmen werden schneller testbar, Varianten fundierter vergleichbar, Erkenntnisse früher wirksam – bei nachvollziehbaren Entscheidungen und Qualitätsmaßstäben.

Genau dafür verbinden wir bei Turing 42 hypothesengetriebene Produktentwicklung, Senior Product Engineering und AI Agents:

Nicht um schneller beliebige Software zu bauen, sondern um schneller herauszufinden, welches digitale Produkt echten Kundennutzen schafft.