Wie man an die Entwicklung mit KI-Agenten herangeht
Kontrolle über das Ergebnis, der Mensch als Architekt und Tester, und ein Skill, der den Agenten zwingt, seinen Entwurf zu erklären, bevor er Code schreibt.
Ich denke, es gibt eine Menge Meinungen dazu, wie man Agenten in der Entwicklung richtig einsetzt. In diesem Artikel teile ich meinen eigenen Ansatz. Er wird sich von dem anderer wahrscheinlich unterscheiden, die Grundgedanken werden sich aber ganz sicher sehr ähneln.
1. Wie du die Kontrolle über das behältst, was der Agent produziert
Ich halte Kontrolle über das Ergebnis für die Grundlage eines guten Einsatzes von Agenten in der Entwicklung. Wir müssen nicht jede Zeile Code kennen. Wir sollten aber jede Architekturentscheidung kennen und verstehen.
Darin liegt ein wesentlicher Unterschied. Eine Zeile Code schreibt man in einer Minute um, und meistens hängt nichts daran. Eine Architekturentscheidung kommt in einem halben Jahr zurück, wenn niemand mehr weiß, warum es so ist — und sie umzuschreiben dauert keine Minute, sondern Wochen.
2. Welche Rolle der Mensch bei der Entwicklung mit KI-Agenten hat
Meiner Meinung nach muss der Mensch in der Entwicklung mit Agenten vor allem Architekt, UX-Designer und Tester sein. Natürlich kann KI auch in diesen Rollen helfen — aber der Mensch muss einen erheblichen Teil der Prüfarbeit selbst leisten.
Das ist der Teil, der sich nicht delegieren lässt. Der Agent schreibt dir Code, der funktioniert. Ob es der richtige Code an der richtigen Stelle ist, und ob das, was du beauftragt hast, überhaupt eine gute Sache war — das bleibt bei dir.
3. Wie man einen Claude-Code-Skill schreibt, der den Entwurf erzwingt
Aus eigener Erfahrung empfehle ich, sich einen Skill anzulegen, in dem du dem Agenten sagst, dass er dir vor jeder Umsetzung zuerst die gewählten Architekturschritte erklären muss — und zwar in einer vorab festgelegten Struktur in einer Markdown-Datei.
Sag dem Agenten, er soll reichlich Mermaid-Diagramme, Beispiele und Grafiken verwenden. Ein Diagramm legt Unsinn offen, der sich im Fließtext gut versteckt: wenn der Agent den Datenfluss zeichnet und zwei Komponenten in beide Richtungen miteinander reden, sieht man es auf den ersten Blick.
Ein solcher Skill kann zum Beispiel so aussehen:
.claude/skills/it-analysis/SKILL.md
---
name: it-analysis
description: Erstelle eine IT-Analyse
---
# IT-Analyst
Du bist ein Senior-IT-Analyst. Du spezialisierst dich auf IT-Analysen von IT-Systemen und deren Architektur.
## Workflow
1. **Verstehe, was du lösen sollst** — Verstehe die Aufgabe und denke darüber nach. Wie löst man sie? Welche Lösungsvarianten gibt es? Edge Cases?
2. **Erstelle die Analyse nach der Vorlage template.md**
3. **Wenn es Antworten auf bestehende Fragen gibt** - Überarbeite die Analyse auf Basis der Antworten auf die offenen Fragen. Lösche weder die offenen Fragen noch die Antworten, lass die ursprünglichen stehen. Du darfst weitere Fragen ergänzen. Setze ans Ende der Analyse eine Übersicht der Änderungen (Changelog).
## Rules
- Die Ausgabe muss der Vorlage `template.md` entsprechen.claude/skills/it-analysis/template.md
# Vorlage für das Erstellen von Analysen
## Inhalt
1. [Architektur](#1-architektur)
2. [Datenbank](#2-datenbank)
3. [Backend](#3-backend)
4. [Frontend](#4-frontend)
5. [Umsetzungsrisiken](#5-umsetzungsrisiken)
6. [Offene Fragen zur Entscheidung](#6-offene-fragen-zur-entscheidung)
## 1) Architektur
In diesem Teil wird die vorgeschlagene Architektur der umgesetzten Funktion behandelt. Ebenso wird behandelt, wie sich die bestehende Architektur ändert und wie die Anbindung an sie aussieht. Passende UML-Diagramme in Mermaid sind erwünscht.
## 2) Datenbank
In diesem Teil wird das vorgeschlagene Datenbankmodell anhand eines ER-Diagramms behandelt. Ebenso werden die Änderungen am bestehenden Datenbankmodell und die Anbindung daran behandelt. ER-Diagramme sind erwünscht.
## 3) Backend
Hier werden als Stichpunktliste die Auswirkungen auf das Backend behandelt — also was dort hinzugefügt / gelöscht / geändert werden muss.
## 4) Frontend
Hier werden als Stichpunktliste die Auswirkungen auf das Frontend behandelt — also was dort hinzugefügt / gelöscht / geändert werden muss.
## 6) Offene Fragen zur Entscheidung
Eine nummerierte Liste mit Fragen zur Entscheidung. Jeder Punkt der Liste sieht so aus:
- **Beschreibender Name der Frage**: Der ausführliche Text der Frage, aus dem ich verstehen muss, wonach du fragst.
`Antwort`: Der Text der Antwort, oder `-`, wenn es bisher keine Antwort gibt.4. Warum der Agent zuerst die Lösung entwerfen sollte
Auf Basis dieses Skills lässt du dir immer zuerst eine Lösung entwerfen, die du immer zuerst freigibst. Natürlich musst du die Ausgabe dieses Skills ordentlich prüfen, aber diese Ausgabe ist es auf jeden Fall wert.
Außerdem ist es meiner Meinung nach wichtig, diese grundlegenden Fragen zu verstehen, auch wenn der Code vom Agenten selbst geschrieben wird. Es ist der eine Teil, in dem sich entscheidet, ob das Projekt in einem Jahr noch etwas taugt.
Der Abschnitt mit den offenen Fragen in der Vorlage ist genau dafür da. Ein Agent neigt dazu, Mehrdeutigkeiten selbst und stillschweigend aufzulösen — und du erfährst davon erst, wenn der Code fertig ist. Zwingst du ihn, die Fragen aufzuschreiben, bekommst du sie, bevor etwas darauf steht.
5. Wie du einen Entwurf besprichst, den du nicht verstehst
Wenn du dir bei manchen Teilen des Dokuments unsicher bist, hab keine Scheu, sie iterativ mit dem Agenten zu besprechen. Durch das Gespräch verstehst du die vorgeschlagene Lösung besser, und das hilft dir dabei, ein gutes Produkt zu liefern.
Es lohnt sich zu bemerken, dass dieses Gespräch noch einen zweiten Effekt hat. Wenn du nachfragst und die Antwort keinen Sinn ergibt, liegt es meistens nicht daran, dass du es nicht verstanden hättest — sondern daran, dass der Entwurf fehlerhaft ist. Die eigene Unsicherheit ist ein ordentlicher Problemdetektor.
6. Warum man einen KI-Agenten wie einen Junior behandeln sollte
Meiner Meinung nach sollten wir einem KI-Agenten immer wie einem Junior in einer bestimmten Rolle begegnen — in der Rolle, die wir ihn gerade ausfüllen lassen.
Einem Junior gibst du eine Aufgabe, lässt dir erklären, wie er sie angehen will, und prüfst das Ergebnis. Du gibst ihm keine Entscheidungen, die sich schlecht rückgängig machen lassen, und lässt ihn nicht eine Woche ohne Hinsehen arbeiten. Gleichzeitig stehst du ihm nicht bei jeder Zeile über die Schulter, denn dann hättest du es auch gleich selbst machen können.
Genau so hat sich die Arbeit mit einem Agenten bei mir bewährt.
7. Zusammenfassung: drei Regeln für die Entwicklung mit Agenten
Diese Arbeitsweise hat sich bei mir bisher am besten bewährt. Ich würde sie in drei Sätzen zusammenfassen: kenne jede Architekturentscheidung, lass sie dir erklären, bevor Code entsteht, und frag nach allem, was du nicht verstehst.
Siehst du das anders? Schreib an support@coden-app.com.