Coding-Agenten sind in der Softwareentwicklung angekommen. Eine Umfrage von JetBrains kommt zu dem Ergebnis, dass neun von zehn Entwicklerinnen und Entwicklern regelmäßig mit einem solchen Werkzeug arbeiten. Gemeint sind damit Assistenten, die nicht nur einzelne Codezeilen vorschlagen, sondern eigenständig mehrere Schritte ausführen: Dateien lesen, Änderungen schreiben, Tests starten, Ergebnisse auswerten.

An der Spitze der Beliebtheitsliste steht laut Umfrage Claude Code, und zwar mit deutlichem Abstand. GitHub Copilot folgt als zweites Werkzeug, das breit im Einsatz ist. Damit hat sich innerhalb kurzer Zeit ein Feld formiert, in dem zwei Namen den Alltag prägen — während die Frage, wie man mit diesen Werkzeugen verlässlich arbeitet, erst in Ansätzen beantwortet ist.

Von der Autovervollständigung zum Agenten

Der Unterschied zur klassischen Code-Vervollständigung ist praktisch relevant. Ein Vorschlag im Editor lässt sich in einer Sekunde annehmen oder verwerfen. Ein Agent dagegen arbeitet über mehrere Minuten und hinterlässt am Ende eine Reihe von Änderungen, die gemeinsam geprüft werden müssen. Die Verantwortung verschiebt sich damit vom Schreiben zum Beurteilen.

Das erklärt, warum die Verbreitung so hoch ist und die Diskussion trotzdem nicht abflacht. Ein Werkzeug, das neun von zehn Personen in einem Team nutzen, ist kein Experiment mehr, sondern Teil des Entwicklungsprozesses — mit allen Konsequenzen für Code-Review, Testabdeckung und Nachvollziehbarkeit von Änderungen.

Das Repository wird zur Arbeitsumgebung des Agenten

Genau an dieser Stelle setzt eine zweite Beobachtung an. Unter dem Begriff Agentic Engineering — also die bewusste Gestaltung von Projekten für die Zusammenarbeit mit KI-Agenten — widmet sich ein Webinar der the native web GmbH am 26. August 2026 der Frage, wie ein Repository beschaffen sein muss, damit ein Agent darin verlässlich arbeiten kann.

Die Fragestellung ist bemerkenswert, weil sie den Blick umdreht. Nicht das Modell ist der Engpass, sondern das Projekt, in dem es arbeitet. Ein Agent liest den Code, die Konfiguration, die Dokumentation und die Testergebnisse — und leitet daraus ab, was er tun soll. Wenn diese Grundlage unklar ist, produziert er unklare Ergebnisse.

Aus der Praxis von Web- und TYPO3-Projekten lassen sich einige Punkte benennen, an denen dieser Unterschied sichtbar wird:

  • Nachvollziehbare Struktur: Ein Projekt mit erkennbaren Konventionen für Verzeichnisse, Namen und Zuständigkeiten ist für einen Agenten leichter zu erfassen als eine über Jahre gewachsene Sonderlösung.
  • Automatisierte Tests: Sie sind die Rückmeldung, an der ein Agent seine Änderungen prüfen kann. Ohne sie fehlt die Kontrollinstanz, die aus einem Vorschlag ein belastbares Ergebnis macht.
  • Reproduzierbare Setups: Lässt sich das Projekt mit wenigen definierten Schritten starten, kann ein Agent Änderungen tatsächlich ausprobieren statt nur zu vermuten.
  • Dokumentierte Entscheidungen: Warum ein Modul so gebaut ist, wie es gebaut ist, steht selten im Code. Genau diese Information verhindert, dass ein Agent gewachsene Entscheidungen versehentlich rückgängig macht.

Kürzere Zyklen, aber nicht automatisch weniger Aufwand

Für Kundenprojekte bedeutet die hohe Verbreitung zunächst: Routinearbeit wird schneller. Refactorings, Migrationen, das Anlegen wiederkehrender Strukturen, das Schreiben von Tests — hier zeigen Agenten ihren praktischen Nutzen am deutlichsten.

Der Aufwand verschwindet dabei aber nicht, er wandert. Wenn mehr Änderungen in kürzerer Zeit entstehen, steigt der Bedarf an Qualitätssicherung. Reviews müssen gründlicher werden, nicht oberflächlicher, weil eine plausibel aussehende Änderung nicht zwangsläufig eine richtige ist. Teams, die diesen Schritt überspringen, verlagern Fehler lediglich in eine spätere Projektphase, in der ihre Korrektur teurer ist.

Was die beiden Meldungen gemeinsam zeigen

Die Umfrage beschreibt einen Zustand: Coding-Agenten sind Standard, und zwei Werkzeuge dominieren. Das Webinar-Thema beschreibt eine offene Baustelle: Wie muss ein Projekt aussehen, damit diese Werkzeuge zuverlässig arbeiten? Beides zusammen ergibt ein realistisches Bild einer Technologie, die breit genutzt wird, deren methodische Einbettung aber noch entsteht.

Zur Einordnung gehört auch, was die Quellen nicht sagen. Über Produktivitätsgewinne in Zahlen, über Fehlerraten oder über die Qualität der erzeugten Änderungen liegen hier keine Angaben vor. Wer eine Werkzeugentscheidung trifft, sollte sie daher nicht allein auf Beliebtheitswerte stützen, sondern an der eigenen Codebasis prüfen.

Ein pragmatischer Einstieg

Für Unternehmen, die den Einsatz von Coding-Agenten strukturieren wollen, empfiehlt sich ein abgegrenzter Anfang statt eines flächendeckenden Rollouts:

  1. Ein Projekt auswählen, das gut getestet und überschaubar ist — dort ist das Risiko kalkulierbar und die Rückmeldung schnell.
  2. Vor dem Agenteneinsatz die Grundlagen prüfen: Läuft die Testsuite, ist das Setup reproduzierbar, sind die Konventionen dokumentiert?
  3. Klären, welche Aufgabentypen delegiert werden und welche nicht — Sicherheitsrelevantes und Architekturentscheidungen bleiben sinnvollerweise beim Team.
  4. Review-Regeln anpassen: Wer prüft agentengenerierte Änderungen, und woran wird die Freigabe festgemacht?
  5. Erfahrungen festhalten, damit aus Einzelfällen eine belastbare Arbeitsweise wird.

Für Web- und Softwareprojekte heißt das: Die Frage ist nicht mehr, ob Coding-Agenten eingesetzt werden, sondern wie gut ein Projekt darauf vorbereitet ist. Investitionen in Testabdeckung, saubere Struktur und dokumentierte Entscheidungen zahlen sich doppelt aus — sie helfen dem Team und machen den Agenten überhaupt erst nutzbar. Wer bestehende Codebasen in diese Richtung entwickelt, verkürzt Entwicklungszyklen nachhaltiger als durch die Wahl eines bestimmten Werkzeugs.

Quellen