Der nächste Programmier-Standard entsteht vor dem Code

Der nächste Programmier-Standard der Softwareentwicklung wird nicht mehr im Code definiert.

Er entsteht in der Leere davor.

Wir beobachten gerade eine Verschiebung der Zuständigkeit.

Lange Zeit war ein Repository vor allem ein Archiv für menschliche Logik: ein Ort, an dem Entwickler:innen ihre Gedanken in Syntax übersetzen.

Doch mit dem verstärkten Einsatz von KI beginnt sich diese Rolle zu verändern.

Ein Repository wird zunehmend zu einem Habitat für synthetische Intelligenz.

Die Kontrolle migriert.
Weg von der Syntax – hin zur kuratierten Umgebung, in der Systeme arbeiten.

Die alte Frage

Lange Zeit lautete die zentrale Frage der Softwareentwicklung:

Wer schreibt die effizienteste Schleife?

Oder allgemeiner:

Wer kann eine Idee am präzisesten in Code übersetzen?

Dieses Paradigma hat uns weit gebracht.

Aber mit KI verschiebt sich der Schwerpunkt.

Die neue Frage

Die entscheidende Frage könnte künftig eine andere sein:

Wer konstruiert den präzisesten Rahmen, in dem eine KI nicht halluziniert?

Denn moderne Entwicklungsprozesse bestehen immer häufiger aus einer Zusammenarbeit zwischen Menschen und Modellen.

In dieser Zusammenarbeit wird Code zunehmend zu einem Resultat, nicht mehr zum alleinigen Ursprung der Lösung.

Das bedeutet nicht, dass Programmieren unwichtig wird.

Aber der Engpass verschiebt sich.

Wir brauchen vielleicht nicht unbedingt bessere Coder.

Wir brauchen bessere Architekt:innen für Kontext.

Das Experiment: AARRS

Genau aus diesem Gedanken heraus beobachte ich ein kleines Versuchskonstrukt namens

AARRS – AI-Assistant-Ready Repository Specification

Zum Repository auf GitHub

AARRS ist kein Tool und kein Framework.

Es ist eher eine forensische Untersuchung einer einfachen Frage:

Wie muss ein Projekt strukturiert sein, damit eine KI nicht nur rät, sondern tatsächlich versteht?

Die Hypothese dahinter ist simpel:

KI ist nur so gut wie der Kontext, den sie bekommt.

Viele Repositories liefern diesen Kontext aber nur indirekt – verteilt über Code, Commit-Historie und implizites Wissen im Team.

Für Menschen ist das mühsam.
Für Maschinen ist es nahezu unsichtbar.

Was ein KI-lesbares Repository auszeichnet

Ein Repository, das für KI-Assistenz vorbereitet ist, könnte zum Beispiel:

klare Einstiegspunkte für nicht-menschliche Leser enthalten
explizite Constraints als Leitplanken gegen Entropie definieren
maschinenlesbaren Repo-Kontext bereitstellen
eine Art Gebrauchsanweisung für Algorithmen mitliefern

Nicht als Ersatz für Architektur.

Sondern als Erweiterung der Dokumentationsebene.

Der mögliche Wendepunkt

Vielleicht erleben wir gerade eine stille Veränderung der Softwareentwicklung.

Eine Verschiebung von

Code-Produktion
hin zu
Problem-Definition und Kontext-Architektur.

Die eigentliche Ausführung rückt zunehmend in den Hintergrund.

Nicht weil sie unwichtig wird.

Sondern weil Maschinen sie immer häufiger übernehmen können.

Ein Artefakt, kein Standard

AARRS ist aktuell nur ein MVP.

Ein Denkanstoß.

Ein Artefakt, das eine Frage sichtbar machen soll.

Vielleicht entsteht daraus irgendwann ein Muster.

Vielleicht auch nicht.

Aber die zugrunde liegende Frage wird bleiben:

Wie bereiten wir unsere Projekte auf die Zusammenarbeit mit KI-Assistenten vor?

Oder anders gefragt:

Wie muss ein Repository aussehen, damit nicht nur Menschen darin denken können – sondern auch Maschinen?

Doom Scrolling PDD

Eigentlich wollte ich gestern die dritte Staffel The Night Agent auf Netflix binge-watchen.

Ein letzter Griff zum Telefon.

Irgendwo zwischen S3 E2 und S3 E3 wurde mir klar:
Ich sehe gar nicht hin.

Ich war in Posts, Threads und Artikeln verschwunden.

Prompt Driven Development.
PDD hier, PDD da.

Weniger Netflix, mehr Meinung.
Mehr Deutung.
Mehr Projektion.

Zwischen zwei Absätzen begriff ich:
Ich setze den Begriff „Prompt“ viel zu sehr ins Zentrum.

Dabei weiß ich es besser:

PDD ist kein Prompt Engineering.
Prompts sind nur das Interface – nicht das System.

Prompt Driven Development ist Architektur-Arbeit mit neuen Mitteln.

Es braucht Kontext.
Es braucht Rollenverteilung.
Es braucht die harte Disziplin von Iteration und Review.

Der „perfekte Prompt“ ist eine gefährliche Illusion.

Sie entsteht oft dort, wo solide Architektur fehlt –
oder wo man hofft, Design-Entscheidungen durch geschickte Formulierungen ersetzen zu können.

Ich werde wohl noch Zeit brauchen, bis das neue Vokabular aus dem flüchtigen Speicher
in mein echtes Gedächtnis wandert.

Bis aus Experiment und Hype-Coding wieder das wird, was es immer war:

Handwerk.
Einfach nur: Coding.

— Eine Randnotiz aus dem Zwischenraum zwischen zwei Tabs.

Ich hab ChatGPT gefragt – und der hat gesagt, ich soll das so machen

Eine kleine Bestandsaufnahme zwischen Vibe-Coding, VIPe, Wipe-Coding und Prompt-Engineering

Es gibt Tage, da fühlt sich die Tech-Szene an wie ein schlecht kuratiertes Buzzword-Bingo.
Kaum scrollt man einmal zu weit, stolpert man über Begriffe wie:

Vibe-Coding
VIPe
Wipe-Coding
Prompt-Engineering
Prompten
„Ich hab ChatGPT gefragt“

Alle meinen irgendwie dasselbe.
Und doch meint jeder etwas anderes.

Zeit, das einmal sauber auseinanderzunehmen – nicht um Begriffe zu verteidigen, sondern um zu verstehen, was wir da eigentlich gerade tun.

Vibe-Coding: Arbeiten nach Gefühl (und Algorithmus)

Fangen wir mit dem aktuell populärsten Begriff an.

Vibe-Coding beschreibt im Kern einen Zustand:

Man beschreibt, was man will
Die KI liefert irgendetwas
Man iteriert, solange es sich richtig anfühlt
Hauptsache, der Flow reißt nicht ab

Das ist kein Vorwurf.
Das ist ein Modus.

Vibe-Coding ist das, was passiert, wenn:

man experimentiert
man lernt
man spielt
man neugierig ist

Problematisch wird es erst, wenn aus diesem Zustand eine Methode gemacht wird.

Denn ein Vibe:

ist nicht dokumentiert
ist nicht reproduzierbar
ist nicht übertragbar
ist nicht überprüfbar

Vibe-Coding funktioniert hervorragend –
solange nur eine Person beteiligt ist und niemand Verantwortung übernehmen muss.

Prompten: Ich tippe, was mir einfällt

„Prompten“ ist die sprachliche Kurzform von:

Ich rede mit einer KI.

Mehr nicht.

Prompten kann alles sein:

ein Satz
ein Roman
eine halbe Idee
eine emotionale Eingebung
ein Copy-Paste aus StackOverflow
ein „mach mal besser“

Prompten ist keine Disziplin, sondern eine Tätigkeit.
So wie „Tippen“.

Niemand würde sagen:

„Ich habe ein neues Software-Paradigma: Tastatur-Coding.“

Aber bei KI sind wir erstaunlich großzügig.

Prompt-Engineering: Ordnung im Gespräch

Prompt-Engineering ist der Versuch, dem Ganzen Struktur zu geben:

Rollen definieren
Kontexte setzen
Formate vorgeben
Iterationen steuern
Ergebnisse vergleichen

Prompt-Engineering ist keine Magie.
Es ist Gesprächsarchitektur.

Und genau hier fängt die Verwirrung an:
Denn vieles, was heute als Vibe-Coding verkauft wird, ist schlicht unsauber ausgeführtes Prompt-Engineering – ohne es so zu nennen.

VIPe: Vibe-Inspired Prompt Engineering

VIPe taucht in diesem Kontext als Begriff auf, der versucht, zwei Welten zusammenzubringen:

den Vibe (Intuition, Gefühl, Vision)
das Engineering (Struktur, Prozess, Verantwortung)

VIPe sagt nicht:

„Vergiss den Vibe.“

Sondern:

„Nimm ihn ernst genug, um ihn zu formalisieren.“

Das bedeutet:

Der Vibe ist der Startpunkt
Nicht der Endzustand

VIPe ist kein neues Werkzeug.
Es ist ein Ordnungsversuch.

Ob man das braucht?
Kommt darauf an, was man baut – und mit wem.

Wipe-Coding: Wenn der Vibe alles wegwischt

Und dann gibt es noch Wipe-Coding.
Kein offizieller Begriff, aber jeder kennt es.

Wipe-Coding ist der Moment, wenn:

alles irgendwie funktioniert
niemand mehr weiß, warum
Änderungen alles kaputt machen
Entscheidungen nicht mehr erklärbar sind
man sagt: „Lass das lieber so, sonst geht’s wieder nicht“

Wipe-Coding ist das natürliche Endstadium von:

ungefiltertem Vibe-Coding
undokumentiertem Prompten
blindem Vertrauen in KI-Output

Es fühlt sich produktiv an –
bis es das nicht mehr tut.

„Ich hab ChatGPT gefragt und der hat gesagt …“

Dieser Satz ist das eigentliche Kernproblem.

Nicht, weil ChatGPT „falsch“ liegt.
Sondern weil er jede Verantwortung aus dem Satz entfernt.

Nicht ich habe entschieden.
Die KI hat gesagt.

Das ist kein Engineering.
Das ist Delegation ohne Rückversicherung.

KI kann Vorschläge machen.
Aber:

sie trägt keine Verantwortung
sie kennt keinen Kontext jenseits des Prompts
sie haftet nicht für Entscheidungen

Wer baut, bleibt verantwortlich.
Auch wenn der Prompt noch so gut war.

Also: Ist das nicht alles dasselbe in unterschiedlichen Kleidern?

Ja.
Und nein.

Alles bewegt sich im Spektrum von Prompt-Engineering.

Der Unterschied liegt nicht im Begriff, sondern im Reifegrad:

Vibe-Coding → Exploration
Prompten → Interaktion
Prompt-Engineering → Struktur
VIPe → Prozessbewusstsein
Wipe-Coding → Warnsignal

Die Begriffe sind nicht das Problem.
Das Problem ist, wenn man sie verwechselt.

Mein persönliches Zwischenfazit

Ich habe keine Lust auf Buzzword-Religionen.
Aber ich habe Lust auf Begriffe, die mir helfen, klarer zu denken.

Wenn VIPe mir hilft:

Vibes nicht zu verlieren
aber trotzdem Verantwortung zu übernehmen

dann nutze ich es.

Nicht, weil es neu klingt.
Sondern weil es mich zwingt, langsamer und sauberer zu arbeiten.

Und wenn sich am Ende herausstellt,
dass das alles nur Prompt-Engineering mit besserer Dokumentation war?

Dann wäre das kein Scheitern.
Sondern ein ziemlich ehrliches Ergebnis.

Ich habe ChatGPT gefragt.
Aber entscheiden musste ich trotzdem selbst.

Fortsetzung folgt.
Vielleicht.

VIPe – Vibe Inspired Prompt Engineering

