Mein LLM-Coding-Workflow mit Blick auf 2026

• AI-Coding-Assistenten haben sich im Lauf des Jahres 2025 als zentrales Werkzeug in der praktischen Entwicklung etabliert, und für ihren effektiven Einsatz sind ein strukturierter Workflow sowie verantwortungsbewusste menschliche Eingriffe unverzichtbar
• Statt sofort um Codegenerierung zu bitten, erhöht ein Vorgehen, bei dem zunächst klare Spezifikationen und ein Plan erstellt und die Umsetzung darauf aufbauend schrittweise durchgeführt wird, zugleich Qualität und Produktivität
• Je stärker man die Arbeit in kleine Einheiten zerlegt und ausreichend Kontext sowie Einschränkungen bereitstellt, desto deutlicher lassen sich Fehler und Konsistenzprobleme von LLMs verringern
• Statt sich auf ein einzelnes Modell zu verlassen, verbreitet sich ein Workflow, bei dem mehrere LLMs und Tools je nach Zweck ausgewählt und KI über den gesamten Entwicklungszyklus hinweg unterstützend eingesetzt wird
• Letztlich wirkt KI als starker Produktivitätsverstärker, wenn der Mensch durch Tests, Reviews und Versionsverwaltung die Kontrolle behält

---

Überblick

• Im Lauf des Jahres 2025 wurden AI-Coding-Assistenten in großem Maßstab tatsächlich zum Schreiben von Produktivcode eingesetzt
• Ingenieure von Anthropic haben Claude Code aktiv eingeführt und inzwischen ein Niveau erreicht, auf dem rund 90 % des Claude-Code-Codes von Claude Code selbst geschrieben werden
• Der Einsatz von LLMs fürs Programmieren ist keine Magie auf Knopfdruck; das Erlernen neuer Muster und kritisches Denken sind unverzichtbar
• KI sollte offensiv genutzt werden, doch die Verantwortung für die erzeugte Software liegt bei den Entwicklern selbst
• Der Kern besteht darin, LLMs nicht als autonome Entscheider, sondern als starke Pair-Programmer zu behandeln, die klare Richtung, Kontext und Aufsicht benötigen

Mit einem klaren Plan beginnen (erst die Spezifikation, dann der Code)

• Man sollte dem LLM keine vagen Anfragen zuwerfen, sondern mit Problemdefinition und Lösungsplanung beginnen
• Bei neuen Projekten erklärt man die Idee und bittet das LLM, wiederholt Fragen zu stellen, um Anforderungen und Edge Cases zu konkretisieren
• Am Ende wird alles in einer spec.md zusammengefasst, einschließlich Anforderungen, Architekturentscheidungen, Datenmodell und Teststrategie
• Diese Spezifikation wird in ein modell mit guter Schlussfolgerungsfähigkeit eingespeist, um einen Projektplan zu erzeugen, der die Umsetzung in logische, kleine Tasks aufteilt
• Wie Les Orchard es formuliert: Ein schneller, strukturierter Planungsschritt nach dem Prinzip „Waterfall in 15 Minuten“ macht das anschließende Coding deutlich reibungsloser
• Mit einer klaren Spezifikation und einem Plan wissen Mensch und LLM gleichermaßen genau, was warum gebaut wird, und Nacharbeit sowie verschwendete Zyklen lassen sich vermeiden

Arbeit in kleine, iterative Chunks aufteilen

• Statt vom LLM in einem Zug eine riesige Ausgabe zu verlangen, wird das Projekt in wiederholbare Schritte bzw. Tickets zerlegt und nacheinander bearbeitet
  • Beispiel: Man promptet mit einer Einheit wie „Implementiere Schritt 1 des Plans“, testet nach dem Coding und geht dann zu Schritt 2 über
