Developing Software with AI (in 2026)

Die Meinungen über den Einsatz von agentischer KI in der Softwareentwicklung gehen weit auseinander. Während einige Traditionalisten darauf bestehen, Software mit ihren eigenen Händen und vor allem ihrem eigenen Kopf zu schreiben, haben die meisten Entwickler begonnen, KI in ihren Entwicklungsprozess zu integrieren. Sogar Nicht-Entwickler sind mittlerweile in der Lage, mittels Vibe-Coding Software zu schreiben. Die Qualität des resultierenden Codes hängt stark von der Aufgabe, der Programmiersprache, der Umgebung, dem Modell und auch den Prompting-Fähigkeiten ab. Allein wenn man sich die rasanten Entwicklungen des letzten Jahres oder sogar der letzten Monate ansieht, können wir uns wohl alle darauf einigen, dass sich unser Job verändert und wir als Entwickler auf der Hut bleiben müssen, um nicht abgehängt zu werden.

Code Reviews

Wir Entwickler bei esveo haben auch unterschiedliche Meinungen zum KI-Einsatz, aber eines vereint uns (und ich denke, die breitere Developer-Community würde zustimmen): Wir lieben hochwertigen und sauberen Code, daher sollte KI-generierter Code immer reviewt werden - und das mindestens zweimal.

Während das Erstellen und Reviewen von Pull Requests schon seit einiger Zeit die Norm ist, sollte ein Entwickler, der einen Pull Request erstellt, den Code, den er mergen möchte, immer selbst zuerst gelesen haben. Auch das ist nichts Neues, denn Copy&Paste gab es schon lange vor KI. Aber mit sich ändernden Development Workflows entsteht auch Raum für neue Fehler. Wenn die KI in einer Session riesige Mengen an Änderungen erstellt, besteht die Gefahr, dass einige Änderungen ohne ordentliches Review durchrutschen. IDEs helfen bereits, indem sie den exakten Diff zeigen, der von der KI verursacht wurde, aber es ist wirklich einfach, die Änderungen einfach zu akzeptieren. Aus den Augen, aus dem Sinn…

Die Arbeit als Entwickler hat sich bereits verschoben, davon selbst den Code zu schreiben hin zum Orchestrieren der KI und zum Reviewen von generiertem Code. Code Review macht nicht immer Spaß, daher brauchen wir Workflows, die uns bei der Stange halten und sicherstellen, dass der generierte Code so nah wie möglich am erwarteten Ergebnis ist - niemand reviewt gerne schlechten Code. (An meinen Kollegen Jonathan, der meinen persönlichen KI-Ausrutscher reviewen musste: Es tut mir wirklich leid, aber danke, dass du mir den Rücken frei hältst! 🙂).

Iteration auf Ergebnissen von KI One-Shots

Wenn wir die KI verwenden, um direkt ein neues Feature zu bauen oder bestehenden Code in einem Rutsch zu überarbeiten, werden viele Dateien geändert und die Review kann schwierig sein, wenn die Änderungen umfangreich sind. Man muss auch die Entscheidung treffen, ob man auf den Änderungen vor oder nach dem Commit in die Versionskontrolle iterieren möchte. Wenn man mit temporären Änderungen arbeitet, können Dinge schief gehen, und man möchte vielleicht zum ersten Ergebnis der KI zurückkehren. Andererseits, wenn man die Änderungen committed, könnte die KI den richtigen Kontext der gesamten Änderung verlieren und viel mehr vom neu erstellten aber schon committeten Code als gegeben annehmen, und ist damit im Grunde in dem mittelmäßigen oder gar schlechten Framework gefangen, das sie sich selbst aufgebaut hat.

Am Anfang war der Prompt

Bevor wir mit auf Ergebnissen iterieren, lasst uns zum Anfang zurückgehen.

Prompt- oder heutzutage Context Engineering liegt irgendwo zwischen Kunst und Wissenschaft. Den richtigen Kontext und die richtigen Anweisungen für eine KI zu liefern, verbessert die Ergebnisse drastisch, aber die Art von Kontext, die dafür benötigt wird, hängt stark von der Aufgabe, dem Modell und wahrscheinlich dem Wetter ab. Kreativität ist wichtig, aber es gibt auch konkrete Strategien, die sich als effektiv erwiesen haben.