VIPE‑Coding vs. VIPe – Warum Vibe‑Inspired Prompt Engineering mehr ist als nur ein Stil

Es gibt Momente in der Tech‑Welt, in denen zwei Begriffe fast gleich aussehen – aber völlig unterschiedliche Welten beschreiben. VIPE‑Coding und VIPe – Vibe‑Inspired Prompt Engineering gehören genau in diese Kategorie.

Beide klingen ähnlich. Beide wirken modern. Beide versprechen Effizienz. Doch nur einer davon ist ein Framework, das Webentwicklung, Kreativität und KI‑Architektur miteinander verschränkt: VIPe.

VIPE‑Coding: Der generische Begriff

VIPE‑Coding ist ein typischer Tech‑Begriff, wie er in vielen Projekten auftaucht: ein Akronym, das für Geschwindigkeit, Pragmatismus oder interne Prozesse stehen kann. Es ist nicht geschützt, nicht formalisiert und nicht an eine Methodik gebunden.

VIPE‑Coding ist damit ein Coding‑Stil, aber kein Engineering‑Framework.

Es beschreibt, wie man schreibt – nicht, wie man denkt.

VIPe – Vibe‑Inspired Prompt Engineering

Der Claim, der den Unterschied macht

VIPe ist kein Zufallswort. Es ist ein bewusst gesetzter Claim: Vibe‑Inspired Prompt Engineering – mit kleinem e, weil es nicht um Ego geht, sondern um Engineering.

VIPe ist ein formaler, dokumentierter Prozess, der kreative Visionen in reproduzierbare Prompt‑Architekturen übersetzt. Es ist die Brücke zwischen:

subjektiver Stimmung
objektiver Struktur
und technisch verwertbarem Output

Während VIPE‑Coding ein Stil ist, ist VIPe ein Framework.

Der VIPe‑Framework: Die vier Phasen

1. Vision – Der Vibe wird dekonstruiert

Der Prozess beginnt nicht mit Code, sondern mit Atmosphäre. Ein Vibe ist schwer greifbar – und genau deshalb wird er in VIPe systematisch zerlegt:

Referenzen
Farbpaletten
Typografie
Tonalität
Interaktionsmuster

Das Ergebnis: ein Vibe‑Sheet, das die kreative Intuition in technische Attribute übersetzt.

2. Interpretation – Die Prompt‑Strategie entsteht

Jetzt wird aus Gefühl Struktur.

Persona‑Definition
Prompt‑Techniken (Few‑Shot, CoT, Constraints)
Rollenverteilung (System/User)
Formatierung (JSON, Markdown, Hybrid)

Das Ergebnis: ein Prompt‑Design‑Dokument, das wie ein Architektengrundriss funktioniert.

3. Prompt – Die technische Generierung

Hier wird der Plan ausgeführt:

finaler Prompt
technische Vorgaben
Code‑Snippets
Ausführung im Zielsystem

Das Ergebnis: Output + Prompt‑Log – versioniert, nachvollziehbar, reproduzierbar.

4. Evaluation – Das Quality Gate

VIPe endet nicht beim Output. Es endet bei der Messbarkeit.

technische Korrektheit
Responsivität
Vibe‑Fidelity (Skala 1–10)
Abweichungen
Empfehlungen

Das Ergebnis: ein Evaluation‑Report, der die nächste Iteration vorbereitet.

VIPe ist damit nicht nur ein Begriff – es ist ein Standard, der Webentwicklung und KI‑Arbeit auf ein neues Level hebt.

Von der Intuition zur Methodik: Die Synthese etablierter Prompt-Engineering-Praktiken im PDD-Ansatz nach Benjamin Lam

Zusammenfassung

Der Ansatz der Prompt-Driven Development (PDD) nach Benjamin Lam stellt keinen Bruch mit bestehendem Wissen dar, sondern vielmehr eine systematische Formalisierung und Synthese etablierter Best Practices des Prompt Engineerings. Dieser Fachartikel analysiert die konzeptionellen Grundlagen von Lams PDD und ordnet sie in den breiteren Kontext des Feldes ein. Es wird argumentiert, dass der wesentliche Innovationsbeitrag nicht in der Erfindung atomarer Techniken, sondern in ihrer rigorosen Neukombination innerhalb eines testgetriebenen Softwareentwicklungs-Paradigmas liegt. Die Analyse zeigt, wie Prinzipien des iterativen Promptings, der evidenzbasierten Validierung und der Aufgabenzerlegung mit der disziplinierten Denkweise des Test-Driven Development (TDD) verschmolzen werden, um Prompt-Engineering von einer heuristischen Kunst zu einer ingenieurwissenschaftlichen Methodik zu erheben.

—

1. Einleitung: Die Suche nach Systematik im Prompt Engineering

Das Feld des Prompt Engineerings entwickelte sich zunächst als eine praktische, oft intuitive Antwort auf die Interaktion mit Large Language Models (LLMs). Während Techniken wie „Few-Shot Learning“ oder „Chain-of-Thought“ schnell an Popularität gewannen, blieb der Prozess ihrer Optimierung häufig unsystematisch und von Trial-and-Error geprägt. Vor diesem Hintergrund positioniert sich der PDD-Ansatz nach Benjamin Lam als Versuch, dieser Praxis eine methodische, wiederholbare und validierbare Struktur zu verleihen. Dieser Artikel dekonstruiert Lams Rahmenwerk und identifiziert seine Wurzeln in allgemein anerkannten Prinzipien des fortgeschrittenen Prompt Engineerings.

2. Konzeptuelle Dekonstruktion: Die Säulen von Lams PDD und ihre Vorläufer

Lams Ansatz lässt sich in mehrere Kernprinzipien zerlegen, die jeweils eine Entsprechung in der etablierten Theorie und Praxis des Feldes finden.

