---
title: "KI-generierter Code 2026: Wie Coding Agents in der Softwareentwicklung arbeiten"
url: https://coding9.de/blog/ki-generierter-code
author: "Alexander Schikowsky"
datePublished: 2023-09-04T00:00:00.000Z
dateModified: 2026-09-30T00:00:00.000Z
description: "Coding Agents 2026: wie KI Code im ganzen Repository ändert, Tests und CI nutzt und Pull Requests stellt. Mit Workflow, Grenzen und Human Review."
---

# KI-generierter Code 2026: Wie Coding Agents in der Softwareentwicklung arbeiten

*Dieser Beitrag erschien im September 2023 und beschrieb KI-generierten Code damals vor allem als fortgeschrittene Autovervollständigung. Am 30. September 2026 haben wir ihn vollständig neu geschrieben, weil Coding Agents heute ganze Aufgaben im Repository übernehmen und die Arbeit mit KI in der Softwareentwicklung damit anders aussieht. Angaben zu Werkzeugen entsprechen dem Stand September 2026.*

2023 hieß KI-Code-Generierung: Die KI schlägt im Editor die nächste Zeile vor, und wer tippt, nimmt den Vorschlag an oder verwirft ihn. 2026 bekommt ein Coding Agent ein ganzes Ticket. Er sucht sich im Repository zusammen, was er wissen muss, ändert Code in mehreren Dateien, lässt Tests und Build laufen, korrigiert seine eigenen Fehler und stellt am Ende einen Pull Request. Dieser Artikel erklärt, wie das technisch abläuft, welche Leitplanken dafür nötig sind, wo Coding Agents heute an Grenzen stoßen und wie wir bei CODING 9 damit arbeiten.

## Von der Autovervollständigung zum Coding Agent

Die Modelle hinter den Werkzeugen sind besser geworden, der größere Unterschied liegt aber in der Arbeitsweise. Ein Coding Agent läuft in einer Schleife: Er plant einen Schritt, führt ihn mit einem Werkzeug aus (Datei lesen, Code ändern, Befehl ausführen), bewertet das Ergebnis und entscheidet über den nächsten Schritt. Das wiederholt er, bis die Aufgabe erledigt ist oder er nicht weiterkommt.

|  | **Autovervollständigung (2023)** | **Coding Agent (2026)** |
| --- | --- | --- |
| Arbeitseinheit | Zeile oder Funktion | Ticket bzw. zusammenhängender Änderungssatz |
| Kontext | geöffnete Datei und Nachbardateien | ganzes Repository, per Suche erschlossen |
| Werkzeuge | keine | Dateisystem, Terminal, Browser, MCP-Server |
| Prüfung | Entwickler beim Übernehmen | Tests, Linter, Build, CI und Code-Review |
| Ergebnis | Vorschlag im Editor | Branch mit Commits und Pull Request |

Für Unternehmen wird damit praktisch interessant, wie ein Team Aufgaben so beschreibt, dass ein Agent sie lösen kann, und wie es sicherstellt, dass nur geprüfter Code in den Hauptzweig kommt.

## Was ein Coding Agent im Repository tut

### Agentic Search: Kontext selbst suchen

Ein Coding Agent bekommt nicht das ganze Repository in den Kontext kopiert. Er sucht gezielt: Dateilisten, Volltextsuche mit Werkzeugen wie `grep` oder `ripgrep`, dann liest er die Treffer und folgt Imports, Typdefinitionen und Aufrufern. Diese Arbeitsweise heißt Agentic Search. Sie arbeitet immer auf dem aktuellen Stand des Codes und findet auch Stellen, die ein vorab berechneter Index übersehen hätte. Manche Werkzeuge kombinieren sie mit einem semantischen Index über die Codebasis.

Daraus folgt eine praktische Regel: Was sich im Repository finden lässt, kann der Agent nutzen. Konventionen, die nur in Köpfen oder in einem Chat existieren, kennt er nicht.

### Terminal und Browser

