Agentic Product Development bedeutet, den gesamten Softwareentwicklungsprozess so zu strukturieren, dass KI-Agenten Gerüstbau, Kontexttransfer und Code-Generierung übernehmen, während sich Engineers auf Urteilsvermögen, Review und Entscheidungen konzentrieren. Es funktioniert am besten, wenn die Grundlagen sauber und der Kontext explizit sind.
Strukturierte Phasen liefern bessere Agenten-Ergebnisse
KI-Agenten liefern bessere Ergebnisse, wenn sie klaren Kontext und klare Grenzen haben. Vage Prompts produzieren generischen Code. Detaillierte Spezifikationen produzieren Code, der zu Ihrer Codebasis passt, Ihrem Design-System entspricht und Ihren Konventionen folgt.
Das hat Teams dazu bewogen, wieder zu linearen, strukturierten Lieferphasen zurückzukehren: zuerst Discovery, dann Design, dann Engineering. Die Logik ist einfach. Wenn Sie den gesamten Kontext und alle Entscheidungen vorab klären, bevor die Umsetzung beginnt, haben Coding Agents alles, was sie brauchen. Kein Raten, kein Improvisieren, kein Hin-und-Her mitten im Sprint.
Die Verwaltungsebene automatisieren
Wenn Sie jeden Schritt in einem typischen Produktprozess erfassen, stellt sich heraus, dass der Großteil der Arbeit aus Meta-Arbeit besteht: Ergebnisse dokumentieren, Übergabedokumente erstellen, Maßnahmen strukturieren und Kontext zwischen Personen übertragen. E-Mails, Tabellen, Übergabe-Präsentationen. Notwendig, aber nicht dort, wo Wert entsteht.
Teams, die Agenten sinnvoll einsetzen, haben diese Verwaltungsebene automatisiert und die gewonnene Zeit in die Gespräche reinvestiert, in denen Produktentscheidungen tatsächlich getroffen werden: das Vertiefen in Domänenwissen, Prioritäten und Rahmenbedingungen mit Stakeholdern.
Eine Kontextebene, die Informationsverlust bei Übergaben verhindert
Das größte strukturelle Problem in der Produktentwicklung ist der Kontextverlust. Jede Übergabe verliert Information. Zwischen Discovery und Design. Zwischen Design und Engineering. Zwischen einem Meeting und dem nächsten.
Eine zentrale Context-Engineering-Ebene, aufgebaut mit Agenten und MCP Servers, begegnet dem direkt. Agenten verbinden sich mit Discovery-Tools, rufen unstrukturierte Sitzungsdaten ab und strukturieren diese automatisch in Produktbriefings, Feature-Boards und Prioritätsmatrizen. Dieser strukturierte Kontext fließt in Design-Tools, wo Agenten echte Komponenten aus dem vorhandenen Design-System aufbauen. Von dort gelangt er in Engineering-Tickets mit Akzeptanzkriterien und Design-Referenzen.
Kein manuelles Kopieren von Informationen zwischen Tools. Der Kontext fließt, anstatt zu zerfallen.
Das macht auch paralleles Erkunden praktikabel. Fünf Lösungsansätze können gleichzeitig anhand echter Design-System-Komponenten und Discovery-Daten prototypisiert und anschließend gemeinsam bewertet werden. Fünf Prototypen manuell zu erstellen würde Wochen dauern. Agenten übernehmen den Gerüstbau; Engineers übernehmen die Beurteilung.
Spezifikationsgetriebene Entwicklung
Wie Entwicklungsarbeit definiert wird, hat sich parallel zu ihrer Ausführung verändert. Klassische Tickets beschreiben Abnahmekriterien: Wann ist etwas fertig? Agentische Teams gehen zunehmend zu Specs über. Anstatt aufzulisten, was ein Feature leisten soll, beschreibt eine Spec das angestrebte Ergebnis als vollständigen Workflow – einschließlich Sonderfällen.
Der Agent arbeitet diese Spezifikation Schritt für Schritt ab und prüft sein Ergebnis selbst dagegen. Das funktioniert nur, weil der Kontext aus Discovery und Design bereits geladen ist. Der Agent arbeitet auf ein klar definiertes Ziel hin. Siehe auch: Spielt Prompt Engineering noch eine Rolle?.
Was tatsächlich schiefgeht
Der häufigste Fehler liegt nicht darin, dass Agenten schlechten Code schreiben. Sie schreiben plausiblen Code. Code, der läuft, Code, der eine oberflächliche Prüfung besteht – der aber im Verborgenen Annahmen trifft, die nicht zutreffen, APIs referenziert, die in Ihrer Version nicht existieren, oder ein Problem so löst, dass drei andere entstehen.
Es wurde beobachtet, dass Agenten veraltete Dokumentation mit Überzeugung verwenden, Datenbankspalten erfinden und elegante Lösungen bauen, die die bestehende Architektur vollständig ignorieren.
Die eigentliche Gefahr besteht darin, dass die Reviewdisziplin sinkt, wenn die Qualität der Agentenausgabe steigt. Teams beginnen dem Agenten zu vertrauen. Sie überfliegen statt zu lesen. Sie genehmigen statt zu hinterfragen. Man spricht hier manchmal von AI Slop, und dessen Verhinderung gehört heute genauso zur Engineering-Rolle wie das Entwickeln von Features. KI-generierten Code zu reviewen erfordert aktiven Einsatz: Drei Ebenen haben sich in der Praxis bewährt. Der Agent schreibt. Automatisiertes Review filtert. Ein menschlicher Engineer trifft die endgültige Entscheidung. Mehr dazu, was sich in diesem Bereich verändert hat, erfahren Sie unter was sich am Code Review verändert hat.
Die besten Engineers in einem agentischen Workflow sind nicht die besten Programmierer. Sie sind die besten Denker.
Ihre Organisation ist möglicherweise noch nicht bereit
All das oben Beschriebene funktioniert nur, wenn Ihre Grundlagen stimmen.
Fehlt ein Design System, produzieren Agenten inkonsistente Designs. Fehlt eine modulare Codebasis, entsteht unwartbarer Output. Fehlt strukturierte Dokumentation, hat die Kontextebene keine Grundlage.
Teams, die agentische Entwicklung einführen wollen, aber auf einer Legacy-Codebasis sitzen, müssen den bestehenden Code zuerst in einen arbeitsfähigen Zustand bringen. Ein praktischer Weg: Sie schreiben eine ausführliche Testsuite für die alte Codebasis und lassen Agenten den Code auf einen modernen Stack umbauen, während sie gegen diese Tests validieren. Die Tests sind dann die maßgebliche Referenz. Besteht der umgebaute Code die Tests, wissen Sie, dass er funktioniert. Das ist eine Form von human-in-the-loop engineering auf Architekturebene.
Die Unternehmen, die den größten Nutzen aus der agentischen Entwicklung ziehen, haben zuerst in die grundlegende Arbeit investiert: saubere Architektur, dokumentierte Konventionen, modularer Code, ein Design-System, das Agenten erweitern können. Das Werkzeug ist nur so gut wie das System, das darum herum aufgebaut wurde.
In einem AI-native Team
AI-native Engineers, die in agentischen Pipelines arbeiten, verbringen mehr Zeit damit, Code zu lesen und zu überprüfen, als ihn von Grund auf neu zu schreiben, da Agenten ganze Module schneller aufbauen können, als ein einzelner Mensch tippen kann. Context Engineering – nicht nur das Schreiben von Prompts – wird zur Kernkompetenz: Die Qualität dessen, was ein Agent produziert, hängt stark davon ab, wie gut die umgebende Dokumentation, die Konventionen und die Spezifikationen strukturiert sind. Teams benötigen zudem eine klare Verantwortlichkeit für die Review-Phase, da das Volumen der agentisch generierten Ausgaben die manuelle Prüfung leicht übersteigen kann, wenn niemand explizit dafür zuständig ist.
Was wir prüfen
Bei der Auswahl von Engineers für agentische Rollen führen wir zwei Assessments durch, wie unter so prüfen wir beschrieben. Das erste prüft die Grundlagen ohne AI-Tools: Kann der Engineer Code selbstständig lesen und nachvollziehen? Im zweiten, dem AI-native Assessment, arbeitet er mit Agenten an einer realistischen Aufgabe. Dieses Assessment prüft das Urteilsvermögen unter Praxisbedingungen: Erkennt er eine halluzinierte API? Fällt ihm eine Architekturannahme auf, die nicht trägt? Kann er generierten Code prüfen, den er nicht selbst geschrieben hat? Diese Fähigkeiten bestimmen, ob ein Engineer in einem agentischen Team wirksam arbeitet, unabhängig von der reinen Coding-Geschwindigkeit.
