Fünf Agenten, fünfzig Entscheidungen
Adam Tornhill zeigt: Fünf parallele Agenten bedeuten für den Entwickler etwa 50 Aufgaben. Der Ausweg sind nicht mehr Agenten, sondern die versteckten Design-Entscheidungen einmal zu treffen, in der Spezifikation. So macht das der AI Unified Process.
Gute Entwickler sind nicht skeptisch. Sie stellen die richtigen Fragen.
Rachel Laycock fragt, warum gute Entwickler bei agentischer Entwicklung zögern. Ihre Fragen sind die richtigen, aber viele davon haben bereits Antworten. Hier zeige ich, wie Spec-Driven Development und der AI Unified Process sie beantworten und wo Rachel recht hat.
OpenSpec und der fehlende Ablauf aus Benutzersicht
OpenSpec beschreibt sehr genau, was ein System tun soll. Wie ein Benutzer Schritt für Schritt durch die Anwendung geht, steht aber nirgends am Stück. Das ist kein Fehler im Tool, sondern eine bewusste Entscheidung des Formats, und sie hat Folgen. Ich habe die Spring PetClinic auf OpenSpec umgestellt. Daraus entstanden fünf Capabilities mit 31 Requirements [...]
Wem gehört das Test-Orakel?
Mehr als 12’000 Unit-Tests, alle grün. Und trotzdem tauchen die Fehler erst beim Release auf. Das berichtet Paul Stack von Swamp, wo Agenten jede Zeile Code schreiben. In zwei aktuellen Beiträgen, Your Agent-Written Tests Aren’t Real Tests und Why Agent-Written Code Needs Product Verification, erklärt er, warum. Ich stimme ihm in fast allem zu. Und [...]
Reverse Engineering: Specs aus bestehendem Code
Spec-Driven Development funktioniert sehr gut, wenn du ein neues Projekt startest. Du schreibst zuerst die Specs, und der KI-Agent setzt sie um. Aber die meisten von uns arbeiten nicht an neuen Projekten. Wir arbeiten an Systemen, die fünf, zehn oder zwanzig Jahre alt sind. Oft gibt es gar keine Specs, oder sie sind veraltet.
Von der Prompt-Vorlage zum Skill: Der AI4RE Prompt Guide von IREB
„Schreib User Stories für ein Bestellportal.“ So sehen die meisten Prompts für Anforderungen aus. Die Antwort wirkt plausibel, liest sich gut, und niemand kann sagen, ob sie gut ist. Die nächste Person fragt dasselbe mit anderen Worten und bekommt eine andere Antwort. Das ist kein Requirements Engineering. Das ist ein Chat.
Hooks, die verhindern, dass der Agent den Status „Erledigt“ meldet
Ein KI-Agent, der „fertig“ sagt, stellt eine Behauptung auf. Mit Claude Code Hooks verlangt die Session einen Beweis: ein Stop-Hook, der einen frischen, grünen Test-Report will, und ein Status-Guard, der ein Coverage-Audit verlangt, bevor ein Use Case als erledigt gilt.
Back to the 90s: Der Software Engineer hat wieder alle Rollen
Als ich in den 90er-Jahren als Software Engineer angefangen habe, habe ich COBOL auf dem IBM Mainframe programmiert. Später kamen Client/Server-Applikationen dazu. Vieles war damals einfacher. Nicht die Technik, aber die Organisation. Ich habe mit den Kunden gesprochen, die Anforderungen aufgenommen, die Architektur und das Design gemacht, den Code geschrieben und dafür gesorgt, dass die [...]
Harness Engineering: Warum ein minimales CLAUDE.md und ein gutes Architektur-Dokument zusammengehören
Der Begriff Harness Engineering hat sich in den letzten Monaten etabliert. Die Formel dahinter ist einfach: Agent = Modell + Harness. Der Harness ist alles, was einen KI-Agenten ausmacht, ausser dem Modell selbst. Dazu gehören Instruktionsdateien wie CLAUDE.md oder AGENTS.md, Skills, Tools, Tests, Linter, Hooks und CI-Gates.
Der INNOQ SCS-Primer und meine Sicht auf Self-contained Systems
NNOQ hat im August 2026 einen Primer zu Self-contained Systems veröffentlicht, geschrieben von Johannes Seitz. Ich habe ihn mit einer klaren Frage im Kopf gelesen: Deckt sich das mit dem, was ich in meinen Vorträgen und im Java-Magazin-Artikel erzähle?
Shift Left braucht Artefakte, nicht nur Gespräche
Rachel Laycock hat einen Artikel geschrieben mit dem Titel Maybe We Shouldn’t Be Reviewing All This Code. Es ist eine Antwort auf Brian Houck, der befürchtet, dass wir mit dem automatisierten Code Review alles verlieren, wofür Review sonst noch da ist: Wissenstransfer, Lernen, gemeinsame Verantwortung, Architekturverständnis. Ihre Antwort ist einfach, und ich bin einverstanden. Warum warten [...]
Agil ist nicht tot. Die Agile-Industrie vielleicht schon.
Ich höre es in letzter Zeit immer wieder: „Agil ist wegen AI tot.“ Auf Konferenzen, in Kundengesprächen, auf LinkedIn. Die Begründung ist meistens dieselbe: Wenn ein AI-Agent in zwei Stunden baut, wofür ein Team früher zwei Wochen brauchte, wozu dann noch Sprints, Standups und Retrospektiven?
