Agentisches Engineering in der Praxis: Spezifikation, Kontext, Verifikation und Verantwortung

„Agentisches Engineering“ wird oft als Ergebnis dargestellt: Agenten bauen die Software. Unserer Erfahrung nach ist es eine Sammlung von Praktiken. Agenten übernehmen abgegrenzte Aufgaben; Menschen entscheiden, welche Aufgaben das sind, prüfen die Ergebnisse und bleiben verantwortlich für das, was in Produktion geht. Ohne diese Praktiken wird aus Tempo Nacharbeit.

Dieser Artikel beschreibt die vier Praktiken, die wir in jedem Projekt anwenden: Spezifikation, gemeinsamer Kontext, Verifikation und Verantwortung. Keine davon ist neu. Was sich mit Agenten ändert, ist, wie konsequent sie eingehalten werden müssen.

1. Spezifikation: Jede Aufgabe beginnt schriftlich

Ein Agent kann die Produktmanagerin nicht fragen, was sie gemeint hat. Bevor ein Agent den Code anfasst, schreibt der Engineer deshalb eine kurze Aufgabenspezifikation.

Task: Add organization invitations by email
Scope: api/invitations/*, web/settings/members/*
Out of scope: billing, SSO
Constraints:
  - active organization comes from the session, never the request body
  - invitation tokens expire after 7 days
Checks:
  - unit tests for expiry and reuse
  - an admin of org A cannot invite into org B
  - typecheck and lint pass

Die Spezifikation setzt eine Grenze ebenso wie ein Ziel. Dateien außerhalb des Umfangs bleiben unangetastet; alles, was der Agent außerhalb dieser Grenze vorschlägt, wird abgelehnt, so vernünftig es auch aussehen mag.

2. Gemeinsamer Kontext: Entscheidungen gehören ins Repository

Agenten arbeiten mit dem, was sie lesen können. Wenn die Gründe hinter der Architektur nur im Kopf einer Person oder in einem alten Chatverlauf existieren, erfindet der Agent sie neu – meist anders. Wir halten kurze Entscheidungsprotokolle, Architekturnotizen und Coding-Konventionen im Repository fest, direkt neben dem Code.

• Entscheidungsprotokolle erklären das Warum: „Die Mandantentrennung wird in der Datenbank und in der API durchgesetzt, weil …“
• Architekturnotizen beschreiben die Grenzen: welches Modul welche Daten verantwortet.
• Konventionen regeln Fehlerbehandlung, Benennung und Testmuster.

Dieselben Dateien helfen auch neuen Engineers am ersten Tag. Kontext, der für Agenten geschrieben wurde, erweist sich als Kontext für Menschen.

3. Verifikation: Nichts wird auf Vertrauen gemergt

Jede Änderung eines Agenten kommt als normaler Pull Request. Bevor ein Mensch sie prüft, laufen automatisierte Checks: Typprüfungen, Linting und die in der Spezifikation genannten Tests. Danach liest ein Engineer den Diff Zeile für Zeile.

Wir bevorzugen kleine Diffs. Eine Agenten-Änderung mit 2.000 Zeilen lässt sich nicht sauber prüfen, also teilen wir die Arbeit stattdessen auf. Kritische Dateien wie Authentifizierung, Abrechnung und Migrationen erhalten eine zusätzliche prüfende Person.

4. Berechtigungen und Verantwortung

Agenten erhalten die Berechtigungen, die eine Aufgabe erfordert, und nicht mehr: Repository lesen, Tests ausführen, einen Pull Request öffnen. Sie erhalten keine Produktionszugangsdaten, keine Deploy-Rechte und keinen Zugriff auf Datenspeicher von Kunden.

Für jede Änderung, die in Produktion geht, ist ein namentlich benannter Engineer verantwortlich. Wenn um 2 Uhr nachts etwas ausfällt, lautet die Antwort auf „Wer versteht das?“: ein Mensch, kein Tool.

Wo Agenten am meisten helfen – und wo nicht

So eingesetzt, verkürzen Agenten klar definierte Arbeit – ein Teil dessen, warum wir uns für einen festen Umfang auf ein erstes Release in 30 Tagen festlegen können. Die Methode zählt mehr als das Tool. Lesen Sie mehr über KI-gestützte Umsetzung oder, wenn Sie KI in Ihren eigenen Workflows einsetzen möchten, über KI-Automatisierung.