• Gibt man auf einmal einen zu großen Umfang vor, gerät das Modell leicht durcheinander oder liefert chaotische Ergebnisse, und die Kosten für die Nachbesserung steigen stark
• Wenn ganze große App-Blöcke am Stück generiert werden, häufen sich Konsistenzbrüche und doppelter Code, und es fiel sogar die Einschätzung, es wirke „als hätten zehn Leute ohne Abstimmung daran gearbeitet“
• In jeder Iteration wird auf dem bereits aufgebauten Kontext aufgesetzt und schrittweise ergänzt; das passt auch gut zum Ansatz des TDD (testgetriebene Entwicklung)
• Einige Coding-Agent-Tools unterstützen diesen Chunk-Workflow ausdrücklich und können Prompt-Plan-Dateien erzeugen, die sich der Reihe nach ausführen lassen

Umfangreichen Kontext und Guidance bereitstellen

• LLMs leisten nur im Rahmen des bereitgestellten Kontexts gute Arbeit; deshalb sollten relevanter Code, Dokumentation und Randbedingungen ausreichend mitgegeben werden
• Claude kann im Projects-Modus ein komplettes GitHub-Repo als Kontext laden, und IDE-Assistenten wie Cursor oder Copilot beziehen geöffnete Dateien automatisch ein
• Ein Brain-Dump ist oft effektiv: Dabei gibt man dem Modell vorab alle Informationen, die es kennen muss, einschließlich hochrangiger Ziele, Beispiele für gewünschte Lösungen und Ansätze, die vermieden werden sollen
• Mit Tools wie gitingest oder repo2txt lassen sich benötigte Teile der Codebasis als Textdatei dumpen und dem LLM bereitstellen
• Claude Skills gehen über eine Arbeitsweise hinaus, die auf wiederholtem Prompting beruht, und bündeln Anweisungen, Skripte und Domänenexpertise zu robusten, wiederverwendbaren Modulen
  • Es gibt auch eine von der Community kuratierte Skills-Sammlung
  • Das Skill frontend-design kann etwa die bei von LLMs erzeugten UIs häufige lila-lastige Designästhetik korrigieren
• Es ist wirkungsvoll, Kommentare und Regeln direkt im Prompt zu verankern, um die KI zu steuern
  • Beispiel: „Hier ist die aktuelle Implementierung von X. Erweitere sie zu Y, aber zerstöre dabei Z nicht.“
• LLMs haben die Eigenschaft, Anweisungen wörtlich zu befolgen; je detaillierter und kontextklarer die Instruktionen sind, desto eher lassen sich Halluzinationen und abwegige Vorschläge reduzieren

Das passende Modell wählen (bei Bedarf mehrere Modelle nutzen)

• Nicht alle Coding-LLMs sind gleich gut; wichtig ist, gezielt ein Modell oder einen Dienst passend zur Art des Tasks auszuwählen
• In manchen Fällen ist es effektiv, zwei oder mehr LLMs parallel einzusetzen, um unterschiedliche Ansätze für dasselbe Problem gegenzuprüfen
• Jedes Modell hat eigene Tendenzen und Stärken; deshalb ist es sinnvoll, bei Blockaden oder nur mittelmäßigen Ergebnissen auf ein anderes Modell zu wechseln
• Mit dem Ansatz der „Model Musical Chairs“ kann man denselben Prompt unverändert in einen anderen Dienst übernehmen und so blinde Flecken eines bestimmten Modells umgehen
• Wenn möglich, bietet die Nutzung aktueller Pro-Tier-Modelle in puncto Qualität einen klaren Vorteil
• Wenn eine längere Zusammenarbeit vorgesehen ist, ist auch der „Vibe“ des KI-Pair-Programmers – also ob Antwortton und Interaktionsgefühl zur eigenen Arbeitsweise passen – ein wichtiges Auswahlkriterium

AI-Coding über den gesamten Lifecycle hinweg nutzen

