Was, Harness, Wie: Die drei Schichten von AIUP

Eine Frage höre ich immer wieder zu Spec-Driven Development: Wo hört die Spezifikation auf und wo fängt die Implementierung an? Die Grenze ist oft unscharf. Specs rutschen in Klassennamen. Implementierungsentscheide schleichen sich in Use-Case-Beschreibungen. Nach ein paar Wochen weiss niemand mehr, was Absicht ist und was Zufall.

KI schreibt Code. Ingenieure entwickeln Software.

Mit Claude Code und ähnlichen Tools schreibe ich kaum noch Code von Hand. Die KI erledigt das für mich. Und meistens ist das Resultat gut. Auf den ersten Blick sieht das wie das Ende einer Ära aus. Wenn die KI den Code schreibt, was bleibt dann für uns? Eine Menge. Nur nicht der Teil, an [...]

Warum bei Spec-Driven Development die Spec für alle Stakeholder lesbar sein muss

Bei Spec-Driven Development (SDD) steht die Spezifikation im Zentrum. Sie ist nicht nur ein Dokument für Entwickler oder Architekten. Sie ist die gemeinsame Grundlage für alle, die am Produkt arbeiten. Genau hier liegt der Knackpunkt: Wenn die Spec nur für Techniker verständlich ist, verfehlt SDD seinen Zweck.

How and Why to Trace Use Cases and Tests

When you build business software, the same question keeps coming back: why does this code exist? The honest answer is almost always: because some business person needed it. A clinic user needs to register a new pet owner. An accountant needs to close the books. A clerk has to approve a request. Every line of code in a [...]

Use-Case 2.0: Die vergessene Praxis, die löst, was User Stories nicht können

Viele Teams behandeln User Stories heute als einzige Methode, um Anforderungen zu erfassen. Aber es gibt eine ältere, bewährte Technik, die besser skaliert und etwas bietet, was User Stories fehlt: Kontext. Sie heisst Use-Case 2.0, und sie verdient einen zweiten Blick, besonders im Zeitalter der KI-gestützten Entwicklung.

Warum Spec-Driven Development Tools im Enterprise-Umfeld scheitern

Die Spec-Driven Development (SDD) Bewegung gewinnt an Fahrt. Tools wie Amazon Kiro, GitHub Spec Kit und BMad Method versprechen, Struktur in die KI-gestützte Softwareentwicklung zu bringen. Und dieses Versprechen lösen sie ein, solange man auf der grünen Wiese beginnt.

A Small App, a Complete Process: Demoing AI Unified Process with a Feedback App

When people hear about AI-assisted software development, they often imagine code generation first. I think that is the wrong place to start.

KI-Tools für Entwickler reichen nicht aus

Warum also investieren wir so viel Energie in Tools für den Teil der Softwareentwicklung, der am ehesten automatisiert werden kann? Warum entwickeln wir nicht weiter KI-Unterstützung für den Rest des Softwareentwicklungszyklus?

BMAD vs. Spezifikationsgetriebene Entwicklung: Warum KI bessere Spezifikationen benötigt

Die Zukunft der Softwareentwicklung hängt daher möglicherweise nicht primär von besseren Codegeneratoren ab. Sie hängt vielmehr von etwas viel Fundamentalerem ab: der Fähigkeit, das Systemverhalten klar zu beschreiben und dieses Wissen in Spezifikationen zu bewahren, die über Jahrzehnte hinweg nützlich bleiben.

KI macht Programmieren billig. Anforderungen sind jetzt der Engpass

Ein kürzlich erschienener Artikel von Geoffrey Huntley argumentiert, dass die Softwareentwicklung dank KI extrem schnell und kostengünstig wird. Diese Beobachtung ist richtig. Code, für den früher Tage benötigt wurden, kann heute in Minuten generiert werden. Ganze Funktionen lassen sich nahezu im Handumdrehen erstellen. Doch das ist nur die halbe Wahrheit.

Die Intuition eines Chief Engineers: Warum „Build Integrity In“ auch 2026 noch der Massstab für Exzellenz ist

In meiner Artikelserie haben wir bereits eine weite Reise durch die taktischen und strategischen Landschaften der Lean Softwareentwicklung gemacht. In den bisherigen Beiträgen haben wir uns mit der Disziplin des „Eliminating Waste“, der Neugier des „Amplifying Learning“, der strategischen Geduld von „Deciding as Late as Possible“, der operativen Notwendigkeit „Deliver as Fast as Possible“ und [...]

Use Cases vs. User Stories – gleicher Inhalt, anderes Ergebnis?

In vielen Diskussionen höre ich die Aussage: „Use Cases und User Stories können dasselbe enthalten.“ Auf den ersten Blick klingt das plausibel. Beide beschreiben Anforderungen. Beide beschreiben Verhalten. Beide werden in der Softwareentwicklung eingesetzt. Aber was passiert, wenn wir ein echtes, nicht triviales Beispiel nehmen und versuchen, es in beiden Formen darzustellen?