2.1 Iterative Prompt-Optimierung als strukturierter Zyklus
Lam betont einen dynamischen, feedbackbasierten Optimierungsprozess. Dies entspricht exakt dem etablierten Konzept des strukturierten iterativen Promptings, einem zyklischen Workflow aus Formulierung, Ausführung, Evaluation und gezielter Verfeinerung von Prompts. Diese Praxis ist grundlegend für die Bearbeitung komplexer oder mehrdeutiger Aufgaben, bei denen eine einzelne Prompt-Formulierung selten ausreicht.

2.2 Evidenzbasierte Validierung durch quantitative Metriken
Die Forderung nach systematischer Messung mittels Testdatensätzen und Metriken wie Genauigkeit oder Relevanz ist ein zentraler Grundsatz des professionellen Prompt Engineerings. Sie markiert den Übergang von subjektiver Einschätzung zu objektivierbarer, datengestützter Entscheidungsfindung. Frameworks zur automatisierten Prompt-Optimierung setzen diese Prämisse bereits operativ um.

2.3 Trennung von Aufgabenlogik und sprachlicher Formulierung
Die propagierte klare Trennung zwischen „Task“ und „Prompt“ reflektiert fortgeschrittene Prompting-Strategien. Die Chain-of-Thought (CoT)-Methode operationalisiert diese Trennung, indem sie den LLM explizit anweist, den Lösungsweg (die Logik) vor der finalen Antwort auszugeben. Ähnlich zielt Aufgabenzerlegung (Task Decomposition) darauf ab, eine komplexe Intention in eine Sequenz logisch verknüpfter, simplerer Sub-Prompts zu überführen, wodurch Logik und Implementierung entkoppelt werden.

2.4 Prompts als spezifizierende Artefakte
Die Behandlung von Prompts als präzise, versionierbare und testbare Spezifikationen gewinnt zunehmend an Bedeutung. Die Idee, Prompts als „First-Class Citizens“ innerhalb des Entwicklungslebenszyklus zu behandeln, wird in der Community diskutiert, um Wartbarkeit und Nachvollziehbarkeit zu erhöhen.

3. Die synthetische Innovation: Integration in das Test-Driven Development (TDD)-Paradigma

Hier liegt der eigentliche und originäre Beitrag von Lams PDD-Ansatz. Während die oben genannten Prinzipien einzeln bekannt sind, besteht seine Innovation in ihrer konsequenten Integration in den etablierten und disziplinierten Rahmen von Test-Driven Development.

· TDD-Zyklus für Prompts: Lam überträgt den klassischen Red-Green-Refactor-Zyklus des TDD. Ein „Test“ definiert hier das erwartete Ergebnis einer Aufgabenlogik. Der initiale „Prompt“ (entsprechend dem Code) wird so lange iterativ verfeinert („refactored“), bis er die Tests („grün“) erfüllt.
· Empirische Denkweise: Diese Integration erzwingt eine Präzision und empirische Strenge, die im ad-hoc Prompting oft fehlt. Die Prompt-Entwicklung wird dadurch zu einem gezielten, ergebnisorientierten Engineering-Prozess.
· Methodische Erhebung: Der Ansatz erhebt das Prompt-Engineering damit vom Status einer vorbereitenden oder begleitenden Tätigkeit zu einer kernmethodischen Aktivität innerhalb der Softwareentwicklung selbst.

4. Diskussion und Implikationen

Lams PDD-Ansatz ist ein Beleg für die fortschreitende Professionalisierung und Akademisierung des Prompt Engineerings. Er adressiert eine kritische Lücke, indem er eine Brücke zwischen der schnelllebigen, praxisorientierten Welt der KI-Interaktion und den methodisch fundierten, bewährten Prinzipien der Softwaretechnik schlägt.
Die Stärke des Ansatzes liegt in seiner Systematik und Übertragbarkeit, die es ermöglicht, Wissen über effektive Prompts zu kumulieren und in Teams weiterzugeben. Eine mögliche Limitation könnte der initial höhere methodische Overhead für einfache Aufgaben sein, der den pragmatischen Einsatz in allen Szenarien hinterfragt.

5. Fazit

Benjamin Lams Konzept von Prompt-Driven Development stellt keine Revolution, sondern eine evolutive Synthese dar. Sein Beitrag ist weniger die Erfindung neuer Techniken, sondern die konzeptionelle Rahmung und methodische Einbettung bestehender Best Practices des Prompt Engineerings in das disziplinierte Ökosystem des Test-Driven Development. Dadurch gelingt es ihm, einen wichtigen Schritt zu gehen: die Transformation des Prompt-Engineerings von einer heuristischen Kunst („Craft“) hin zu einer ingenieurwissenschaftlichen, lehr- und lernbaren Methodik. Dieser Ansatz bietet ein vielversprechendes Framework für den zuverlässigen und skalierbaren Einsatz von LLMs in kritischen Softwareentwicklungsprozessen.

Copilot hat mein Projekt gerettet, eine kurze Gutenachtgeschichte.

Ich bin froh, dass die Projekte, an denen ich aktuell arbeite, stabil laufen. Aber Erfahrung entsteht nicht nur aus funktionierenden Systemen, sondern vor allem aus denen, die nicht funktionieren.Als Gedankenexperiment habe ich mir deshalb ein bewusst chaotisches Projekt vorgestellt – eines, das viele Entwickler:innen, Projektmanager:innen und Teams in ähnlicher Form schon erlebt haben dürften.Ein Projekt mit:

vielen Tickets, aber wenig Orientierung
vielen Beteiligten, aber unklarer Verantwortung
vielen Meetings, aber kaum Entscheidungen

Ein Projekt, das niemand bewusst so gebaut hat – das aber genau so gewachsen ist.

Ich habe Copilot gefragt, wie er mit einem solchen Anti-Pattern-Projekt umgehen würde. Die folgende Antwort habe ich nicht als technische Anleitung gelesen, sondern als strukturierte Verdichtung von Erfahrung.

Wie man ein chaotisches Projekt rettet – ohne sich selbst zu verlieren

<Copilot-Anfang>

Ein Feldbericht aus der Realität, in der Best Practices nur auf Folien existieren

