KI-gestützte Softwareentwicklung in der Praxis
Wo KI im Entwicklungs-Workflow wirklich Zeit spart, wo sie an Grenzen stößt und warum technisches Verständnis wichtiger wird, nicht überflüssig.
KI-Tools gehören seit ein paar Jahren zu meinem Entwicklungsalltag. Der Unterschied zwischen „KI als Autocomplete“ und „KI als Teil eines echten Workflows“ ist allerdings größer, als LinkedIn-Kacheln vermuten lassen. Ein Zwischenstand aus der Praxis, ohne Heilsversprechen und ohne reflexhaftes Abwinken.
KI als Code-Generator vs. KI als Workflow-Baustein
GitHub Copilot ist im Kern besseres Autocomplete: Zeilen vervollständigen, Funktionsrümpfe vorschlagen, die nächsten drei Zeilen raten. Das spart Tipparbeit, gerade in Sprachen mit viel Boilerplate. Wie ein Team Software baut, ändert es nicht – der Denkprozess bleibt gleich, nur die Finger werden entlastet.
Werkzeuge wie Claude Code oder Codex arbeiten auf einer anderen Ebene: Sie bekommen ein Repository, eine Aufgabe, ein paar Vorgaben – und liefern Änderungen über mehrere Dateien, Testläufe, teils iterative Selbstkorrekturen. Der Unterschied ist qualitativ, nicht quantitativ. Diskutiert wird nicht mehr über Syntax, sondern über Ergebnisse.
Ich nutze beides parallel. Copilot bleibt im Editor als Beschleuniger für Passagen, die jeder Entwickler auswendig kennt. Claude Code oder Codex bekommen die Aufgaben, die klar umrissen sind und mehrere Dateien betreffen – etwa „Ergänze diese API um Pagination und zieh die neue Signatur konsistent bis ins Frontend durch, inklusive Tests“.
Wo KI heute wirklich Zeit spart
Am zuverlässigsten profitiert Boilerplate: Formulare, CRUD-Endpunkte, DTO-Mapping, Testgerüste, Datenmigrationen. Alles, was ein erfahrener Entwickler in 20 Minuten runterschreibt und lieber in fünf reviewt. Je konsistenter ein Projekt aufgebaut ist, desto mehr trägt der Effekt – gut strukturierte Repositories mit klaren Konventionen liefern bessere Ergebnisse als historisch gewachsene Monolithen.
Refactorings sind der zweite starke Anwendungsfall. Feldumbenennungen, ein Interface herausziehen, Call-Sites mechanisch anpassen – Aufgaben, die früher stundenlange Fleißarbeit waren, werden zugänglich. Refactorings, die man vorher aus Aufwandsgründen geschoben hat, gehören ehrlich neu bewertet.
Tests und Dokumentation sparen ebenfalls Zeit. KI schreibt plausible Unit-Test-Skelette, Storybook-Cases, README-Abschnitte oder ADR-Entwürfe. Das ersetzt kein Nachdenken, senkt aber die Hürde: aus „schreib ich später“ wird „ich habe einen Entwurf und zieh den jetzt in zehn Minuten gerade“.
Unterschätzt sind erste Debugging-Hypothesen. Für eine Fehlermeldung oder einen Stacktrace liefert ein Assistent zwei, drei plausible Erklärungen. Häufig ist eine davon richtig – und selbst wenn nicht, hat man eine Struktur, an der man weiterdenkt.
Wo KI zuverlässig an Grenzen stößt
Bei Architekturfragen wird die Luft dünn. „Bauen wir Feature X als eigenen Service oder integrieren wir es in den Monolithen?“ beantwortet kein Modell aus einem Repository. Solche Entscheidungen tragen Domänenwissen, Teamdynamik, historische Trade-offs und Betriebsrealität in sich – Kontext, den kein Prompt vollständig einfängt.
Blindfleck Nummer zwei: implizites Wissen im Code. Ältere Systeme haben undokumentierte Annahmen – „diese Spalte darf nicht null sein, weil vor sieben Jahren der Import brach“. Ein Assistent liest Code, aber nicht die Geschichte dahinter. Vorschläge sehen sauber aus und produzieren trotzdem Chaos.
Sicherheit wird unterschätzt. Ein Assistent schreibt Code, der läuft, aber SSRF öffnet, Rate-Limits ignoriert oder Auth an der falschen Stelle prüft. Solange Modelle keinen Threat-Model-Kontext haben, bleibt Sicherheitsverantwortung beim Team.
Und Wartbarkeit über Jahre. Ein KI-Vorschlag optimiert auf „löse jetzt“, nicht auf „ist in drei Jahren noch verständlich, wenn zwei Entwickler ausgetauscht sind“. Ohne Review entsteht Code, der oberflächlich funktioniert, aber innerlich fragmentiert und stilistisch inkonsistent ist.
Learnings aus der Praxis
Nach zwölf Monaten intensiver Nutzung bleiben drei Lehren. Die Qualität des Outputs hängt an der Qualität der Spezifikation; wer knapp und unklar formuliert, bekommt oberflächliche Ergebnisse. „Spec-Driven Development“ ist kein Buzzword, sondern die logische Konsequenz aus dem, was diese Werkzeuge belohnen.
Code-Review bleibt Pflicht. Nicht als Formalie, sondern als bewusster Filter. In Teams, die KI-Vorschläge ohne Prüfung mergen, wächst Tech-Debt schneller, als ein späterer Refactoring-Sprint sie einholen kann. Ich behandle KI-Commits inzwischen wie Pull Requests eines sehr produktiven, aber neuen Team-Mitglieds.
Die Rolle des Entwicklers verschiebt sich – nicht in Richtung „redundant“, sondern in Richtung „kuratierend“. Wer präzise formuliert, Ergebnisse einordnet, Leitplanken setzt und Schwächen sieht, wird spürbar produktiver. Wer stumpf abnickt, produziert schnell viel schlechten Code.
Fazit
KI ändert nichts daran, dass jemand verstehen muss, was gebaut wird. Sie verschiebt nur, wer welchen Anteil an der Produktion trägt. Die Erwartung „bald braucht man keine Entwickler mehr“ verkennt, dass genau die Fähigkeiten wichtiger werden, die man vorher als selbstverständlich betrachtet hat: sauber spezifizieren, kritisch reviewen, Architektur bewusst gestalten, Trade-offs benennen. Wer das kann, wird mit KI schneller. Wer nur Zeilen abtippt, wird ersetzbar – nicht durch die KI, sondern durch die Person, die sie souverän einsetzt.