Ich habe Claude Code in den letzten drei Monaten etwa 40 % des neuen Codes in einem unserer Projekte schreiben lassen. Es funktioniert. Aber nicht so, wie die meisten denken.
Die Erwartung war klar. Ich beschreibe Aufgaben, der Agent schreibt Code, ich prüfe und merge. Wie das Führen eines schnellen Junior-Entwicklers. Die Realität sieht anders aus. Ich verbringe genauso viel Zeit an der Tastatur. Die Arbeit hat sich verlagert. Weniger Tippen, mehr Lesen. Weniger mechanischer Aufwand, mehr Nachdenken darüber, ob das, was der Agent vorschlägt, angesichts eines Kontexts, den er nicht sehen kann, wirklich Sinn ergibt.
Ich habe das meiste ausprobiert, was es gibt. Cursor, Claude Code, GitHub Copilot, OpenAI Codex. Sie sind alle brauchbar, und sie unterscheiden sich alle auf eine Weise, die je nach Arbeitsweise ins Gewicht fällt.
Alles Größere geht an Claude Code, ob das nun das Neuschreiben eines Service, der Aufbau einer Test-Suite oder das Refactoring einer ganzen Projektschicht ist. Die terminalbasierte Interaktion passt dazu, wie ich über größere Änderungen nachdenke. Cursor ist besser, wenn ich in meinem Editor bleiben und kleinere, lokale Änderungen vornehmen will. Copilot behalte ich für die Autovervollständigung und sonst nichts. Codex habe ich bei zwei Projekten ausprobiert und bin zu Claude Code zurückgekehrt. Die Ergebnisse waren in Ordnung, aber das Interaktionsmodell hat für mich nicht gepasst.
Update, Juli 2026. Seit OpenAI Codex nach Verbrauch abrechnet, ist es wieder bei uns im Einsatz. Es übernimmt inzwischen agentische Aufgaben neben Claude Code und der Text von April bleibt unverändert.
Nichts davon ist eine Empfehlung. Jedes Team, jede Person findet die eigene Passung. Das Interessante ist nicht, welches Werkzeug man wählt. Es ist das, was danach passiert.
Das Vercel-Team hinter Turborepo hat seine Erfahrungen mit KI-Agenten in der Entwicklung veröffentlicht. Vollständig autonome Schleifen (der Agent schreibt Code ohne Aufsicht) lieferten keine Ergebnisse in Produktionsqualität. Ihre Agenten erzeugten Code, der die Tests bestand, aber Logikfehler enthielt, die ein erfahrener Entwickler instinktiv bemerkt hätte. Der Code sah richtig aus. Er war es nicht.
Shopify hat öffentlich über den Einsatz von KI für interne Werkzeuge gesprochen. Google nutzt sie in großem Maßstab zur Testgenerierung. Microsoft liefert Copilot aus und setzt es vermutlich auch selbst ein. Das Muster ist bei allen dasselbe. Die KI erzeugt, Menschen prüfen. Niemand, bei dem Produktionssysteme auf dem Spiel stehen, schickt die Ausgabe eines Agenten direkt ins Deployment.
Und trotzdem dreht sich der LinkedIn-Diskurs immer wieder um Beiträge nach dem Motto „KI hat mein Team ersetzt". Dabei geht es entweder um MVPs, um Nebenprojekte oder um Fiktion.
In einem Kundenprojekt ließ ich den Agenten eine Middleware-Schicht neu schreiben. Rund 1.200 Zeilen. Konzeptionell nichts Schwieriges, aber viel mechanische Arbeit. Nach zwanzig Minuten war er fertig. Ich habe eine Stunde für die Durchsicht gebraucht, und das Ergebnis war sauberer als der ursprüngliche Code. Die Tests liefen durch, die Edge Cases waren abgedeckt, und selbst die Variablenbenennung war konsistenter als das, was die Menschen dort geschrieben hatten. Ich war beeindruckt.
Eine Woche später ließ ich ihn im selben Projekt eine Änderung an der Datenbankschicht entwerfen. Es sah gut aus. Die Tests liefen durch.
Bei der manuellen Durchsicht (Zeile für Zeile, denn so prüfe ich die Ausgabe eines Agenten inzwischen) fand ich ein Szenario, in dem Datensätze gelöscht worden wären, die hätten erhalten bleiben müssen. Die Test-Suite deckte es nicht ab. Der Agent hatte diesen Test nicht aufgenommen, weil das Szenario aus seiner Sicht im Code nicht erkennbar war. Die Information steckte in einer Kunden-E-Mail von vor drei Monaten.
Ein Agent ist kein Junior-Entwickler, der Fragen stellt. Er füllt die Stille mit plausiblem Code.
Diese zweite Aufgabe hat meine Arbeitsweise mit diesen Werkzeugen stärker verändert als jeder Blogbeitrag oder Konferenzvortrag. Die Frage war nicht mehr „Kann der Agent diesen Code schreiben", sondern „Was weiß der Agent nicht, das ich weiß".
Vor einem Jahr ging es in der Debatte darum, ob KI überhaupt Code schreiben kann. Heute zweifelt das niemand mehr ernsthaft an. Die Debatte hat sich zu Modellen der Aufsicht verschoben. Wie viel menschliche Kontrolle braucht KI-generierter Code? Wann kann man ihm vertrauen und wann nicht?
Nach dem, was ich in unserer eigenen Arbeit sehe und was andere Teams berichten:
Mechanischen Code (CRUD-Endpunkte, Migrationen, Typdefinitionen, Boilerplate-Komponenten) bewältigt der Agent gut, und der Prüfaufwand ist gering. Die Zeitersparnis ist hier real. Aus einer Aufgabe von 3-4 Stunden werden 1,5-2 Stunden. Nicht weil der Agent alles erledigt, sondern weil er die Teile übernimmt, die kein Urteilsvermögen erfordern.
Architektur, Sicherheit, Geschäftslogik mit ungeschriebenen Regeln. Das braucht weiterhin einen Menschen, der die Problemdomäne versteht, nicht nur den Code. Kein Modell, das ich genutzt habe, kann über das nachdenken, was nicht aufgeschrieben ist. Und der wichtigste Kontext in jedem Geschäftssystem ist meist genau das, was niemand aufgeschrieben hat.
Das kommt in Gesprächen mit anderen CTOs auf, und ich habe bis heute keine gute Antwort darauf. Wenn Junior-Entwickler vom ersten Tag an mit Agenten programmieren lernen, lernen sie dann, Code zu schreiben, oder lernen sie nur, Code zu lesen und freizugeben? Das sind unterschiedliche Fähigkeiten. Code zu lesen, den jemand anderes geschrieben hat, ist leichter, als ihn von Grund auf zu schreiben. Das Muskelgedächtnis, Probleme selbst zu lösen, lässt sich schwer ersetzen.
Ich weiß nicht, was das in fünf Jahren für den Beruf bedeutet. Ich weiß nur, dass gerade jetzt die Entwickler in meinem Team, die am besten mit Agenten arbeiten, diejenigen sind, die schon vorher stark waren.
KI-Coding-Agenten machen mein Team bei mechanischer Arbeit schneller. Sie machen uns nicht klüger. Sie sind genau dort gefährlich, wo sie am selbstsichersten wirken, nämlich bei Aufgaben, die Kontext erfordern, den sie nicht haben. Unser Prozess funktioniert, weil die Prüfung auffängt, was der Agent übersieht, und diese Prüfung ist bewusst langsam und menschlich.
Ob das eine Übergangsphase ist oder die dauerhafte Form der KI-gestützten Entwicklung, weiß ich ehrlich gesagt nicht.
Wenn Sie herausfinden möchten, wo KI in Ihren Entwicklungsprozess passt, sprechen wir darüber.
Gründer und technischer Leiter von Rise.sk. Er konzipiert und liefert Webanwendungen, Datensysteme und Automatisierungen und schreibt über Softwareentscheidungen, KI und digitale Dienste.
OpenAI sagt, dass GPT-5.6 Sol Claude Fable 5 beim Programmieren zu einem Drittel der Kosten schlägt. Anthropic sagt, Fable 5 führt bei der reinen Leistungsfähigkeit. Beide haben recht. Hier erfahren Sie, welches Modell welche Aufgabe gewinnt.
API-Tokens können weniger kosten als eine Entwicklerstunde, aber Tokens sind nicht das ganze Projekt. Ein praktischer Vergleich von Modellnutzung, Prüfung, Tests und Betriebskosten.
Ein KI-Agent kann Stunden sparen, aber nur, wenn Berechtigungen, Protokolle, Freigaben, Verantwortliche und Fehlerpfade entworfen sind, bevor er Produktivsysteme berührt.
Ihr Kontext entscheidet
