Programmieren ist nicht tot – Teil 2: Coding Agents richtig nutzen

Im ersten Teil dieser Serie haben wir geklärt, warum Programmieren nicht einfach verschwindet — sondern sich fundamentaler verändert. Jetzt wird es konkret: Wie arbeiten Teams heute wirklich mit Coding Agents — und was bedeutet das für Architektur, Tools und tägliche Workflows?

Coding Agents verändern den Workflow

Teams, die ernsthaft mit Coding Agents arbeiten, berichten ziemlich konsistent von denselben Verschiebungen: Geschwindigkeit steigt — vor allem bei Recherche, Refactoring und Boilerplate. Qualität verbessert sich, weil ständiges Gegenchecken und Iterieren Fehler früh sichtbar macht. Und der Fokus verschiebt sich weg von Syntax, hin zu Struktur und Entscheidungen.

Der entscheidende Punkt ist nicht, dass Code schneller entsteht. Agents verändern, wie Arbeit überhaupt strukturiert wird. Typischer Effekt: weniger „ich implementiere jetzt Feature X”, mehr „ich orchestriere mehrere Schritte und prüfe Ergebnisse”. Das ist ein anderer Modus — und er braucht Zeit, sich zu setzen.

Der Hebel ist Context Engineering, nicht das Modell

Ein verbreiteter Denkfehler: besseres Modell = bessere Ergebnisse. In der Praxis ist es umgekehrt: besserer Kontext = bessere Ergebnisse.

Gute Teams arbeiten mit Agents ähnlich wie mit einem erfahrenen Entwickler:

Konkrete Aufgaben — „Refactor Auth-Service, gleiche API behalten” statt „mach was mit der Auth”
Explizite Constraints — „Keine neuen Dependencies, muss in bestehende Architektur passen”
Gezielter Kontext — nur die Dateien, die wirklich nötig sind, nicht der ganze Monolith
Feedback-Schleifen — Output prüfen, nachschärfen, iterieren

Das ist kein Prompting im klassischen Sinne mehr. Das ist Context Engineering — und es wird zur Kernkompetenz. Teams, die das können, arbeiten um Größenordnungen schneller als solche, die einfach Anfragen stellen und Outputs übernehmen.

Task-Slicing entscheidet über Erfolg oder Frust

Viele Probleme mit Coding Agents sind keine Modellprobleme — es sind falsch geschnittene Aufgaben.

Typische Fehler:

Zu groß → Agent verliert Kontext, Ergebnis wird inkonsistent
Zu klein → unnötiger Overhead, kein echter Gewinn
Zu unklar → inkonsistente Ergebnisse, die sich schwer bewerten lassen

Was gut funktioniert: Aufgaben so schneiden, dass sie in sich abgeschlossen und direkt prüfbar sind. Ergebnis validieren (Tests, Diff, Logs), dann den nächsten Schritt delegieren.

Ein Agent ist stark in klar abgegrenzten Transformationsschritten. Er ist schwach, wenn die Aufgabe lautet: „Baue mir das komplette System.”

Learning Curve ist real — und wird unterschätzt

Produktiv mit Agents zu arbeiten fühlt sich am Anfang langsamer an. Das ist normal.

Man lernt:

wie viel Kontext genug ist — und wann es zu viel wird
wann ein Chat „kippt” und die Antwortqualität abnimmt
wann ein Neustart sinnvoller ist als Nachschärfen
wie man Fehler früh im Diff erkennt, bevor sie sich weiter ausbreiten

Das lernt man nicht durch Lesen. Nur durch Nutzung im echten Projekt — mit echten Fehlern und echtem Feedback.

Local-first wird plötzlich relevant

Sobald mehrere Agents parallel arbeiten, wird ein Problem sichtbar: Latenz killt Flow.

Cloud-first-Architektur stößt hier schnell an Grenzen. Roundtrips kosten Zeit, Kontext muss ständig neu übertragen werden, offline geht nichts. Deshalb verschiebt sich gerade einiges:

lokale Modelle und hybride Setups werden attraktiver
persistenter Kontext im Editor statt immer neu aufzubauen
weniger API-Calls, mehr State vor Ort

Das Ziel ist Reaktion in Millisekunden statt Sekunden. Nicht weil die Cloud grundsätzlich schlechter ist — sondern weil schnelle Iteration Latenz als limitierenden Faktor sichtbar macht.

Sync wird zum eigentlichen Fundament

Wenn Code lokal liegt, aber mehrere Instanzen — Menschen und Agents — gleichzeitig daran arbeiten, braucht man Synchronisation. Das ist kein neues Problem, aber ein neu relevantes.