Es gibt Projekte, die riechen schon beim Betreten nach verbranntem Gummi.
Zu viele Tickets, zu wenig Klarheit.
Zu viele Meinungen, zu wenig Entscheidungen.
Zu viele Meetings, zu wenig Verantwortung.

Und dann wirst du hineingeschoben.
Mit dem freundlichen Satz:
„Kannst du das bitte retten?“

Willkommen im echten Leben.

1. Erst überleben, dann verbessern

Die wichtigste Erkenntnis:
Du rettest ein Projekt nicht, indem du sofort alles richtig machst.

Du rettest es, indem du Schaden begrenzt.

In chaotischen Projekten ist der erste Schritt immer derselbe:

Stabilisieren, nicht optimieren.

Das bedeutet:

keine neuen Features
keine neuen Tools
keine neuen Prozesse

Sondern eine einzige Frage:

Was brennt gerade wirklich?

Chaos ist laut.
Wahrheit ist leise.

2. Erwartungen sichtbar machen – brutal, ehrlich, sofort

In Projekten voller Anti-Pattern fehlt fast immer dasselbe:
eine gemeinsame Realität.

Alle glauben, sie reden über dasselbe.
Tun sie aber nicht.

Deshalb stelle ich eine Frage, die alles verändert:

„Woran würden wir erkennen, dass wir erfolgreich waren?“

Nicht: Was steht im Ticket.
Nicht: Was jemand „immer so macht“.
Nicht: Was „doch klar ist“.

Sondern: Was ist das erwartete Ergebnis?

Wenn niemand es sagen kann, ist das Problem nicht der Code.
Es ist die Führung.

3. Die kleinste funktionierende Wahrheit bauen

In chaotischen Projekten ist Komplexität der Feind.
Deshalb suche ich nach der kleinsten überprüfbaren Wahrheit.

Das ist kein MVP.
Das ist kein Prototyp.
Das ist ein Realitätsanker.

Ein Beispiel:

Nicht: „Checkout optimieren“
Sondern: „Unter Bedingung X soll Y passieren – und wir messen Z.“

Diese Mini-Wahrheit ist der erste Stein, auf dem man wieder stehen kann.

4. Tests als Diagnosewerkzeug, nicht als Ritual

In einem Anti-Pattern-Projekt kannst du nicht mit TDD anfangen.
Das wäre wie Yoga in einem brennenden Haus.

Aber du kannst Tests nutzen, um die Wahrheit sichtbar zu machen.

Ein Test ist eine Frage:
„Was genau soll passieren?“

Wenn niemand die Frage beantworten kann, ist das der eigentliche Bug.

Ich schreibe in solchen Projekten zuerst Charakterisierungstests:

Was tut das System jetzt?
Was sollte es tun?
Wo klaffen die Lücken?

Tests werden hier nicht zur Qualitätssicherung genutzt.
Sondern zur Realitätssicherung.

5. Verantwortung neu verteilen – aber richtig

In chaotischen Projekten ist Verantwortung oft ein Wanderpokal.
Jeder hält ihn kurz, bis er heiß wird, und wirft ihn weiter.

Ich drehe das um:

„Wer entscheidet das?“
„Wer trägt die Konsequenz?“
„Wer definiert ‚fertig‘?“

Nicht als Angriff.
Sondern als Struktur.

Verantwortung ist kein Schuldspiel.
Verantwortung ist ein Klärungswerkzeug.

6. Kommunikation entgiften

Chaotische Projekte haben toxische Kommunikationsmuster:

„Das war doch klar.“
„Das stand im Ticket.“
„Das haben wir immer so gemacht.“
„Das muss jetzt einfach schnell gehen.“

Ich ersetze das durch:

Explizite Erwartungen
Explizite Entscheidungen
Explizite Risiken

Nicht laut.
Nicht belehrend.
Sondern ruhig, präzise, unmissverständlich.

Chaos verliert gegen Klarheit.
Immer.

7. Kleine Siege sichtbar machen

Ein chaotisches Projekt wird nicht durch einen großen Wurf gerettet.
Sondern durch eine Serie kleiner, konsequenter Verbesserungen.

Ich mache diese sichtbar:

Was war vorher unklar?
Was ist jetzt klar?
Was wurde entschieden?
Was wurde verhindert?
Was wurde stabilisiert?

Das Team merkt plötzlich:
„Wir bewegen uns wieder.“

Und Bewegung ist der Anfang von Vertrauen.

8. Der stille Trick: Du rettest nicht das Projekt – du rettest die Entscheidungsfähigkeit

Am Ende ist die Wahrheit brutal einfach:

Projekte scheitern nicht an Code.
Sie scheitern an fehlenden Entscheidungen.

Wenn du es schaffst, dass Erwartungen klar werden,
Entscheidungen früher fallen,
und Realität wieder sichtbar wird,

dann rettest du nicht nur das Projekt.

Du rettest die Menschen darin.

Schlussgedanke

Wer in ein chaotisches Projekt geworfen wird,
braucht keine Heldentaten.

Er braucht Klarheit.
Mut zur Wahrheit.
Und die Fähigkeit, Erwartungen in überprüfbare Realität zu übersetzen.

Das ist keine Best Practice.
Das ist Überleben.

Und manchmal ist Überleben der erste Schritt zu Qualität.

</Copilot-Ende>

Fazit: Warum das alles richtig klingt – und in der Realität oft anders ist

Das alles klingt schlüssig.
Fast beruhigend.

Klarheit.
Entscheidungen.
Realitätsanker.
Verantwortung.

Als würde Chaos nur darauf warten, endlich richtig angesprochen zu werden.

Und ja – in der Theorie funktioniert das.
In vielen Situationen sogar erstaunlich gut.

Aber die Realität chaotischer Projekte ist komplizierter.

Nicht, weil die beschriebenen Ansätze falsch wären.
Sondern weil Projekte selten nur technische oder organisatorische Probleme sind.

Sie sind soziale Systeme.

Und soziale Systeme reagieren nicht linear auf Klarheit.

Chaos ist oft kein Zustand, sondern ein Schutzmechanismus

