Agentic Coding 2026: CTOs bauen Entwicklerteams um

Ein CTO, der 2026 noch nach dem Personalschlüssel von 2023 plant, baut ein Team für Probleme, die es nicht mehr gibt. Während die Personalabteilung Stellenausschreibungen für Junior-Entwickler nach altem Muster formuliert, verschiebt sich in den Engineering-Organisationen gerade die Grundlage, auf der diese Ausschreibungen einmal Sinn ergaben.

Das eigentliche Problem sitzt tiefer als die Frage, ob ChatGPT 5.6 gut programmiert. CTOs stehen vor den Budgetrunden für 2026 – ohne belastbare Daten darüber, wie viele Junior-Entwickler, Reviewer und Architekten sie tatsächlich noch brauchen. Wer jetzt Entscheidungen auf Basis von Bauchgefühl oder LinkedIn-Hype trifft, riskiert entweder überdimensionierte Teams mit doppelten Kosten oder ausgedünnte Organisationen, die niemand mehr hat, der KI-generierten Code verantworten kann. Das gilt unabhängig davon, ob man auf ChatGPT 5.6, Anthropics Claude Code oder Cognitions Devin setzt – die Rollenfrage stellt sich bei jedem agentischen Coding-Tool gleich.

Dieser Artikel ordnet ein, was ChatGPT 5.6 als autonomer Code-Agent technisch tatsächlich leistet, wo sich Teamstrukturen konkret verschieben – und welche Schritte CTOs jetzt einleiten sollten, bevor die Budgets für 2026 fixiert sind.

Der entscheidende Unterschied zu früheren Modellgenerationen liegt nicht in besseren Code-Snippets. ChatGPT 5.6 arbeitet als Agent auf Repository-Ebene: Das Modell analysiert Abhängigkeiten über Dutzende Dateien hinweg, versteht Import-Strukturen, erkennt, welche Module von einer Änderung betroffen sind, und plant Änderungen entsprechend. Wer bisher mit Copilot-artigen Autovervollständigungen gearbeitet hat, unterschätzt diesen Sprung systematisch – es geht nicht mehr um Vorschläge im Editor, sondern um eigenständig ausgeführte Arbeitspakete.

Konkret heißt das: Der Agent erhält ein Ticket, analysiert die betroffenen Codepfade, implementiert die Änderung und erstellt eigenständig einen Pull Request – inklusive Commit-Messages, die den Änderungsverlauf dokumentieren, und einer Beschreibung der Änderungslogik, die erklärt, warum welche Datei angefasst wurde. Für Standardaufgaben wie Dependency-Updates, API-Anpassungen nach Schema-Änderungen oder das Nachziehen von Deprecations funktioniert dieser Workflow in vielen Teams bereits ohne menschliches Eingreifen bis zum Review.

Dazu kommt die automatisierte Testfall-Generierung. Das Modell leitet aus der bestehenden Codebasis ab, welche Edge Cases eine Funktion abdecken muss – Null-Werte, Grenzbereiche, Race Conditions bei asynchronen Aufrufen – und generiert entsprechende Tests. In Projekten mit historisch niedriger Testabdeckung ist das oft der schnellste messbare Nutzen, das bestätigt sich in der technischen Begleitung von Migrationsprojekten immer wieder als erster Anwendungsfall, an dem Teams Vertrauen in Agentic Coding aufbauen.

Wer das Modell produktiv einsetzt, stößt auf vier wiederkehrende Grenzen:

• Kontextfenster: Auch mit erweitertem Kontext erfasst das Modell große Monolithen nicht vollständig. Bei Repositories jenseits einiger Hunderttausend Zeilen arbeitet der Agent mit Ausschnitten – und übersieht Seiteneffekte in Bereichen, die es nicht geladen hat.
• Business-Logik: Je komplexer die fachliche Logik, desto höher die Fehlerquote. Ein Rabattsystem mit zwölf historisch gewachsenen Sonderfällen versteht der Agent nur so gut, wie die Sonderfälle dokumentiert sind – also meist gar nicht.
• Garbage in, garbage out: Die Qualität der Agent-Outputs korreliert direkt mit der Qualität der Eingabe-Codebasis. Inkonsistente Patterns, fehlende Typisierung und tote Codepfade verwirren das Modell messbar.
• Ambiguität: Unpräzise formulierte Tickets führen zu technisch korrekten, fachlich falschen Lösungen – der Agent fragt nicht nach, er entscheidet.

Diese Fähigkeiten und Grenzen sind der technische Ausgangspunkt. Sie verändern unmittelbar, wer im Team welche Aufgabe übernimmt – und der erste Ort, an dem das sichtbar wird, ist das Junior-Level.

Die klassische Junior-Rolle war jahrzehntelang klar definiert: Boilerplate-Code schreiben, einfache Bugfixes übernehmen, Testabdeckung erhöhen, kleinere Features unter Anleitung umsetzen. Genau dieses Aufgabenprofil deckt ein Code-Agent inzwischen weitgehend ab – schneller, rund um die Uhr und ohne Onboarding-Phase.

Das verschiebt die Erwartungshaltung fundamental. In Teams, die Agenten produktiv einsetzen, prüfen und korrigieren Junior-Entwickler zunehmend KI-generierten Code, statt ihn selbst zu schreiben. Aus der Produktionsrolle wird eine Prüfrolle – und das ist ein Problem, das viele Engineering-Leiter noch nicht zu Ende gedacht haben.

Denn hier entsteht eine Qualifikationslücke mit Ansage: Code reviewen kann nur, wer versteht, wie guter Code entsteht. Wenn Nachwuchskräfte nie lernen, ein Feature von Grund auf zu bauen, Fehler selbst zu machen und Debugging unter Druck zu erleben, fehlt ihnen genau die Erfahrung, die für qualifiziertes Review nötig wäre. Die Branche riskiert, sich ihre eigene Senior-Pipeline abzuschneiden – ein Effekt, der erst in fünf bis acht Jahren voll durchschlägt, wenn die heutigen Juniors die Seniors von morgen sein sollten.

Die Praxis reagiert bereits, und zwar deutlich. Klarna ist das prominenteste Beispiel: CEO Sebastian Siemiatkowski kommunizierte offen, dass das Unternehmen unter Verweis auf KI-Produktivität die Belegschaft schrumpfen ließ – von rund 5.000 auf etwa 3.500 Mitarbeitende, primär über einen Einstellungsstopp statt Entlassungen. Siemiatkowski formulierte es unmissverständlich:

"KI kann bereits alle Jobs erledigen, die wir Menschen machen. Es ist nur eine Frage, wie wir sie in der Organisation einsetzen."

Dass Klarna später zurückruderte und in Teilbereichen wieder Menschen einstellte, gehört zur ehrlichen Bilanz dazu – und leitet direkt zur nächsten Frage über: Bevor CTOs aus solchen Schlagzeilen den Schluss ziehen, KI ersetze Entwicklerteams, lohnt ein nüchterner Blick auf die Grenzen dieser These.

Die These vom vollautomatischen Entwicklerteam scheitert in der Praxis an drei Stellen, die in keiner Produktdemo vorkommen.

Erstens: Autonome Code-Agenten scheitern regelmäßig an unklaren Anforderungen und fehlendem Geschäftskontext. Softwareentwicklung war nie primär das Tippen von Code – sie war immer das Übersetzen unscharfer Geschäftsanforderungen in präzise Systeme. Ein Agent, der ein mehrdeutiges Ticket erhält, liefert eine von fünf möglichen Interpretationen. Welche die richtige ist, entscheidet weiterhin ein Mensch, der die Domäne versteht.