Normalerweise hat man bei der Implementierung eines neuen Features für ein bestehendes Projekt eine grundlegende Idee, wo dieses Feature leben wird, wie es sich an bestehenden Code anschließt, und vielleicht hat man sogar bestimmte Edge Cases mit möglichen Lösungen im Kopf. Je erfahrener man als Entwickler ist, desto mehr nützlichen Input kann man liefern, um dem Modell zu helfen, das Ziel zu erreichen. Wir Menschen sind noch nicht obsolet und können unsere Erfahrung nutzen.

Anstatt direkt mit der KI zu chatten, speichere ich den Prompt gerne als separate Datei. Das hilft, die Gedanken zu strukturieren und ist auch später eine nützliche Referenz. Diese Datei kann einfach eine MyFeature.prompt.md Datei im Projekt sein. Markdown zu verwenden ist vorteilhaft, weil die KI es versteht und es einen guten Rahmen bietet, um den Prompt sauber zu strukturieren.

Ich habe gute Erfahrungen mit den folgenden groben Richtlinien gemacht:

• Erklärt das Business-Feature und wie das Feature am Ende verwendet werden soll
• Seid spezifisch über Workflows, liefert User Stories, die die beabsichtigten Workflows beschreiben
• Legt technische Details in einen separaten Abschnitt
• Referenziert Dateien im Workspace. Man muss dabei nicht zwingend korrekt formatierten Markdown-Dateilinks verwenden, die KIs sind ziemlich smart im automatischen Auflösen von Datei-, Funktions- oder Klassennamen
• Beschränkt den Scope explizit, wo sinnvoll. Manchmal ist die KI etwas eifrig, einfach alles fertigzustellen oder zu bauen, was an das Feature angrenzt

Man kann gerne KI verwenden, um über die Business-Spezifikation zu iterieren. Manchmal kann die KI Inkonsistenzen entdecken oder bereits interessante Fragen stellen.

Eine Prompt-Datei könnte in der Struktur etwa so aussehen:

# Business Specification

Allow users to archive TODO-List items. As a user I want to be able to remove (but not permanently delete) items from my TODO list.

Interactions:
- In the main list view, there should be a link to another view that shows all archived items
- An item can be archived or restored through the context menu on the item.

# Further effects

- The user should no longer receive any notifications (e.g. for deadlines) on archived items.
- archived items cannot be edited through UIs. to edit an archived item the user needs to restore it first

# Technical Details

- Use a boolean field `isArchived` to the `TodoListItem` entity.
- Instead of adding a new endpoint, add a parameter to the existing `items/get` endpoint
- Create new end-to-end tests for the new functionality and UIs

# Scope Restriction

- Do not create new permissions for the operation to archive/restore items. For now use the same permission that is used for deletion for both operations.

Man kann schnell erkennen, dass dieses Feature, obwohl es ein relativ einfaches Beispiel ist, mehrere Schichten der Anwendung umfasst, einschließlich Datenbank, Backend-Logik, APIs und Frontend-UI.

Arbeit nach Plan

Sobald man mit dem Prompt zufrieden ist, könnte man die KI einfach alles implementieren lassen, aber dann hätte man wieder einen riesigen Block an Änderungen, der auf sorgfältige Review wartet.

Statt mit resultierenden Änderungen zu arbeiten, kann man Review und Iteration vereinfach, indem man einen schrittweisen Implementierungsplan ausarbeitet und erstmal auf dem Plan iteriert. Den Plan lassen wir von der KI verfassen; dafür geben wir einfach unser Prompt-File als Input.

Auch hier bevorzuge ich es, mit einer Plan-Datei MyFeature.plan.md zu arbeiten, die direkt neben der Prompt-Datei liegt, anstatt den Plan in der Chat-Session zu entwerfen. Wenn der Plan größer wird und man mehrfach Anpassungen vornimmt, kann der Chat schnell über sein Context Window hinauswachsen. Und obwohl die IDEs besser darin werden, einen Wechsel des Context Windows vor uns zu verstecken, verliert die KI manchmal den Überblick über Details die weiter zurück in der Konversation liegen. Mit einer Plan-Datei geht nichts verloren.

Dank Plan können wir die Implementierungsschritte überarbeiten und anpassen, bevor eine einzige Zeile Code geschrieben wurde. Aktuelle Modelle neigen dazu, automatisch Code-Snippets einzuschließen, die als Entwürfe für die geplante Implementierung dienen. Diese Snippets machen es uns recht einfach zu sehen, ob die KI in die richtige Richtung geht. Anstatt einen großen Satz an Änderungen im Code zu überarbeiten, iterieren wir auf eine einzelne Datei, bis wir mit dem resultierenden Entwurf zufrieden ist.