• In der Kommandozeilenumgebung sind KI-Agenten wie Claude Code, OpenAI Codex CLI, Google Gemini CLI aufgekommen, die innerhalb eines Projektverzeichnisses Dateien lesen, Tests ausführen und mehrstufige Änderungsarbeiten erledigen können
• Googles Jules und GitHubs Copilot Agent lassen sich als asynchrone Coding-Agenten nutzen, die ein Repo in eine Cloud-VM klonen, dort arbeiten und anschließend einen PR eröffnen
• Diese Tools sind nicht perfekt; ihre Grenzen zu verstehen und sie entsprechend zu verwenden, ist unverzichtbar
  • Bei mechanischen Arbeiten wie dem Erzeugen von Boilerplate, dem Anwenden wiederholter Änderungen oder dem automatischen Ausführen von Tests beschleunigen sie stark, doch die Qualität hängt weiterhin entscheidend von menschlicher Guidance ab
• Beim Einsatz von Agenten hilft es erheblich, zu Beginn auch einen Plan oder eine Todo-Liste mitzugeben, damit die korrekte Reihenfolge der Arbeitsschritte erkannt wird
• KI-Agenten sind noch nicht an dem Punkt, eine komplette Funktion unbeaufsichtigt zu implementieren und dabei perfekte Ergebnisse zu liefern; ein beaufsichtigter Einsatz ist der realistische Ansatz
• Mit Orchestrierungstools wie Conductor wird derzeit experimentiert, mehrere Agenten parallel laufen zu lassen und unterschiedliche Funktionen gleichzeitig zu bearbeiten

Den Menschen im Loop halten – gründlich validieren, testen und reviewen

• KI erzeugt zwar ohne Zögern plausibel wirkenden Code, aber die Verantwortung für Qualität und Ergebnis liegt vollständig beim Entwickler
• Wie Simon Willison es ausdrückt, sollte man einen LLM-Pair-Programmierer als selbstüberschätzend und fehleranfällig betrachten; er schreibt Bugs oder unsinnigen Code auch noch mit voller Überzeugung
• Von KI erzeugte Code-Snippets sollten wie Code eines Junior-Entwicklers behandelt werden; den Code selbst lesen, ausführen und bei Bedarf Tests durchführen
• Tests sollten natürlich in den Workflow eingebunden werden, und schon in der Planungsphase sollten für jeden Schritt Testlisten und ein Testplan mitentworfen werden
• Tools wie Claude Code sollte man nach der Implementierung einer Aufgabe explizit anweisen, die Test-Suite auszuführen und bei Fehlschlägen auch die Ursachenanalyse und Behebung vorzunehmen
• Coding-Agenten werden meist dort am besten genutzt, wo Teams und Einzelpersonen bereits eine solide Testkultur haben
• In Umgebungen ohne Tests besteht die Gefahr, dass der Agent weitermacht und von keinem Problem ausgeht, obwohl er tatsächlich mehrere Teile kaputtgemacht hat
• Zusätzlich zu automatisierten Tests sollte Code Review als Pflichtschritt bestehen bleiben, idealerweise mit manuellen Reviews und KI-basierten Reviews parallel
  • Mit einer separaten KI-Session oder einem anderen Modell kann man die von der ersten KI geschriebenen Codes kritisch prüfen oder reviewen lassen
  • Beispiel: Nachdem Claude Code geschrieben hat, Gemini bitten, die Fehler oder Verbesserungsmöglichkeiten der betreffenden Funktion zu prüfen
• Chrome DevTools MCP als zentrales Werkzeug für Debugging und die Qualitätsschleife nutzen, um die Lücke zwischen statischer Analyse und realer Browser-Ausführung zu schließen
  • Dem KI-Agenten Zugriff geben, damit er DOM-Struktur, Performance-Traces, Konsolenlogs und Netzwerkanfragen direkt beobachten kann
  • So sind LLM-basierte automatische UI-Tests möglich, ohne den Kontext manuell übertragen zu müssen
  • Auf Basis echter Runtime-Daten werden Bugs präzise diagnostiziert und behoben