Zweitens: Fehlerhafte KI-generierte Pull Requests erzeugen mehr Review-Aufwand als manuell geschriebener Code – wenn kein sauberer Prozess existiert. Ein menschlicher Entwickler, der einen PR einreicht, hat seine Änderung durchdacht und kann Rückfragen beantworten. Ein Agent liefert Volumen: Teams berichten von PR-Fluten, bei denen Seniors mehr Zeit mit dem Aussortieren plausibel aussehender, aber subtil falscher Änderungen verbringen, als sie durch die Automatisierung gewinnen. Ohne Prozess kippt der Effizienzgewinn ins Negative – genau dieses Muster beobachten wir immer wieder in Projekten, in denen Agentic Coding ohne begleitende Review-Struktur eingeführt wurde.

Drittens liefern die Marktprognosen selbst kein Ersetzungs-, sondern ein Integrationsszenario. Laut Gartner werden bis 2028 rund 33 Prozent aller Enterprise-Software-Anwendungen agentische KI enthalten – 2024 lag dieser Anteil noch unter 1 Prozent. Das ist ein massives Wachstum, aber es beschreibt die Durchdringung von Software mit Agenten-Funktionen, nicht die vollständige Automatisierung von Entwicklungsprozessen. Gartner prognostiziert im selben Zeitraum, dass etwa 15 Prozent der täglichen Arbeitsentscheidungen autonom von Agenten getroffen werden – nicht 100 Prozent.

Und hier die unpopuläre Meinung, die in den meisten Budget-Diskussionen fehlt: Der Flaschenhals verschiebt sich von "Code schreiben" zu "Code verstehen und verantworten" – und das macht Teams nicht kleiner, sondern anders zusammengesetzt. Diese Menschen sind teurer, nicht billiger.

Wenn Verdrängung also nicht die richtige Beschreibung ist – welche Rolle entsteht dann tatsächlich in Teams, die mit Code-Agenten arbeiten?

In Organisationen, die Agentic Coding ernsthaft betreiben, kristallisiert sich ein neues Rollenprofil heraus, das man am treffendsten als Review-Architekt bezeichnet. Die Rolle bündelt drei Verantwortlichkeiten, die bisher auf Tech Leads, Senior-Entwickler und Architekten verteilt waren: die Verantwortung für das Systemdesign, die Freigabe von KI-generierten Pull Requests und die durchgängige Qualitätssicherung des Agenten-Outputs.

Der Review-Architekt schreibt selbst wenig Code. Seine Kernaufgabe ist es, die Leitplanken zu definieren, innerhalb derer Agenten arbeiten dürfen – welche Patterns gelten, welche Module tabu sind, welche Änderungen automatisch mergen dürfen und welche zwingend über seinen Tisch gehen. Er ist die menschliche Instanz, die Verantwortung übernimmt, wo der Agent nur Wahrscheinlichkeiten liefert.

Damit verschieben sich die Skill-Anforderungen im gesamten Team spürbar:

Auch das Onboarding verändert sich strukturell. Junior-Rollen werden zu AI-Pairing-Rollen: Neue Entwickler lernen von Anfang an, Agenten-Output zu prüfen, zu hinterfragen und zu korrigieren – Review statt Produktion als Ausbildungspfad. Kluge Organisationen kombinieren das mit bewussten "Handarbeits-Sprints", in denen Nachwuchskräfte ohne Agenten-Unterstützung bauen, um die im vorherigen Abschnitt beschriebene Qualifikationslücke nicht entstehen zu lassen.

Die wichtigste Konsequenz für die Planung: Teamgrößen verkleinern sich nicht zwangsläufig – sie verschieben sich in Richtung Senior-schwerer Besetzung. Ein Team, das früher aus zwei Seniors, vier Mid-Levels und vier Juniors bestand, besteht künftig eher aus drei bis vier Review-Architekten, zwei bis drei Mid-Levels und zwei AI-Pairing-Rollen – bei gleichzeitig deutlich höherem Output. Wie sich solche Rollenprofile konkret in eine Systemarchitektur übersetzen lassen, zeigen wir im Detail im Bereich Software & API Development – dort finden CTOs den technischen Rahmen für agentenfähige Architekturen, nicht nur die Theorie.