Als letzten Schritt vor der Implementierung starte ich gerne eine frische KI-Session und lasse die KI den Plan reviewen und prüfen, wie gut er zum initialen Prompt passt. Nach vielen Iterationsschritten, weicht der erstelle Plan auch gerne mal hier und da vom initialen Prompt ab. Das ist ein weiterer Grund, warum die Arbeit mit Prompt- und Plan-Dateien vorteilhaft ist. Die KI kann beide Dateien schnell parsen und Diskrepanzen aufzeigen.

Kleinschrittige Implementierung und Review

Man könnte jetzt versucht sein, die KI einfach anzuweisen: "Do it!". Wieder würde das Ergebnis ein riesiger Satz an Änderungen sein, und obwohl man nach dem interaktiveren Entwurf des Plans vertrauter mit den Strukturen ist, könnte es immer noch eine Menge Code sein, den man auf einmal reviewen muss.

Mein erster Prompt sieht normalerweise so aus, wenn ich mit der eigentlichen Implementierung beginne:

Start implementation by following the plan defined in MyFeature.plan.md. Start with Step 1 and keep the plan file updated as you go. Do not continue with the other steps, until I explicitly instruct you to do so.

Die Anweisung, die Plan-Datei aktualisiert zu halten, erlaubt es sowohl einem selbst als auch der KI, leicht den Überblick zu behalten, wo man in der Implementierung steht. Das macht es viel einfacher, die Arbeit am nächsten Tag fortzusetzen, wenn man an größeren Features arbeitet.

Ich lasse die KI explizit jeden Schritt einzeln implementieren und weise sie an, zu warten, bevor sie mit den nächsten Schritten fortfährt. Ich sehe mehrere Vorteile bei einem schrittweisen Ansatz in der Implementierung:

Kleinere Review-Pakete

Wenn die KI die Implementierung nach jedem Schritt stoppt und auf Review wartet, bevor sie fortfährt, gibt uns das als Entwicklern einen gut definierten Scope, in dem wir die Änderungen reviewen können, die nur mit diesem einzelnen Implementierungsschritt zusammenhängen.

Fehler früh erkennen

Wenn wir während der Review eines einzelnen Schritts etwas entdecken, mit dem wir nicht zufrieden sind, können wir die KI bitten, die Probleme zu beheben, bevor sie weiter auf ihren Fehlern aufbaut und uns damit später Kopfschmerzen bereitet.

Versionskontrolle

Die Aufteilung der Implementierung in sinnvolle Schritte erlaubt es, die gesichteten Änderungen für jeden Schritt zu committen. Sobald man mit allem fertig und zufrieden ist, kann man die einzelnen Änderungen immer noch zusammenführen. Aber so hat man immer Savepoints, zu denen man zurückkehren kann, wenn man eine Pause machen möchte oder falls etwas schrecklich schief geht.

Leerlauf minimieren

Wenn ich das Modell einfach alles auf einmal machen lasse, wird es eine gewisse Zeit dauern, bis die KI fertig ist. Die KIs können (noch) nicht vollständig unabhängig arbeiten, und zu jedem Zeitpunkt könnte die KI zusätzlichen Input, Klärung oder Bestätigung anfordern. Man kann dieses Verhalten anpassen, aber letztendlich ist das Verhalten nicht deterministisch. Abhängig von der Größe der Aufgabe könnte man sich einen Kaffee holen, zu Mittag essen oder vielleicht parallel an anderen Projekten arbeiten, aber wenn es erforderlichen Input von meiner Seite gibt, müsste ich mich wieder reindenken und dann doch wieder warten. Und im Gegensatz zu KI sind wir Menschen nicht so gut darin, häufig den Kontext zu wechseln.

Ich habe diesen Ansatz ausprobiert, aber bevorzuge erstmal noch, nah am Implementierungsprozess dran zu bleiben. Während die KI mit dem ersten Schritt beschäftigt ist, kann ich bereits anfangen, die ersten eingehenden Änderungen zu prüfen, was den gesamten Prozess beschleunigt. Dieses Vorgehen begrenzt zusätzlich die Anzahl der auf einmal zu sichtenden Dateien und erlaubt es mir, Probleme noch früher zu erkennen. Das Unterbrechen und die Wiederaufnahme der Arbeit der KI innerhalb eines Schritts hat für mich bisher keine Probleme verursacht, also zögert nicht, einzugreifen und frühes Feedback zu geben.

