# Mit KI programmieren: Workflow, der das Review übersteht URL: https://codebasechat.com/de/journal/mit-ki-programmieren Type: blog Locale: de Published: 2026-11-10 Updated: 2026-11-11 --- > Ein Workflow für Entwickler und Teams, die mit KI-Werkzeugen arbeiten: vom Plan vor dem Prompt über die Prüfung des Diffs bis zu Regeln, die im Review wirklich helfen. Sie öffnen ein Ticket, kopieren die Beschreibung in ein Chatfenster und bekommen 200 Zeilen plausibel aussehenden Code zurück. Er kompiliert. Zwei Tage später fragt der Reviewer, warum der Code den Retry-Wrapper ignoriert, und niemand im Team kann es erklären. So scheitert es meistens, wenn Teams lernen, mit KI programmieren: Der Generierungsschritt klappt, alles drumherum nicht. Hier ist der Workflow, den ich neuen Entwicklerinnen und Entwicklern gebe. Er behandelt das Modell wie eine schnelle, selbstsichere Nachwuchskraft, die Ihr Repository nie gesehen hat. Im Mittelpunkt steht die Zeit fürs Review, nicht die Zeit fürs Tippen. ## Macht KI Sie beim Programmieren wirklich schneller? Manchmal, und die ehrliche Antwort hängt von der Aufgabe ab. Die [Stack Overflow Developer Survey 2025](https://survey.stackoverflow.co/2025/ai) ergab, dass 84% der Befragten KI-Werkzeuge nutzen oder nutzen wollen, aber nur 33% der Ausgabe in gewissem Maß vertrauen. Die häufigste Klage, mit 66%, lautet, der Code sei „fast richtig, aber nicht ganz“. Weitere 45,2% sagen, das Debuggen von KI-generiertem Code dauere länger als erwartet. Kontrollierte Daten fallen weniger schmeichelhaft aus. In einer Studie von [METR](https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/) aus dem Jahr 2025 bearbeiteten 16 erfahrene Open-Source-Entwickler 246 echte Issues in Repositories, die sie gut kannten. Mit erlaubter KI brauchten sie etwa 19% länger, obwohl sie glaubten, rund 20% schneller gewesen zu sein. METR hat inzwischen neuere Daten veröffentlicht. Behandeln Sie diese Zahl also als Momentaufnahme der Werkzeuge von Anfang 2025, nicht als Urteil. Die Lehre lautet nicht „KI ist langsam“. Das Gefühl von Tempo ist ein schlechtes Messinstrument. Messen Sie in Minuten vom Ticket bis zum gemergten PR, nicht daran, wie schnell der erste Entwurf erschien. ![Offenes Notizbuch mit handgezeichnetem Funktionsplan neben Tastatur und Haftnotizen](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/codebasechat/2026-11/216434-inline1.webp) ## Was sollten Sie aufschreiben, bevor Sie einen Prompt schreiben? Einen Plan, in eigenen Worten, unter zehn Zeilen. Ohne ihn füllt das Modell die Lücken mit eigenen Vermutungen, und die sind per Definition generisch. Meine Vorlage ist kurz: - Die Verhaltensänderung, in einem Satz. - Die Dateien, die Sie voraussichtlich anfassen, auch wenn Sie unsicher sind. - Die bestehende Funktion oder das Muster, das der neue Code wiederverwenden muss. - Eine Sache, die er nicht tun darf (keine neue Abhängigkeit, keine Schemaänderung). - Woran Sie erkennen, dass es funktioniert: ein Test, ein curl-Aufruf, ein Screenshot. Punkt 3 wird am häufigsten übersprungen, und genau dort entsteht ein großer Teil des „fast richtigen“ Codes. Das Modell kennt Ihre Hilfsfunktion `withRetry` nicht, es sei denn, Sie nennen sie oder das Modell kann sie lesen. Verzichten Sie auf den Prompt „Bau mir die ganze App“. Einsteiger und Senior-Entwickler bekommen damit dasselbe Ergebnis: einen großen Diff, den niemand versteht, und ein unfertiges Projekt. ## Wie sieht ein brauchbarer Prompt in der Praxis aus? Nehmen wir eine echte Routineaufgabe: Der Webhook-Sender verwirft Events, wenn der Empfänger in ein Timeout läuft. Ein schwacher Prompt lautet „Webhook-Zuverlässigkeit verbessern“. Ein brauchbarer liest sich wie ein Ticket: `Füge sendWebhook() in src/webhooks/sender.ts einen Retry mit exponentiellem Backoff hinzu. Verwende withRetry() aus lib/http.ts wieder. Maximal 4 Versuche, Jitter an. Ändere nicht die öffentliche Signatur und füge keine Abhängigkeiten hinzu. Ergänze einen vitest-Fall für einen Empfänger, der zweimal fehlschlägt und dann antwortet.`Dieser Prompt nennt die Datei, den wiederzuverwendenden Helfer, eine Grenze und eine Prüfung. Das Ergebnis ist ein Diff von vielleicht 30 Zeilen, den Sie in einer Sitzung lesen können. Kommt der Diff mit 150 Zeilen zurück, ist das Modell abgeschweift, und Sie lehnen ihn ab, statt ihn nachzubessern. Zwei kleine Tricks helfen dabei. Lassen Sie sich zuerst einen Plan geben und lesen Sie ihn, bevor sich eine Datei ändert: Ein falscher Plan kostet dreißig Sekunden, ein falscher Diff zehn Minuten. Und wenn eine Antwort danebenliegt, benennen Sie die verletzte Vorgabe, statt zu diskutieren. „Du hast eine neue Abhängigkeit hinzugefügt, die Regel lautet keine“ wirkt besser als ein Absatz Erklärung. ## Welches KI-Werkzeug passt zu welcher Aufgabe? Es gibt drei Typen, und sie zu verwechseln ist der zweithäufigste Fehler. **Inline-Vervollständigung** schlägt die nächsten Zeilen vor, während Sie tippen. Sie eignet sich für Boilerplate und Tests, wenn das Muster schon auf dem Bildschirm steht. **Chat im Editor** beantwortet Fragen zu markiertem Code und schlägt Änderungen vor, die Sie Hunk für Hunk annehmen. **Agenten** nehmen eine Aufgabe entgegen, lesen Dateien, führen Befehle aus und liefern einen Branch zurück. Entscheiden Sie danach, wie viel Sie günstig prüfen können. Eine Vervollständigung, die Sie in zwei Sekunden lesen, ist risikoarm. Ein Agentenlauf über 14 Dateien hat hohen Nutzen und hohen Prüfaufwand. Cursor ist die editorzentrierte Wahl: ein VS-Code-Fork mit starker Tab-Vervollständigung und parallelen Agenten-Sitzungen. Lohnt sich, wenn Sie den ganzen Tag im Editor arbeiten. Überspringen Sie es, wenn Ihr Team auf JetBrains festgelegt ist und nicht wechselt. GitHub Copilot ist die reibungsarme Wahl für Teams, die schon auf GitHub arbeiten, weil PRs, Issues und Reviews an einem Ort liegen. Achten Sie auf die Abrechnung: Seit Juni 2026 läuft sie über nutzungsbasierte AI Credits. Intensive Agentennutzung kostet deshalb mehr, als der Preis pro Platz vermuten lässt. Claude Code ist terminalnativ und agentisch: Sie delegieren einen Refactor oder eine Fehlersuche und prüfen danach das Ergebnis. Es hat keine Inline-Vervollständigung und läuft nur mit Claude-Modellen. Das ist ein fairer Tausch, wenn Sie Delegation auf Aufgabenebene wollen. Aider ist die skriptbare, git-native Option. Jede Änderung wird mit einer Commit-Nachricht automatisch committet, ein Rollback ist also ein `git revert`. Sie zahlen nur die Modell-Tokens, was sich für alle eignet, die die Kosten selbst steuern wollen. ## Wie verhindern Sie, dass die KI Ihr Repository ignoriert? Geben Sie gezielt Kontext. Die meisten schlechten Ergebnisse gehen darauf zurück, dass das Modell die relevante Datei nie gesehen hat. Drei Gewohnheiten helfen. Erstens: Hängen Sie die zwei oder drei Dateien an, die das Muster definieren, nicht das ganze Verzeichnis. Zweitens: Fügen Sie den fehlschlagenden Test oder die Fehlermeldung wörtlich ein, statt sie zu beschreiben. Drittens: Legen Sie im Repository eine kurze Regeldatei an (Benennung, Fehlerbehandlung, verbotene Bibliotheken), die das Werkzeug bei jedem Lauf liest. Die meisten Agenten-Werkzeuge unterstützen eine solche Datei. `# AI-RULES.md - Fehler: Result zurückgeben, in services/ nie werfen - HTTP-Aufrufe laufen über lib/http.ts (hat Retry und Tracing) - Keine neuen Abhängigkeiten ohne Hinweis in der PR-Beschreibung - Tests: vitest, neben der Datei als *.test.ts`Vier solche Zeilen entfernen einen erstaunlich großen Teil der Review-Kommentare. Sie helfen auch Menschen. In einem Repository, das Sie noch nicht kennen, stellen Sie Fragen, bevor Sie Änderungen verlangen. „Wo wird der Ablauf einer Session erzwungen, und was ruft ihn auf?“ ist ein besserer erster Prompt als „füge ein Refresh-Token hinzu“. Sie lesen die Antwort, öffnen die beiden Dateien, die sie nennt, und entscheiden erst dann, was Sie ändern. Das ist dieselbe Schleife aus Suche, Blame und Nachfragen, die Sie ohnehin machen, nur schneller. ![Laptop-Bildschirm mit einem Code-Diff, grün und rot markierte Zeilen](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/codebasechat/2026-11/567383-inline2.webp) ## Wie prüfen Sie KI-generierten Code? Langsamer als den Code einer Kollegin oder eines Kollegen. Ein Kollege hat eine Erfolgsbilanz in Ihrer Codebasis, das Modell nicht. Meine Checkliste, in dieser Reihenfolge: - **Erst ausführen, dann lesen.** Ein Test, den Sie selbst geschrieben haben, schlägt jede selbstsichere Erklärung. - **Imports lesen.** Erfundene Pakete und unbekannte Helfer fallen dort zuerst auf. - **Auf Fehlendes achten.** Fehlerpfade, Null-Behandlung, Aufräumen. Modelle schreiben den Erfolgsfall gut. - **Die Diff-Größe prüfen.** Wenn Sie eine Korrektur mit 10 Zeilen wollten und 120 Zeilen bekommen haben, wurde etwas umgeschrieben, das Sie nicht angefragt haben. - **Löschen, was Sie nicht erklären können.** Wenn Sie eine Zeile im Review nicht verteidigen können, wird sie nicht gemergt. Halten Sie den Commit klein und die Nachricht ehrlich. „Retry zum Webhook-Sender hinzugefügt (KI-unterstützt, Tests ergänzt)“ ist in Ordnung. Verschweigen hilft niemandem und erschwert das spätere Debugging. ## Was geben Sie nie an eine KI ab? Alles, bei dem ein Fehler still und teuer ist. Auth-Logik, Zahlungsabläufe, Datenmigrationen und Berechtigungsprüfungen sind Stellen, an denen „fast richtig“ die Tests besteht und in der Produktion scheitert. Sie können KI auch dort nutzen, aber im anderen Modus: Lassen Sie sie Ihren Code prüfen und Risiken auflisten, statt Code zu schreiben. Eine Liste mit fünf möglichen Problemen kostet drei Minuten. Eine generierte Migration zu lesen kostet den Nachmittag, den Sie damit verbringen, daran zu zweifeln. Wenn Sie noch lernen, gilt eine zweite Ausnahme. Schreiben Sie die erste Version selbst und lassen Sie das Modell sie dann kritisieren. Wer immer die generierte Version übernimmt, lernt Prompten statt Programmieren, und die Lücke zeigt sich beim ersten Ausfall. ## Was ändert sich im Team, und wie sieht die erste Woche aus? Der Unterschied zwischen Einzelpersonen und Teams ist die Review-Last. Eine Entwicklerin mit Agenten kann mehr PRs pro Tag öffnen, als Reviewer lesen können. Legen Sie früh drei Dinge fest: - **Eine Größenobergrenze.** PRs mit mehr als einigen hundert geänderten Zeilen werden aufgeteilt, egal wer oder was sie geschrieben hat. - **Eine Offenlegungsregel.** Sagen Sie, wenn eine Änderung KI-unterstützt ist, damit Reviewer ihre Aufmerksamkeit anpassen. - **Eine gemeinsame Regeldatei.** Eine Quelle der Wahrheit für Konventionen schlägt fünf persönliche Prompts. Beim Onboarding ist die beste Nutzung, die ich gesehen habe, fragegetriebenes Lesen. Neue Kolleginnen und Kollegen fragen den Assistenten, wo Dinge liegen, und prüfen die Antwort dann im Code. Das verkürzt die erste Woche voller „Wem gehört das hier?“, ohne ihnen Code zu geben, den sie nicht pflegen können. ![Zwei Ingenieure sehen gemeinsam ausgedruckte Seiten am Besprechungstisch durch](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/codebasechat/2026-11/e7c330-inline3.webp) Ein Plan für die erste Woche, zum Nachmachen: Tag 1 nur Inline-Vervollständigung, für Tests und Boilerplate. Tag 2 drei Fragen zur Codebasis am Tag im Chat stellen und jede Antwort prüfen. Tag 3 den Chat pro Aufgabe eine kleine Änderung vorschlagen lassen und jeden Hunk lesen. Tag 4 einen Agenten an einer risikoarmen Routine testen, etwa dem Umbenennen eines Konfigurationsschlüssels über mehrere Dateien, auf einem Branch. Tag 5 die Regeldatei aus dem schreiben, was Sie im Review gestört hat. Verfolgen Sie in dieser Woche eine Zahl: Minuten vom Start eines Tickets bis zum gemergten PR, inklusive Review-Korrekturen. Ist sie nicht gesunken, haben Sie gelernt, wo das Werkzeug zu Ihrer Arbeit nicht passt. Auch das ist ein Ergebnis. Der schnellste ehrliche Gewinn, den ich gesehen habe, ist nicht das Generieren. Es ist das Verstehen: ein unbekanntes Modul in zehn Minuten begreifen statt in einer Stunde. Code zu schreiben war nie der langsame Teil der Arbeit. Langsam waren Lesen, Entscheiden und Prüfen. Richten Sie das Werkzeug darauf, behalten Sie das Urteil über den Merge-Knopf, und der Rest folgt. ## FAQ ### Macht KI-Programmierung wirklich schneller? Es hängt von der Aufgabe ab. In einer METR-Studie aus dem Jahr 2025 brauchten erfahrene Entwickler mit KI etwa 19% länger, obwohl sie sich schneller fühlten. Messen Sie deshalb Minuten vom Ticket bis zum gemergten PR. ### Welches KI-Werkzeug eignet sich für ein Team, das auf GitHub arbeitet? GitHub Copilot ist die reibungsarme Wahl, weil PRs, Issues und Reviews dort liegen. Beachten Sie, dass die Abrechnung seit Juni 2026 nutzungsbasiert läuft. ### Welche Aufgaben sollte man KI beim Programmieren nicht überlassen? Auth-Logik, Zahlungsabläufe, Datenmigrationen und Berechtigungsprüfungen. Dort lassen Sie die KI Risiken prüfen, statt Code zu schreiben. ### Wie gibt man einer KI genug Kontext über das eigene Repository? Hängen Sie die zwei oder drei Dateien an, die das Muster definieren, fügen Sie Fehlermeldungen wörtlich ein und pflegen Sie eine kurze Regeldatei im Repository. ### Wie groß sollte ein KI-unterstützter Pull Request sein? Halten Sie PRs unter einigen hundert geänderten Zeilen. Größere Änderungen werden aufgeteilt, unabhängig davon, wer oder was sie geschrieben hat.