{"author":{"@type":"Person","name":"Alexander Bock","url":"https://abxk.ai/de/autor/alexander-bock/"},"categories":["AI Development"],"content":{"markdown":"Ein KI-Coding-Assistent schreibt eine Funktion in wenigen Minuten. Das Tempo ist nicht das Problem. Das Problem ist Code, den niemand wirklich geprüft hat: ein API-Schlüssel in einer Konfigurationsdatei, ein Paket, das es nicht gibt, ein Test, den der Agent stillschweigend geändert hat, damit er besteht. Ein guter Workflow behält das Tempo und ergänzt **Gates**: Prüfstellen, die jede Änderung passieren muss, bevor sie weiterkommt.\n\nDies ist Teil 5 von Level 2 in unserem Lernpfad AI Development. Er macht aus den Gewohnheiten aus [Was KI-Coding-Assistenten tun](/de/ai-development/learn/what-ai-coding-assistants-do/) einen wiederholbaren Ablauf: planen, erzeugen, prüfen, testen, committen. Sie lernen, wie Sie einen Assistenten einweisen, warum kleine Diffs und Tests zuerst wichtig sind, welche automatischen Prüfungen Secrets und riskante Pakete finden und wie Sie KI-geschriebenen Code mit einer Checkliste prüfen.\n\n## Fünf Schritte, fünf Gates\n\nJede Änderung durchläuft dieselben fünf Schritte. Jeder Schritt endet mit einem Gate: einer Frage, die mit Ja beantwortet sein muss. Lautet die Antwort Nein, geht die Änderung zurück, meist zum Erzeugen, manchmal bis zum Plan.\n\n![Fünf Schritte vom Plan bis zum Commit, jeder mit einer Gate-Frage: Kriterien notiert, ein kleiner Diff, jede Zeile verstanden, alle Prüfungen grün, Nachricht und Doku fertig; ein gestrichelter Weg führt vom Prüfen und Testen zurück zum Erzeugen](/images/learn/de/ai-assisted-coding-workflow-workflow.webp \"Der Workflow mit seinen fünf Gates. Ein verfehltes Gate schickt die Änderung zurück.\")\n\nDie Gates sind keine Bürokratie. Googles DORA-Forschung weist in dieselbe Richtung: Arbeiten in kleinen Schritten verstärkt den positiven Einfluss von KI auf die Produktleistung, und häufige Commits verstärken ihren positiven Einfluss auf die individuelle Effektivität (Quelle: DORA AI Capabilities Model, Google Cloud, 2025, cloud.google.com).\n\nDieser Workflow gilt für Code, der ausgeliefert wird. Für schnelle Experimente können lockerere Regeln genügen: Unser [VibeCoding-Artikel](/de/ai-development/vibecoding-faster-experiments-ai-development/) zeigt, wie wir mit KI Prototypen bauen — und warum Prototypen nicht in Produktion gehen.\n\n## Planen: erst die Aufgabe, dann der Prompt\n\nViel schlechter KI-Code beginnt mit einer vagen Anfrage. Bevor Sie den Assistenten öffnen, schreiben Sie die Aufgabe auf wie ein Ticket für eine neue Kollegin. Fünf Teile genügen:\n\n![Eine Aufgabenbeschreibung in fünf Teilen — Ziel, Kontext, Vorgaben, Abnahmekriterien und was nicht zum Umfang gehört — ausgefüllt für ein Rabattcode-Feld](/images/learn/de/ai-assisted-coding-workflow-brief.webp \"Eine Aufgabenbeschreibung für einen Assistenten. Aus den Abnahmekriterien werden die Tests.\")\n\nFragen Sie dann nach einem Plan, bevor Code entsteht: „Nenne zuerst die Dateien, die sich ändern, und die Schritte. Warte dann auf meine Freigabe.“ Ein falscher Plan ist in einer Minute korrigiert. Derselbe Fehler in einem fertigen Diff kostet viel mehr Zeit.\n\nZwei weitere Gewohnheiten gehören zu diesem Schritt:\n\n- **Tests zuerst schreiben.** Machen Sie aus den Abnahmekriterien Tests, oder lassen Sie den Assistenten sie schreiben, und prüfen Sie sie, bevor Code für die Funktion existiert. Bitten Sie dann um Code, der die Tests besteht, ohne sie zu ändern. Das heißt **testgetriebene Entwicklung** (Test-Driven Development, TDD) und liefert eine klare Definition von „fertig“.\n- **Feste Regeln ins Repository legen.** Viele Coding-Agenten lesen eine Projektdatei mit Anweisungen, etwa AGENTS.md, ein offenes Format, das mehrere Tools unterstützen. Halten Sie dort Ihre Konventionen fest: wie die Tests laufen, den Code-Stil und was der Agent nie tun darf.\n\n## Erzeugen: kleine Diffs und begrenzte Rechte\n\nEin **Diff** ist die Liste der Zeilen, die eine Änderung hinzufügt, ändert oder löscht. Halten Sie ihn klein: eine Aufgabe, ein Branch, ein kleiner Diff. Googles Leitfaden für Code-Reviews nennt etwa 100 Zeilen eine vernünftige Größe für eine Änderung und 1.000 Zeilen meist zu groß (Quelle: Google Engineering Practices, „Small CLs“, google.github.io). Kleine Änderungen werden früher und sorgfältiger geprüft und lassen sich leicht rückgängig machen.\n\n![Vergleich einer großen KI-Änderung über viele Dateien mit gemischten Zielen und vier kleinen Schritten, jeder mit einem Ziel, eigenen Tests und eigenem Commit](/images/learn/de/ai-assisted-coding-workflow-small-diffs.webp \"Eine große Änderung versteckt Fehler. Kleine Schritte machen jeden Fehler leicht zu finden und rückgängig zu machen.\")\n\nCommitten Sie nach jedem funktionierenden Schritt, damit Sie zurückkehren können, wenn der nächste scheitert. Im Terminal kann ein Schritt so aussehen:\n\n```bash\ngit switch -c feature/discount-code    # ein Branch pro Aufgabe\ngit diff                               # nach jeder KI-Änderung: jede Zeile lesen\nmake test                              # alle Tests, nicht nur die neuen\ngit add -p                             # die Änderung Stück für Stück übernehmen\ngit commit -m \"Validate discount codes at checkout (#1234)\"\n```\n\nAgenten brauchen Grenzen, denn sie handeln, statt nur vorzuschlagen:\n\n- Lassen Sie sie in einer Sandbox oder einem Container laufen, mit Testdaten und ohne Zugangsdaten für Produktivsysteme.\n- Lassen Sie sie nachfragen, bevor sie Befehle ausführen, Pakete installieren oder Code pushen.\n- Brechen Sie ab, wenn der Diff Dateien außerhalb des Plans berührt, und lehnen Sie jede Änderung ab, die Tests anpasst, damit sie bestehen.\n\n## Prüfen und testen: Menschen und Tools finden Verschiedenes\n\nLesen Sie den Diff, nicht den Chat. Die Zusammenfassung des Assistenten kann falsch sein. Lassen Sie ihn riskante Stellen erklären und vergleichen Sie die Erklärung mit dem Code. Code für Anmeldungen, Zahlungen, Berechtigungen oder personenbezogene Daten bekommt eine zweite menschliche Prüfung.\n\nEin Pull Request mit einem großen KI-Diff und ohne Erklärung ist die Programmierfassung dessen, was Forschende **Workslop** nennen: Ergebnisse, die fertig aussehen, aber die eigentliche Arbeit auf andere abwälzen. BetterUp Labs und das Stanford Social Media Lab zählen Code ohne Kontext zu den typischen Formen (Quelle: BetterUp Labs, 2025). Jeder Pull Request sollte sagen, was sich geändert hat, warum und wie es getestet wurde – geschrieben von der Person, die ihn öffnet.\n\nDann laufen bei jedem Pull Request automatische Prüfungen. Jede findet eine andere Art von Problem, und keine findet alles:\n\n![Matrix aus sechs häufigen Problemen in KI-geschriebenem Code und fünf Arten von Prüfungen; Markierungen zeigen, welche Prüfungen welches Problem meist finden](/images/learn/de/ai-assisted-coding-workflow-checks.webp \"Keine einzelne Prüfung findet alles. Mehrere Schichten von Prüfungen schon.\")\n\nDrei dieser Prüfungen verdienen einen genaueren Blick:\n\n- **Secret-Scanning.** Ein Scanner sucht nach Schlüsseln, Tokens und Passwörtern, bevor der Code Ihren Rechner verlässt, als Pre-Commit-Hook, und noch einmal in der CI. Viele Code-Hosting-Dienste können außerdem einen Push blockieren, der ein bekanntes Schlüsselformat enthält. Ist ein Secret trotzdem im Commit gelandet, widerrufen Sie es und erzeugen ein neues. Die Zeile zu löschen genügt nicht, denn die alte Version bleibt in der Historie.\n- **Prüfung der Abhängigkeiten.** Prüfen Sie für jedes neue Paket, ob es existiert, ob der Name exakt stimmt und ob es gepflegt wird. Assistenten schlagen manchmal Pakete vor, die nie veröffentlicht wurden, und Angreifer können solche Namen registrieren. Fixieren Sie Versionen in einer Lock-Datei, lassen Sie einen Schwachstellenscanner sie mit Datenbanken bekannter Lücken abgleichen und prüfen Sie die Lizenz.\n- **Statische Analyse.** Diese Tools lesen Code, ohne ihn auszuführen, und finden unsichere Muster, etwa Nutzereingaben, die direkt in eine Datenbankabfrage eingefügt werden. Modelle lernen aus öffentlichem Code, samt seiner Fehler. In einer frühen Studie zu GitHub Copilot enthielten etwa 40 Prozent von 1.689 Programmen, die für 89 sicherheitsrelevante Szenarien entstanden, eine Schwachstelle (Quelle: Pearce et al., „Asleep at the Keyboard?“, IEEE S\u0026P 2022, arxiv.org). Die Modelle sind seither besser geworden, aber diese Prüfungen sind eine günstige Versicherung.\n\nKI-gestützte Tools können einen ersten Prüfdurchgang übernehmen. Laut Anbieter führt TestDriver.ai Pull Requests in einer Desktop-Sandbox aus und meldet Regressionen, bevor eine Änderung gemergt wird. App-Builder wie Emergent und Devs.ai erzeugen ganze Anwendungen aus einer Beschreibung, was die Gates noch wichtiger macht. Wir haben diese Tools nicht getestet.\n\n{{\u003c tools \"testdriver-ai emergent devs-ai\" \u003e}}\n\nBetrifft Ihre Änderung eine KI-Funktion in Ihrem Produkt, gehören zum Test-Gate auch die Evals aus [Teil 4](/de/ai-development/learn/test-ai-features-with-evals/).\n\n## Committen: klare Nachrichten, aktuelle Doku, geschützter Branch\n\nDer Commit schließt den Kreis. Schreiben Sie eine Nachricht, die sagt, was sich geändert hat und warum, und verlinken Sie das Ticket. Legen Sie Aufgabenbeschreibung und Plan in die Beschreibung des Pull Requests, damit die Prüfenden Absicht und Ergebnis vergleichen können. Wenn Ihr Team es verlangt, vermerken Sie, dass ein Assistent geholfen hat.\n\nAktualisieren Sie die Dokumentation in derselben Änderung: die README für neue Einrichtungsschritte, das Changelog und Kommentare, die erklären, *warum* der Code so arbeitet. Assistenten schreiben Dokumentation schnell, aber prüfen Sie sie wie Code. Sie kann Verhalten beschreiben, das es nicht gibt.\n\nSchützen Sie zuletzt den Hauptbranch: Änderungen gelangen nur über einen Pull Request hinein, mit grünen Prüfungen und einer Freigabe. Dann kann weder ein Mensch noch ein Agent die Gates überspringen.\n\n## Was Benchmark-Daten über KI-Codeänderungen sagen\n\nWie zuverlässig ändern Modelle vorhandenen Code? Genau das prüft der Benchmark Aider Polyglot. Wie Ihr Test-Gate gibt er dem Modell einen zweiten Versuch, nachdem es die Testausgabe gesehen hat. Das sind die Spitzenreiter in unseren LLM-Daten:\n\n{{\u003c llm-top bench=\"aider-polyglot\" n=\"5\" \u003e}}\n\nSelbst die besten Ergebnisse lassen einen Teil der Aufgaben ungelöst, obwohl jede Aufgabe klare Tests hat und das Modell einen zweiten Versuch bekommt. Nicht jedes neue Modell wurde mit diesem Benchmark getestet, daher können die neuesten Modelle aus unserer [LLM-Datenbank](/de/llm/) hier fehlen. Ein hoher Wert zeigt Ihnen, welche Modelle einen Versuch wert sind. Der echte Test ist Ihr eigenes Repository mit seinen Regeln und seiner Geschichte. Level 4 erklärt, [wie Coding-Benchmarks funktionieren](/de/ai-development/learn/coding-benchmarks-explained/) und wo sie in die Irre führen.\n\n## Checkliste vor dem Merge von KI-geschriebenem Code\n\nNutzen Sie diese Liste für jeden Pull Request mit KI-geschriebenem Code. Sie geht weiter als die schnellen Prüfungen aus Level 0:\n\n| Bereich | Prüfung |\n|---|---|\n| Umfang | Berührt der Diff nur die Dateien, die der Plan nennt? |\n| Tests | Decken neue Tests die Abnahmekriterien ab? Wurden bestehende Tests geändert oder gelöscht, und warum? |\n| Korrektheit | Sind leere, fehlende und extreme Werte abgedeckt? Führen Fehler zu klaren Meldungen? |\n| Sicherheit | Werden alle Eingaben geprüft, Datenbankabfragen parametrisiert und Berechtigungen kontrolliert? |\n| Secrets | Ist die Änderung frei von Schlüsseln, Tokens und Passwörtern, in Code, Konfiguration, Tests und Logs? |\n| Abhängigkeiten | Existiert jedes neue Paket, mit dem beabsichtigten Namen, fixierter Version und erlaubter Lizenz? |\n| Personenbezogene Daten | Landen keine personenbezogenen Daten in Logs, Testdaten oder Prompts? |\n| Dokumentation | Sind README, Changelog und Kommentare aktuell? |\n| Rückgängig machen | Lässt sich die Änderung für sich zurücknehmen, ohne andere Änderungen zu brechen? |\n| Verständnis | Können Sie jede Zeile einer Kollegin erklären? |\n\n{{\u003c callout type=\"try\" \u003e}}\nNehmen Sie Ihren letzten Pull Request, an dem ein Assistent mitgeschrieben hat, und gehen Sie die Checkliste durch. Notieren Sie jedes „Nein“. Machen Sie dann aus dem häufigsten eine automatische Prüfung: einen Pre-Commit-Hook, einen Schritt in der CI oder eine Regel in Ihrer Anweisungsdatei für Agenten.\n{{\u003c /callout \u003e}}","text":"Ein KI-Coding-Assistent schreibt eine Funktion in wenigen Minuten. Das Tempo ist nicht das Problem. Das Problem ist Code, den niemand wirklich geprüft hat: ein API-Schlüssel in einer Konfigurationsdatei, ein Paket, das es nicht gibt, ein Test, den der Agent stillschweigend geändert hat, damit er besteht. Ein guter Workflow behält das Tempo und ergänzt Gates: Prüfstellen, die jede Änderung passieren muss, bevor sie weiterkommt.\nDies ist Teil 5 von Level 2 in unserem Lernpfad AI Development. Er macht aus den Gewohnheiten aus Was KI-Coding-Assistenten tun einen wiederholbaren Ablauf: planen, erzeugen, prüfen, testen, committen. Sie lernen, wie Sie einen Assistenten einweisen, warum kleine Diffs und Tests zuerst wichtig sind, welche automatischen Prüfungen Secrets und riskante Pakete finden und wie Sie KI-geschriebenen Code mit einer Checkliste prüfen.\nFünf Schritte, fünf Gates Jede Änderung durchläuft dieselben fünf Schritte. Jeder Schritt endet mit einem Gate: einer Frage, die mit Ja beantwortet sein muss. Lautet die Antwort Nein, geht die Änderung zurück, meist zum Erzeugen, manchmal bis zum Plan.\nDer Workflow mit seinen fünf Gates. Ein verfehltes Gate schickt die Änderung zurück. Die Gates sind keine Bürokratie. Googles DORA-Forschung weist in dieselbe Richtung: Arbeiten in kleinen Schritten verstärkt den positiven Einfluss von KI auf die Produktleistung, und häufige Commits verstärken ihren positiven Einfluss auf die individuelle Effektivität (Quelle: DORA AI Capabilities Model, Google Cloud, 2025, cloud.google.com).\nDieser Workflow gilt für Code, der ausgeliefert wird. Für schnelle Experimente können lockerere Regeln genügen: Unser VibeCoding-Artikel zeigt, wie wir mit KI Prototypen bauen — und warum Prototypen nicht in Produktion gehen.\nPlanen: erst die Aufgabe, dann der Prompt Viel schlechter KI-Code beginnt mit einer vagen Anfrage. Bevor Sie den Assistenten öffnen, schreiben Sie die Aufgabe auf wie ein Ticket für eine neue Kollegin. Fünf Teile genügen:\nEine Aufgabenbeschreibung für einen Assistenten. Aus den Abnahmekriterien werden die Tests. Fragen Sie dann nach einem Plan, bevor Code entsteht: „Nenne zuerst die Dateien, die sich ändern, und die Schritte. Warte dann auf meine Freigabe.“ Ein falscher Plan ist in einer Minute korrigiert. Derselbe Fehler in einem fertigen Diff kostet viel mehr Zeit.\nZwei weitere Gewohnheiten gehören zu diesem Schritt:\nTests zuerst schreiben. Machen Sie aus den Abnahmekriterien Tests, oder lassen Sie den Assistenten sie schreiben, und prüfen Sie sie, bevor Code für die Funktion existiert. Bitten Sie dann um Code, der die Tests besteht, ohne sie zu ändern. Das heißt testgetriebene Entwicklung (Test-Driven Development, TDD) und liefert eine klare Definition von „fertig“. Feste Regeln ins Repository legen. Viele Coding-Agenten lesen eine Projektdatei mit Anweisungen, etwa AGENTS.md, ein offenes Format, das mehrere Tools unterstützen. Halten Sie dort Ihre Konventionen fest: wie die Tests laufen, den Code-Stil und was der Agent nie tun darf. Erzeugen: kleine Diffs und begrenzte Rechte Ein Diff ist die Liste der Zeilen, die eine Änderung hinzufügt, ändert oder löscht. Halten Sie ihn klein: eine Aufgabe, ein Branch, ein kleiner Diff. Googles Leitfaden für Code-Reviews nennt etwa 100 Zeilen eine vernünftige Größe für eine Änderung und 1.000 Zeilen meist zu groß (Quelle: Google Engineering Practices, „Small CLs“, google.github.io). Kleine Änderungen werden früher und sorgfältiger geprüft und lassen sich leicht rückgängig machen.\nEine große Änderung versteckt Fehler. Kleine Schritte machen jeden Fehler leicht zu finden und rückgängig zu machen. Committen Sie nach jedem funktionierenden Schritt, damit Sie zurückkehren können, wenn der nächste scheitert. Im Terminal kann ein Schritt so aussehen:\ngit switch -c feature/discount-code # ein Branch pro Aufgabe git diff # nach jeder KI-Änderung: jede Zeile lesen make test # alle Tests, nicht nur die neuen git add -p # die Änderung Stück für Stück übernehmen git commit -m \u0026#34;Validate discount codes at checkout (#1234)\u0026#34; Agenten brauchen Grenzen, denn sie handeln, statt nur vorzuschlagen:\nLassen Sie sie in einer Sandbox oder einem Container laufen, mit Testdaten und ohne Zugangsdaten für Produktivsysteme. Lassen Sie sie nachfragen, bevor sie Befehle ausführen, Pakete installieren oder Code pushen. Brechen Sie ab, wenn der Diff Dateien außerhalb des Plans berührt, und lehnen Sie jede Änderung ab, die Tests anpasst, damit sie bestehen. Prüfen und testen: Menschen und Tools finden Verschiedenes Lesen Sie den Diff, nicht den Chat. Die Zusammenfassung des Assistenten kann falsch sein. Lassen Sie ihn riskante Stellen erklären und vergleichen Sie die Erklärung mit dem Code. Code für Anmeldungen, Zahlungen, Berechtigungen oder personenbezogene Daten bekommt eine zweite menschliche Prüfung.\nEin Pull Request mit einem großen KI-Diff und ohne Erklärung ist die Programmierfassung dessen, was Forschende Workslop nennen: Ergebnisse, die fertig aussehen, aber die eigentliche Arbeit auf andere abwälzen. BetterUp Labs und das Stanford Social Media Lab zählen Code ohne Kontext zu den typischen Formen (Quelle: BetterUp Labs, 2025). Jeder Pull Request sollte sagen, was sich geändert hat, warum und wie es getestet wurde – geschrieben von der Person, die ihn öffnet.\nDann laufen bei jedem Pull Request automatische Prüfungen. Jede findet eine andere Art von Problem, und keine findet alles:\nKeine einzelne Prüfung findet alles. Mehrere Schichten von Prüfungen schon. Drei dieser Prüfungen verdienen einen genaueren Blick:\nSecret-Scanning. Ein Scanner sucht nach Schlüsseln, Tokens und Passwörtern, bevor der Code Ihren Rechner verlässt, als Pre-Commit-Hook, und noch einmal in der CI. Viele Code-Hosting-Dienste können außerdem einen Push blockieren, der ein bekanntes Schlüsselformat enthält. Ist ein Secret trotzdem im Commit gelandet, widerrufen Sie es und erzeugen ein neues. Die Zeile zu löschen genügt nicht, denn die alte Version bleibt in der Historie. Prüfung der Abhängigkeiten. Prüfen Sie für jedes neue Paket, ob es existiert, ob der Name exakt stimmt und ob es gepflegt wird. Assistenten schlagen manchmal Pakete vor, die nie veröffentlicht wurden, und Angreifer können solche Namen registrieren. Fixieren Sie Versionen in einer Lock-Datei, lassen Sie einen Schwachstellenscanner sie mit Datenbanken bekannter Lücken abgleichen und prüfen Sie die Lizenz. Statische Analyse. Diese Tools lesen Code, ohne ihn auszuführen, und finden unsichere Muster, etwa Nutzereingaben, die direkt in eine Datenbankabfrage eingefügt werden. Modelle lernen aus öffentlichem Code, samt seiner Fehler. In einer frühen Studie zu GitHub Copilot enthielten etwa 40 Prozent von 1.689 Programmen, die für 89 sicherheitsrelevante Szenarien entstanden, eine Schwachstelle (Quelle: Pearce et al., „Asleep at the Keyboard?“, IEEE S\u0026amp;P 2022, arxiv.org). Die Modelle sind seither besser geworden, aber diese Prüfungen sind eine günstige Versicherung. KI-gestützte Tools können einen ersten Prüfdurchgang übernehmen. Laut Anbieter führt TestDriver.ai Pull Requests in einer Desktop-Sandbox aus und meldet Regressionen, bevor eine Änderung gemergt wird. App-Builder wie Emergent und Devs.ai erzeugen ganze Anwendungen aus einer Beschreibung, was die Gates noch wichtiger macht. Wir haben diese Tools nicht getestet.\nTestDriver.aiApp-Bau \u0026amp; Tests · KI ist der KernFührt Pull Requests in einer Desktop-Sandbox aus, sucht Fehler und baut Regressionstests. EmergentApp-Bau \u0026amp; Tests · KI ist der KernBaut Web- und Mobil-Apps aus einer Beschreibung in Alltagssprache. Devs.aiApp-Bau \u0026amp; Tests · KI ist der KernPlattform, auf der Teams KI-Anwendungen und eigene Agenten mit ihren Daten bauen und betreiben. Kurzbeschreibungen aus unserem Tool-Vergleich, nach Angaben der Anbieter — nicht von ABXK getestet.\nBetrifft Ihre Änderung eine KI-Funktion in Ihrem Produkt, gehören zum Test-Gate auch die Evals aus Teil 4.\nCommitten: klare Nachrichten, aktuelle Doku, geschützter Branch Der Commit schließt den Kreis. Schreiben Sie eine Nachricht, die sagt, was sich geändert hat und warum, und verlinken Sie das Ticket. Legen Sie Aufgabenbeschreibung und Plan in die Beschreibung des Pull Requests, damit die Prüfenden Absicht und Ergebnis vergleichen können. Wenn Ihr Team es verlangt, vermerken Sie, dass ein Assistent geholfen hat.\nAktualisieren Sie die Dokumentation in derselben Änderung: die README für neue Einrichtungsschritte, das Changelog und Kommentare, die erklären, warum der Code so arbeitet. Assistenten schreiben Dokumentation schnell, aber prüfen Sie sie wie Code. Sie kann Verhalten beschreiben, das es nicht gibt.\nSchützen Sie zuletzt den Hauptbranch: Änderungen gelangen nur über einen Pull Request hinein, mit grünen Prüfungen und einer Freigabe. Dann kann weder ein Mensch noch ein Agent die Gates überspringen.\nWas Benchmark-Daten über KI-Codeänderungen sagen Wie zuverlässig ändern Modelle vorhandenen Code? Genau das prüft der Benchmark Aider Polyglot. Wie Ihr Test-Gate gibt er dem Modell einen zweiten Versuch, nachdem es die Testausgabe gesehen hat. Das sind die Spitzenreiter in unseren LLM-Daten:\nAider Polyglot: die 5 besten Modelle #ModellErschienenErgebnis 1GPT-5 (high) OpenAI07.08.202588,0 % 2o3-pro OpenAI10.06.202584,9 % 3Gemini 2.5 Pro Preview (Jun 2025) Google DeepMind05.06.202583,1 % 4o3 (high) OpenAI16.04.202581,3 % 5Grok 4 xAI09.07.202579,6 % 225 schwierige Programmieraufgaben in C\u0026#43;\u0026#43;, Go, Java, JavaScript, Python und Rust. Misst, ob ein Modell vorhandenen Code korrekt ändern kann — mit einem zweiten Versuch nach Sicht der Testausgabe. Daten: Epoch AI, abgerufen am 17.10.2026, Lizenz CC BY 4.0. Alle Modelle: LLM-Datenbank.\nSelbst die besten Ergebnisse lassen einen Teil der Aufgaben ungelöst, obwohl jede Aufgabe klare Tests hat und das Modell einen zweiten Versuch bekommt. Nicht jedes neue Modell wurde mit diesem Benchmark getestet, daher können die neuesten Modelle aus unserer LLM-Datenbank hier fehlen. Ein hoher Wert zeigt Ihnen, welche Modelle einen Versuch wert sind. Der echte Test ist Ihr eigenes Repository mit seinen Regeln und seiner Geschichte. Level 4 erklärt, wie Coding-Benchmarks funktionieren und wo sie in die Irre führen.\nCheckliste vor dem Merge von KI-geschriebenem Code Nutzen Sie diese Liste für jeden Pull Request mit KI-geschriebenem Code. Sie geht weiter als die schnellen Prüfungen aus Level 0:\nEin KI-gestützter Coding-Workflow, der sicher bleibt Bereich Prüfung Umfang Berührt der Diff nur die Dateien, die der Plan nennt? Tests Decken neue Tests die Abnahmekriterien ab? Wurden bestehende Tests geändert oder gelöscht, und warum? Korrektheit Sind leere, fehlende und extreme Werte abgedeckt? Führen Fehler zu klaren Meldungen? Sicherheit Werden alle Eingaben geprüft, Datenbankabfragen parametrisiert und Berechtigungen kontrolliert? Secrets Ist die Änderung frei von Schlüsseln, Tokens und Passwörtern, in Code, Konfiguration, Tests und Logs? Abhängigkeiten Existiert jedes neue Paket, mit dem beabsichtigten Namen, fixierter Version und erlaubter Lizenz? Personenbezogene Daten Landen keine personenbezogenen Daten in Logs, Testdaten oder Prompts? Dokumentation Sind README, Changelog und Kommentare aktuell? Rückgängig machen Lässt sich die Änderung für sich zurücknehmen, ohne andere Änderungen zu brechen? Verständnis Können Sie jede Zeile einer Kollegin erklären? ▸Probieren Sie es aus\nNehmen Sie Ihren letzten Pull Request, an dem ein Assistent mitgeschrieben hat, und gehen Sie die Checkliste durch. Notieren Sie jedes „Nein“. Machen Sie dann aus dem häufigsten eine automatische Prüfung: einen Pre-Commit-Hook, einen Schritt in der CI oder eine Regel in Ihrer Anweisungsdatei für Agenten.\n","words":1675},"date":"2026-10-14","description":"Planen, erzeugen, prüfen, testen, committen: ein Workflow für KI-gestütztes Programmieren mit kleinen Diffs, Tests zuerst, Secret- und Paketprüfung.","image":"https://abxk.ai/images/cover/ai-assisted-coding-workflow.webp","json":"https://abxk.ai/de/ai-development/learn/ai-assisted-coding-workflow/index.json","kind":"page","language":"de","learning_path":{"category":"ai-development","level":2,"level_name":"Fortgeschritten"},"modified":"2026-10-14","related_tools":["TestDriver.ai","Emergent","Devs.ai"],"section":"ai-development","tags":["ki-coding","code-review","sichere-entwicklung","testen","workflow"],"title":"Ein KI-gestützter Coding-Workflow, der sicher bleibt","translations":[{"json":"https://abxk.ai/en/ai-development/learn/ai-assisted-coding-workflow/index.json","language":"en","url":"https://abxk.ai/en/ai-development/learn/ai-assisted-coding-workflow/"}],"url":"https://abxk.ai/de/ai-development/learn/ai-assisted-coding-workflow/"}