Abschluss der Implementierung

Sobald man mit der Implementierung des ersten Schritts zufrieden ist, fährt man mit dem nächsten Schritt fort. Das macht man, bis alle Schritte erledigt sind und bis es keine offenen TODOs mehr in der Plan-Datei gibt. Nachdem man die einzelnen Schritte mit individueller Review durchlaufen hat, gibt es für uns selbst keinen Bedarf für eine große Review. Jeder andere Reviewer muss immer noch eine große Review machen, aber wenn ihr alles richtig gemacht habt, ist dieses Review nicht anders als bei handgeschriebenem Code.

Je nach persönlicher Präferenz kann man entscheiden, ob man die Prompts und Pläne im Projekt behält. Die Dateien können als Form von Dokumentation dienen, die die KI später referenzieren kann, um die Ideen und die inneren Abläufe bestimmter Features besser zu verstehen.

Weitere Aspekte

Die hier beschriebenen Workflows wurden Ende 2025 entwickelt und verwendet. Angesichts dessen, wie schnell sich Modelle und Tooling entwickeln, könnte alles, was man hier liest, bereits in wenigen Monaten veraltet sein. Meine Vermutung ist, dass die Empfehlungen vor 2027 obsolet werden, aber wer weiß.

Falls ihr den Artikel also irgendwann in der wahrscheinlich nicht so fernen Zukunft lest, seht es als Snapshot der Vergangenheit, wie wir damals 2025/2026 mit KI gearbeitet haben.

Es gibt noch viele weitere Aspekte der KI-gestützten Softwareentwicklung, von denen ich in diesem Abschnitt zumindest einige kurz ansprechen möchte:

MCP-Server

MCP-Server bieten eine großartige Möglichkeit, die Fähigkeiten der KI zu erweitern. Bei der Arbeit mit dem zuvor beschriebenen Prompt-, Plan- und Implementierungs-Workflow haben sich diese MCP-Server als besonders nützlich erwiesen:

• https://github.com/upstash/context7 gibt der KI Zugriff auf die Dokumentation vieler öffentlich verfügbarer Pakete. So kann die KI autonom die offizielle Dokumentation prüfen und verstehen, wie das Paket auf die verwendet werden soll und welche Funktionen zur Verfügung stehen. Wenn man die KI Code schreiben lässt, der Third-Party-Libraries verwendet, verbessert context7 die Qualität der ersten Ergebnisse drastisch.
• https://github.com/ChromeDevTools/chrome-devtools-mcp verbindet die KI mit den Chrome DevTools. Die KI kann jetzt durch Webseiten klicken, Formulare ausfüllen und Layouts verstehen. Das schließt im Grunde den Feedback-Kreis und ermöglicht es der KI, Webapplikationen zu testen und zu debuggen, indem sie selbst Code anpasst und autonom das Ergebnis im Browser überprüft.
• MCP-Server für Datenbanken: Mittlerweile gibt es MCP-Servers für praktisch jeden großen Datenbankanbieter. Das erlaubt der KI, Schema und Daten in der Datenbank zu lesen und zu manipulieren. Migrationen können akkurat generiert werden, weil die KI die Struktur der Datenbank verstehen kann. Die meisten verfügbaren MCP-Server erlauben es, die Art des Zugriffs (read/write, data/schema) zu konfigurieren, den die KI erhält. Falls man sich also Sorgen macht, Daten nach außen zu leaken oder versehentlich die Datenbank zu löschen, kann man einfach den Zugriff einschränken.

Es gibt unzählige verfügbare MCP-Server, die helfen können, Workflows zu verbessern. Wenn der KI bestimmte Fähigkeiten fehlen, stehen die Chancen gut, dass es bereits einen MCP-Server gibt, der der KI die benötigten Tools bereitstellt.

Prompt Refinement und AGENTS.md

Das Verfeinern des Prompts bietet eine riesige Chance, KI-Verhalten auf die spezifischen Bedürfnisse anzupassen. Wenn man über Prompt Design liest, sieht man oft initiale Instruktionen im Stil von:

You are a specialist in … and are assisting with …
Your answers are expertly crafted…

...und so weiter. Wenn man eingebaute KI in Coding-Umgebungen wie VS Code oder Cursor verwendet, erhält das Modell normalerweise bereits vorgebaute Instruktionen, die den Kontext geben, in einer Coding-Umgebung verwendet zu werden.

