Coding-Agents im Entwicklungsalltag: Was trägt, was nicht

von Christoph Knauft · 20.5.2026 · 3 Min. Lesezeit

  1. Softwareentwicklung
  2. KI

Auf unserer Karriereseite steht ein Tech-Radar, und wer genau hinsieht, findet dort einen scheinbaren Widerspruch: KI-gestützte Entwicklung steht im äußersten Ring — „Assess” — und gleichzeitig schreiben wir dazu: wir nutzen sie täglich. Beides stimmt. Coding-Agents sind bei uns Alltagswerkzeug geworden, aber wir sind noch dabei zu lernen, was wirklich trägt. Dieser Artikel ist der Zwischenstand — ohne Hype und ohne Abgesang.

Was trägt

Mechanische Breite. Die deutlichste Stärke: Änderungen, die nicht schwer, aber breit sind. Ein Muster über dreißig Dateien nachziehen, eine API-Migration, Testgerüste für bestehende Module, Boilerplate jeder Art. Was früher ein zäher Nachmittag war, ist heute ein präziser Auftrag plus eine Review. Der Agent wird nicht müde und vergisst nicht die Datei Nummer 27.

Code-Erkundung. Unterschätzt, aber im Alltag fast wertvoller: Agents als Recherche-Werkzeug in gewachsenen Codebasen. „Wo wird dieser Status überall gesetzt?”, „Wie hängt dieser Ablauf zusammen?” — Fragen, die früher eine Stunde Grep und Lesen kosteten, beantwortet ein Agent in Minuten, mit Verweisen zum Nachprüfen. Gerade beim Einstieg in Bestandssysteme ist das ein echter Hebel.

Tests zuerst. Wir haben hier schon vor Jahren über testgetriebene Entwicklung geschrieben, und die Disziplin zahlt sich jetzt doppelt aus: Agents sind gut darin, Testfälle vorzuschlagen — auch Randfälle, an die man selbst nicht sofort denkt. Und umgekehrt sind vorhandene Tests das beste Geländer, an dem agentisch erzeugter Code entlanglaufen muss. Wer eine belastbare Testbasis hat, kann Agents deutlich mutiger einsetzen.

Erste Entwürfe. Prototypen, Dokumentations-Rohfassungen, MR-Beschreibungen — überall dort, wo eine solide erste Version mehr wert ist als ein leeres Blatt, liefern Agents zuverlässig ab.

Was (noch) nicht trägt

Der fachliche Schnitt. Wo eine Aggregatgrenze verläuft, welche Invarianten ein Modell durchsetzen muss, wie sich ein Geschäftsprozess sinnvoll in Bausteine zerlegt — das ist Domänenarbeit, und sie bleibt Menschenarbeit. Ein Agent schlägt bereitwillig Strukturen vor, aber er kennt weder die Geschichte hinter den Anforderungen noch die Gespräche mit dem Fachbereich. Domain-Driven Design wird durch Agents nicht überflüssig; es wird wichtiger, weil jemand dem Werkzeug die Richtung geben muss.

Plausibel ist nicht korrekt. Die tückischste Fehlerklasse: Code, der gut aussieht, sauber benannt ist, kompiliert — und an einer Stelle subtil das Falsche tut. Solche Fehler übersieht man beim Querlesen leichter als handgeschriebene, gerade weil die Oberfläche so überzeugend ist. Die Arbeit verschwindet also nicht, sie verschiebt sich: vom Schreiben zum Prüfen.

Großzügigkeit. Agents neigen dazu, mehr Code zu erzeugen als nötig — eine Abstraktion auf Vorrat, ein Fallback, den niemand braucht. Einfachheit muss man explizit einfordern, sonst wächst die Codebasis schneller, als ihr guttut.

Was sich am Workflow ändert

Drei Dinge haben sich bei uns spürbar verschoben:

  1. Die Review ist die Arbeit. Vier-Augen-Prinzip und Merge Requests hatten wir immer — aber das Gewicht liegt jetzt dort. Kleine, klar geschnittene Aufträge an den Agenten erzeugen kleine, prüfbare Änderungen. Wer dem Agenten „bau das Feature” sagt, bekommt eine Review-Last, die jeden Zeitgewinn auffrisst.
  2. Spezifizieren wird zur Kernfähigkeit. Der Engpass ist nicht mehr das Tippen, sondern das präzise Beschreiben: Was soll entstehen, was gilt als fertig, was darf sich nicht ändern? Das ist dieselbe Fähigkeit, die gute Anforderungsarbeit immer ausgemacht hat — sie wird jetzt nur im Minutentakt abgefragt.
  3. Lernen braucht bewusste Räume. Die ehrliche offene Frage: Wer heute anfängt, lernt anders. Verständnis entsteht auch durch das eigene Schreiben — wer nur noch prüft, was ein Agent erzeugt hat, baut anderes Wissen auf. Wir achten deshalb darauf, dass nicht jede Aufgabe durch den Agenten läuft, gerade in der Einarbeitung.

Fazit

Warum also weiterhin „Assess” und nicht „Adopt”? Weil Adopt bei uns heißt: seit Jahren in Produktion, wir kennen die Grenzen. Bei Coding-Agents kennen wir die Grenzen erst in Umrissen, und die Werkzeuge ändern sich schneller, als sich Urteile festigen. Was sich aber jetzt schon sagen lässt, passt zu einem Satz, den wir hier oft schreiben: Gute Software ersetzt keinen Menschen — gute Werkzeuge auch nicht. Coding-Agents machen unsere Entwickler nicht überflüssig. Sie machen den Unterschied zwischen sorgfältiger und schludriger Ingenieursarbeit nur deutlicher sichtbar als je zuvor.