Agentisches Programmieren: Das Ende von handgeschriebenem Code

Handgeschriebener Code hat ein Ablaufdatum

Nicht in fünf Jahren. Jetzt.

Das ist keine Übertreibung und keine Marketing-These. Das ist das, was wir jeden Tag in unseren Engagements sehen. Die Werkzeuge haben sich verändert. Nicht ein bisschen. Grundlegend.

Vor zwei Jahren war „KI-gestützte Entwicklung” ein Texteditor, der die nächste Zeile vorschlägt. GitHub Copilot. Autocomplete auf Steroiden. Nützlich, sicher. Aber kein Paradigmenwechsel. Der Entwickler schrieb immer noch jede Zeile. Er schrieb sie nur schneller.

Das ist vorbei.

Von Autocomplete zu Orchestrierung

Heute schreiben Agenten Code. Ganze Module. Komplette Funktionen. Testsuites. Infrastruktur-Konfigurationen. Der Mensch definiert das Ziel, beschreibt die Constraints und orchestriert den Prozess. Der Agent liefert.

Das ist der Unterschied zwischen einem Fahrerassistenzsystem und einem selbstfahrenden Auto. Copilot war Tempomat. Claude Code, Cursor und Codex sind Systeme, die eigenständig navigieren.

Wir arbeiten so. Jeden Tag. In echten Kundenprojekten. Das ist unser Werkzeugkasten.

Agenten schreiben Code. Menschen orchestrieren. Wer das nicht versteht, versteht die nächsten zehn Jahre Softwareentwicklung nicht.

Wie unser Werkzeugkasten aussieht

Claude Code für komplexe Architekturentscheidungen und größere Codeblöcke. Es versteht Kontext, navigiert durch Codebasen und produziert Code, der nicht nach Template aussieht. Wir nutzen es als primäres Werkzeug für Greenfield-Entwicklung und Refactoring.

Cursor als IDE mit eingebautem Agenten. Der Editor weiß, was das Projekt tut. Er sieht den gesamten Kontext. Wenn wir in einem Astro-Projekt eine Komponente überarbeiten, versteht Cursor die Abhängigkeiten, die Imports und die Tailwind-Klassen.

Codex für parallelisierte Aufgaben. Mehrere Agenten, die gleichzeitig an verschiedenen Teilen arbeiten. Bei der Multi-Agenten-Orchestrierung wird der Entwickler zum Dirigenten, nicht zum einzelnen Instrumentalisten.

Das klingt nach Theorie. Ist es nicht. Die Website, auf der Sie gerade lesen, wurde mit diesem Stack gebaut, als ganz normale Arbeitsweise.

Was sich für Entwicklungsteams ändert

Die Werkzeuge sind der sichtbare Teil des Wandels. Die größere Veränderung liegt in der Arbeitsweise.

Früherer Rhythmus: Entwickler öffnet IDE. Tippt Code. Debuggt. Tippt mehr Code. Review. Merge. Nächstes Ticket.

Neuer Rhythmus: Entwickler definiert die Aufgabe präzise. Agent schreibt die erste Version. Entwickler prüft, korrigiert die Richtung, lässt den Agenten iterieren. Ergebnis in einem Bruchteil der Zeit.

Die Fähigkeit, die zählt, verschiebt sich: weg von „wie schreibe ich diesen Algorithmus”, hin zu „wie beschreibe ich präzise, was ich brauche”. Weniger Syntax, mehr Architektur.

Das bedeutet nicht, dass Entwickler überflüssig werden. Das Gegenteil. Gute Entwickler werden wertvoller. Wer den Code versteht, den der Agent produziert, wer Architekturentscheidungen treffen kann, wer weiß, welche Fragen er dem Agenten stellen muss: der ist produktiver als je zuvor.

Wer allerdings seinen Wert darin sieht, Code von Hand zu schreiben, hat ein Problem.

Warum die meisten Teams das nicht allein schaffen

Der Umstieg auf agentisches Programmieren ist mehr als „Cursor installieren, fertig”. Er erfordert neue Workflows und ein anderes Qualitätsmanagement.

Prompt Engineering ist eine Fähigkeit. Nicht jeder Entwickler kann einem Agenten präzise genug beschreiben, was er braucht. Das ist erlernbar, aber es braucht Anleitung.

Code Review ändert sich. Wenn der Agent 500 Zeilen in fünf Minuten produziert, muss das Review-Verfahren mitziehen. Wer reviewt wie vorher, erzeugt einen Engpass.

Vertrauen muss aufgebaut werden. Teams, die noch nie mit Agenten gearbeitet haben, misstrauen dem Output. Zu Recht: Blindes Vertrauen ist falsch, blindes Misstrauen aber auch. Es braucht Erfahrung, um zu wissen, wo man dem Agenten vertrauen kann und wo nicht.

Wir bringen diese Erfahrung mit, wenn wir in ein Team kommen: als Praxis statt Schulung. Pair Programming mit Agenten. Code Reviews von agentengeschriebenem Code. Echte Aufgaben aus dem echten Backlog, gelöst mit dem neuen Werkzeugkasten.

Der COBOL-Vergleich

In den Achtzigern gab es Programmierer, die gesagt haben: „Hochsprachen sind Spielzeug. Richtiger Code wird in Assembler geschrieben.” Sie hatten nicht unrecht; Assembler ist schneller und näher an der Maschine. Aber die Welt hat sich weitergedreht. Wer 1990 nur Assembler konnte, war raus.

Dann kamen die Neunziger. COBOL-Programmierer sagten: „Objektorientierung ist ein Hype.” Zwanzig Jahre später suchen Unternehmen verzweifelt die letzten COBOL-Entwickler, um Systeme zu warten, die niemand neu bauen will.

Wir stehen an der gleichen Schwelle. Der Entwickler, der sich weigert, Orchestrierung zu lernen, ist der COBOL-Programmierer von 2030. Nicht sofort. Nicht in einem Jahr. Aber der Trend ist eindeutig.

Die Teams, die jetzt den Umstieg machen, werden einen strukturellen Vorteil haben: mehr Output und kürzere Zykluszeiten. Beides messen wir bei uns selbst; das ist ein Messwert, kein Versprechen.

Was wir tun

Wenn wir in ein Entwicklungsteam kommen, bringen wir den Werkzeugkasten mit. Claude Code, Cursor, Multi-Agenten-Workflows. Wir zeigen nicht Folien. Wir arbeiten mit dem Team an echten Aufgaben. Der Agent schreibt Code, wir orchestrieren zusammen, das Team lernt durch Praxis.

Nach 100 Tagen gehört der Werkzeugkasten dem Team. So wie die Architektur, die Methoden und die Infrastruktur. Das ist das Modell.

Handgeschriebener Code hat ein Ablaufdatum. Die Frage ist nicht ob, sondern wann Ihr Team umsteigt.