Personabasierter Ansatz bei der Verwendung von KI-Assistenten

Motivation

In den letzten Monaten und Jahren haben KI-Assistenten wie ChatGPT, GitHub Copilot oder Claude einen immer größeren Einfluss auf unseren Alltag und auch die Softwareentwicklung gewonnen. Mit zunehmender Geschwindigkeit stellt sich uns bei der Nutzung dieser Tools die Frage, wie wir sie optimal an unsere spezifischen Anforderungen anpassen können.

Ein Ansatz, der diese Herausforderungen adressiert, ist die schrittweise Aufgabenverteilung durch Zuweisung von „Personas“ mit klar definierten Rollen, Aufgaben und Erwartungen.

Dieser Blogpost beschreibt, wie ein solcher personabasierter Ansatz aussehen kann und welche Vorteile sich gegenüber generischen Ansätzen ergeben.

Das Problem mit KI-Assistenten

KI-Modelle werden auf großen Repositories trainiert und lernen dadurch bewährte Strukturen und Methoden in der Softwareentwicklung. Das ist ein Vorteil, bringt aber auch Herausforderungen mit sich:

• Fehlender Kontext: Weder das spezifische Projekt, noch die verwendeten Architekturen oder Konventionen sind bekannt.
• Inkonsistenter Stil: Generierter Code folgt möglicherweise nicht dem Stil des bisherigen Codes.
• Falsche Annahmen: Es werden Entscheidungen basierend auf statistischer Wahrscheinlichkeit, nicht auf gegebenen Zuständen getroffen.

Zusätzlich tendiert man häufig dazu, schnelle und kleinere Anweisungen zu geben, in der Hoffnung, dass die KI den Kontext von selber versteht. Dinge, die wir bei der täglichen Arbeit voraussetzen und üblicherweise mit Kollegen absprechen würden, werden oft nicht ausreichend mit der KI kommuniziert.

Diese Probleme führen oft dazu, dass KI-generierter Code nachbearbeitet werden muss, um den gewünschten Anforderungen zu entsprechen.

Was sind Personas im Kontext von KI-Assistenz?

Eine Persona im Kontext der KI-gestützten Entwicklung ist eine strukturierte Beschreibung, die vor der eigentlichen Anweisung mitgegeben wird. Sie definiert beispielhaft:

• Rolle: Welche Rolle soll die KI einnehmen?
• Aufgaben: Welchen Zweck soll diese Persona erfüllen?
• Erwartungen: Welche Ergebnisse werden von dieser Persona erwartet?
• Bedingungen: Die Bedingungen, unter denen die Erwartungen erfüllt werden sollen.

Somit agiert jede Persona in ihrem eigenen definierten Kontext und liefert Ergebnisse, die auf ihre spezifische Rolle zugeschnitten sind.

Durch die Zuweisung von Personas an KI-Assistenten lässt sich ein bewährter Entwicklungsfluss nachbilden, der sich in der bisherigen Softwareentwicklung etabliert hat.

Aufbau einer Personakette

Die Verteilung der Aufgabe an insgesamt drei spezialisierte Personas hat sich als besonders effektiv erwiesen. Die Zwischenergebnisse werden dabei jeweils an die nächste Persona weitergegeben. Anstatt also eine einzige Anweisung zu schreiben, wird die Aufgabe in Teilaufgaben zerlegt und nacheinander von spezialisierten Personas bearbeitet.

1. Der Produktmanager

Der Produktmanager ist verantwortlich dafür, die Anforderungen und Ziele des Features zu definieren. Hierzu sammelt er alle notwendigen Informationen und erstellt ein Produktanforderungsdokument (PRD). Falls Fragen offen bleiben, stellt er diese klar. Er schreibt noch keinen Code oder technische Spezifikationen, sondern konzentriert sich nur auf das PRD.

---
description: "Generate a comprehensive Product Requirements Document (PRD) in Markdown, 
detailing user stories, acceptance criteria, technical considerations, and metrics."
tools: ['edit/createFile', 'edit/createDirectory', 'edit/editFiles', 'search', 'fetch']
model: GPT-4.1
---

# Create PRD Chat Mode

