Agent-First Engineering

Einige Details sind verallgemeinert. Diese Arbeit läuft sowohl über ein eigenes Live-Produkt als auch über eine Enterprise-Codebase — ich beschreibe die Praxis und ihre Ergebnisse, keine internen Produkt-, System- oder Kundendetails.

Der Wandel

Die erste Welle von KI-Coding war Autocomplete — ein Modell, das einer Person in einer Datei hilft. Der eigentliche Wandel: Agenten treten in die ganze Schleife ein — planen, Kontext ziehen, Artefakte erzeugen, sie validieren und Arbeit weitergeben. Das zahlt sich nur aus, wenn das Repository selbst dafür gebaut ist. Meine Diplomarbeit begann mit einem Scoping Review, wie agentische KI tatsächlich in echten Arbeitssystemen ankommt, und kam zu einem praktischen Schluss: Das ist ein Konfigurationsproblem, bevor es ein Adoptionsproblem ist. Wirf fähige Agenten in ein kaltes, undokumentiertes Repo, und sie stochern im Nebel; der Hebel liegt darin, wie die Codebase um sie herum strukturiert ist.

Die praktische Arbeit ist genau das — keine weitere Modell-Demo, sondern die Engineering-Praxis: wie Repositories strukturiert sein sollten, wie Kontext geliefert wird, wie Teams ausgerichtet bleiben, wie Übergaben und Review-Gates funktionieren und wie mehrere Menschen und Agenten gleichzeitig arbeiten, ohne sich in die Quere zu kommen.

Was ich baue

Ein Repository, das zugleich als Betriebssystem für die Menschen und die Agenten dient, die darin arbeiten:

• Kontext dort, wo Agenten ihn lesen — eine strukturierte, versionierte Wissensbasis (nummerierte Taxonomie, maschinenlesbares Frontmatter, Querverweise), damit ein Agent eine Aufgabe fundiert statt ratend beginnt. Produktkontext liegt direkt neben dem Code, nicht in einem separaten Wiki, das Agenten nicht erreichen.
• Anweisungen, die nach Akteur routen — eine tool-agnostische Einstiegsdatei, die pro Person und pro Agent die richtige Rolle, Konventionen und Berechtigungen lädt, statt eines generischen Prompts.
• Skills und MCP-Server — wiederverwendbare, schrittweise offengelegte Skills für wiederkehrende Arbeit und angebundener Live-Tool-Zugriff (Issue-Tracker, Datenbank, Deploy, Design), damit Agenten am echten System handeln, nicht an dessen Beschreibung.
• Design in derselben Schleife — dieselbe MCP-Anbindung läuft bidirektional zu Figma: Design-Kontext liest direkt in den Code, und Struktur fließt zurück in die Design-Datei, sodass ein Designer und ich ein gemeinsames Artefakt von beiden Seiten iterieren, statt bei der Übergabe an Genauigkeit zu verlieren. Einen mehrstufigen, zweisprachigen Onboarding-Prototyp habe ich genau so gebaut.

Koordination, Übergaben und Gates

Das Schwierige ist nicht ein Agent — es sind viele Akteure, die nicht kollidieren dürfen. Das Modell, das ich gebaut habe, macht jede Grenze explizit:

• Parallele Arbeit, keine Interferenz — ein Issue, ein Branch, ein PR und eine definierte Integrationsreihenfolge, damit sich Contract-, Backend- und Frontend-Änderungen nicht gegenseitig zertrampeln.
• Contract-first-Übergaben — Schnittstellen werden vereinbart und veröffentlicht, bevor die konsumierende Arbeit beginnt, damit asynchrone Übergaben zwischen Menschen (und Agenten) nicht driften.
• Review-Gates — unabhängiges Agent-prüft-Agent-Review vor jedem menschlichen Merge: Der erzeugende Agent gilt als fehlbar, und ein frischer Agent prüft seine Arbeit — hinter Merge-Safety-Gates (grünes CI, kein Schema-Drift, Owner-Freigabe) und Runtime-Guardrails für alles, was Produktion berührt.

Der rote Faden ist der, auf den die Forschung immer wieder zeigte: Kontext → Artefakt → Validierung → Review-Gate → Übergabe → Owner. Autorität wandert zu den Gates, und nichts geht voran ohne verantwortlichen Owner.

Bewährt an einem Live-Build

Das ist keine Theorie. Es trägt meine eigene Zwei-Gründer-SaaS: Zwei Menschen und mehrere verschiedene KI-Tools arbeiten täglich an denselben Repos über genau dieses Setup — persona-geroutete Anweisungen, geteilte Skills, angebundene MCP-Server, contract-first-Übergaben und unabhängiges Review. Diese Koordinationsschicht lässt ein Zweierteam wie ein größeres agieren.

Der Ausblick

Die vorausschauende Hälfte der Arbeit trägt dieselbe Praxis in eine große, multi-service Enterprise-Codebase. Der Ansatz ist eine agent-first-Restrukturierung: Repositories querverlinken, jedem ein README und eine Agent-Kontext-Datei geben und die Produktseite — wofür jeder Service da ist — in den Code selbst liefern, sodass die Systemkarte zu etwas wird, auf dem ein Agent direkt handeln kann. Der Nutzen ist für einen KI-Agenten und einen neuen Entwickler identisch: Beide starten fundiert. Diese Hälfte läuft jetzt an.

Status

Aktiv in Arbeit und das praktische Zentrum meiner Diplomarbeit — in Produktion an meinem eigenen Produkt bewährt, mit dem Enterprise-Rollout, der jetzt anläuft.

Das ist der rote Faden hinter allem, was ich baue: Der Hebel ist heute kein einzelnes Tool, sondern echtes Produktdenken und Engineering gepaart mit der Vorstellungskraft, anders zu arbeiten — und der Konsequenz, dranzubleiben, bis die Idee wirklich läuft.