Über das Terminal installiert der Agent Abhängigkeiten, startet Tests, ruft Linter und Typecheck auf, baut das Projekt und arbeitet mit git. Die Ausgabe dieser Befehle ist sein wichtigstes Feedback: Ein roter Test oder ein Typfehler sagt ihm genauer als jede Beschreibung, was noch nicht stimmt.

Bei Frontend-Änderungen kommt ein Browser dazu. Der Agent startet die Anwendung, öffnet die Seite in einem Headless-Browser, macht Screenshots, liest die Konsole und prüft, ob ein Formular wirklich abschickt. So fallen Fehler auf, die kein Unit-Test abdeckt, etwa ein Layout, das auf dem Smartphone bricht.

### MCP: Anbindung an Ticketsystem, Doku und weitere Werkzeuge

Das [Model Context Protocol (MCP)](https://coding9.de/blog/mcp-model-context-protocol-integration) ist ein offener Standard, über den ein Agent externe Werkzeuge nutzt. Ein MCP-Server stellt Funktionen bereit, etwa Tickets lesen und kommentieren, Doku durchsuchen, Logs aus dem Monitoring abfragen oder eine Testdatenbank lesen. Der Agent holt sich damit den Kontext, der nicht im Code steht: Akzeptanzkriterien aus dem Ticket, Fehlermeldungen aus der Produktion, Entscheidungen aus dem Wiki.

Jeder MCP-Server ist dabei eine zusätzliche Berechtigung. Ein Server, der schreiben darf, kann auch falsch schreiben. Wir binden MCP-Server deshalb mit dem kleinsten nötigen Zugriff an, lesend, wo Lesen reicht.

### Projektwissen für Agents im Repository

Viele Teams legen Anweisungen für Agents direkt ins Repository, in Dateien wie `CLAUDE.md` oder `AGENTS.md`. Dort steht, wie das Projekt gebaut und getestet wird, welche Konventionen gelten und welche Bereiche besondere Vorsicht brauchen. In unseren eigenen Repositories gibt es zusätzlich eine Struktur-Doku für Agents: eine Übersicht, wo welche Routen, Komponenten und Datenmodule liegen, und Rezepte für wiederkehrende Aufgaben. Ein Agent findet damit schneller die richtige Stelle, und wenn er Code ändert, aktualisiert er die Doku im selben Commit.

## Qualitätskontrolle: Tests, Linting, CI und Review

Ein Coding Agent schreibt Code schneller, als ein Mensch ihn lesen kann. Die Qualität entsteht deshalb in den Prüfschritten, die jede Änderung durchlaufen muss, egal ob ein Mensch oder ein Agent sie geschrieben hat. Bei uns sieht die Kette so aus:

1. Lint und Typecheck laufen im Arbeitsbereich des Agents, bevor er überhaupt committet. Typfehler und Stilverstöße behebt er selbst.
2. Tests: Der Agent führt die vorhandenen Tests aus und schreibt für neues Verhalten eigene. Ein Bugfix beginnt mit einem Test, der den Fehler reproduziert.
3. Build: Das Projekt muss vollständig bauen. Viele Fehler, etwa in Server-Komponenten oder Konfiguration, zeigen sich erst hier.
4. CI auf dem Pull Request: Die Pipeline wiederholt alle Prüfungen in einer sauberen Umgebung, ergänzt um statische Sicherheitsanalyse und Dependency-Checks. Lokal grüne Tests reichen nicht.
5. Automatisches Review: Ein zweites KI-Review kommentiert den Diff auf typische Fehler, fehlende Fehlerbehandlung und Abweichungen von den Konventionen.
6. Human Review: Ein Mensch liest den Pull Request, prüft die Tests mit und entscheidet über den Merge.

Beim Review lohnt ein zweiter Blick auf die Tests. Ein Agent, der einen roten Test nicht grün bekommt, neigt dazu, den Test anzupassen statt den Code. Deshalb prüfen wir bei jedem Pull Request, ob geänderte Assertions fachlich stimmen. Tests, die ein Agent selbst geschrieben hat, belegen, dass der Code tut, was der Agent verstanden hat. Ob das der Anforderung entspricht, zeigt erst das Review.

Wie wir Pipelines und Tests grundsätzlich aufsetzen, beschreiben wir im Beitrag [Wartbarer Code und saubere Übergabe](https://coding9.de/blog/wartbarer-code-und-uebergabe). Für Coding Agents gilt dasselbe, nur mit höherem Takt.

## Sandbox, Berechtigungen und Secrets

Ein Agent, der Befehle ausführt, braucht eine Umgebung, in der ein falscher Befehl keinen Schaden anrichtet. Das ist die wichtigste technische Entscheidung beim Einsatz von Coding Agents, wichtiger als die Wahl des Werkzeugs.

### Isolierte Arbeitsumgebung

Bei uns arbeitet jeder Agent in einem eigenen Container, mit einer frischen Kopie des Repositorys und auf einem eigenen Branch. Er hat keinen Zugriff auf Produktionssysteme, Kundendatenbanken oder die Rechner der Entwickler. Ausgehender Netzwerkverkehr läuft über einen Proxy, der nur freigegebene Ziele erlaubt, etwa die Paketregistries. Geht etwas schief, wird der Container verworfen.

### Permission-Modell

Die gängigen Werkzeuge fragen vor riskanten Aktionen nach, zum Beispiel bevor sie eine Datei außerhalb des Projekts schreiben oder einen unbekannten Befehl ausführen. Über Allow- und Deny-Listen legt ein Team fest, was ohne Rückfrage erlaubt ist. Einen Modus ohne Rückfragen setzen wir nur innerhalb der Sandbox ein, wo die Umgebung selbst die Grenze zieht.

Dazu kommt die Rechtevergabe in git: Der Agent darf seinen Branch pushen und einen Pull Request öffnen. Mergen kann er nicht, weil Branch Protection auf dem Hauptzweig ein bestandenes CI und ein menschliches Approval verlangt.

### Secrets

API-Keys, Datenbank-Passwörter und Zugangsdaten gehören nicht ins Repository und nicht in den Kontext eines Agents. Sie liegen im Secret-Store der CI und der Hosting-Umgebung. Lokale Dateien wie `.env` sind für den Agent gesperrt. Braucht der Agent für einen Test einen Dienst, bekommt er einen Testzugang mit minimalen Rechten, der nichts mit der Produktion zu tun hat.

Ein Grund für diese Strenge ist Prompt Injection. Ein Agent liest Tickets, Webseiten, Issues und Abhängigkeiten, und jeder dieser Texte kann Anweisungen enthalten, die ihn zu etwas anderem bewegen sollen. Gegen dieses Risiko hilft vor allem eine Umgebung, in der der Agent wenig erreichen kann, auch wenn er getäuscht wird.

Für den Datenschutz zählt außerdem, über welches Konto ein Agent läuft. Warum Unternehmen Coding Agents nur über kommerzielle Konten mit Auftragsverarbeitungsvertrag nutzen sollten, erklären wir im Beitrag [Claude DSGVO-konform nutzen](https://coding9.de/blog/claude-dsgvo-konform-nutzen).

## Wofür Coding Agents gut geeignet sind

Am zuverlässigsten arbeiten Coding Agents dort, wo eine Aufgabe klar beschrieben ist und das Repository schnelles Feedback liefert. In unseren Projekten sind das vor allem:

- Tickets mit klaren Akzeptanzkriterien, etwa ein neues Feld im Formular samt Validierung, API-Anpassung und Test.
- Bugfixes, bei denen sich der Fehler reproduzieren lässt. Der Agent schreibt zuerst den fehlschlagenden Test und behebt dann die Ursache.
- Updates von Abhängigkeiten und Framework-Migrationen, wenn eine gute Testabdeckung vorhanden ist. Der Agent arbeitet Breaking Changes Datei für Datei ab und lässt nach jedem Schritt die Tests laufen.
- Tests nachziehen für bestehenden Code, bevor jemand ihn umbaut.
- Refactorings nach einem festen Muster, zum Beispiel eine alte API an allen Aufrufstellen ersetzen.
- Dokumentation, Changelogs und Content-Änderungen, die gegen feste Regeln geprüft werden. Für die Texte auf coding9.de prüft ein Skript jeden Beitrag auf typische KI-Formulierungen.

Weil Agents parallel arbeiten, lassen sich mehrere solcher Tickets gleichzeitig bearbeiten. Der Engpass verschiebt sich damit vom Schreiben zum Review: Wer Coding Agents einsetzt, sollte Review-Zeit fest einplanen.

## Wo Coding Agents an Grenzen stoßen

### Unklare Anforderungen

Ein Agent füllt Lücken in der Aufgabe mit Annahmen, und das Ergebnis sieht trotzdem fertig aus. Steht im Ticket nur "Checkout verbessern", baut er irgendetwas, das sich als Verbesserung begründen lässt. Bei uns gilt deshalb: Ist ein Ticket unklar, stellt der Agent eine konkrete Rückfrage und setzt das Ticket auf "Blocked". Eine halbe Lösung auf Basis geratener Anforderungen kostet im Review mehr Zeit als die Rückfrage.

### Architekturentscheidungen

Innerhalb eines Tickets treffen Agents meist gute Entscheidungen. Sie finden dort eine funktionierende Lösung, kennen aber weder das Budget noch die Pläne für das nächste Jahr, noch die Absprachen mit dem Kunden. Änderungen am Datenmodell, an Authentifizierung, Zahlungsabwicklung oder an Schnittstellen zu anderen Systemen entwerfen bei uns Menschen. Der Agent setzt den Entwurf danach um.

### Große Diffs und fehlende Tests

Ein Pull Request mit 3.000 geänderten Zeilen lässt sich nicht sorgfältig reviewen, egal wer ihn geschrieben hat. Große Aufgaben teilen wir deshalb in Tickets, die einzeln prüfbar sind. Ähnlich bei altem Code ohne Tests: Dort fehlt dem Agent das Feedback, und er kann nicht erkennen, was er kaputt macht. Der erste Schritt ist dann ein Satz Tests, der das heutige Verhalten festhält.

### Wissen, das nicht im Repository steht

Warum ein Workaround existiert, welche Sonderregel ein Großkunde hat, was ein Feld in der Warenwirtschaft wirklich bedeutet: Solches Wissen kennt der Agent nur, wenn es aufgeschrieben ist. Coding Agents belohnen Teams, die Entscheidungen im Ticket, im Wiki oder im Code-Kommentar festhalten.

### Sicherheit und Selbstüberschätzung

Generierter Code übernimmt Muster aus Trainingsdaten und aus dem bestehenden Projekt, auch unsichere. Eine [Studie der Stanford University](https://arxiv.org/abs/2211.03622) fand, dass Teilnehmende mit KI-Assistent weniger sicheren Code schrieben und ihn trotzdem häufiger für sicher hielten. Die Untersuchung stammt aus der Zeit der Autovervollständigung, der Effekt auf die Menschen im Review gilt für Agents genauso. Sicherheitskritische Stellen bekommen bei uns deshalb immer ein menschliches Review, und die CI prüft jede Änderung mit statischer Analyse. Lizenzfragen bei übernommenem Code klären wir über Dependency- und Lizenz-Checks in der Pipeline.

## So arbeiten wir bei CODING 9 mit Coding Agents

Wir setzen Coding Agents in eigenen Produkten und in Kundenprojekten ein. Der Ablauf ist in beiden Fällen gleich und hängt an unserem Ticketsystem [Spedy](https://coding9.de/leistungen/produkte), an das die Agents per MCP angebunden sind:

1. Ein Ticket beschreibt die Aufgabe mit Akzeptanzkriterien. Ein Coding Agent, etwa Claude Code, übernimmt es und liest Ticket, Kommentare und verknüpfte Wiki-Seiten.
2. Der Agent arbeitet in einem isolierten Container auf einem eigenen Branch. Er orientiert sich an der Agent-Doku im Repository und ändert Code, Tests und Doku im selben Zug.
3. Vor dem Commit laufen Lint, Typecheck, Tests und Build. Bei Website-Texten kommt der Check auf KI-Formulierungen dazu.
4. Der Agent öffnet einen Pull Request mit Beschreibung und Verweis auf das Ticket. Das Ticket wandert auf "IN PR".
5. Auf dem Pull Request laufen CI und ein automatisches Review. Danach prüft ein Mensch aus unserem Team den Diff und merged ihn oder gibt ihn mit Kommentaren zurück.
6. Ist ein Ticket unklar, schreibt der Agent eine konkrete Frage ins Ticket und setzt es auf "Blocked". Die Antwort kommt vom Menschen, der das Ticket geschrieben hat.

Dazu gelten feste Regeln: Secrets liegen nicht im Repository, Agents haben keinen Zugriff auf Produktionssysteme und können nicht selbst mergen. Die Neufassung dieses Artikels ist übrigens genauso entstanden, als Ticket, bearbeitet von einem Coding Agent auf einem eigenen Branch, geprüft und freigegeben von uns.

Was sich für uns dadurch verändert hat, ist die Arbeit an den Rändern: Tickets schreiben wir heute genauer als früher, Review ist ein fester Teil jedes Arbeitstags, und Architekturentscheidungen fallen bewusster, weil sie danach schnell umgesetzt sind.

## Werkzeuge im Überblick (Stand September 2026)

Der Markt bewegt sich schnell, Funktionen und Preise ändern sich im Monatsrhythmus. Die folgende Übersicht nennt die verbreiteten Werkzeuge ohne Rangfolge:

- Claude Code von Anthropic arbeitet im Terminal, in IDEs und als Cloud-Agent, der Aufgaben in einer eigenen Umgebung abarbeitet und Pull Requests stellt.
- OpenAI Codex gibt es als Kommandozeilen-Werkzeug und als Cloud-Agent, der Aufgaben parallel in Sandboxes bearbeitet.
- GitHub Copilot hat neben der Autovervollständigung einen Agentenmodus im Editor und einen Coding Agent, dem man Issues zuweisen kann und der daraus Pull Requests erstellt.
- Cursor ist ein KI-Editor mit Agentenmodus und Hintergrund-Agents, die Aufgaben außerhalb des eigenen Rechners bearbeiten.

Welche Modelle dahinterstehen, lässt sich bei mehreren Werkzeugen wählen. Für die Qualität des Ergebnisses zählt nach unserer Erfahrung weniger das Werkzeug als das Setup drumherum: Tests, CI, Berechtigungen und gute Tickets.

## Checkliste: bevor ein Agent an Ihr Repository darf

- Es gibt automatisierte Tests, und die CI läuft bei jedem Pull Request.
- Der Hauptzweig ist geschützt: Merge nur mit grüner CI und menschlichem Approval.
- Secrets liegen in einem Secret-Store und nirgends im Repository oder in lokalen Dateien, die ein Agent lesen kann.
- Agents arbeiten in einer isolierten Umgebung ohne Zugriff auf Produktion und Kundendaten.
- Build, Tests und Konventionen sind im Repository für Agents beschrieben.
- Tickets haben Akzeptanzkriterien, und unklare Tickets gehen mit einer Frage zurück.
- Im Team ist Zeit für Reviews eingeplant.
- Die Werkzeuge laufen über kommerzielle Konten mit passendem Vertrag.

Wenn ein Punkt fehlt, lohnt es sich, ihn vor dem ersten Agent-Ticket nachzuziehen. Tests und CI helfen dem Team auch ganz ohne KI.

Sie möchten Coding Agents in Ihrem Entwicklungsteam einführen oder eine Anwendung mit diesem Vorgehen bauen lassen? Wir zeigen Ihnen gern, wie das bei uns aussieht, ob in der [Softwareentwicklung](https://coding9.de/leistungen/individualsoftware/softwareentwicklung), bei [Individualsoftware](https://coding9.de/leistungen/individualsoftware) oder beim Aufbau eigener Dev-Workflows mit [KI für Agenturen](https://coding9.de/leistungen/ki/beratung/ki-fuer-agenturen).

## Häufige Fragen

### Was ist ein Coding Agent?

Ein Coding Agent ist ein KI-Werkzeug, das eine Entwicklungsaufgabe selbstständig in mehreren Schritten bearbeitet. Er durchsucht das Repository, liest die relevanten Dateien, ändert Code in mehreren Dateien, führt Befehle wie Tests, Linter und Build im Terminal aus und korrigiert sich anhand der Ergebnisse. Am Ende steht ein Änderungssatz auf einem eigenen Branch, meist als Pull Request, den ein Mensch prüft und freigibt.

### Was ist der Unterschied zwischen KI-Code-Generierung und einem Coding Agent?

Klassische KI-Code-Generierung schlägt im Editor die nächste Zeile oder Funktion vor, die Entwicklerin entscheidet sofort, ob sie den Vorschlag übernimmt. Ein Coding Agent bekommt eine ganze Aufgabe, etwa ein Ticket, sucht sich den nötigen Kontext im Repository selbst, arbeitet über viele Dateien hinweg, prüft das Ergebnis mit Tests und Build und liefert einen Pull Request. Die Prüfung verlagert sich damit vom Tippen in Tests, CI und Code-Review.

### Kann man mit KI programmieren, ohne selbst programmieren zu können?

Für Prototypen, kleine Skripte und interne Werkzeuge funktioniert das 2026 oft erstaunlich gut. Für Software, die im Betrieb läuft, Kundendaten verarbeitet oder Geld bewegt, braucht es weiterhin jemanden, der den Code beurteilen kann: Architektur festlegen, Pull Requests reviewen, Sicherheitsfragen einschätzen und entscheiden, wann eine Lösung fertig ist. Coding Agents beschleunigen Entwicklerinnen und Entwickler, die Verantwortung für das Ergebnis bleibt beim Team.

### Ist KI-generierter Code sicher?

KI-generierter Code ist so sicher wie der Prozess, durch den er läuft. Modelle übernehmen unsichere Muster aus Trainingsdaten und aus dem bestehenden Code, und eine Stanford-Studie hat gezeigt, dass Menschen mit KI-Assistent ihren Code häufiger für sicher hielten, obwohl er weniger sicher war. Deshalb gehören statische Analyse und Dependency-Checks in die CI, sicherheitskritische Stellen wie Authentifizierung und Zahlungen in ein menschliches Review, und der Agent selbst arbeitet ohne Zugriff auf Produktionssysteme und Secrets.

### Ersetzen Coding Agents Softwareentwickler?

Coding Agents übernehmen einen wachsenden Teil der Umsetzung, besonders bei klar beschriebenen Aufgaben. Anforderungen klären, Architektur entscheiden, Ergebnisse reviewen und die Verantwortung für den Betrieb tragen bleibt Aufgabe von Menschen. In unserer Arbeit verschiebt sich die Rolle der Entwickler hin zu Ticketqualität, Review und Architektur, der Bedarf an erfahrenen Leuten sinkt dadurch nicht.

### Wie setzt CODING 9 Coding Agents ein?

Coding Agents wie Claude Code bearbeiten bei uns Tickets aus unserem Ticketsystem Spedy. Jeder Agent arbeitet auf einem eigenen Branch in einem isolierten Container, führt Lint, Typecheck, Tests und Build aus und öffnet einen Pull Request, das Ticket wandert auf "IN PR". Auf dem Pull Request laufen CI und ein automatisches Review, ein Mensch prüft und merged. Secrets liegen nicht im Repository, Agents können nicht selbst mergen, und unklare Tickets landen mit einer konkreten Rückfrage auf "Blocked".

---

Quelle: [KI-generierter Code 2026: Wie Coding Agents in der Softwareentwicklung arbeiten](https://coding9.de/blog/ki-generierter-code)