Diese Rollenverschiebung hat direkte Konsequenzen für Budgetplanung und Gehaltsstrukturen – und genau dort zeigen die ersten Unternehmen bereits, wie die Rechnung für 2026 aussieht.

Die sichtbarste Verschiebung in den Budgets für 2026 verläuft von Personalkosten hin zu Lizenz- und Tooling-Budgets für Agentic-Coding-Plattformen. Was früher ein überschaubarer Posten für IDE-Lizenzen und CI/CD-Tooling war, wird zu einer eigenen Budgetkategorie: Enterprise-Zugänge für Code-Agenten, API-Kontingente, Orchestrierungs-Infrastruktur und die Evaluations-Tools, um Agenten-Output zu messen.

Klarna liefert weiterhin das Referenzbeispiel für die Personalseite: Der bereits beschriebene KI-begründete Einstellungsstopp zeigt, wie schnell sich Personalbudgets verschieben, wenn Führungsteams KI-Produktivität konsequent einpreisen. GitHub wiederum zeigt die Adoptionsseite: Nach eigenen Angaben nutzen über 90 Prozent der Fortune-100-Unternehmen Copilot-Technologie, und GitHubs eigene Studien berichten von bis zu 55 Prozent schnellerer Task-Erledigung bei unterstützten Entwicklern. Beides zusammen erklärt, warum Neueinstellungsquoten auf Junior-Level branchenweit sinken, während die Nachfrage nach Senior-Architekten mit Review- und Systemdesign-Kompetenz steigt – und deren Gehälter mit.

Eine vereinfachte Modellrechnung für eine mittelgroße Engineering-Organisation macht die Verschiebung greifbar. Die Zahlen sind bewusst als Schätzung markiert und dienen der Größenordnung, nicht der exakten Kalkulation:

Die Pointe dieser Rechnung: Das Budget sinkt nicht zwingend – es wird umgeschichtet. Der Wegfall von Junior-Stellen kompensiert die API- und Lizenzkosten für Code-Agenten sowie die teureren Senior-Profile ungefähr, während der Output pro Euro steigt. Wie stark KI-Kosten dabei ins Gewicht fallen, hängt vom Nutzungsvolumen ab – wie stark dieser Hebel wirken kann, zeigt unser Beitrag zu sinkenden KI-Inferenzkosten in der B2B-Automatisierung, der die Kostenkurve für genau diese Budgetposten einordnet.

Einen Kultureffekt sollten CTOs dabei nicht unterschätzen: Teams berichten von spürbar schnellerer Feature-Auslieferung – aber auch von deutlich höherem Review-Aufwand pro Senior-Entwickler. Die Seniors werden zum Nadelöhr, und wer sie ausschließlich mit Agenten-Reviews auslastet, riskiert Frustration bei genau den Leuten, die am schwersten zu ersetzen sind. Wie schnell sich Tooling-Landschaften dabei verschieben, zeigt auch unsere Analyse dazu, wie Code-Agenten zunehmend klassische SaaS-Tools im Entwicklungsstack ablösen – ein Muster, das sich in der Praxis branchenübergreifend wiederholt.

Diese Effizienzgewinne bringen jedoch neue Risiken mit sich, die in der Budgetplanung regelmäßig unterschätzt werden – und die teurer werden können als jede eingesparte Junior-Stelle.