• Das Ergebnis einer übermäßigen Abhängigkeit von KI in einem eiligen Projekt beschrieb ein Entwickler als inkonsistentes Chaos
  • Doppelte Logik, unterschiedliche Methodennamen und eine nicht integrierte Architektur häuften sich an
  • Im Rückblick räumte er ein, immer weiter erzeugt zu haben, ohne einen Schritt zurückzutreten und die von der KI zusammengefügte Gesamtstruktur zu prüfen
  • Am Ende kam es zu einem großen Refactoring und zur Schlussfolgerung, es nie wieder unbeaufsichtigt laufen zu lassen
• Unabhängig vom Umfang der KI-Nutzung muss der Entwickler bis zum Schluss ein verantwortungsvoller Engineer bleiben
• Praktisch bedeutet das: erst mergen oder deployen, wenn man den Code verstanden hat; liefert die KI eine komplexe Implementierung, sollte man erklärende Kommentare oder eine Umschreibung in eine einfachere Form verlangen

Häufig committen und Versionsverwaltung als Sicherheitsnetz nutzen

• Je mehr man mit einer KI arbeitet, die schnell große Mengen Code erzeugt, desto mehr braucht man engmaschige Gewohnheiten in der Versionsverwaltung
• Nach jeder kleinen abgeschlossenen Aufgabe oder erfolgreichen automatischen Korrektur sollte man einen git-Commit mit klarer, aussagekräftiger Nachricht anlegen, damit man bei Problemen durch die nächste Änderung sofort zu einem Checkpoint zurückkehren kann
• Commits wie Save Points in einem Spiel behandeln, damit man jederzeit zum letzten stabilen Zustand zurückkehren kann, wenn eine LLM-Session aus dem Ruder läuft
• Versionsverwaltung spielt auch in der Zusammenarbeit mit KI eine wichtige Rolle; wenn wegen der Grenzen des Kontextfensters nicht alle Änderungen erinnert werden, wird die git-Historie zum verlässlichen Arbeitsprotokoll
• Durch das Durchsehen der jüngsten Commits lassen sich Änderungen schnell gegenüber der KI oder auch sich selbst zusammenfassen
• Wenn man git diff oder Commit-Logs in den Prompt aufnimmt, kann das LLM neuen Code und den vorherigen Zustand präzise erfassen
• LLMs sind gut darin, Diffs zu interpretieren und Werkzeuge wie git bisect zu nutzen, um entlang der Commit-Historie hartnäckig den Punkt zu verfolgen, an dem ein Bug hineingekommen ist
• Fein aufgeteilte Commits und klare Nachrichten dokumentieren den Entwicklungsprozess ganz natürlich und helfen stark beim Code Review
• Auch wenn ein KI-Agent viele Änderungen auf einmal ausführt, lässt sich bei in Commit-Einheiten getrennten Änderungen die problemverursachende Stelle präzise bestimmen
• Branches oder Worktrees nutzen, um KI-Experimente vom produktiven Code zu isolieren
  • Nach einer von Jesse Vincent inspirierten Methode für jedes neue Feature oder Teilprojekt ein frisches git-Worktree anlegen
  • Mehrere KI-Coding-Sessions im selben Repo parallel und ohne gegenseitige Störung laufen lassen und die Ergebnisse selektiv mergen
  • Jede KI-Aufgabe ist damit wie in einem eigenen Sandbox-Branch; fehlgeschlagene Experimente können verworfen werden, ohne main zu beeinflussen
• Den Grundsatz beibehalten, niemals Code zu committen, den man nicht versteht und nicht erklären kann

KI-Verhalten mit Regeln und Beispielen anpassen