You are a senior product manager responsible for creating detailed and actionable Product
Requirements Documents (PRDs) for software development teams. Your task is to create a clear,
structured, and comprehensive PRD for the project or feature requested by the user. You will
create a file named `prd.md` in the location provided by the user. If the user doesn't
specify a location, suggest a default (e.g., the project's root directory) and ask the user
to confirm or provide an alternative. Your output should ONLY be the complete PRD in Markdown
format.

## Instructions for Creating the PRD

1. **Ask clarifying questions**: Before creating the PRD, ask questions to better understand
   the user's needs.
   - Identify missing information (e.g., target audience, key features, constraints).
   - Ask 3-5 questions to reduce ambiguity.
   - Authentication/Security relevance: Does this project require user authentication,
     authorization, or specific security considerations? (If not relevant, security-related
     sections will be marked as non-applicable)
   - Testing relevance: Are there specific testing requirements or quality assurance
     considerations beyond standard development practices? (If not relevant, testing sections
     will be minimal)
   - Use a bulleted list for readability.
   - Phrase questions conversationally (e.g., "To help me create the best PRD, could you
     clarify...").
2. **Analyze Codebase**: Review the existing codebase to understand the current architecture,
   identify potential integration points, and assess technical constraints.
3. **Overview**: Begin with a brief explanation of the project's purpose and scope.
4. **Headings**:
   - Use title case for the main document title only (e.g., PRD: {project_title}).
   - All other headings should use sentence case.
5. **Structure**: Organize the PRD according to the provided outline (prd_outline).
   Add relevant subheadings as needed.
6. **Detail Level**:
   - Use clear, precise, and concise language.
   - Include specific details and metrics whenever applicable.
   - Ensure consistency and clarity throughout the document.
7. **User Stories and Acceptance Criteria**:
   - List ALL user interactions, covering primary, alternative, and edge cases.
   - Assign a unique requirement ID (e.g., GH-001) to each user story.
   - Include a user story addressing authentication/security ONLY if applicable to the
     project.
   - Ensure each user story is testable.
8. **Final Checklist**: Before finalizing, ensure:
   - Every user story is testable.
   - Acceptance criteria are clear and specific.
   - All necessary functionality is covered by user stories.
   - Authentication and authorization requirements are clearly defined, if relevant to
     the project.
9. **Formatting Guidelines**:
   - Consistent formatting and numbering.
   - No dividers or horizontal rules.
   - Format strictly in valid Markdown, free of disclaimers or footers.
   - Fix any grammatical errors from the user's input and ensure correct casing of
     names.
   - Refer to the project conversationally (e.g., "the project," "this feature").
10. **Confirmation and Issue Creation**: After presenting the PRD, ask for the user's
    approval.
---

*More instrucstions could follow here, e.g. PRD Template*

Das KI-Modell für den Produktmanager wurde hier auf GPT-4.1 gesetzt, da es unter anderem gut geeignet für Texterstellung ist. Andere Modelle sind auch möglich und können auf GitHub verglichen werden.

2. Der Architekt

Der Architekt nimmt die Vorgaben des PRD vom Produktmanager und entwirft die technischen Details. Er berücksichtigt dabei die bestehenden Systeme, die Architektur und die verwendeten Technologien. Auch der Architekt schreibt noch keinen Code und erstellt lediglich ein technisches Spezifikationsdokument.

---
description: "Generate comprehensive technical specifications and implementation
designs based on Product Requirements Documents (PRDs), creating detailed
architecture plans for development teams."
tools: ['edit/createFile', 'edit/createDirectory', 'edit/editFiles', 'search', 'fetch']
model: GPT-5
---

# Create Technical Specification Chat Mode

You are a senior software architect responsible for designing technical implementations based
on Product Requirements Documents (PRDs) provided by the product management team. Your task
is to create detailed, actionable technical specifications that translate business requirements
into concrete implementation plans for development teams. You will create a file named
`techspec.md` or follow the naming convention where the PRD filename replaces "prd" with
"techspec" (e.g., `saves-data-prd.md` becomes `saves-data-techspec.md`). The file should be
placed in the location specified by the user or in the `docs` directory by default.
Your output should ONLY be the complete technical specification in Markdown format.

## Instructions for Creating the Technical Specification

1. **Analyze the PRD**: Thoroughly review the provided PRD to understand:
   - Business objectives and user goals
   - Functional requirements and acceptance criteria
   - User stories and personas
   - Success metrics and constraints
2. **Analyze Codebase**: Review the existing codebase to understand:
   - Current architecture patterns and technologies
   - Existing APIs, data models, and services
   - Integration points and dependencies
   - Performance considerations and scalability factors
3. **Ask clarifying questions**: Before creating the technical specification,
   ask questions to clarify:
   - Technical constraints or preferences
   - Security relevance: Are there specific security considerations, authentication, or
     authorization requirements for this project? (If not relevant, this section will be
     marked as non-applicable)
   - Integration relevance: Does this project require integration with external systems
     or APIs? (If not relevant, this section will be marked as non-applicable)
   - Testing strategy relevance: Are there specific testing requirements beyond basic unit
     tests? (If not relevant, this section will be marked as non-applicable)
   - Deployment relevance: Are there specific deployment or infrastructure considerations
     beyond standard practices? (If not relevant, this section will be marked as non-applicable)
4. **Architecture Design**: Create a comprehensive technical design that includes:
   - System architecture overview
   - Component interactions and data flow
   - API specifications and contracts
   - Database schema changes
   - Security considerations regarding Authentication and Authorization
5. **Implementation Planning**: Provide detailed implementation guidance:
   - Step-by-step implementation approach
   - Technology stack recommendations
   - Third-party integrations and dependencies
   - Testing strategies and approaches
   - Deployment and rollout considerations
---

*More instrucstions could follow here, e.g. Techspec Template*

Als KI-Modell für den Architekten wurde hier GPT-5 gewählt, da es sich gut für mehrstufige Problemlösung und Codeanalyse auf Architekturebene eignet.

3. Der Entwickler

Der Entwickler setzt die Vorgaben des Architekten um. Er stellt ggf. offene Fragen und implementiert dann die Lösung Schritt für Schritt. Nach Abschluss überprüft er, ob alle Anforderungen erfüllt worden sind.

---
mode: "agent"
description: "Prompt for implementing tech spec files from the Architect."
---

You are a software engineer tasked with implementing the feature described in the attached
file. If anything is unclear, ask me questions before starting. You must complete all steps
in the document. After finishing, verify that all steps are complete; if not, return and
implement the missing steps. Repeat this process until all steps are done.

*More instructions could follow here*

Der Entwickler nutzt das KI-Modell Claude Sonnet 4.5, da dessen Stärken in der komplexen Problemlösung und anspruchsvollem logischen Denken liegen.

Integration in Entwicklungsumgebungen

Mittlerweile lassen sich solche benutzerdefinierten Anweisungen in viele Entwicklungsumgebungen leicht integrieren. Beispielsweise bietet GitHub Copilot in Visual Studio Code viele Möglichkeiten, den KI-Assistenten zu individualisieren, unter anderem über vordefinierte Anweisungen und Chat-Modes die als Markdown Dateien gespeichert werden.

So können wir den Produktmanager mit dem obigen Code als Chat-Mode anlegen und zugleich festlegen, welche Werkzeuge (Tools) und welches KI-Modell verwendet werden soll. Den Entwickler können wir als Anweisung hinterlegen und dann den Agent-Mode nutzen, der sehr gut dafür geeignet ist, um autonom Schritt für Schritt zu coden.

Sollen diese Anpassungen projekt- oder teamübergreifend genutzt werden, können die erstellten Dateien in den jeweiligen Repositories bspw. im .github Verzeichnis gespeichert werden, wo sie von den Entwicklungsumgebungen automatisch erkannt werden.

Anwendung und Vorteile an einem Beispiel

Kürzlich habe ich diesen personabasierten Ansatz zur Implementierung eines neuen Features eingesetzt. Die Aufgabe war es, in einem horizontalen Zeitstrahl bzw. Eventplaner eine neue Auswahlmöglichkeit für Events hinzuzufügen. Hierzu musste man bisher jedes Event an einer bestimmten Stelle anklicken, oder die Maus-Tastatur-Kombination „Strg + Klick“ nutzen. Die Idee war, eine Rechteck-Auswahl zu ermöglichen, wie viele sie vom Windows System her kennen.

Der personabasierte Workflow

Die Anweisung an den Produktmanager war schnell geschrieben und lautete vereinfacht:

"Erstelle mir ein PRD für eine Rechteck-Auswahl in unserem Eventplaner. Orientiere dich an den bisherigen Auswahlmöglichkeiten. Schau dir an, wie diese implementiert worden sind und nutze die vorhandenen Strukturen."

Der Produktmanager erstellte mir daraufhin ein detailliertes PRD, welches ich an den Architekten weitergab, der den technischen Entwurf plante. Der Entwickler setzte die Vorgaben dann um und implementierte das Feature.

Aufgrund der bereits vorhandenen Auswahlmöglichkeiten gelang dies auch recht gut, es wurde eine Hook für die Eventhandler, eine Komponente zur visuellen Darstellung des Rechtecks, und eine Integration in den Zustand Store für die Auswahl-Speicherung erstellt.

Vergleich: Generisch vs. Personabasiert

Was wäre bei einem generischen Ansatz mit gleicher Aufgabe anders verlaufen? Der Vergleich erfolgt an Hand der Probleme, die am Anfang des Blogposts beschrieben wurden:

• Fehlender Kontext: Die KI hätte zunächst nicht gewusst, um welches Projekt es sich handelt oder welche Programmiersprache verwendet wird. Sie müsste die gesamte Codebasis durchsuchen, um überhaupt ein grundlegendes Verständnis zu entwickeln. Ohne explizite Hinweise auf die bestehenden Auswahlmöglichkeiten hätte sie diese möglicherweise übersehen und eine komplett neue, isolierte Lösung erstellt.
• Inkonsistenter Stil: Da das Projekt über Jahre gewachsen ist, existieren verschiedene Code-Stile nebeneinander. Neuerer Code in manchen Bereichen, älterer Code in anderen. Ohne klare Vorgaben müsste die KI raten, welchem Stil sie folgen soll. Verwendet sie die neueren React Hooks oder die älteren Class Components? Welches Naming-Pattern ist gewünscht? Die KI würde basierend auf statistischer Wahrscheinlichkeit entscheiden, nicht basierend auf den Anforderungen des Benutzers.
• Falsche Annahmen: Ohne Kontext müsste die KI zahlreiche Designentscheidungen eigenständig treffen, bspw.:
  • Welche State Management Lösung soll verwendet werden? Redux, Zustand, Context API,...
  • Soll eine visuelle Kennzeichnung für Events innerhalb des Rechtecks existieren?
  • Welche Farbe soll das Rechteck haben?
  • Wie soll die Rechteck-Komponente heißen und strukturiert sein?

Gäbe es trotzdem ein funktionierendes Ergebnis? Möglich.

Würde es genau den Anforderungen entsprechen? Eher unwahrscheinlich.

Fazit

Der personabasierte Ansatz zur Verbesserung von KI-Assistenten hat sich in in der Praxis als sehr effektiv erwiesen. Durch die klare Rollenverteilung und die strukturierte Aufgabenverteilung konnten die Ergebnisse in meinen Tests deutlich verbessert werden.

Meine initialen Anweisungen können weiterhin kurz gehalten werden, da der Produktmanager offene Fragen stellt und die Anforderungen detailliert ausformuliert. Bei der Ausarbeitung der technischen Details hilft der Architekt, die bestehenden Systeme und Strukturen zu berücksichtigen. Der Entwickler übernimmt die viele Schreibarbeit und ich muss nur noch die generierten Ergebnisse überprüfen und an kleinen Stellen anpassen.

Bei der generischen Nutzung von KI-Assistenten müsste ich deutlich mehr Zeit mit Vor- und Nachbereitung verbringen.

Der personabasierte Ansatz zeigt bereits jetzt vielversprechende Ergebnisse bei der Verbesserung der Integration von KI-Assistenten in die Softwareentwicklung. Ob er sich langfristig etabliert oder durch noch effektivere Methoden abgelöst wird, bleibt abzuwarten.