Ein Punkt, der in den Produktivitätszahlen gerne verschwiegen wird: Autonome Pull Requests können Sicherheitslücken einführen, und zwar systematisch. Ein Agent, der auf öffentlichem Code trainiert wurde, reproduziert auch die unsicheren Patterns dieses Codes – hartcodierte Secrets in Beispielstrukturen, fehlende Input-Validierung, veraltete Kryptografie-Aufrufe. Wenn im Prozess keine dedizierten Security-Reviews verankert sind, wandern diese Schwachstellen mit derselben Geschwindigkeit in Produktion, mit der der Agent Features liefert. Genau die Geschwindigkeit, die als Vorteil verkauft wird, wird zum Risikomultiplikator.

Das zweite Problem ist schleichender: technische Schulden durch Muster-Wiederholung. Ein menschlicher Entwickler, der zum dritten Mal denselben Code kopiert, spürt irgendwann den Impuls zu refaktorieren. Ein Agent hat dieses Refactoring-Bewusstsein nicht – er wendet wiederholt ähnliche Lösungsmuster an, ohne die wachsende Duplikation als Problem zu erkennen. Nach zwölf Monaten agentengetriebener Entwicklung ohne Gegensteuerung finden Teams Codebasen vor, die funktionieren, aber strukturell erodiert sind: fünf leicht unterschiedliche Implementierungen derselben Logik, verteilt über das Repository.

Für regulierte Branchen kommt eine dritte Dimension dazu: Nachvollziehbarkeit. Wer in Finanzdienstleistung, Gesundheitswesen oder kritischer Infrastruktur arbeitet, muss bei Audits belegen können, wer welche Änderung warum vorgenommen und freigegeben hat. Mit dem EU AI Act, der risikobasierte Anforderungen an den Einsatz von KI-Systemen stellt, wird dieser Nachweis zusätzlich zur regulatorischen Pflicht statt zur Kür. Ein Agent, dessen Entscheidungslogik nicht dokumentiert ist, erschwert Compliance-Nachweise erheblich. "Das hat der Agent so entschieden" ist keine Antwort, die ein Prüfer der BaFin akzeptiert. Wie sich Nachvollziehbarkeit in regulierten Umgebungen praktisch lösen lässt, haben wir im financial.com Projekt konkret umgesetzt – dort wurden KI-Automatisierung und auditierbare Freigabeprozesse von Anfang an zusammen gedacht, nicht nachträglich aufgesetzt.

Die Konsequenz aus allen drei Risikofeldern ist dieselbe: Es braucht klare Freigabe-Gates, bevor KI-generierter Code in Produktion geht. Kein autonomer Merge in sicherheitskritische Module, verpflichtende Security-Scans für jeden Agenten-PR, dokumentierte menschliche Freigabe für alles, was Kundendaten oder Zahlungsflüsse berührt. Diese Gates kosten Geschwindigkeit – aber deutlich weniger als der erste Incident, der ohne sie passiert.

Die gute Nachricht: Diese Risiken lassen sich strukturell abfedern. Die Frage ist nur, wie CTOs den Umbau konkret angehen – und in welcher Reihenfolge.

Der Umbau eines Entwicklerteams auf ein agentenintegriertes Modell scheitert am häufigsten an einem Muster: Big-Bang-Einführung ohne Messung. Wer ChatGPT 5.6 organisationsweit ausrollt, bevor er die eigene Fehlerquote kennt, verhandelt Budgets auf Basis von Anbieter-Marketing statt eigener Daten. Der belastbare Weg führt über vier klar abgegrenzte Phasen.