• Den Standardstil oder Ansatz der KI nicht einfach unverändert übernehmen; schon klare Richtlinien haben großen Einfluss auf Qualität und Konsistenz der Ausgaben
• Die Datei CLAUDE.md regelmäßig pflegen, um Prozessregeln und Präferenzen für Claude festzuhalten, und beim Einsatz von Gemini CLI auf die gleiche Weise GEMINI.md nutzen
  • Zum Beispiel: Code im Projektstil schreiben, Lint-Regeln einhalten, bestimmte Funktionen nicht verwenden, funktionalen Stil gegenüber OOP bevorzugen usw.
  • Zu Beginn der Session die entsprechende Datei an Claude geben, damit sich die gesamte Arbeit an diesen Vorgaben ausrichtet
  • Laut Jesse Vincent verringert dieser Ansatz die Häufigkeit, mit der die KI in unerwünschte Richtungen abdriftet oder fremde Muster einführt
• Auch ohne separate Regeldatei lassen sich über Custom Instructions oder System Prompts Ton und Verhalten allgemein festlegen
  • Sowohl GitHub Copilot als auch Cursor bieten Funktionen, um das Verhalten der KI projektweit global zu konfigurieren
  • Den Coding-Stil in einem kurzen Absatz festhalten: „4 Leerzeichen Einrückung verwenden, in React Pfeilfunktionen vermeiden, beschreibende Variablennamen nutzen, der Code muss ESLint bestehen“
  • Ben Congdon erwähnte, dass er überrascht war, wie selten die Funktion für Custom Instructions in Copilot genutzt wird, und wies darauf hin, dass schon ein paar Beispiele und Präferenzen im Voraus genügen, damit Code im teamtypischen Stil ausgegeben wird
• Inline-Beispiele bereitzustellen ist eine besonders starke Technik
  • Wenn eine Funktion auf eine bestimmte Weise implementiert werden soll, zuerst eine ähnliche bereits vorhandene Funktion im Codebestand zeigen und erklären: „X wurde so implementiert, also nutze für Y denselben Ansatz“
  • Wenn der Kommentarstil angepasst werden soll, selbst eine Zeile schreiben und dann darum bitten, diesen Stil fortzusetzen
  • Letztlich geht es darum, das Modell mit einem Muster zum Nachahmen vorzuprägen; LLMs sind bei solcher Imitation sehr stark
• In der Community werden verschiedene Regelsets geteilt, um das Verhalten von LLMs zu verfeinern
  • Etwa die „Big Daddy“-Regeln oder die Ergänzung von Klauseln wie „keine Halluzinationen, keine Täuschung“ im Prompt
  • Solche Mechanismen sollen verhindern, dass die KI nicht existierenden Code erfindet oder übertrieben selbstsicher auftritt
  • Beispiel: Wenn man am Anfang des Prompts ergänzt „Wenn du unsicher bist oder der Kontext der Codebasis fehlt, erfinde keine Antwort, sondern bitte um Klärung“, verringert das Halluzinationen
  • Eine weitere Regel wie „Bei Bugfixes immer kurz per Kommentar den Grund erläutern“ führt dazu, dass die KI erklärende Kommentare wie // Fixed: X zu Y geändert, um gemäß Spezifikation Z zu verhindern hinterlässt

Tests und Automatisierung als Verstärker nutzen

• Je konsequenter CI/CD, Linter und Code-Review-Bots eingesetzt werden, desto besser funktioniert AI in einer Umgebung, die Fehler automatisch herausfiltert
• Je höher der Anteil von AI-generiertem Code in einem Repo ist, desto unverzichtbarer ist eine robuste Continuous-Integration-Umgebung
  • Bei jedem Commit oder PR automatische Tests ausführen, Stilprüfungen mit Tools wie ESLint und Prettier erzwingen und nach Möglichkeit sogar Staging-Deployments pro Branch einschließen
  • Das lässt sich so einrichten, dass die AI dies selbst auslöst und die Ergebnisse bewertet
  • Beispiel: Wenn Jules oder GitHub Copilot Agent einen PR öffnet, führt die CI Tests aus und meldet Fehlschläge → die Fehlerlogs werden an die AI weitergegeben, was zu „Der Integrationstest ist bei XYZ fehlgeschlagen, lass uns das gemeinsam debuggen“ führt
  • Der Prozess der Fehlerbehebung verwandelt sich in eine kollaborative Schleife mit schnellem Feedback, worauf AI besonders gut anspringt
