TL;DR. Agentic Engineering baut den Software Development Lifecycle rund um KI-Agenten auf, geerdet im Wissen deiner Firma. Es ist nicht KI, die du auf ein bestehendes Produkt draufschraubst. Im DACH-Mittelstand hat fast niemand begonnen, und das Problem ist Führung und Kultur, nicht die DSGVO. Der Aufbau folgt drei Schritten nach dem Buy-in: Codebase-Wissen extrahieren, Security-Risiko abbilden, ein echtes Testset bauen. Erst dann deployst du einen Agenten.
Im Mai 2026 betrat ein Produktverantwortlicher, mit dem ich eng arbeite, eine deutsche Softwarefirma. Produkt seit Jahrzehnten am Markt. Ein Raum voller Senior-Entwickler. Fast keine KI-Erfahrung in der gesamten Produktabteilung.
Kein Startup, das die Welle verpasst hat. Eine Firma mit tiefem Software-Know-how, die es schlicht nie probiert hat.
Wir gehen davon aus, alle seien jetzt agentisch unterwegs. Wir leben in der Blase. Der DACH-Mittelstand ist die eigentliche Realität, und was ihn aufhält, ist nicht der EU AI Act, nicht die DSGVO, nicht Data Residency. Es ist Führung, Kommunikation und Kultur.
Dieser Artikel ist die lange Version eines Gesprächs aus dem Studio-Podcast mit Valentin Binnendijk, Co-Founder von TrekkSoft und STARTUPS.CH, der seit zwei Jahrzehnten analoge Geschäfte in SaaS-Firmen umbaut. Heute baut er hyperschlanke Produktteams.
Was ist Agentic Engineering, und wie unterscheidet es sich von Vibe Coding?
Agentic Engineering ist ein definierter, mehrstufiger Software Development Lifecycle, der von KI-Agenten gegen ein bestehendes Produkt ausgeführt wird, mit Integrationen, realen Daten, Security Guardrails und Tests. Vibe Coding ist schnelles Prototyping für Nicht-Programmierer auf der grünen Wiese. Gleiche Modelle, ganz andere Disziplin.
Die Verwechslung der beiden richtet realen Schaden an. Teams probieren Vibe Coding auf einer zwanzig Jahre alten Codebase aus, sehen es scheitern, und folgern, KI sei noch nicht so weit. Das Tool war für diesen Job nie gedacht.
Ein nützliches Bild: Bau dein Frontend auf Lovable, verbinde es über die API mit dem Shopify-Kern. Das ist die richtige Arbeitsteilung. Vibe Coding für die Oberfläche, Agentic Engineering für das System darunter.
Warum der DACH-Mittelstand bei Schritt eins stehen bleibt
Die Ausreden sind vorhersagbar. Wir sind speziell. Unsere Codebase ist zu komplex. Ich habe es einmal probiert, hat nicht funktioniert.
Die ehrliche Version sieht anders aus. Das Team hat Angst, die Kontrolle zu verlieren, Angst, dass der Agent es besser macht, Angst, ein neues Tool von null lernen zu müssen. Das sind keine technischen Probleme. Das sind Führungsprobleme.
Wir bauen den AI Monitor 2026 gemeinsam mit der ETH Zürich und der Universität St. Gallen genau aus diesem Grund: „Wir machen was mit KI“ ist kein Reifegrad. Über den DACH-Mittelstand hinweg zeigt sich dasselbe Muster: KI-Readiness korreliert mit Führung und Kultur, nicht mit Regulierung. [SOURCE NEEDED: AI Monitor Datenpunkt]
Warum sich das Bottleneck von Engineering zu Leadership verschoben hat
Zwanzig Jahre lang war das Engineering-Team der limitierende Faktor jeder Softwarefirma. Nicht mehr. Sobald die Transformation abgeschlossen ist, ist dein einziges echtes Limit dein Token-Budget. Bis dahin ist der Engpass Führung und Produktmanagement.
Entwickler bleiben risikoavers, und das aus guten Gründen. Sie wurden jahrelang für Verzögerungen und unterschätzte Komplexität verantwortlich gemacht. Wenn du sie ein Feature klassisch bauen lässt, können sie schätzen: ein Sprint, zwei Wochen. Wenn du sie zwingst, es mit Agenten zu bauen, können sie diese Zahl nicht nennen, weil sie das Verhalten des Agenten noch nicht kennen. Also greifen sie zu den Tools, denen sie vertrauen.
Das einzige, was diesen Default bricht, ist eine CEO- oder R&D-Stimme, die explizit sagt: Du darfst probieren und du darfst scheitern, solange du etwas lernst. Ohne diese Top-down-Erlaubnis bewegt sich nichts.
Wie bringst du Agentic Engineering auf die GuV eines CFO?
Zwei Cases, und ein CFO erkennt beide. Der Kosten-Case: gleicher Output mit weniger Leuten, oder doppelter Output mit demselben Team, nach einer Transformationsphase. Der Überlebens-Case: börsennotierte Softwarefirmen mit einem schmalen Use Case wurden mit Bewertungsabschlägen von 40 bis 50 Prozent abgestraft, weil sie keine Antwort darauf haben, wie Wert in einer agentischen Welt aussieht. [SOURCE NEEDED: SaaS-Multiples-Daten]
Der Überlebens-Case ist der stärkere. Er verschiebt das Spending von „Innovation Budget" zu „im Markt bleiben."
Als wir Aioma in sechs Monaten auf 30 Leute skaliert haben, war die Mathematik simpel: jeder zusätzliche Engineer war ein linearer Kostenpunkt. Mit einem agentischen Stack biegt sich diese Linie. Das ist der Teil, der den CFO tatsächlich interessiert.
Der Drei-Schritte-Aufbau nach dem Leadership-Buy-in
Sobald die Führung committed ist, beginnt die eigentliche Arbeit. Drei Schritte, bevor du einen einzigen Agenten deployst.
Wissen extrahieren. Dein Produkt ist über Jahrzehnte gewachsen. KI ist heute schon gut darin, alles davon zu lesen: den Code, jede Abhängigkeit, die Dokumentation, die Slack-Historie, die Jira- und Support-Tickets. Manches Wissen sitzt nur in den Köpfen der Senior-Entwickler, lass sie das System durchsprechen, transkribiere es, füttere es ein. Das Resultat ist ein strukturierter Context Hub, und er muss kontinuierlich wachsen. Ohne ihn ist der Agent ein brillanter Junior mit Morgen-Amnesie.
Security-Risiko abbilden. Auch die Angreifer haben KI. Neue Modelle werden gut darin, Zero-Day-Schwachstellen zu finden, die bisher nie entdeckt wurden. [SOURCE NEEDED: Zero-Day-KI-Paper] Bevor Agenten irgendwas verändern, willst du einen klaren Security-Überblick, damit du weisst, was zuerst zu fixen ist.
Testset bauen. Fünfzig Unit Tests bei fünf Prozent Coverage reichen nicht. Du brauchst ein umfassendes End-to-End-Set, idealerweise tausende Szenarien auf Basis realer Nutzungsdaten, möglicherweise einen Digital Twin des Systems. Agenten ändern viel, schnell. Die Tests sagen dir, ob es noch funktioniert.
Erst nach diesen drei Schritten deployst du deinen ersten Agenten, und du startest sequenziell: ein Modul, eine API, ein Frontend. Nicht überall gleichzeitig.
Genau diese Architektur bauen Simon Scheurer und ich in Teklens ein: ein Knowledge Hub, der GitHub, Jira, Confluence, Slack, Dokumente und beliebige APIs in einen durchsuchbaren Graph zusammenführt, eine Agent-Runtime, die via RAG darauf aufsetzt, und Use Cases (Workflow-Assistenten, SaaS-Modernisierung, Due-Diligence-Pakete) darüber. Der Punkt des Diagramms: du startest nicht beim Use Case. Du startest beim Hub.
Warum Agentic Engineering ein GTM-Problem ist, nicht nur ein R&D-Problem
Diesen Teil übersehen die meisten Operator. Agentic Engineering ist nicht nur eine Development-Story. Es ist eine Revenue-Story.
Wenn du ein Release pro Jahr ausspielst, hast du einen Versuch pro Jahr, Product-Market-Fit im agentischen Layer deines Produkts zu finden. Ein Wettbewerber mit monatlichen Releases hat zwölf. Er iteriert dich in die Irrelevanz. Der Sinn der Transformation ist genau, diese Schleife so zu verdichten, dass du Positionierung und Value schnell genug testen kannst.
Das Value Proposition selbst muss sich auch verändern. Kunden wollen nicht mehr Software, in die sie Daten eingeben und einen Report rausbekommen. Sie wollen Outcomes und erledigte Workflows. Das ist ein Repositionierungs-Problem, und Repositionierung ist ein GTM-Job, kein Engineering-Job.
Die interne Verdichtung zählt ebenfalls. Wenn Support Eskalationen direkt an einen Agenten gibt, wenn Product Management 50 Themen priorisiert statt auf 5 herunterzukürzen, beschleunigt sich der gesamte Revenue-Motor. Schlanke agentische Produktteams ändern deine Unit Economics, und Unit Economics ändern, wie du verkaufst. Die längere Argumentation findest du unter Revenue Systems & GTM Engineering.
Wo Agentic Engineering bricht
Drei Failure Modes, geordnet nach Häufigkeit.
Die Talent-Lücke. Das Skillset ist für alle neu, es gibt keinen tiefen Pool, aus dem du hiren kannst. Entweder du holst jemanden mit echter Erfahrung rein, oder du akzeptierst eine lange interne Lernkurve. Eine Abkürzung gibt es nicht.
Die Single-Prompt-Fantasie. „Claude code, fix it" auf einer Codebase mit zwanzig Millionen Zeilen wird scheitern, und das Team wird die Technologie verantwortlich machen statt die Erwartung. Die Erwartung muss ein mehrstufiger Prozess mit Iteration sein, nicht ein magischer Befehl.
Die „Kann ich das einfach kaufen?"-Falle. Das häufigste Scheitern, das ich sehe: Firmen, die Agentic Engineering wie eine Lizenz kaufen und dann vergessen wollen. So funktioniert es nicht. Es wird trainiert, nicht gekauft. Tägliche Verbesserung, wie ein Team-Mitglied.
Der Mindshift, vom CEO abwärts
Hör auf, KI als Use-Case-Liste auf dein Produkt zu schrauben. Bau das Operating System darunter: Kontext, Security, Tests. Dann lass die Agenten los.
Der Shift geht vom CEO, der Vibe Coding lernen muss, über den R&D-Leader, der überzeugt werden muss, dass es funktioniert, bis zum Entwickler, der neue Tools annimmt und tägliche Veränderung akzeptiert. Wenn dieser Shift nicht stattfindet, scheitert es.
Der Zug ist abgefahren. Der Bus fährt noch.
Willst du die wöchentliche Version davon? Abonnier den The Science of GTM Newsletter und bekomm die Aufschlüsselung, wie Produkt, GTM und KI als ein System operieren. Oder trag dich auf die Warteliste für die AI GTM Lab Cohort ein, wenn du das Playbook live willst.
FAQ
Was ist Agentic Engineering?
Agentic Engineering ist ein definierter, mehrstufiger Software Development Lifecycle, der von KI-Agenten gegen ein bestehendes Produkt ausgeführt wird, mit Integrationen, realen Daten, Security Guardrails und Tests. Es unterscheidet sich von Vibe Coding, das schnelles Prototyping für Nicht-Programmierer auf der grünen Wiese ist.
Ist die DSGVO der Hauptblocker für KI-Adoption im DACH-Mittelstand?
Nein. Felderfahrung und der AI Monitor zeigen beide, dass Führung, Kommunikation und Kultur die primären Blocker sind. Regulierung ist eine lösbare Einschränkung. Das härtere Problem ist Führungs-Commitment und Entwickler-Risikoaversion.
Wo startest du mit Agentic Engineering in einer bestehenden Softwarefirma?
Schritt eins ist Leadership-Buy-in mit Budget für Tooling und Coaching und expliziter Erlaubnis zu scheitern. Danach folgt die Engineering-Arbeit in drei Schritten: Codebase-Wissen in einen Context Hub extrahieren, das Security-Risiko abbilden, ein umfassendes Testset bauen. Erst dann deployst du deinen ersten Agenten, ein Modul nach dem anderen.
Warum ist Agentic Engineering relevant für Go-to-Market, nicht nur Engineering?
Weil es Release-Kadenz, Value Proposition und Unit Economics verändert. Schnellere Iteration lässt dich Positionierung testen, bevor Wettbewerber es tun. Kundenerwartungen verschieben sich von Software-die-du-bedienst zu gelieferten Outcomes. Schlankere agentische Teams ändern, wie du verkaufst.
Kannst du eine Agentic-Engineering-Lösung von der Stange kaufen?
Nein. Agentic Engineering muss auf dein Produkt, deine Codebase und deinen Prozess trainiert werden und sich kontinuierlich verbessern. Es als einmaligen Kauf zu behandeln ist der häufigste Grund, warum Transformationen scheitern.