Viele chaotische Projekte sind nicht zufällig chaotisch.
Sie sind es geworden, weil Chaos lange Zeit funktioniert hat.

Unklare Tickets vermeiden Entscheidungen.
Viele Meetings verteilen Verantwortung.
Vage Ziele schützen vor Messbarkeit.

Chaos hält Dinge offen.
Und Offenheit fühlt sich sicher an, wenn niemand verlieren will.

Wer Klarheit schafft, greift in diese Schutzmechanismen ein.
Und das erzeugt Widerstand – nicht aus Bosheit, sondern aus Selbstschutz.

Entscheidungen sind selten technisch – sondern politisch

Die Idee, Entscheidungen „einfach sichtbar zu machen“, unterschätzt einen zentralen Punkt:

Entscheidungen haben Konsequenzen.
Und Konsequenzen haben immer eine Adresse.

In der Realität bedeutet Klarheit oft:

jemand liegt falsch
jemand verliert Einfluss
jemand wird sichtbar verantwortlich

Nicht jedes Projekt scheitert an fehlender Kompetenz.
Viele scheitern daran, dass niemand die Kosten einer Entscheidung tragen will.

Methoden können das nicht auflösen.
Nur Machtverhältnisse können das.

Nicht jedes Projekt will gerettet werden

Das ist unbequem, aber realistisch:

Nicht jedes Projekt will gerettet werden.

Manche Projekte existieren, weil:

Budgets gebunden werden müssen
Organisationen beschäftigt bleiben sollen
politische oder strategische Versprechen erfüllt werden müssen

In solchen Kontexten ist „Projekt retten“ nicht das Ziel.
Stabilität des Systems ist es.

Wer hier echte Klarheit schafft, wird schnell als Störfaktor wahrgenommen –
nicht als Retter.

Klarheit hat einen emotionalen Preis

Was in vielen Leitfäden fehlt, ist der Preis:

Klarheit kostet Energie.
Wahrheit kostet Beziehungskapital.
Entscheidungen kosten Schlaf.

Nicht jede Person kann oder will diesen Preis zahlen –
vor allem nicht dauerhaft.

Viele Anti-Pattern sind deshalb keine Dummheit.
Sondern Erschöpfung, die sich in Struktur verwandelt hat.

Schlussgedanke 2

Der Text beschreibt einen idealen Umgang mit Chaos.
Einen reifen, reflektierten, verantwortungsvollen.

Aber in der Realität braucht es dafür mehr als gute Methoden:

Rückendeckung
ein klares Mandat
psychologische Sicherheit
und manchmal schlicht Glück

Ohne das bleibt Klarheit ein Risiko.

Die eigentliche Frage ist deshalb nicht:
„Wie rette ich ein chaotisches Projekt?“

Sondern:

„In welchem System ist Rettung überhaupt erwünscht –
und was kostet sie mich persönlich?“

Manchmal ist der klügste Schritt nicht, Ordnung zu schaffen.
Sondern zu erkennen, wo Ordnung strukturell nicht vorgesehen ist.

Und auch das ist Erfahrung.

Lost in Translation?

Wie testgetriebene Entwicklung die Qualität wirklich verbessert

Über Erwartungen, Übersetzungsfehler und warum Code selten das eigentliche Problem ist

Es gibt viele Gründe, warum Software scheitert.
Zu wenig Zeit.
Zu wenig Budget.
Zu viele Anforderungen.

Aber erstaunlich selten scheitert sie am Code.

1. Das eigentliche Problem liegt davor

In den meisten Projekten, die ich gesehen habe, beginnt der Qualitätsverlust lange vor der ersten Codezeile.

Er beginnt im Anforderungsmanagement.

Nicht, weil Anforderungen falsch wären.
Sondern weil sie übersetzt werden müssen.

Von:

vagen Erwartungen
zu Tickets
zu Aufgaben
zu Code

Jede dieser Übersetzungen ist eine potenzielle Fehlerquelle.

Und je später ein Fehler auffällt,
desto teurer wird er.

2. Tickets sind keine Anforderungen

Ein Ticket ist kein Ziel.
Ein Ticket ist ein Behälter.

Darin liegen:

Annahmen
Hoffnungen
Halbsätze
implizites Wissen

„Button einbauen“
„Checkout optimieren“
„Performance verbessern“

Das klingt konkret.
Ist es aber nicht.

Was fehlt, ist fast immer die Antwort auf eine einfache Frage:

Woran erkennen wir, dass es richtig ist?

3. Erwartetes Ergebnis ist keine Selbstverständlichkeit

Viele Teams glauben, sie wüssten,
was ein „erwartetes Ergebnis“ ist.

Bis jemand fragt.

Dann kommen Sätze wie:

„Na, das sieht man doch.“
„So wie immer.“
„Das ist Standard.“

Tests beginnen genau hier.

Nicht beim Tool.
Nicht beim Framework.
Sondern beim Explizitmachen von Erwartungen.

Ein guter Test ist nichts anderes als eine präzise formulierte Erwartung:

Unter diesen Bedingungen soll genau das passieren – und nichts anderes.

4. Testgetriebene Entwicklung ist Übersetzungsarbeit

Testgetriebene Entwicklung wird oft missverstanden als:

Technikspielerei
Zusatzaufwand
Entwicklersache

In Wahrheit ist sie eine Übersetzungsschicht.

Sie übersetzt:

fachliche Erwartungen
in überprüfbare Aussagen

Bevor Code entsteht.

Der Code ist dann nur noch die Antwort auf eine bereits gestellte Frage.

5. Warum das die Qualität verbessert

Nicht, weil Tests Fehler finden.
Sondern weil sie Denkfehler sichtbar machen.

Wenn ein Test schwer zu formulieren ist,
ist meist nicht der Code kompliziert.

Sondern die Erwartung unklar.

Testgetriebene Entwicklung zwingt dazu,

Annahmen offenzulegen
Randfälle zu benennen
Verantwortung zu übernehmen

Nicht nur technisch, sondern fachlich.

6. Automatisierte Tests sind nur der letzte Schritt

