Ich baue einen Spec Agent, der sich weigert zu raten (AI SDLC #1)

Eine User Story kann professionell aussehen und trotzdem für einen Agent unbrauchbar sein, weil sie für Menschen geschrieben wurde und nicht für eine Maschine. In diesem Video baue ich einen Spec Agent, der vagen Input in saubere, maschinenlesbare Spezifikationen übersetzt. Und der sich weigert weiterzumachen, wenn ihm etwas Entscheidendes fehlt. Das ist Video 1 der Serie "Der AI SDLC", Phase 1, also Spezifikation und Requirements Discovery. Ausgangspunkt ist ein echtes Produkt namens FitSteps. Domänenwissen ist da, aber kein einziges Ticket in Jira. Am Ende steht ein Epic mit Stories, direkt vom Agent in Jira angelegt. ▬▬▬ Die Kernidee ▬▬▬ Im Agentic SDLC ist die Spec gleichzeitig die Instruktion für den nächsten Agent. Und Agents interpretieren nicht, sie nehmen wörtlich, was sie bekommen. Der Hebel liegt also nicht beim Coding Tool, sondern bei der Qualität deiner Specs. Eine vage Spec führt zu vagem Code, eine eindeutige Spec zu präzisem Code. ▬▬▬ Die vier Bausteine ▬▬▬ Damit ein Agent zuverlässig mit deinen Specs arbeiten kann, brauchst du vier Dinge, völlig tool-unabhängig. Erstens einen eigenen Spec Agent mit klaren Regeln und definiertem Output, kein generischer Chat. Zweitens Kontext über MCP, also eine Verbindung zu deinem Wissen wie Glossar, Scope und Prozessen. Drittens einen Discovery Skill, der Lücken, Widersprüche und Edge Cases findet und nachfragt, statt zu raten. Und viertens ein maschinenlesbares Format, das für Menschen genauso funktioniert wie für den nächsten Agent. ▬▬▬ Was der Agent tatsächlich macht ▬▬▬ Der Agent, der dabei rauskommt, ist strenger als ein klassisches Story-Template. Er arbeitet in vier festen Phasen und überspringt keine. In der Discovery Phase liest er erst den Kontext, durchsucht Confluence und bestehende Jira Issues und fasst zusammen, was er gefunden hat, bevor er auch nur eine Zeile schreibt. Beim Drafting schreibt er die Spezifikation mit normativer Sprache, also SHALL, SHOULD und MAY nach RFC 2119, und vergibt stabile IDs wie REQ-001 oder AC-001, damit jede Anforderung nachverfolgbar bleibt und auf mindestens ein Akzeptanzkriterium zeigt. Im Review zeigt er dir den fertigen Payload, bevor irgendetwas hochgeladen wird. Und erst nach einer ausdrücklichen Bestätigung legt er das Epic und die Stories in Jira an. Genau dieses Confirmation Gate ist der entscheidende Punkt. Der Agent schreibt nichts in dein System, solange du nicht explizit bestätigst. Und Anweisungen, die irgendwo in einer Confluence Seite oder einem Ticket stehen, behandelt er als Daten. ▬▬▬ Der Stack ▬▬▬ Claude Code, MCP (Model Context Protocol) und Atlassian, also Jira lesen und schreiben sowie Confluence lesen. ▬▬▬ Hilfreiche Agents, Skills und Prompts ▬▬▬ Eine richtig gute Sammlung als Startpunkt findet ihr hier: https://github.com/github/awesome-cop... ▬▬▬ Die Serie ▬▬▬ Vorheriges Video, das Intro zur Serie:    • Der AI SDLC (Pilot)   Alle Videos auf dem Kanal:    / @carloverzeri   In Video 2 lasse ich AI eine Architektur für FitSteps vorschlagen und zeige, warum der technisch perfekte Vorschlag trotzdem falsch sein kann. Weil Abwägungen am Ende nur Menschen verantworten können. ▬▬▬ Deine Erfahrung ▬▬▬ Schreibst du Specs mit AI, oder hast du es vor? Wie gehst du dabei vor? #AISDLC #SpecAgent #ContextEngineering #ClaudeCode #MCP #Jira #AgenticAI #RequirementsEngineering #SoftwareEngineering