Früher war Git die zentrale Wahrheit: du pushst, du pullst, du mergst. Jetzt entsteht ein kontinuierlich synchronisierter Zustand, der auf klassische Pull/Push-Zyklen schlecht passt.

Technisch bedeutet das: CRDTs oder ähnliche Modelle, event-basierte Updates statt Polling, Konfliktauflösung in Echtzeit. Tools wie Figma oder Notion zeigen das Prinzip schon lange — jetzt kommt es in die Entwicklung.

Multi-Agent statt Single-Agent

Ein weiterer Shift, der sich gerade vollzieht: nicht mehr ein Agent pro Task, sondern mehrere spezialisierte Agents parallel.

Beispiele aus der Praxis:

ein Agent für Refactoring
einer für Tests
einer für Dokumentation
einer für Code-Review

Der Entwickler wird dabei zum Orchestrator — er verteilt, prüft, entscheidet. Das ist ein komplett anderes Arbeiten als klassisches Coding. Und es verlangt andere Fähigkeiten: nicht tippen, sondern steuern.

Architektur verändert sich — subtil, aber tiefgreifend

Klassische Architektur war API-first: Server als zentrale Instanz, Client fragt an, bekommt Antwort.

Was sich gerade verschiebt:

Lokaler State als Ausgangspunkt statt zentraler Server
Kontinuierliche Synchronisation statt Request-Response-Zyklen
Weniger harte Grenzen zwischen Frontend und Backend
Mehr reaktive Systeme — State verändert sich, statt dass Responses ankommen

Vorteil ist schnelle UX ohne Roundtrips. Kehrseite ist höhere Komplexität im State-Handling. Das erfordert Entwickler, die Systeme denken können — nicht nur Features implementieren.

AI verändert nicht die Verantwortung

Ein häufiger Einwand lautet: „Dann generiert man ja nur noch Code.”

Ja. Aber: Schlechte Entwickler generieren schneller schlechten Code. Gute Entwickler validieren schneller guten Code.

Die Verantwortung verschiebt sich nicht — sie wird sichtbarer. Wichtiger als je zuvor sind Architekturentscheidungen, systemisches Verständnis und sauberes Review. Die Qualität bleibt menschliche Verantwortung. Nur die Geschwindigkeit, mit der sich Entscheidungen auswirken, ändert sich.

Der eigentliche Skill-Shift

Der Unterschied zwischen Entwicklern wird sich verschieben.

Weniger relevant wird:

Tippgeschwindigkeit
Syntax-Wissen auswendig
Boilerplate-Erfahrung

Mehr relevant wird:

Agents präzise steuern
Kontext sauber strukturieren
Ergebnisse schnell und zuverlässig bewerten
Systeme als Ganzes denken

Das sind keine neuen Skills. Aber sie werden jetzt zum Engpass. Wer sie hat, arbeitet mit Agents effektiv. Wer sie nicht hat, erzeugt mit Agents nur schneller Rauschen.

So sieht ein echter Agent-Arbeitstag aus

Ein typischer Flow mit Coding Agents sieht nicht spektakulär aus — aber strukturiert. Weniger „ich programmiere”, mehr „ich steuere”.

Einstieg: Kontext laden statt Code lesen

Statt einer langen Phase, in der Code manuell gescannt wird, werden die relevanten Dateien ausgewählt und das Ziel formuliert:

„Erkläre mir den Auth-Flow in diesen drei Dateien. Wo sind mögliche Schwachstellen?”

Ergebnis: schneller Überblick, erste Hypothesen für Änderungen.

Task definieren und schneiden

Nicht direkt loslegen, sondern sauber schneiden. Der Unterschied zwischen:

„Baue Login neu”

und:

„Refactoriere die Token-Validierung ohne API-Änderungen. Ziel: bessere Testbarkeit.”

ist kein Detailproblem — es ist der Unterschied zwischen brauchbarem und unbrauchbarem Output.

Erste Umsetzung: Diff prüfen, nicht den ganzen Code

Der Agent bekommt gezielten Kontext und generiert einen Vorschlag. Geprüft wird der Diff, nicht die gesamte Datei. Der typische Loop:

Vorschlag generieren
Diff prüfen
Gezielt nachschärfen

Nicht: neue Anfrage stellen und von vorne beginnen.

Iteration statt Perfektion

Die erste Lösung ist selten die beste — und das ist kein Fehler. Statt neu anzufangen, wird gezielt korrigiert:

„Der Code funktioniert, aber ist schwer testbar. Mach ihn dependency-injectable.”

Dieser Schritt — gezieltes Nachschärfen — ist oft wertvoller als der erste Vorschlag.

