Die erste Generation von KI-Unterstützung im Editor war im Kern eine bessere Autovervollständigung: Sie schlug die nächste Zeile vor, ergänzte eine Funktionssignatur, füllte eine Schleife aus. Der Mensch blieb dabei durchgehend am Steuer, Zeile für Zeile. Diese Phase geht gerade zu Ende.
Aktuell rückt eine andere Arbeitsweise in den Vordergrund, für die sich der Begriff agentisch etabliert hat. Gemeint ist damit ein Werkzeug, das nicht nur einen Vorschlag liefert, sondern eine Aufgabe in mehreren Schritten selbst abarbeitet: Dateien im Projekt lesen, Zusammenhänge erfassen, Änderungen an mehreren Stellen vornehmen, Befehle ausführen, Ergebnisse prüfen. Claude Code ist eines der Werkzeuge, die genau diesen Ansatz in konkrete Entwicklungsabläufe übertragen. Dass die Golem Karrierewelt inzwischen einen Workshop zu Grundlagen und fortgeschrittenen agentischen Workflows anbietet, ist ein gutes Indiz dafür, dass das Thema die Phase des Ausprobierens verlässt und in der Projektpraxis ankommt.
Was sich an der Arbeitsweise tatsächlich ändert
Der Unterschied ist weniger ein technischer als ein organisatorischer. Bei der Autovervollständigung war die Einheit der Arbeit die Zeile. Bei agentischen Workflows ist sie die Aufgabe – also eher das, was sonst in einem Ticket steht.
Damit verschiebt sich die Rolle der Entwicklerin und des Entwicklers in drei Richtungen:
- Vom Schreiben zum Beschreiben. Wer eine Aufgabe delegiert, muss sie präzise formulieren: Was soll erreicht werden, welche Randbedingungen gelten, welche Stellen im Projekt sind tabu. Unscharfe Anforderungen werden teuer, weil sie unscharfe Ergebnisse erzeugen – nur eben schneller.
- Vom Tippen zum Prüfen. Der Anteil des Lesens von Code steigt gegenüber dem Schreiben. Ein Änderungssatz, der zehn Dateien berührt, verlangt anderes Review als eine handgeschriebene Methode.
- Vom Einzelschritt zum Ablauf. Sinnvoll wird die Arbeitsweise dort, wo Aufgaben wiederkehrende Muster haben: Migrationen, Refactorings, Testabdeckung nachziehen, Schnittstellen anpassen.
Kürzere Zyklen erzeugen neuen Prüfbedarf
Für Kundenprojekte ist der Effekt zunächst angenehm: Aufgaben, die früher einen halben Tag Fleißarbeit bedeuteten, sind schneller durch. Das verkürzt Entwicklungszyklen und macht es realistischer, technische Schulden zwischendurch abzubauen, statt sie auf ein großes Refactoring zu schieben.
Der Aufwand verschwindet dabei aber nicht, er wandert. Wenn mehr Codeänderungen pro Tag entstehen, wird die Qualitätssicherung zum Nadelöhr. Konkret betrifft das drei Bereiche:
Review. Ein Pull Request – also ein zur Prüfung eingereichter Änderungssatz – mit dreißig geänderten Dateien ist praktisch nicht mehr seriös lesbar. Agentische Arbeit braucht deshalb kleine, thematisch geschnittene Änderungssätze, auch wenn das Werkzeug technisch in einem Durchgang mehr erledigen könnte. Die Disziplin, Aufgaben klein zu halten, wird wichtiger als vorher.
Tests. Automatisierte Tests waren immer sinnvoll, werden hier aber zur Voraussetzung. Sie sind das Netz, das prüft, ob eine schnell erzeugte Änderung die bestehende Funktionalität unangetastet lässt. Projekte ohne belastbare Testabdeckung profitieren von agentischen Workflows deutlich weniger, weil jede Änderung manuell nachgeprüft werden muss.
Nachvollziehbarkeit. Wer in einem halben Jahr verstehen will, warum eine Stelle so aussieht, wie sie aussieht, braucht Commit-Nachrichten und Dokumentation, die die Absicht festhalten – nicht nur das Ergebnis. Das gilt bei delegierter Arbeit stärker, weil niemand im Team die Änderung Zeile für Zeile selbst getippt hat.
Verantwortung bleibt, wo sie war
Ein Punkt, der in der Diskussion gern untergeht: Die Haftung für ausgelieferten Code verändert sich nicht. Ob eine Funktion von Hand entstanden ist oder von einem Agenten erzeugt wurde, ist gegenüber der Kundschaft und gegenüber Prüfstellen irrelevant. Wer freigibt, verantwortet.
Praktisch bedeutet das, dass Teams Regeln brauchen, bevor sie solche Werkzeuge breit einsetzen. Sinnvolle Fragen sind: In welchen Repositories darf ein Agent arbeiten? Welche Bereiche – Zahlungsabwicklung, Authentifizierung, personenbezogene Daten – bleiben ausgenommen oder erfordern ein Vier-Augen-Prinzip? Wie gehen wir mit Abhängigkeiten um, die ein Agent vorschlägt? Und welche Daten aus dem Projekt dürfen überhaupt an einen externen Dienst übertragen werden? Gerade der letzte Punkt ist in vielen mittelständischen Projekten die eigentliche Hürde und gehört vor die technische Evaluierung.
Wie ein Einstieg realistisch aussieht
Der Sprung von punktueller Autovervollständigung zu delegierten Aufgaben lässt sich nicht durch die Installation eines Werkzeugs erledigen. Er verlangt eingeübte Abläufe – deshalb gibt es zu genau diesem Übergang inzwischen Schulungsangebote.
Ein pragmatischer Weg beginnt mit gut abgrenzbaren, risikoarmen Aufgaben: Tests für bestehenden Code ergänzen, veraltete Aufrufe projektweit ersetzen, Dokumentation aus dem Code heraus aktualisieren. Das erzeugt Erfahrung, ohne dass ein Fehler direkt in produktiven Geschäftslogik landet. Erst wenn Review- und Testroutinen mit dem höheren Durchsatz mithalten, lohnt es sich, komplexere Aufgaben zu übertragen.
Ebenso wichtig ist eine ehrliche Messung. Wer den Nutzen belegen will, sollte nicht die Menge des erzeugten Codes betrachten, sondern die Durchlaufzeit von der Anforderung bis zur Freigabe – und die Fehlerquote danach. Mehr Code ist kein Ergebnis, sondern ein Kostenfaktor.
Was das für Web- und Softwareprojekte bedeutet
Agentische Workflows verschieben den Engpass in Projekten von der Umsetzung zur Qualitätssicherung. Wer in Testabdeckung, klein geschnittene Änderungssätze und klare Freigaberegeln investiert, kann die kürzeren Zyklen tatsächlich in schnellere Releases umsetzen; wer das nicht tut, produziert vor allem schneller Nachbesserungsbedarf. Für die Projektplanung heißt das: Reviewkapazität und Testinfrastruktur gehören ab jetzt genauso in die Kalkulation wie die Entwicklungszeit selbst.