• Automatisierte Code-Qualitätsprüfungen dienen ebenfalls als Steuerinstrument für AI
  • Die Linter-Ausgabe direkt in den Prompt aufnehmen; wenn Code geschrieben wurde, der beim Linting durchfällt, die Fehlermeldungen kopieren und mit „Behebe diese Probleme“ an die AI geben
  • Das wirkt, als würde ein strenger Lehrer der AI über die Schulter schauen
  • Wenn AI Tool-Ausgaben wie Testfehlschläge oder Linter-Warnungen erkennt, versucht sie hartnäckig, Korrekturen vorzunehmen
• Auch AI-Coding-Agenten selbst integrieren zunehmend Automatisierungs-Hooks
  • Manche Agenten erkennen eine Aufgabe erst dann als „abgeschlossen“ an, wenn alle Tests bestanden sind
• Code-Review-Bots, ob AI oder Mensch, lassen sich ebenfalls als zusätzlicher Filter nutzen
  • Review-Kommentare können direkt als Verbesserungs-Prompts verwendet werden
  • Beispiel: Wenn CodeRabbit oder ein anderer Reviewer schreibt: „Diese Funktion tut X, aber das ist nicht ideal“, kann man die AI fragen: „Kannst du das unter Berücksichtigung dieses Feedbacks refaktorieren?“
• Die Kombination aus AI und Automatisierung schafft eine positive Rückkopplungsschleife
  • AI schreibt Code → Automatisierungstools finden Probleme → AI behebt sie → Wiederholung; der Entwickler überwacht nur noch die Richtung auf hoher Ebene
  • Es fühlt sich an wie die Arbeit eines extrem schnellen Junior-Entwicklers, die sofort von einem unermüdlichen QA-Ingenieur geprüft wird
  • Allerdings muss diese Umgebung vom Entwickler selbst aufgebaut werden; in Projekten ohne Tests oder Automatisierung besteht das Risiko, dass subtile Bugs oder Qualitätsverluste durch AI erst viel später sichtbar werden
• Eines der Ziele auf dem Weg zu 2026 ist die Stärkung der Quality Gates rund um AI-Codebeiträge
  • Mehr Tests, mehr Monitoring und bei Bedarf sogar Strukturen, in denen AI andere AI reviewt
  • In der Praxis wurde bereits beobachtet, dass ein Modell Probleme erkennt, die ein anderes übersehen hat

Kontinuierliches Lernen und Anpassen (AI verstärkt Fähigkeiten)

• Wenn jede AI-Coding-Session als Lernchance behandelt wird, entsteht ein positiver Kreislauf, in dem mit wachsendem Wissen auch der Nutzen von AI steigt
• Durch den Einsatz von LLMs in der Entwicklung kommt man ganz natürlich mit neuen Sprachen, Frameworks und Techniken in Berührung, die man sonst vielleicht nie ausprobiert hätte
• Mit einem soliden Fundament im Software Engineering kann AI die Produktivität um ein Vielfaches steigern; fehlt dieses Fundament, verstärkt sie ebenso die Verwirrung
• Eine gemeinsame Beobachtung erfahrener Entwickler ist, dass LLMs dazu neigen, bestehende Best Practices zu verstärken
  • Klare Spezifikationen, gut ausgebaute Tests und konsequente Code Reviews entfalten noch größere Wirkung, je stärker AI eingebunden ist