Ob man am Ende mit Playwright, Cypress oder etwas anderem testet,
ist fast nebensächlich.

Wichtiger ist:

Was getestet wird
Warum es getestet wird
Wann entschieden wurde, dass etwas „fertig“ ist

Automatisierte Tests sind kein Ersatz für Denken.
Sie sind dessen Konservierung.

7. Gute Tests wollen getestet werden

Code, der getestet werden soll,
muss testbar sein.

Das führt fast automatisch zu:

klareren Schnittstellen
weniger Seiteneffekten
besserer Struktur

Nicht, weil es „Best Practice“ ist.
Sondern weil untestbarer Code oft auch unverständlicher Code ist.

8. Qualität ist kein Feature

Qualität entsteht nicht am Ende.
Nicht in der Abnahme.
Nicht im Bugfixing.

Sie entsteht dort,
wo Erwartungen präzise genug sind,
um geprüft zu werden.

Testgetriebene Entwicklung ist deshalb weniger eine Methode
als eine Haltung:

Wir versuchen, uns selbst nicht zu täuschen.

Schlussgedanke

Wer testgetrieben arbeitet,
schreibt nicht mehr Tests.

Er trifft früher Entscheidungen.

Und das ist meistens genau das,
was einem Projekt gefehlt hat.

Prompt Driven Development (PDD)

Ein Manifest gegen das bequeme Raten

Wir haben TDD gelernt, weil Code lügt. Oder genauer: Code erzählt alles, was du ihm erlaubst.
Jetzt haben wir LLMs – und die erzählen dir sogar dann noch eine runde Geschichte, wenn die Prämisse schon schief hängt.
Zeit für einen kleinen Prozess-Hack, der sich nicht wie ein Hack anfühlt.

Die Szene

Du sitzt da. Kaffee. Tabs. Eine Timeline voller „AI will replace developers“.
Du gibst einen Prompt ein. Das Modell liefert Code. Der Code sieht gut aus.
Und genau deshalb ist es gefährlich.

Denn LLMs sind höflich. Sie widersprechen selten. Sie liefern. Sie füllen Lücken.
Und Lücken sind im Projektmanagement nicht romantisch. Lücken sind Budget.

„Du wolltest eine Lösung. Du hast eine Antwort bekommen. Das ist nicht dasselbe.“

Was PDD ist (und was nicht)

Prompt Driven Development (PDD) behandelt Prompts als prüfbare Spezifikationen.
Nicht als Wunschzettel. Nicht als Chat. Sondern als Vertrag, der sich an der Realität messen lassen muss.

PDD ist nicht

kein „Prompt Engineering“ (mehr Worte, bessere Magie)
kein „LLM schreibt meinen Code“ (Delegation ohne Haftung)
kein „Tests generieren lassen und hoffen“
kein Workflow für Buzzword-Pitches

PDD ist

Spezifikation zuerst – als Prompt
Tests als Schiedsrichter (nicht als Deko)
Iterationen am Prompt, bis er messbar ist
Code erst dann, wenn „Done“ definierbar ist

Der Loop

Klassisch (und leider verbreitet): Prompt → Code → Fix → Noch mehr Fix → „Warum dauert das so lange?“

PDD dreht die Reihenfolge um:

Prompt (als Spezifikation)
Test (als Realitätssensor)
Prompt (Iteration: Präzision statt Poesie)
Code (Implementierung im Testkäfig)

Wenn du das System nicht messen kannst, steuerst du es nicht.
Du erzählst nur eine Geschichte über Kontrolle.

Die fünf Thesen (Manifest)

1) Prompts sind Artefakte

Ein Prompt ist kein Gespräch. Er ist ein Dokument. Versionierbar. Reviewbar. Kritikwürdig.
Wenn dein Prompt im Chat versickert, ist er im Projekt faktisch nicht existent.

2) Unklarheit ist der eigentliche Bug

Wenn etwas schief läuft, ist es selten „einfach ein Bug“. Oft ist es ein Nebelwort.
„Schnell.“ „Intuitiv.“ „Einfach.“ – diese Wörter sind wie Nebelgranaten, nur ohne Explosion, dafür mit Sprint-Meetings.

3) Tests prüfen den Prompt, nicht nur den Code

Scheitert ein Test, ist die erste Frage nicht: „Wer hat das kaputt gemacht?“
Sondern: „Was haben wir eigentlich wirklich verlangt?“

4) LLMs sind Co-Autoren, keine Orakel

Das Modell liefert Möglichkeiten. Du lieferst Verantwortung.
PDD ist die Methode, die diese Rollen trennt, statt sie romantisch zu vermischen.

5) Erst der Vertrag, dann die Implementierung

PDD ist eine Rückkehr zu etwas Altmodischem:
Definition of Done, die man ausführen kann.

„Wenn mein Prompt nicht testbar ist, ist er keine Spezifikation.“

Die Praxis: Wie ein Prompt testbar wird

Ein testbarer Prompt benennt:

Ziel (warum existiert das Feature?)
Input/Output (welche Daten rein, welche raus?)
Constraints (Performance, Security, Offline, KISS/YAGNI)
Edge Cases (wie scheitert es korrekt?)
Nicht-Ziele (was wird bewusst nicht gebaut?)
Akzeptanzkriterien (messbar: was heißt „fertig“?)

Wenn du nur „mach mal“ schreibst, bekommst du „mach mal“-Qualität zurück.
Und dann diskutierst du drei Tage über Ergebnisse, statt zwei Stunden über Anforderungen.

Anti-Patterns (die du erkennen wirst)

Der Roman-Prompt: zu lang, zu vage, zu viel Welt – und keine einzige harte Kante.
Der Good-Vibes-Test: „soll sich gut anfühlen“ – schön, aber nicht ausführbar.
Der Tool-Fetisch: neue Modelle, neue Plugins – aber keine Definition of Done.
Der Halluzinations-Deal: „Wird schon stimmen“ – bis Production es anders sieht.

Warum das gerade jetzt zählt