Ein einfacher Schritt zur Anreicherung des Prompts durch projektspezifischen Kontext ist die Verwendung einer richtig konfigurierten AGENTS.md-Datei. Es gibt viele Guides und Artikel darüber, wie man diese Datei einrichtet, und wie die IDE sogar beim Einrichten assistieren kann. Mit dieser Datei kann man projektspezifischen Kontext für jede KI bereitstellen, die mit der Codebase interagiert. Kurz gesagt könnte diese Datei enthalten:

• Dokumentation über die Architektur, Pakete und Frameworks, die im Projekt verwendet werden
• Informationen über die fachlichen Probleme, die die Software zu lösen versucht
• Coding Guidelines
• Dokumentation von Development Workflows (wie man Tests ausführt, wie man einen Development Server startet, …)

Die bereitgestellten Informationen sind immer automatisch im Scope, wenn man die KI promptet. Falls man also auf bestimmte wiederkehrende Themen stößt, bei denen die KI ein bestimmtes Thema immer wieder recherchieren muss, fügt man einfach eine Notiz in die AGENTS.md hinzu oder noch besser, weist man die KI an, einen Abschnitt für dieses Thema in die AGENTS.md-Datei verfassen.

Für große Monorepos kann man eine separate AGENTS.md-Datei pro Package definieren. Die KI verwendet automatisch die nächstgelegene Datei im Directory-Tree.

Weitere Details findet ihr unter https://agents.md/.

IDE und Model Selection

Eine Sache, über die ich noch gesprochen habe, ist der Einfluss der Auswahl von Model und IDE. Ich verwende hauptsächlich VS Code und GitHub Copilot. Es gibt viele andere praktikable IDEs, die mehr oder weniger native KI-Integration haben. Cursor ist ein gutes Beispiel für eine IDE, in der KI viel tiefer in die IDE integriert ist, was bestimmte Workflows vereinfachen kann.

Was Modelle betrifft, habe ich in den letzten Monaten sehr gerne mit den Anthropic-Modellen gearbeitet, besonders Sonnet 4.5 und Opus 4.5. Obwohl etwas teurer, sind die Fähigkeiten und die Geschwindigkeit des Opus-Modells wirklich die Kosten wert. Beide Modelle sind sehr gut darin, sich in großen Code-Basen zurechtzufinden, und der beschriebene Ansatz zur Entwicklung neuer Features funktioniert einwandfrei mit beiden Modellen.

GPT-5.1 und Gemini 3 produzieren ähnliche Ergebnisse, haben aber leicht unterschiedliche Stile. Meine aktuelle Einschätzung zur Model-Auswahl ist, dass die Wahl des "besten" Modells stark vom individuellen Projekt, Stack und Stil abhängt. Das verwendete Tool zu kennen und zu wissen, wie man es verwendet, ist immer noch besser, als das perfekte Tool zu haben, aber mit seinen Eigenheiten nicht vertraut zu sein.

Background Agents

Die aktuellsten Entwicklungen gehen in Richtung autonomerer Orchestrierung, bei der ein zentrales Modell Sub-Agenten orchestrieren kann, die an unabhängigen Aufgaben im Hintergrund und sogar parallel in isolierten Umgebungen arbeiten. Support für Background Agenten wurde gerade erst im Dezember 2025 in VS Code eingeführt. Im Moment sind One-Shot-Lösungen für größere Aufgaben noch nicht an einem Punkt, an dem ich mit dem Ergebnis zufrieden bin. Daher bevorzuge ich vorerst, nah am Geschehen zu bleiben, anstatt am Ende viele Änderungen auf einmal zu bearbeiten. Ich bin mir ziemlich sicher, dass sich mit den nächsten Generationen von Modellen einiges wird, und ich bin gespannt zu sehen, wohin uns das führt.

Abschließende Gedanken

Es ist schwer zu beurteilen, wie sich unser Job als Entwickler und auch die Rolle von Softwareunternehmen in den nächsten Jahren entwickeln wird. Unsere beste Chance ist es, flexibel zu bleiben und offen für Veränderungen zu sein, um nicht irgendwo auf dem Weg zurückgelassen zu werden.

Durch unseren Blog wollen wir bei esveo praktische Einblicke und reale Erfahrungen mit euch teilen, während wir diese Veränderungen gemeinsam durchleben. Stay curious and happy developing! :-)