Artikel

Artikel · 6 Min

Agentic Development im Enterprise-Alltag

Coding-Agenten sind keine Demo mehr. Was in großen Organisationen funktioniert - und woran es scheitert.

Ein Agent, der aus einem Ticket einen fertigen Pull Request macht, sieht in der Demo beeindruckend aus. Im Konzern trifft er auf zwanzig Jahre alten Code, drei Freigabeinstanzen und ein Security-Team, das zu Recht nachfragt. Hier ist, was wir gelernt haben.

Agenten brauchen kleine, klare Aufgaben

Je präziser die Aufgabe, desto besser das Ergebnis. „Baue das neue Kundenportal“ funktioniert nicht. „Aktualisiere diese Bibliothek in allen Services und passe die Tests an“ funktioniert erstaunlich gut. Die besten Einstiegsaufgaben sind wichtig, wiederkehrend und unbeliebt.

Kontext schlägt Modell

Das stärkste Modell nützt wenig, wenn es die Architektur nicht kennt. Der größte Hebel liegt darin, Agenten den richtigen Kontext zu geben: Coding-Guidelines, Architekturentscheidungen, Domänenbegriffe, Beispiele für guten Code. Wer dieses Wissen strukturiert ablegt, hilft Agenten - und neuen Kolleg:innen gleich mit.

Events statt Chat

Im Alltag werden Agenten selten von Hand gestartet. Sie reagieren auf Ereignisse: Ein Issue bekommt ein Label, ein Build schlägt fehl, eine Abhängigkeit hat eine Sicherheitslücke. Das macht sie zu Teamkollegen, die im Hintergrund arbeiten, statt zu Werkzeugen, die man bedienen muss.

Der Mensch bleibt im Loop - an der richtigen Stelle

Agenten sollten nicht direkt in den Hauptzweig schreiben. Der Pull Request ist die natürliche Freigabestelle: Das Team sieht, was sich ändert, warum, und kann ablehnen. Damit verschiebt sich die Arbeit von Schreiben zu Prüfen - und Review wird zur Kernkompetenz.

Sicherheit von Anfang an

  • Agenten laufen in isolierten Umgebungen mit minimalen Rechten.
  • Zugangsdaten sind kurzlebig und auf die Aufgabe beschränkt.
  • Jede Aktion wird protokolliert - nachvollziehbar für Audits.

Woran es scheitert

Nicht an der Technik. Agentic Development scheitert, wenn niemand für die Agenten verantwortlich ist, wenn Ergebnisse nicht gemessen werden oder wenn Teams das Gefühl haben, ersetzt statt entlastet zu werden.

Unser Rat: Mit einem Team und einer Aufgabenklasse starten, sauber messen, dann skalieren.

Ein Teil des Teams von SII Germany

Lassen Sie uns
sprechen.