Weil KI nicht nur den Code schneller macht.
Sie macht auch das Scheitern schneller – wenn wir weiterhin im Nebel spezifizieren.

PDD ist keine Religion. Es ist ein Geländer.
Und Geländer sind nicht sexy. Sie sind das, was dich davon abhält, nachts um 23:48 Uhr
eine „kleine Änderung“ in Production zu machen.

„Du willst Geschwindigkeit? Dann hör auf, in Unklarheit zu investieren.“

Warum Arbeitszeiterfassung komplizierter ist, als man denkt

Ein Projektbericht aus der Grauzone zwischen Technik, Recht und Ethik

Ich arbeite seit ein paar Monaten an einer Anwendung zur Arbeitszeiterfassung.
Technisch ist dieses Projekt übersichtlich – ein paar Modelle, Zeitstempel, Reports, vielleicht eine Mobile App.
Inhaltlich aber ist es deutlich anspruchsvoller, als ich am Anfang gedacht habe.

Während ich mich in anderen Projekten durch API-Dokumentationen klicke, wälze ich hier Gesetzestexte, Verordnungen und Gerichtsurteile.

Keine fest definierten Endpunkte, dafür ein Haufen „könnte“, „sollte“, „müsste“.

YAGNI und KISS sind in meinem Kopf Gebot – aber dieses Projekt steckt voll von „Nichts ist in Stein gemeißelt“.

Der betriebswirtschaftliche Rahmen ist vergleichsweise klar:
Zeiterfassung spart Verwaltungsaufwand, verbessert Projekt-Controlling, hilft bei Ressourcenplanung, sichert faire Entlohnung und schützt das Unternehmen vor rechtlichen Risiken – besonders, wenn es bald ernst wird mit den Bußgeldern für fehlende Erfassungspflichten^[1].

Was mir allerdings Bauchschmerzen bereitet, ist der rechtliche Rahmen.
Nicht, weil die Gesetze unverständlich wären – sondern weil vieles noch auf Gerichtsurteilen basiert und (noch) nicht gesetzlich kodifiziert ist^[2].
Das BAG hat entschieden, dass Arbeitszeiterfassung verpflichtend ist^[3], aber das Gesetz, das dies konkret regelt, steht noch aus^[4].
Dazwischen: eine Grauzone aus Referentenentwürfen, Kommentierungen und branchenübergreifender Spekulation.

Und dann wären da noch die anderen „Layer“:

Datenschutz: Arbeitszeit ist personenbezogen^[5], bei biometrischer Authentifizierung wird’s richtig kritisch^[6].
UX / UI: Wer will schon ein weiteres Tool, das sich wie Pflichtbürokratie anfühlt?
Ethik und Moral: Wie viel Kontrolle ist zumutbar, wenn man Vertrauen erhalten will?
Wie formuliere ich ein Produkt, das fair ist – nicht nur compliant?

Kurz:

So ein richtig geiles Projekt.
Weil: Einfach wäre mir vermutlich zu langweilig.

Fußnoten:

Betriebswirtschaftliche Risiken bei fehlender Zeiterfassung und geplante Bußgeldregelungen: BAG-Urteil 2022 und Referentenentwurf zur ArbZG-Novelle (2023).
Pflicht zur Arbeitszeiterfassung besteht auf Basis EuGH- und BAG-Urteil, ohne dass ein neues Gesetz verabschiedet wurde.
BAG, Beschluss vom 13.09.2022 (Az. 1 ABR 22/21): Einführungspflicht für Arbeitgeber.
BMAS-Referentenentwurf (Stand 2023): elektronische Erfassung, Aufbewahrungspflicht, Übergangsfristen geplant.
DSGVO Art. 4 Abs. 1: Arbeitszeitdaten = personenbezogen.
DSGVO Art. 9: Biometrische Daten (z. B. Fingerabdruck) sind besonders schützenswert.

Das Design ist (meistens) nicht das Problem

Wenn ein Online-Shop nicht funktioniert, ist der erste Reflex fast immer derselbe:
„Wir brauchen ein Redesign.“

Neue Farben, neue Typografie, ein Slider, der größer wirkt.
Als ließe sich Relevanz durch Schärfentiefe ersetzen.

Doch meistens ist das Design gar nicht die Ursache.
Es ist nur die sichtbare Oberfläche, an der sich die Unklarheit entlädt.

Schlechtes Design kann wehtun,
aber oft ist es nur das Symptom einer tieferliegenden Gleichgültigkeit.

Das Unsichtbare wiegt mehr

Was viele für ein Designproblem halten,
ist oft ein Richtungsproblem.

Sichtbarkeit, Vertrauen, Ladezeit, Sprache –
die leisen Dinge entscheiden darüber,
ob jemand bleibt oder weiterklickt.

Man kann nichts verkaufen, was niemand findet.
Und niemand vertraut etwas, das sich selbst nicht versteht.

Wenn der Lack zu früh kommt

Design ist kein Motor, sondern ein Verstärker.
Es lässt nur sehen, was ohnehin da ist –
oder eben nicht.

Viele Projekte polieren zuerst den Lack
und wundern sich später, dass der Wagen nicht anspringt.

Die Ursachen sind fast immer banal:
Langsame Seiten, schwache Inhalte,
fehlende Struktur, kein klares Ziel.

Design kann all das schöner machen.
Aber Schönheit allein bewegt nichts.

Strategie statt Kosmetik

Ein Redesign kann helfen.
Aber es ersetzt keine Haltung.
Keine klare Sprache, keine erkennbare Position.

Bevor man also Farben diskutiert,
sollte man sich fragen:

Wird man gefunden?
Wird man verstanden?
Wird man vertraut?

Drei Fragen, die wichtiger sind
als jede Farbpalette.

Fazit

Design ist das, was man sieht.
Erfolg ist das, was bleibt.

Gutes Design schafft Vertrauen –
aber Vertrauen entsteht nicht durch Farbe,
sondern durch Orientierung.

Das eigentliche Redesign beginnt da,
wo man aufhört, die Oberfläche zu betrachten,
und anfängt, das Fundament zu reparieren.