1. Pilotprojekt mit abgegrenztem Repository (Monate 1–3): Wählen Sie ein Repository mit mittlerer Komplexität, guter Testabdeckung und ohne direkte Anbindung an kritische Systeme. Lassen Sie den Agenten dort produktiv arbeiten und messen Sie zwei Kennzahlen rigoros: die Fehlerquote der Agenten-PRs und den Review-Aufwand pro PR in Minuten. Diese beiden Zahlen sind die Grundlage jeder späteren Budget-Argumentation – ohne sie planen Sie blind.
2. Rollenprofile definieren statt Stellen streichen (Monate 3–6): Übersetzen Sie die Pilot-Erkenntnisse in konkrete Rollenprofile: Wie viele Review-Architekten braucht Ihre Organisation, welche AI-Pairing-Rollen ersetzen klassische Junior-Ausschreibungen? Passen Sie die Stellenausschreibungen für 2026 entsprechend an. Der häufigste Fehler in dieser Phase ist reine Kostensenkung – wer nur streicht, statt umzubauen, steht in achtzehn Monaten ohne Verantwortungskapazität da.
3. Verbindliche Freigabe-Gates etablieren (Monate 4–8): Bevor Agenten in kritische Systeme eingreifen dürfen, brauchen Sie dokumentierte Gates: automatisierte Security-Scans als Pflichtstufe, menschliche Architektur-Freigabe für alle Änderungen an Kernmodulen, und ein Audit-Log, das jede Agenten-Entscheidung nachvollziehbar macht. Diese Gates gehören in die CI/CD-Pipeline, nicht in ein Wiki-Dokument, das niemand liest.
4. Erfolgsmessung institutionalisieren (ab Monat 6, laufend): Messen Sie den Erfolg des Umbaus an drei Kennzahlen: Review-Zeit pro Pull Request, Fehlerquote in Produktion und Time-to-Deploy. Ausdrücklich nicht an Codezeilen-Metriken – ein Agent, der 40.000 Zeilen generiert, hat nichts geleistet, wenn davon die Hälfte im Review verworfen wird. Reporten Sie diese Zahlen quartalsweise an die Geschäftsführung, denn sie sind die Grundlage der nächsten Budgetrunde.

Wer diesen Weg nicht allein gehen will: Im Bereich KI & Automatisierung begleiten wir genau diese Pilotphasen – von der Repository-Auswahl über das Metrik-Setup bis zur Definition der Freigabe-Gates. Entscheidend bleibt dabei, dass die Messinfrastruktur und die Rollenentscheidungen im eigenen Haus verankert bleiben. Ausgelagerte Verantwortung ist keine Verantwortung.

Der Umbau ist dabei kein einmaliges Projekt mit Enddatum. Er ist ein laufender Prozess, der mit jeder Modellgeneration neu kalibriert werden muss – und der die Erkenntnisse aus Pilotphase, Rollendesign und Risikomanagement kontinuierlich in konkrete Personal- und Budgetentscheidungen übersetzt.

Was bleibt als Kernerkenntnis? Der Umbau von Entwicklerteams 2026 ist keine Frage von Personalabbau durch KI, sondern eine Neuverteilung von Verantwortung: weg von reiner Code-Produktion, hin zu Review, Architektur und Risikomanagement. Wer Budget und Rollenprofile weiterhin nach dem alten Muster plant, unterschätzt beides: die realen Effizienzgewinne von Agentic Coding und die Governance-Anforderungen, die damit einhergehen. Entscheidend wird 2026 nicht sein, wer am schnellsten Stellen abbaut, sondern wer am schnellsten die richtigen Rollenprofile aufbaut – denn der Wettbewerb um erfahrene Review-Architekten wird den Arbeitsmarkt für genau diese Profile in den kommenden Jahren spürbar verknappen.

Der konkrete nächste Schritt ist unspektakulär, aber entscheidend: Starten Sie innerhalb der nächsten Budgetrunde ein abgegrenztes Pilotprojekt mit ChatGPT 5.6 als Code-Agent – und erfassen Sie die Review-Zeit pro Pull Request als zentrale Kennzahl, bevor Sie Personalentscheidungen für 2026 fixieren. Ein CTO, der mit eigenen Messdaten in die Budgetverhandlung geht, ist jedem überlegen, der mit Vendor-Slides argumentiert. Die Organisationen, die 2026 vorne liegen, werden nicht die mit den wenigsten Entwicklern sein – sondern die mit dem klarsten Verständnis dafür, wo menschliche Verantwortung durch nichts zu ersetzen ist.