Tests: Fälle definieren, Varianten generieren lassen

Agents sind stark beim Generieren von Tests. Aber die wichtigen Fälle definiert der Entwickler — der Agent ergänzt Varianten:

„Schreibe Unit-Tests für diese Funktion. Dann: Welche Edge Cases fehlen noch?”

Zwei Anfragen, nicht eine. Der zweite Schritt ist oft der interessantere.

Parallelisierung: der eigentliche Hebel

Der echte Geschwindigkeitsgewinn entsteht nicht durch schnelleres Tippen — sondern durch Parallelisierung. Während Feature A reviewt wird, läuft parallel: Tests generieren, Doku schreiben, Refactoring vorbereiten. Das ist der Punkt, an dem Coding Agents ihren vollen Effekt entfalten.

Kontext bewusst beenden

Wichtig, wird oft vergessen: Chat resetten, neuen Task sauber starten. Ohne Reset entsteht Context Drift — die Antwortqualität nimmt schleichend ab, ohne dass es sofort auffällt.

Konkrete Patterns aus der Praxis

Hier ein paar Patterns, die sich in der täglichen Arbeit bewähren.

Code verstehen — schneller Einstieg

Erkläre mir, was diese Funktion macht.
Fokus:
- Datenfluss
- mögliche Edge Cases
- Schwachstellen

Erkläre es wie einem neuen Teammitglied in drei Minuten.

Refactoring ohne Risiko

Refactoriere diesen Code mit folgenden Constraints:
- gleiche API beibehalten
- keine neuen Dependencies
- Fokus auf Lesbarkeit und Testbarkeit

Zeige nur den Diff und erkläre kurz die Änderungen.

Der Constraint-Block ist entscheidend: er begrenzt den Scope und zwingt den Agent zu einer strukturierten Antwort.

Debugging: strukturiert, nicht intuitiv

Hier ist der Code und die Fehlermeldung.
Finde die wahrscheinlichste Ursache.

Antworte strukturiert:
1. Ursache
2. Warum das passiert
3. Fix-Vorschlag

Gib mir zwei alternative Hypothesen, falls das nicht stimmt.

Tests generieren — mit Qualität

Schreibe Unit-Tests für diese Funktion.

Fokus:
- normale Fälle
- Edge Cases
- Fehlerfälle

Keine trivialen Tests.

Danach immer separat: „Welche wichtigen Testfälle fehlen noch?” Der zweite Prompt findet meistens mehr als der erste.

Architektur-Feedback

Hier ist mein Ansatz für Feature X.

Bewerte:
- Skalierbarkeit
- Komplexität
- typische Fehler in ähnlichen Designs

Schlage eine einfachere Alternative vor, falls möglich.

Stark für frühe Entscheidungen — bevor viel Code existiert, der Richtung vorgibt.

Task-Splitting

Ich will Feature X bauen.

Teile das in kleine, umsetzbare Schritte auf:
- jeder Schritt maximal ein bis zwei Stunden
- klare Abhängigkeiten

Reihenfolge: was muss zuerst stehen?

Unterschätzt, aber oft der größte Hebel. Gut strukturierte Tasks ergeben gut strukturierte Outputs.

Code-Review durch Agent

Review diesen Code wie ein Senior Developer.

Fokus:
- Bugs
- Lesbarkeit
- Architekturprobleme

Sei kritisch, aber konkret. Keine generischen Hinweise.

Kontext bewusst resetten

Ignoriere alles vorherige.

Wir starten neu.
Hier ist nur der relevante Kontext:
[...]

Extrem wichtig in längeren Sessions. Wenn Antworten schlechter werden oder der Fokus abdriftet — nicht weiter iterieren, sondern resetten.

Anti-Patterns, kurz

„Mach mal komplett Feature X” — zu groß, kein klares Ergebnis prüfbar
20 Dateien gleichzeitig in den Kontext — Agent verliert Fokus
Output blind übernehmen ohne Diff-Prüfung — Fehler wandern in die Codebasis
Kein Reset nach langer Session — schleichende Qualitätsverschlechterung

Was das konkret bedeutet

Nicht: „Agents ersetzen Entwickler.”

Sondern: Entwickler, die Agents nutzen, arbeiten anders als solche, die es nicht tun — und der Unterschied wird größer, je länger er anhält.

Das Tool ist nicht der Unterschied. Der Umgang damit ist es. Context Engineering, Task-Slicing, Parallelisierung, bewusstes Resetten — das sind keine Tricks, das ist das eigentliche Handwerk.

Und das Handwerk ist lernbar. Es braucht echte Projekte, echte Fehler und echtes Feedback — kein Tutorial ersetzt das.