Warum man gerade leicht den Überblick verliert
Es ist die letzten Monate ziemlich leicht geworden, bei AI-assisted Softwareentwicklung den Überblick zu verlieren. Ständig tauchen bei LinkedIn neue Heldentaten auf (“17.000 LoC pro Tag pro Entwickler”), neue Tools wie Gas Town, deren Vorgehen überwältigen oder CEOs, die verkünden, dass man “keine Entwickler mehr braucht” bzw. gleichzeitig andere CEOs, die wiederum verkünden, dass “man mehr Entwickler einstellen will”.
Das Ende der Programmiersprachen wird verkündet (Erik Meijer) und dann doch wieder mit Constraints eingefangen. Code ist zukünftig kein Artefakt mehr, oder doch? Wenn nein, was ist es dann? Waren kleine “Batch Sizes” nicht lange das Nonplus-Ultra? Kurze Feedback-Loops? Gilt das (zukünftig) noch, ja oder nein? Gibt es denn gar nichts mehr, an dem man sich orientieren kann? Keine stabilen Patterns und Vorgehensweisen, an die neues Wissen angedockt werden kann?
Gibt es schon noch. Bei unserem neusten CaSE Podcast hatten Heinrich Hartmann, Principal SRE bei Zalando und ich letzte Woche das Vergnügen, uns mit Birgitta Boeckeler dazu auszutauschen. Sie ist Distinguished Engineer bei ThoughtWorks, Expertin fur AI-assisted Software Delivery, Technology Radar Member und auch Teilnehmerin des Anfang Februar statt gefundenen Retreats in Utah zur Zukunft der Software Entwicklung in Zeiten von AI über den wir auch gesprochen haben und ich hier auch berichten will. Ihr könnt natürlich gerne den 90-minütigen Podcast hören (wir haben nicht alle o.g. Punkte adressieren können). Ich wollte aber zusätzlich einen begleitenden Text jenseits der typischen AI-generierten Zusammenfassung zu schreiben, in dem ich noch ein paar Punkte unterbringen kann, die im Podcast nicht angesprochen wurden bzw. davor oder danach diskutiert wurden und natürlich um noch einmal selbst zu reflektieren :-)
Stand der AI Assistance Tools (19. Februar 2026, 19:46 Uhr)
Wir schreiben den 19. Februar 2026, 19:46 Uhr. Es ist wichtig diesen Zeitstempel zu nennen, denn die Entwicklung geht rasend schnell. Wir schauen auf die groben wichtigen Entwicklungen. Das Jahr 2025 war ein interessantes Jahr: es gibt wirklich gute Modelle, es gibt Agenten, es gibt CLIs und es gibt Context Engineering. MCP war ziemlich in und ist nun ein kleines bisschen out.
Bei den Modellen können wir uns kurz halten: Dort sind Claude Opus 4.6 und OpenAI GPT-5.3-Codex die Spitzenreiter. Ich persönlich hänge in meinem Umfeld noch auf 5.2 fest, deswegen kann ich keine Aussage zu den neuen Modellen jenseits von Spielzeugsystemen machen, aber im Allgemeinen herrscht Begeisterung was die Leistungsfähigkeit angeht.
Die Einführung von Coding Agents war ein weiterer Meilenstein in 2025. Im Gegensatz zum einfachen Chatfenster innerhalb der IDE können Agenten mehr. Man kann ihnen Ziele geben und sie können im Gegensatz zum Chatfenster nicht nur Code generieren oder analysieren, sondern auch Dateien schreiben, Kommandos ausführen, Tests schreiben und ausführen, Code-Qualitätswerkzeuge aufrufen oder auch Git-Kommandos ausführen. Dadurch ist es möglich nicht einfach nur im Frage-/Antwort Modus zu arbeiten, sondern konkrete Aufgaben zu vergeben, die iterativ ausgeführt werden können. Man kann auch mehrere (Sub-)Agenten unterschiedliche Aufgaben ausführen lassen, z.B. einer plant, ein anderer implementiert, wiederum ein anderer testet, usw. Implementierungen können auch gesplittet werden, z.B. Frontend-Subagent und Backend-Subagent.
Context Engineering ist die Kuratierung dessen, was das Modell sieht und ist auch eine nennenswerte Entwicklung aus 2025. Man muss dem Modell nicht immer die gesamte Codebasis als Kontext mitgeben, denn das führt nicht nur zu erhöhten Kosten, sondern auch zur Degradierung der Antwortqualität. Code ist auch nicht das Einzige, was ein Modell benötigt um eine Aufgabe gut zu lösen. Zusätzliche nützliche Informationen können Beschreibungen sein, wie man eine Technologie idiomatisch korrekt umsetzt, Coding-Guidelines des Unternehmens oder die zu wählende Konstruktionsoption aus einem Architecture Decision Record. Diese können je nach Tool in dafür vorgesehenen Dateien (z.B. agents.md), slash-commands oder Skills mitgegeben werden. Mit Subagenten kann man die Kontexte für spezielle Aufgaben klein halten und dadurch bessere Resultate erzielen.
Der Trend für alles einen eigenen MCP-Server anzubieten, nimmt ab. Stattdessen kann man existierende CLIs nutzen mit denen die AI inzwischen gut umgehen kann.
“You must be this tall to use Microservices, äh, Agentic Coding“
Ihr lest es sicher täglich bei LinkedIn: wer den generierten Code noch reviewed und feinjustiert ist ein Dino und bald ausgestorben. Die Frontsäue lassen große Teile von neuen Funktionalitäten komplett generieren. Software muss zu großen Teilen immer noch in kurzen, kleinen Schritten entwickelt werden, zumindest wenn sie geschäfts- oder sicherheitskritisch ist und im Team entwickelt wird. Es kommt auch darauf an, von wo man startet und wie das Umfeld ist. Die wenigsten Systeme und Organisationen sind heutzutage AI Native. Die Überschrift sagt es schon: so wie bei Martin Fowlers Artikel, welche Bedingungen gelten müssen um Microservices zu entwickeln und zu betreiben, müssen auch einige Bedingungen erfüllt werden, um AI Agents erfolgreich nutzen zu können.
Wo bleibt die Präzision im Hipster-Land?
Die Frage die ich mir und ihr euch und auch und die Teilnehmer des o.g. Events in Utah stellen, ist, wie man denn in der Gegenwart, der nahen und fernen Zukunft die Qualität unserer Software sicherstellen kann, wenn man deutlich schneller viel mehr Code erzeugen kann. Jetzt interessiere ich mich eher für das heute und die nahe Zukunft und hier ist es so, dass individuelle Teams auch ihre individuellen Developer-Workflows finden müssen. Wie immer ist es ratsam, klein anzufangen und auszuprobieren was geht und was nicht. Die o.g. Dino-Taktik funktioniert für viele Teams gut und kann inkrementell weiterentwickelt werden. Aber wohin? Wie sieht die State-of-Art aus? Bei Microservices war das Poster-Child Netflix, wer ist es bei AI-assistance?
OpenAI (und auch andere Firmen wie z.B. Databricks) haben das Ziel, gar keinen Code mehr von Hand zu schreiben und stattdessen alles generieren zu lassen. Aber welche Voraussetzungen müssen gelten um das sicher in der benötigte Qualität tun zu können? Natürlich, wie immer in komplexen Setups, geht das gut in kleinen, inkrementellen Schritten. Baby-Steps, wie Kent Beck sagen würde. Ein großes komplexes (soziotechnisches) System, welches funktioniert, entsteht immer aus einem kleineren komplexen System, welches funktioniert. OpenAI nutzt z.B. Harness Engineering um Präzision sicherzustellen und fokussiert sich auf 3 Säulen:
- Context-Engineering: Kontinuierlich erweiterte Wissensdatenbank im Code sowie Zugriff der Agenten auf dynamische Kontexte wie Monitoringdaten, Browser-Navigation oder ADRs.
- Architektureinschränkungen: Überwachung nicht nur durch LLM-basierte Agenten, sondern auch durch deterministische benutzerdefinierte Linter und strukturelle Tests. Wir schreiben Unit Tests, Acceptance Tests und Property-Tests selbst - wir wollen im Driver-Seat sitzen. ArchUnit kann strukturelle Einschränkungen als Test liefern und die Freiheit des Agenten einschränken.
- „Garbage Collection“: Agenten, die regelmäßig ausgeführt werden, um technische Schulden zu bekämpfen (Agenten replizieren existierende Patterns und wenn diese schlecht sind und man das erkennt, dann muss man das eben bekämpfen).
Immer wenn die Resultate nicht gut sind, dann ist das ein Smell und diese Säulen müssen verbessert werden (wie auch bei der Netflix-Microservices-Architektur muss sich jeder vor Conference-Driven Development und Cargo-Culting schützen. Selbst überlegen was im eigenen Kontext richtig ist).
Aber, huch? Die letzten beiden Punkte gelten für gute Software-Entwicklung im Allgemeinen. Hier sehe ich eine einfach zu begehende Rampe für uns alle.
Risikodenken
Ach ja, wieder so etwas, dass im AI Land notwendig ist und in der Software Entwicklung im Allgemeinen äußerst nützlich: Risikodenken. Der Code, den ich gerade entwickeln (oder generieren lassen) will: wieviel Risiko (Wahrscheinlichkeit x Auswirkung) steckt da drin? Brauche ich gerade einen Testdata-Builder oder eine Steuerberechnung? CRUD für Stammdaten oder Atomreaktorsteuerungslogik? Wie groß ist der Blastradius? Schreibe ich für mich privat ein Tool oder ist es ein produktionskritisches System? Wie einfach ist es, einen Fehler im generierten Code zu erkennen? Kann das ein Test oder brauche ich eine qualitative Analyse? Es ist ein ständiger Balanceakt – wie viel Aufsicht man braucht bzw. wie viel Autonomie man gibt ist abhängig vom Risiko und von den möglichen Feedbackzyklen.
Innovatoren, frühe und späte Mehrheit, Nachzügler
Ein Problem in sehr vielen Organisationen heutzutage sind Spannungen zwischen Enthusiasten und Skeptikern. Das ist normal, bei neuen Technologien und Methoden unterscheidet man im allgemeinen zwischen Innovatoren, der frühen Mehrheit, der späten Mehrheit und Nachzüglern. Die meisten Menschen sind je nach Situation in allen diesen Kategorien gleichzeitig vertreten. Ich kann AI Innovator sein, aber in ganz anderen Bereichen ein Nachzügler und umgekehrt.
Wie kann eine Organisation diese Spannungen positiv nutzen? Wir brauchen Beides, Experimentierlust und Vorsicht sind gleichermaßen zu belohnen. Es ist gut, wenn eine Kollegin ein interessantes neues Tool oder eine clevere Methodik ausprobiert und sie in die Entwicklungsteams trägt. Skeptiker sorgen dafür das unterschiedlichste Entwicklungskontexte beachtet werden und die Technologie/Methode besser eingeordnet werden kann.
Skeptiker sind nicht immer Nachzügler. Die frühe Mehrheit ist auch erstmal skeptisch und will sehen, dass eine Technologie funktioniert, bevor sie sie nutzt. Innovatoren müssen die frühe Mehrheit überzeugen, sonst geht es nicht weiter.
Nicht zu vernachlässigen ist auch die allgemeine Adoption-Rate. Innovation passiert im Allgemeinen viel, viel langsamer als man denkt. Daher: Nur keine Panik schieben, aber ein Gefühl der Dringlichkeit braucht heute jeder Software-Entwickler.