yk.camelcase.work
Yevhen Kim
techaiAI-Assisted Development

KI in der Entwicklung ist kein Zusatz mehr — sie wird zur Basisschicht

Ein paar Jahre lang war KI in der Entwicklung schnell beschrieben: Code vervollständigen, Boilerplate vorschlagen, ein paar Minuten im Editor sparen, gelegentlich ein brauchbarer Hinweis.

Diese Phase ist vorbei.

Im Jahr 2026 ist die wichtigste Veränderung nicht, dass KI schneller Code schreibt. Sie hört nicht mehr beim Schreiben auf. Sie arbeitet heute durch den gesamten Weg einer Änderung: Kontext sammeln, einen Plan vorschlagen, Code bearbeiten, Änderungen prüfen, Sicherheits- und Qualitätsrisiken markieren, Korrekturen empfehlen, die Arbeit an den automatisierten Veröffentlichungsprozess übergeben.

Sobald KI auf mehreren Etappen einer Änderung beteiligt ist, ist sie kein Komfortwerkzeug mehr. Sie wird Teil davon, wie das Team tatsächlich arbeitet.

GitHub hat das Ende 2025 sichtbar gemacht, als es KI, Agenten und typisierte Sprachen als Kräfte beschrieb,

die die größten Verschiebungen in der Softwareentwicklung seit mehr als einem Jahrzehnt antreiben.

Was dort zählt, ist nicht die Formulierung. Es ist, was dahintersteht: Der Markt behandelt KI nicht mehr als Nebentool. Sie wird zunehmend als Teil der Engineering-Grundlage gesehen.

Zur selben Zeit änderte sich auch Copilots Code-Review-System. Weg vom Modell, bei dem KI nur Kommentare hinterlässt, hin zu einer Kombination aus LLM-Analyse, Tool Calls und regelbasierten Prüfungen, die konsistente Ergebnisse liefern. GitHub beschreibt es als

Erkennung von Problemen durch ein großes Sprachmodell, den Aufruf externer Werkzeuge und konsistente regelbasierte Prüfungen durch Werkzeuge wie ESLint und CodeQL.

KI schlägt keinen Text mehr vor. Sie arbeitet mit den Werkzeugen zusammen, die Teams ohnehin zur Code-Inspektion nutzen.

Dasselbe gilt für den Copilot Cloud Agent, der ein Repository untersuchen, einen Umsetzungsplan erstellen, Änderungen in einem separaten Branch vornehmen und zur Review vorbereiten kann. GitHub nennt ihn

einen autonomen und asynchronen Agenten für die Softwareentwicklung.

KI wartet also nicht mehr im Editor auf den nächsten Befehl. Sie kann eine klar abgegrenzte Aufgabe übernehmen, mehrere Schritte durchlaufen und das Ergebnis in den normalen Review-Prozess zurückgeben. Das ist der eigentliche Inhalt von "agentischen Workflows" — kein neues Label für altes Autocomplete, sondern der Übergang von einer einzelnen Reaktion zur mehrstufigen Beteiligung.

Wenn das passiert, verändern sich auch die Fragen, die Teams stellen müssen.

"Sollten wir KI nutzen?" hat aufgehört, interessant zu sein. In 2026 ist auch "Welches Modell bevorzugen wir?" schon die falsche Ebene. Die nützlichere Frage ist, wie gut KI in Code-Review, Tests, Release-Vorbereitung, Sicherheit und Qualitätskontrolle eingebunden ist.

Denn sobald KI den ganzen Weg vom Entwurf zur fertigen Änderung mitgeht, optimiert man nicht mehr für Geschwindigkeit. Man optimiert für Kontrolle.

Ohne Kontrolle beschleunigt KI nur das Rauschen.

Eine mittelmäßige Anforderung wird schneller zur sauber verpackten Änderung. Eine fragile Architekturentscheidung landet früher im System. Eine schwache Annahme hält länger durch, weil Prototypen billig geworden sind. Ein Review-Prozess, der schon vorher Dinge übersehen hat, übersieht sie nun schneller.

Deshalb beschreiben die stärksten aktuellen Untersuchungen KI nicht als etwas, das Engineering automatisch reif macht. DORA hat es 2025 auf ein Wort gebracht:

ein Verstärker.

KI stärkt gute Systeme und vergrößert Probleme in schwachen. Teams mit echter Lieferdisziplin, soliden Tests und klaren Standards bekommen mehr heraus. Teams mit schwachen Grundlagen bekommen nicht mehr Reife — sie bekommen schnellere Instabilität.

Die praktischen Folgen sind konkret.

Code-Review wird zu einem gemischten System: KI markiert Auffälligkeiten, regelbasierte Checks bestätigen oder verwerfen sie, Menschen entscheiden, was wirklich riskant ist. Die Aufgabe verschiebt sich vom Querlesen zum Managen von Signal und Eskalation. CI/CD kann sich nicht mehr auf "Build starten" beschränken — wenn KI Änderungen erzeugen, korrigieren und weiterreichen darf, muss die Pipeline Absichten prüfen, Verhalten testen und die Fehler erkennen, die ein Modell überzeugend übersehen kann. Repo-Qualität wird dabei zum echten Eingabeparameter: Je besser Dokumentation, Architekturgrenzen und Tests innerhalb eines Projekts, desto weniger Chaos entsteht, wenn KI autonom arbeitet.

Auch das Bild des starken Entwicklers ändert sich. Die besten stehen heute nicht nur hervor, weil sie schneller liefern, sondern weil sie besser wissen, was sie an KI übergeben, was sie einschränken, was sie von Hand prüfen, und wo ihre eigene Aufmerksamkeit scharf bleiben muss — unabhängig davon, was das Modell vorschlägt.

GitHub hat die Richtung klar beschrieben:

Copilot war früher ein Werkzeug zur Autovervollständigung. Heute ist es ein vollwertiger KI-Assistent, der mehrstufige Arbeitsabläufe ausführen kann.

Wenn KI am System teilnimmt statt nur im Editor zu assistieren, brauchen Teams ein anderes Niveau an Disziplin: klare Regeln im Repository, starke automatisierte Tests, einen verlässlichen Review-Prozess vor dem Merge, Sicherheits-Tools im Lieferpfad, dokumentierte Architekturgrenzen, explizite Vorgaben dafür, was KI autonom tun darf und was nicht.

Ob KI in die Softwareentwicklung gehört, ist keine offene Frage mehr.

Offen ist, ob Teams sie als losen Trick für Geschwindigkeit behandeln oder als etwas, das denselben Anspruch erfordert wie jeder andere kritische Teil des Prozesses. KI in der Entwicklung ist kein Zusatz mehr. Sie ist auf dem Weg, Grundlage zu werden. Die Teams, die dabei gut abschneiden, werden nicht die sein, die am meisten Code erzeugen — sondern die, die wissen, was um diese Erzeugung herum gebaut werden muss.

Quellen

Geschrieben vonYevhen Kim

Wenn dieser Artikel hilfreich war, gibt es im Journal weitere Notizen zu Architektur, AI-Workflows, Delivery und Engineering-Praxis.