Je mehr KI in der Softwareentwicklung übernimmt, desto wichtiger wird für mich eine Frage: Wie gebe ich einer KI nicht nur einzelne Coding-Aufgaben, sondern integriere sie sinnvoll in einen bestehenden Entwicklungsprozess?
Nachdem Claude Code in meinem Projekt bereits die Architektur, Coding-Konventionen und Review-Regeln kennt, lag der nächste Schritt nahe: Die eigentliche Anforderung sollte nicht mehr in einem langen Prompt stehen, sondern dort, wo sie auch in klassischen Entwicklungsprojekten hingehört – in einem Ticket.
Das Ziel ist ein Workflow, bei dem Jira die Anforderungen vorgibt, Penpot bei UI-Features das Design liefert und Claude Code die einzelnen Arbeitsschritte anhand definierter Regeln selbstständig durchläuft.
Im Idealfall reduziert sich der eigentliche Auftrag dadurch auf einen Satz:
„Bearbeite das Ticket nach unserem definierten Workflow.“
Wie man einen solchen Ablauf aufbauen kann, zeige ich in diesem Beitrag.
1. Das Ticket wird zum Arbeitsauftrag
Der erste wichtige Schritt besteht darin, die Verantwortlichkeiten sauber zu trennen.
Die Anforderungen gehören für mich weiterhin nach Jira. Claude Code soll nicht aus einem kurzen Prompt selbst entscheiden müssen, was ein Feature eigentlich können soll.
Ein Ticket enthält deshalb alle Informationen, die auch ein menschlicher Entwickler für die Umsetzung benötigt.
Bei einer Story sind das insbesondere:
- User Story beziehungsweise fachliches Ziel,
- Beschreibung,
- testbare Akzeptanzkriterien,
- gegebenenfalls Abgrenzungen,
- Definition of Done.
Für Bugs und technische Aufgaben verwende ich dagegen eigene Strukturen. Ein Bug benötigt beispielsweise eher Schritte zur Reproduktion sowie erwartetes und tatsächliches Verhalten als eine künstlich formulierte User Story.
Diese Regeln habe ich in einer eigenen ticket-guidelines.md im Repository hinterlegt. Claude kennt dadurch nicht nur den Inhalt eines einzelnen Tickets, sondern auch wie Tickets grundsätzlich zu interpretieren und zu bearbeiten sind.
2. Jira mit Claude Code verbinden
Damit daraus mehr als eine Dokumentation für den Entwickler wird, benötigt Claude Code Zugriff auf Jira.
Über eine MCP-Anbindung kann Claude Tickets selbstständig lesen, erstellen und aktualisieren.
Dadurch entstehen zwei interessante Möglichkeiten:
Variante 1: Ein bestehendes Ticket bearbeiten
Das Ticket wurde beispielsweise von Product Owner, Kunde oder Entwickler erstellt und Claude verwendet es als Grundlage für die weitere Arbeit.
Variante 2: Aus einer Anforderung zunächst ein Ticket erstellen
Ich kann Claude auch eine noch relativ informelle Feature-Beschreibung geben und daraus zunächst eine sauber strukturierte Story erstellen lassen.
Das ist besonders praktisch für eigene Projekte, Prototypen oder kleinere Teams.
Auch aus einer zunächst einfachen Feature-Beschreibung kann Claude anhand der hinterlegten Regeln ein strukturiertes Jira-Ticket erstellen.
Das Ticket bildet anschließend die verbindliche fachliche Grundlage für die weitere Bearbeitung.
3. Design als eigener Schritt im Entwicklungsprozess
Bei einem UI-Feature möchte ich nicht, dass Claude unmittelbar nach dem Lesen des Tickets anfängt, Compose- oder SwiftUI-Code zu erzeugen.
Zwischen Anforderung und Implementierung gehört für mich ein Design-Schritt.
Dafür verwende ich Penpot.
Das Ticket enthält einen Designstatus, anhand dessen Claude erkennt, was als Nächstes passieren darf:
PENDING– ein Design wird benötigt,IN_REVIEW– das Design wurde erstellt und wartet auf Freigabe,APPROVED– das Design wurde freigegeben und darf implementiert werden,NOT_REQUIRED– für die Story ist kein Design erforderlich.
Zusätzlich gibt es im Ticket ein eigenes Feld für den Link zum entsprechenden Penpot-Design.
Damit wird der Zustand des Features sowohl für Claude als auch für einen menschlichen Entwickler sofort sichtbar.
Erkennt Claude bei einer Story, dass zunächst ein Design benötigt wird, darf nicht direkt programmiert werden. Erst nach der Designphase und einer menschlichen Freigabe beginnt die Umsetzung.
4. Claude erstellt das Design in Penpot
Ist für eine Story ein Design erforderlich, beginnt Claude zunächst mit Penpot.
Dabei soll nicht einfach irgendein neuer Screen entstehen. Claude kann vorhandene Screens, Komponenten und Designvorgaben berücksichtigen und das neue Feature entsprechend einordnen.
Zum Designprozess gehört außerdem, relevante Zustände mitzudenken. Je nach Feature können beispielsweise folgende Varianten notwendig sein:
- Default State,
- Loading State,
- Empty State,
- Error State,
- wichtige Interaktionszustände.
Anschließend wird das Design mit dem Jira-Ticket verknüpft.
Der Penpot-Link bildet dabei die visuelle Source of Truth.
Zusätzlich lasse ich eine Vorschau als Screenshot am Jira-Ticket hinterlegen. Dadurch kann ein Entwickler bereits beim Öffnen des Tickets erkennen, wie die geplante Oberfläche aussieht, ohne zunächst Penpot öffnen zu müssen.
Das UI-Design entsteht vor der Implementierung in Penpot und wird anschließend mit der Story verknüpft.
5. Der Mensch bleibt beim Design die Freigabeinstanz
An dieser Stelle habe ich bewusst einen Stop-Punkt eingebaut.
Claude darf ein selbst erstelltes Design nicht selbst freigeben.
Nach Fertigstellung wird das Design zur Prüfung bereitgestellt und der Workflow stoppt.
Erst ein Entwickler, Product Owner oder eine andere verantwortliche Person entscheidet, ob das Design umgesetzt werden darf.
Das ist für mich ein wichtiger Unterschied zwischen automatisierter Arbeit und automatisierten Entscheidungen.
Claude kann viele Arbeitsschritte selbstständig erledigen. Bestimmte Entscheidungen bleiben trotzdem bewusst beim Menschen.
Design und Vorbereitung können automatisiert erfolgen. Die Entscheidung, ob das Ergebnis tatsächlich umgesetzt wird, bleibt bewusst ein menschlicher Kontrollpunkt.
6. Erst nach der Freigabe beginnt die Entwicklung
Sobald das Design freigegeben wurde, darf Claude mit der eigentlichen Umsetzung beginnen.
Dabei kommen nun mehrere Informationsquellen zusammen.
Jira liefert die fachlichen Anforderungen und Akzeptanzkriterien.
Penpot liefert das freigegebene UI-Design.
Die Projekt-Guidelines definieren Architektur, Coding-Konventionen, verwendete Frameworks und technische Regeln.
Claude muss also nicht bei jedem Ticket erneut erklärt bekommen, wie beispielsweise State Management, Dependency Injection oder API-Zugriffe in diesem Projekt umgesetzt werden sollen.
Diese Regeln kennt er bereits aus dem Repository.
Der eigentliche Ticket-Prompt kann dadurch erstaunlich unspektakulär werden:
„Bearbeite das Ticket nach unserem definierten Workflow.“
weil der Prozess besser definiert ist.
Anforderungen stehen in Jira, das Design liegt in Penpot und die technischen Regeln im Repository. Der Prompt muss diese Informationen nicht jedes Mal erneut enthalten.
7. Tests und Code Review gehören ebenfalls zum Workflow
Mit dem erzeugten Code endet der Prozess nicht.
Auch die Definition of Done ist Bestandteil der Regeln.
Je nach Projekt und Ticket gehören dazu beispielsweise:
- Erfüllung aller Akzeptanzkriterien,
- Unit Tests,
- UI Tests,
- erfolgreiche Builds,
- Accessibility-Prüfungen,
- Code Review,
- keine offenen kritischen Findings.
Claude kann anschließend selbst einen ersten Code Review durchführen und die Implementierung anhand der hinterlegten Review-Regeln prüfen.
Damit endet die Aufgabe nicht bei „Code wurde generiert“, sondern erst dann, wenn die definierten Qualitätskriterien erfüllt sind.
8. Der vollständige Ablauf
Aus den einzelnen Bausteinen ergibt sich schließlich der eigentliche Workflow.
↓
🎫 Jira Story
↓
🎨 Design in Penpot
↓
👁️ Design Review
↓
👤 Menschliche Freigabe
↓
💻 Implementierung
↓
🧪 Tests
↓
🔍 Code Review
↓
✅ Abschluss
9. Was sich im Praxistest noch verbessert hat
Der grundsätzliche Ablauf stand damit. Gerade beim tatsächlichen Durchspielen sind aber einige Details aufgefallen, die den Prozess noch robuster gemacht haben.
Strukturierte Jira-Felder statt Informationen im Beschreibungstext
In einer ersten Variante hatte ich beispielsweise den Designstatus einfach innerhalb der Ticketbeschreibung hinterlegt.
Claude konnte damit problemlos arbeiten.
Für Jira selbst ist das allerdings wenig hilfreich. Ein Text wie Design Status: IN_REVIEW lässt sich nicht so komfortabel für Filter, Boards oder Auswertungen verwenden.
Deshalb sind daraus echte Jira Custom Fields geworden.
Damit kann ich beispielsweise gezielt nach Stories suchen, deren Design aktuell auf eine Freigabe wartet.
Das ist ein kleines Detail, macht aus einer Konvention für die KI aber einen richtigen Bestandteil des Projektworkflows.
Nicht jede MCP-Funktion deckt alles ab
Eine weitere Erkenntnis betraf die Screenshots.
Über die verwendeten Jira-MCP-Funktionen konnte Claude zwar Tickets bearbeiten, aber keine Datei-Anhänge hochladen.
Die Lösung bestand darin, für diesen Arbeitsschritt auf die Jira-Weboberfläche im Browser auszuweichen.
Auch das ist inzwischen Bestandteil der Regeln:
Wenn ein Tool einen Arbeitsschritt nicht unterstützt, darf Claude einen definierten alternativen Weg verwenden.
Das verhindert, dass der gesamte Prozess an einer einzelnen technischen Einschränkung scheitert.
Der eigentliche Workflow war schnell definiert. Interessant wurden vor allem die Details im Praxistest: Welche Informationen sollten echte Jira-Felder sein? Was passiert, wenn ein MCP einen bestimmten Arbeitsschritt nicht unterstützt? Genau solche Erkenntnisse machen einen KI-Workflow am Ende belastbar.
10. Jira bleibt auch für Menschen verständlich
Ein Aspekt gefällt mir an diesem Ansatz besonders:
Der Prozess wird nicht ausschließlich für Claude optimiert.
Ein Entwickler kann das Ticket öffnen und findet weiterhin:
- die fachliche Anforderung,
- die Akzeptanzkriterien,
- den aktuellen Designstatus,
- einen Link zum Design,
- eine visuelle Vorschau,
- die Definition of Done.
Das bedeutet: Selbst wenn ein anderer Entwickler das Ticket übernimmt, ist nicht erst ein langer Claude-Chat notwendig, um zu verstehen, was eigentlich passieren soll.
Die KI integriert sich in den Entwicklungsprozess – der Entwicklungsprozess wird nicht um die KI herumgebaut.
Das halte ich insbesondere für die Arbeit in Teams für wichtig.
11. Vom Coding-Assistenten zum Entwicklungs-Agenten
Für mich liegt genau hier der Unterschied zwischen einem klassischen Coding-Assistenten und einem stärker agentischen Entwicklungsworkflow.
Bei einem Coding-Assistenten lautet die Aufgabe beispielsweise:
„Erstelle einen Compose Screen für diese Anforderungen.“
In dem hier beschriebenen Workflow lautet sie irgendwann nur noch:
„Bearbeite das Ticket.“
Die eigentliche Komplexität steckt nicht mehr im Prompt.
Sie steckt in den Regeln.
Claude muss selbst erkennen:
- Welcher Tickettyp liegt vor?
- Was sind die Anforderungen?
- Ist ein Design erforderlich?
- Darf bereits implementiert werden?
- Welche technische Architektur gilt?
- Welche Tests sind erforderlich?
- Welche Qualitätskriterien müssen erfüllt sein?
- An welcher Stelle ist eine menschliche Entscheidung notwendig?
Genau deshalb bedeutet mehr Automatisierung für mich nicht weniger Prozess.
Eigentlich ist das Gegenteil der Fall.
Je selbstständiger eine KI arbeiten soll, desto klarer müssen ihre Grenzen, Zuständigkeiten und Übergabepunkte definiert sein.
desto klarer muss der Prozess sein.
Ziel ist nicht, jede Entscheidung an Claude abzugeben. Ziel ist ein Entwicklungsprozess, in dem die KI innerhalb klarer Regeln möglichst viele Arbeitsschritte selbstständig übernehmen kann.
Fazit
Ein Jira-Ticket als Ausgangspunkt für KI-gestützte Entwicklung zu verwenden, wirkt zunächst wie ein relativ kleiner Schritt.
In Kombination mit einem definierten Workflow verändert es den Umgang mit Claude Code aber deutlich.
Die Anforderung steht in Jira. Ein benötigtes UI-Design entsteht zunächst in Penpot. Das Ergebnis wird einem Menschen zur Prüfung vorgelegt. Erst nach der Freigabe beginnt die Implementierung. Tests, Definition of Done und Code Review bilden anschließend den Abschluss.
Claude Code bekommt dadurch nicht einfach mehr Freiheit.
Er bekommt vor allem klarere Regeln dafür, wann er was tun darf.
Und genau darin liegt für mich aktuell einer der spannendsten Ansätze für KI-gestützte App-Entwicklung: Nicht immer größere Prompts zu schreiben, sondern Entwicklungsprozesse so zu strukturieren, dass ein immer kleinerer Prompt genügt.