• Während AI Boilerplate übernimmt, kann sich der Entwickler auf Abstraktionen höherer Ebene wie Design, Interfaces und Architektur konzentrieren, doch dafür müssen diese Fähigkeiten bereits vorhanden sein
• Wie Simon Willison anmerkt, führt heute fast alles, was einen Senior Engineer ausmacht—Systemdesign, Komplexitätsmanagement, das Abwägen zwischen Automatisierung und manueller Arbeit—zu den besten Ergebnissen, wenn es mit AI kombiniert wird
• Der Einsatz von AI fördert tatsächlich den Ausbau der Engineering-Fähigkeiten
  • Man wird in der Planungsphase strenger und denkt bewusster über Architektur nach
  • Indem man eine AI steuert, die sehr schnell, aber etwas naiv codet, schärft man das eigene Urteilsvermögen
• Auf die Sorge, AI könne Fähigkeiten abbauen, gilt: Richtig eingesetzt bewirkt sie eher das Gegenteil
  • Durch AI-Code-Reviews lernt man neue Idiome und Lösungsansätze
  • Beim Debuggen der Fehler von AI vertieft sich das Verständnis für Sprache und Problemdomäne
  • Indem man verlangt, dass sie Code oder Gründe für Änderungen erklärt, kann man sie wie einen Bewerber im Interview ständig befragen und dabei Erkenntnisse gewinnen
  • Wenn Bibliotheken oder Ansätze unklar sind, lässt sich AI als Research Assistant nutzen, um Optionen und Trade-offs zu vergleichen
• Im großen Bild verstärken AI-Tools Fachkompetenz
  • Mit Blick auf 2026 überwiegt weniger die Angst, den Job zu verlieren, als vielmehr die Erwartung, repetitive und monotone Arbeit abzugeben und mehr Zeit für kreative und komplexe Probleme zu haben
  • Umgekehrt besteht ohne solides Fundament das Risiko eines auf Steroiden gesetzten Dunning-Kruger-Effekts durch AI
• Als Empfehlung gilt, die eigenen Fähigkeiten kontinuierlich zu schärfen, während man mit AI Lernen und Produktivität beschleunigt, und regelmäßig bewusst ohne AI zu coden, um die Grundlagen scharf zu halten
• Letztlich ist die Kombination aus Entwickler und AI deutlich stärker als jede Seite für sich allein, und innerhalb dieser Kombination muss der Entwickler seinen Teil der Rolle zuverlässig erfüllen

Fazit

• AI wurde zwar aktiv in den gesamten Entwicklungs-Workflow integriert, aber weiterhin vorsichtig und expertengesteuert
• Der angestrebte Ansatz ist keine Entwicklung, bei der AI alles automatisiert, sondern „AI-augmented Software Engineering“
• Die besten Ergebnisse entstehen, wenn auf die Zusammenarbeit mit AI weiterhin klassische Disziplinen des Software Engineerings angewendet werden
• All die mühsam aufgebauten Praktiken—Design vor dem Coden, Tests schreiben, Versionsverwaltung, das Einhalten von Code-Standards—bleiben gültig und sind in einer Situation, in der AI die Hälfte des Codes schreibt, sogar noch wichtiger
• Die Tools entwickeln sich weiter, und der Workflow wird sich ebenfalls mit ihnen verändern
  • Ein vollständig autonomer „AI-Entwicklungspraktikant“ könnte noch mehr einfache Aufgaben übernehmen, während Menschen sich auf Probleme höherer Ebene konzentrieren
  • Neue Methoden zum Debuggen und neue Paradigmen für die Code-Erkundung könnten entstehen
• Bei allen Veränderungen gilt es, immer im Loop zu bleiben
  • Die AI anleiten, Ergebnisse validieren, dabei lernen und die Produktivität verantwortungsvoll ausweiten
• Das abschließende Fazit ist klar: AI-Coding-Assistenten sind starke Verstärker, aber die Regie auf der Bühne liegt bis zum Schluss beim menschlichen Engineer