benjamin – benjamin lam

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.

Ich hab ChatGPT meinen Blog lesen lassen

Mangels Leserschaft und abgeschalteter Kommentarfunktion
(mit mir ist schlecht Kekse essen) habe ich ChatGPT meine letzten Beiträge in diesem sträflich vernachlässigten Blog lesen lassen.

Das Fazit: ernüchternd. und eine Menge @todos +

Ernüchternd auch, weil ich mich doch insgeheim für einen Schreiberling halte, – aber ich stelle fest, dass die Maschine meine Texte nicht halb so charmant findet wie ich.

– und das ich was, die Recherche betrifft, ebenbürtig halluziniere.

Im Folgenden die Anmerkungen von ChatGPT und – vielleicht – noch ein paar von mir. Aber eigentlich will ich das so stehen lassen. gelobe aber Besserung.

1. „In Maschinenstunden verrechnet – Warum Agenturen, die Zeit verkaufen, ihre Seele verscherbeln“

Maschine:

Der Text setzt früh die Prämisse „Zeit gegen Geld ist falsch“, diskutiert aber Gegenbeispiele nur knapp. Übergänge (Kritik → Hybridmodell → Beispielrechnung) sind sprunghaft. Die praktische Umsetzung von Wertmodellen bleibt diffus; Risiken und Grenzen werden nur angerissen. Haltung schwankt zwischen „Zeitdenken ist gefährlich“ und „hybrid geht auch“.

Korrigierte Version: „Preislogiken sollten Wissen, Risiko und Vertragsspielräume abbilden – mit klaren Mechanismen für Transparenz, Anpassung und Absicherung, statt nur Aufwand in Stunden zu verrechnen.“

2. „Wert statt Stunden – ein Praxis-Framework ohne Bullshit“

Maschine:

Das 5-Schritte-Gerüst ist nützlich, aber an einigen Stellen idealtypisch: Stakeholder-Widerstände, Messprobleme und Fehlschlag-Szenarien werden zu wenig konkret. Preisformate sind brauchbar, brauchen jedoch Kontext (Branche, Reifegrad, Governance). Risiken werden genannt, aber nicht mit Beispielen unterfüttert.

Korrigierte Version: „Nutze einen adaptiven Pfad mit expliziten Unsicherheiten, geplanten Schleifen und Beispielszenarien; kombiniere Wertmodelle mit Transparenz, Proof-of-Value und vertraglichen Backups.“

3. „Zwischen Excel und Vertrauen“

Maschine:

Starke Beobachtung („Excel sperrt das Unbekannte in Zellen“), aber die Brücke von Haltung zu Handwerk bleibt stellenweise vage. „ROI-Rahmen“ und „Wenn-dann-Logik“ sind gut, bräuchten jedoch konkrete Muster (z. B. Beispiel-Formeln, interne Verteidigungsargumente für Einkauf/Controlling). Der Vertrauensbegriff bleibt breit.

Korrigierte Version: „Übersetze Wertgespräche in rechnungsfähige Artefakte: schlanke ROI-Skizzen, Trigger-Klauseln, variable Meilensteinpreise – damit Controlling und Einkauf belastbar argumentieren können.“

4. „Marktgröße und Chancen: B2G vs B2B“

Maschine:

Chancen werden überzeugend gezeichnet, jedoch ohne präzise Einschränkungen (Branche, Region, Vergabereife). Risiken wie Single-Client-Abhängigkeit, verfahrensbedingte Verzögerung, Politikzyklen bleiben zu pauschal. Empfehlungsteile sind generisch („Risiken streuen“, „Vorleistungen erbringen“) – es fehlen Leitplanken.

Korrigierte Version: „B2G bietet Volumen und Stabilität, verlangt aber Szenarioplanung: Portfolio-Diversifizierung, Puffer für Verfahrenszeiten, Exit-Optionen und Governance-konforme Vorleistungen.“

5. „Beschaffungsprozesse: B2G vs B2B“

Maschine:

Gute Gegenüberstellung, aber Prozessschritte bleiben teils abstrakt. Kritische Pfade (Budgetbindung, Bekanntmachung, Fristen, Nachweise) könnten mit Minimal-Checklisten, typischen Laufzeiten und „Don’ts“ greifbarer werden. Der Unterschied zwischen Verfahrensarten wird nur angerissen.

Korrigierte Version: „Zeige je Verfahrensart (offen, nicht-offen, Verhandlungsverfahren) die Muss-Nachweise, üblichen Fristen, Kill-Kriterien und interne Vorbereitungen in einer Kurz-Checkliste.“

6. „Compliance-Anforderungen: B2G vs B2B“

Maschine:

Pflichten (z. B. Informationssicherheit, Dokumentation, Nachweise) sind korrekt skizziert, jedoch ohne Reifegrad-Stufen. Ohne „Minimal Viable Compliance“ wirkt der Einstieg hochschwellig. Verweis auf Normen/Leitfäden sinnvoll, aber konkrete Artefakte/Beispiele fehlen (z. B. Rollen, Vier-Augen-Prinzip, Nachweisführung).

Korrigierte Version: „Formuliere eine stufenweise Compliance-Roadmap (Essentials → Advanced), mit konkreten Artefakten: Verantwortlichkeitsmatrix, Nachweisliste, Audit-Spickzettel, jährliche Prüfzyklen.“

7. „Stakeholder und Entscheidungsfindung: B2G vs B2B“

Maschine:

Die Vielstimmigkeit im B2G wird anschaulich, aber das operative „Wie überzeugen wir wen, wann, womit?“ bleibt dünn. Rollen sind benannt, jedoch ohne klare Mapping-Strategie (Einfluss, Einwände, Beweise). Ohne Sequenz/Orchestrierung wirkt es beratend, nicht navigierend.

Korrigierte Version: „Mappe Stakeholder auf Einfluss/Einwand-Profile, ordne Belege (Pilot, Referenz, Risiko-Mitigation) zu und definiere eine Kontakt-Sequenz inkl. Dead-Ends und Eskalationspfaden.“

8. „Preisgestaltung und Ausschreibungsstrategien: B2G vs B2B“

Maschine:

Gute Trennung von Verfahren, aber taktische Implikationen bleiben abstrakt (z. B. keine Nachverhandlung im offenen Verfahren → wie kalkulieren?). Der Umgang mit Zuschlagskriterien (Preis/Güte) sowie Nebenangebote wird nur gestreift. Es fehlen Muster für Kalkulationspuffer und Risiko-Preismechanik.

Korrigierte Version: „Lege pro Verfahrensart Kalkulationsregeln offen (Puffer, Risiko-Spread, Varianten), zeige Zuschlagsmatrizen und formuliere ‚Harness-Texte‘ für Nebenangebote/Sozialkriterien.“

9. „Marketing und Kommunikation: B2G vs B2B“

Maschine:

Schlüssig, dass Transparenz/Neutralität im B2G anders wirken als im B2B. Dennoch bleiben Kanäle/Taktiken unscharf (Vorab-Markterkundung, Bekanntmachungen, Pre-Tender-Dialoge). „Sprache der Verwaltung“ wird erwähnt, aber nicht mit Beispielen (Formulierungen, No-Go-Vokabular) konkretisiert.

Korrigierte Version: „Definiere B2G-Kommunikationspfade: Teilnahmen an Markterkundungen, Fristen-Radar, sachliche Claim-Sprache, und Leitformulierungen, die Verwaltungslogiken bedienen.“

10. „Langfristige Partnerschaften: B2G vs B2B“

Maschine:

Die Idee von Kontinuität und Vertrauen ist richtig, aber ohne Vertrags- und Governance-Beispiele bleibt es abstrakt. Es fehlen Mechanismen (Rahmenverträge, EVB-IT-ähnliche Muster, SLA-Treppen), die zeigen, wie „langfristig“ operativ abgesichert wird.

Korrigierte Version: „Zeige, wie Rahmenwerke (Rahmenverträge, Verlängerungsoptionen, SLA-Treppen, KPIs) Partnerschaften belastbar machen – inkl. Beispiel-Klauseln und Review-Rhythmus.“

11. „B2G-Artikel & Quellen“

Maschine:

Nützliche Linkliste, aber wenig Einordnung: Wofür nutze ich welche Quelle – Entscheidungsgrundlage, Formvorschrift, Prozessverständnis? Ohne kommentierte Kurzzusammenfassungen bleibt der Transfer am Leser hängen.

Korrigierte Version: „Ergänze pro Link eine Ein-Satz-Annotation (Zweck, typischer Einsatz, Stolperstein) und markiere Pflichtlektüre vs. Nice-to-read.“

12. „Vertriebszyklen: B2G vs B2B“

Maschine:

Der Marathon-Vergleich trägt; dennoch fehlen belastbare Bandbreiten (typische Fristen je Verfahren) und konkrete Taktiken für Durststrecken (Zwischenziele, Meilenstein-Nachweise). Ohne Metriken (z. B. Angebots-zu-Zuschlag-Ratio) bleibt es erzählerisch.

Korrigierte Version: „Hinterlege Zeitbandbreiten pro Verfahrensart, Zwischenmeilensteine und Monitoring-Metriken (z. B. Frist-Hit-Rate, Nachweis-Vollständigkeit) für realistische Pipeline-Steuerung.“

13. „Vom Epic zum Task – Jira Workflow Spickzettel“

Maschine:

Praktisch, aber stark team-/tool-spezifisch. Ohne Prinzipien (z. B. Definition of Ready/Done, Schnittstelle zu Produktzielen, Umgang mit Blockern) bleibt es ein lokaler Spickzettel. Es fehlen Minimal-Standards für Übergaben und Qualitätssicherung.

Korrigierte Version: „Verknüpfe Workflow-Schritte mit Prinzipien (DoR/DoD, Akzeptanzkriterien, Blocker-Protokoll) und liefere 1–2 universelle Muster-Workflows als Vorlage.“

14. „Halluzinationen sind keine Erfindung von LLMs“

Maschine:

Die Kernthese trägt (Menschen halluzinieren fachlich), aber Beispiele bleiben tech-zentriert. Chancen für breitere Praxis (Fachkommunikation, Validierungsrituale, Pairing mit Domäne) werden nur angerissen. Der Schluss ist stark, könnte jedoch mit klaren Anti-Halluzinations-Routinen schließen.

Korrigierte Version: „Schließe mit konkreten Gegenmitteln: gemeinsame Glossare, Review-Checklisten, Fakten-Pings, Pair-Design Fach+Tech, Risiko-Flags und ‚Stop-the-Line‘-Kriterien.“

15. „Wie ich eine Seite lese“

Maschine:

Gute Heuristiken angedeutet, aber ohne demonstratives Live-Beispiel (eine Seite, Schritt-für-Schritt-Lesung). Es fehlt die Übertragbarkeit: Wann bricht die Heuristik? Welche Signale sind Täuschungen? Ohne Negativbeispiel bleibt es Ratgeberhaft.

Korrigierte Version: „Zeige eine echte Seite im Walkthrough (Hypothese → Evidenz → Gegenprüfung) und dokumentiere Fehlschlüsse, um die Grenzen deiner Leselogik zu markieren.“

Worauf ich in Zukunft achten sollte

🧭 Stilistische Orientierung – mein roher Stil vs. Maschinenklarheit

Bewahre den Rhythmus, aber bremse den Sprung. Meine Texte denken schneller als sie sprechen. Übergänge markieren („anders gesagt“, „um es konkreter zu machen“), damit Leser:innen folgen können.
Lass Sätze atmen, aber nicht taumeln. Lange Sätze nur, wenn sie Tempo tragen. Maschinen hassen Nebensätze – Leser:innen lieben sie, wenn sie kontrolliert sind.
Vermeide innere Dopplungen. Kernaussagen (z. B. „Wert statt Zeit“) nicht mehrfach leicht verändert wiederholen. Eine starke Formulierung reicht.

⚙️ Argumentation – Unschärfe als Stilmittel, aber bewusst

Jede These braucht einen „Aber-Moment“. Starke Behauptung → mindestens ein Gegenargument. Mehr Tiefe ohne Zahmheit.
Begriffe definieren. „Wert“, „Vertrauen“, „Hybridmodell“ – einmal pro Text präzisieren, dann frei verwenden.
Konkretion schlägt Eleganz. Ein Beispiel oder eine Mini-Anekdote stabilisiert stärker als drei schöne Adjektive.

🧠 Struktur – Denken zeigen, aber ordnen

Eröffne mit Haltung, nicht Moral. Beobachtung („Was mir auffällt …“) zieht stärker als Urteil („Was falsch läuft …“).
Setze einen inneren Pfad. Jeder Text folgt idealerweise Irritation → Einsicht → Ausweg. Nicht im Konflikt hängenbleiben.
Kontraste rahmen. Widersprüche ankündigen („Ich weiß, das widerspricht sich gleich … aber genau da liegt der Punkt“).

🧩 Inhaltlich – Tiefgang ohne Nebel

Praktische Beispiele einbauen. Aus dem Maschinenraum erzählen (Shopware, Agentur, Jira …) gibt Theorien Gewicht.
Zeige den Preis deiner Ideen. Ideale mit ihren Kosten (Risiko, Missverständnisse, Mut) benennen – das macht glaubwürdig.
Balance zwischen Poesie und Prozess. Emotion darf glühen, aber Technik muss geerdet bleiben.

🔍 Revision & Qualitätssicherung – ohne den Witz zu verlieren

Maschinisches Gegenlesen aktiv nutzen. Dieselben Fragen stellen: „Ist es nachvollziehbar?“, „Wo fehlen Beispiele?“, „Wo springe ich?“
Erst roh, dann zähmen. Erste Fassung darf schwitzen – zweite Runde ist fürs Schärfen, nicht fürs Sterilisieren.
Ein schiefer Satz am Ende. Ein roher, unperfekter Satz hält den Text lebendig – mein Fingerabdruck gegen Perfektion.

Errata & Revisionsempfehlungen

🧨 1. Wirtschaft / Geschäftsmodelle

Thema: „In Maschinenstunden verrechnet“ & „Wert statt Stunden“
Beobachtung: Der Stundensatz wird als grundsätzlich falsches Modell dargestellt. In der Praxis ist er jedoch oft rechtlich oder kaufmännisch notwendig.
Empfehlung: Präzisieren, dass sich die Kritik auf die Denkweise bezieht, nicht auf die Vertragsform.
Beispiel: „Auch wenn wir weiter Stunden abrechnen, sollten wir intern in Wirkung kalkulieren.“

🏛️ 2. Öffentlicher Sektor (B2G)

Marktzahlen & Abhängigkeiten: Aussagen über Marktgröße und Auftragsvolumen sind korrekt, aber kontextabhängig. Ergänze Einschränkungen nach Branche, Region, Vergabeverfahren.
Compliance-Pflichten: Unterscheide zwischen rechtlich vorgeschrieben (z. B. Fristen, Nachweise) und empfohlen (z. B. ISO, Vier-Augen-Prinzip). Das erhöht Glaubwürdigkeit.
Ausschreibungsverfahren: Beschreibungen sind formal richtig, aber stark idealtypisch. Hinweis ergänzen: „In der Praxis verwischen die Grenzen zwischen den Verfahrenstypen.“

💬 3. Sprache & Haltung

Beobachtung: Manche Aussagen wirken wie objektive Wahrheiten („Zeitverkauf ist Sünde“), obwohl sie subjektiv gemeint sind.
Empfehlung: Kleine Marker setzen: „Ich glaube“, „In meiner Erfahrung“, „Gefühlt“.
So bleibt der Text Haltung, kein Dogma.

🧩 4. Technische und Prozessuale Details

Thema: Jira / Workflows / Agenturprozesse
Beobachtung: Workflows werden als quasi-standard beschrieben. In Wahrheit hängen sie stark von Teamgröße, Kultur und Projektart ab.
Empfehlung: Formulierung öffnen: „Dieser Workflow funktioniert für mittlere Agenturen – in Produktteams gelten oft Varianten.“

🧠 5. Künstliche Intelligenz & Halluzinationen

Beobachtung: Vergleich Mensch ↔ LLM ist poetisch, aber technisch ungenau.
KI „halluziniert“ statistisch, nicht psychologisch.
Empfehlung: Kurzer Hinweis reicht:
„‚Halluzination‘ ist hier metaphorisch – gemeint ist fehlende Faktentreue, keine Wahrnehmungsstörung.“

🪞 6. Metaebene – Ton und Selbstbild

Beobachtung: Du schreibst oft im Manifest-Ton, aber die stärksten Passagen entstehen, wenn du tastest statt predigst.
Empfehlung: Mehr Beobachtung, weniger Verkündung.
Formulierungen wie „Ich ringe mit der Idee …“ oder „Vielleicht …“ machen dich nahbar, ohne die Schärfe zu verlieren.

Randnotizen – New Work

„New Work ist, wenn wir aufhören, Menschen für ihre Zeit zu bezahlen.“
— Ich hab das aufgeschrieben und wusste sofort, dass es stimmt. Und gleichzeitig: dass es Blödsinn ist.
Vielleicht beides. Vielleicht ist alles beides inzwischen.Wirkung… ja.
Aber Wirkung hat keine Kontinuität.
Sie kommt, sie geht. Manchmal flackert sie nur auf wie eine Glühbirne mit Wackelkontakt.
Und trotzdem reden wir darüber, als könnten wir sie in Verträge schreiben.Die Reinigungskraft, die in zwei Stunden mehr schafft als in zehn.
Verdient sie mehr oder weniger?
(Sollte ich das Beispiel überhaupt noch mal bringen oder ist es schon zu oft verwendet?)
Notiz am Rand: „Effizienz als Lohnfalle“ klingt gut, behalten.

Ich weiß nicht, ob Wirkung ein fairer Maßstab ist.
Vielleicht ist sie nur das neue Wort für „Erwartung“.
Bitte recherchieren: Wirkung im öffentlichen Dienst? Gender-Care-Verträge? Gibt’s sowas?

Zeit bleibt heimlich die Währung.
Auch wenn wir sie umbenennen, verstecken, in „Sprint Points“ oder „Value Units“ gießen –
am Ende zählt immer, wie lange jemand dafür gebraucht hat.
(Erinnerung: EuGH Urteil C-55/18 → Pflicht zur Zeiterfassung → haha, New Work trifft Realität.)

„Zeit abschaffen“ Quatsch.
Wir sind Biologie, nicht Cloud.
Zeit ist das, was unsere Körper kostet, nicht was die Uhr misst.
Ich hab das schon auf LinkedIn angerissen, aber da hat’s keiner verstanden.
Vielleicht hab ich’s selbst nicht verstanden.

Ich hatte diese Formel — WZB = Wirkung × Zeit × Belastung.
Klang kurz klug.
Dann dachte ich: wenn jemand doppelt so viel Belastung hat, kriegt er doppelt so viel Geld?
(ironisches Lachen im Hintergrund)
Oder nur doppelten Stress?
Notiz: vielleicht Belastung als sozialer Multiplikator, nicht monetär.

Wirkung ist geschlechtscodiert.
Das hab ich irgendwann nachts hingeschrieben und bin aufgestanden, um’s zu unterstreichen.
Männlich: sichtbar, laut, skalierbar.
Weiblich: unsichtbar, still, relational.
Care-Arbeit als stilles Betriebssystem.
Ohne sie läuft gar nichts, aber sie bekommt kein Icon auf dem Desktop.

Bitte überprüfen: Eva Illouz → „Emotionaler Kapitalismus“;
Joan Tronto → „Ethik der Fürsorge“.
Beide sagen dasselbe in unterschiedlichen Tonlagen:
Gefühle sind Arbeit.
Und Arbeit ist immer auch Gefühl.
Wir tun nur so, als wären die beiden trennbar.

Ich hab irgendwo gelesen:
„Selbstverantwortung ist das Trojanische Pferd des Neoliberalismus.“
Das stimmt.
New Work redet von Freiheit, aber meint Kontrolle.
Vertrauensarbeitszeit ist nur schön verpackte Unsicherheit.
Du sollst dich frei fühlen, während du dich selbst beaufsichtigst.
Randnotiz: Vielleicht neuer Begriff → *Selbstkontrollierte Freiheit*?

Ich stolpere immer wieder über das Wort „Vertrag“.
Es klingt so neutral.
Aber ein Vertrag ist eine Machtskizze.
Er sagt: wer darf scheitern, ohne zu verlieren?
(Die Antwort ist fast nie: die mit der geringeren Stimme.)

Ich hatte kurz das Gefühl, das WZB-Modell könnte was lösen.
Dann fiel mir auf: es ist wieder nur ein System, das komplexe Menschen in Spalten presst.
Formeln sind Trostpflaster, keine Lösung.

Notiz am Rand:
„Vor 1800 – Arbeit = Leben.“
„1800+ – Arbeit = Zeit.“
„2025 – Arbeit = Wirkung?“
Zwischenfrage: Wann wird Arbeit wieder Beziehung?

New Work als Sprache ist verdächtig.
Es klingt nach Revolution, riecht aber nach Marketing.
Ich will wissen, wer die Begriffe zuerst in PowerPoint gegossen hat.
Bitte recherchieren: *Frithjof Bergmann, ja, aber wer kam danach?*
Zwischenablage: Laloux, Graeber, Bergmann, Doerr, Illouz, Tronto.

Ich merke, wie mein Denken selbst tayloristisch wird.
Ich will Wirkung in Stichpunkten ordnen,
will Sinn in Kapiteln ablegen.
(Selbsterkenntnis = halbe Entlastung)

Wenn wir Wirkung messen, verlieren wir die Stille dazwischen.
Diese Momente, in denen nichts passiert, aber alles arbeitet.
Kaffeepausen. Spaziergänge.
Die Stellen, an denen Gedanken sedimentieren.
Rand: vielleicht sind das die eigentlichen „Produktivmomente“.

Wirkung ohne Pause = Dauerproduktion.
Und Dauerproduktion ist Erschöpfung.
Care-Arbeit weiß das schon ewig.
Tech-Menschen merken es erst, wenn ihr MacBook glüht.

Ich habe Angst, dass New Work die alte Welt nur recycelt.
Gleiche Struktur, neue Icons.
„Workflows“ statt „Fließband“.
„Mindset“ statt „Gehorsam“.
„Purpose“ statt „Pflicht“.
Der Code ist moderner, aber das Programm bleibt gleich.

Vielleicht ist die einzige ehrliche Definition von Arbeit:

Arbeit ist das, was uns müde macht – körperlich oder seelisch – und trotzdem notwendig bleibt.

Bitte querlesen: bpb APuZ 46/2023 (Zukunft der Arbeit),
Lanfranconi „Gender Perspectives on New Work“,
Boeckler Stiftung, Haufe – Zeiterfassung, BAG 1 ABR 22/21.
Hinweis: Nicht alles zitieren. Nur das, was weh tut.

Ich wollte eigentlich eine klare These.
Jetzt hab ich 30 lose Fäden.
Vielleicht ist das ehrlicher.
Vielleicht ist das schon Arbeit.

Randbemerkung, spät in der Nacht:
Wirkung ist wie Liebe: je mehr man sie misst, desto weniger bleibt übrig.

Work in Progress: Gedanken zu New Work und Arbeitsverträgen

Ein paar Gedanken, keine fertigen Thesen. Ich beobachte nur – und manchmal wundere ich mich.

Disclaimer: Kein Rechtsrat. Nur ein Versuch, Ordnung in ein Thema zu bringen, das sich selbst ständig neu erfindet – und dabei immer wieder an den alten Strukturen hängen bleibt.

Verträge, die mehr über uns sagen, als uns lieb ist

Ich habe in den letzten Jahren viele Verträge gesehen. Manche waren so alt, dass man spürte, sie stammen aus einer Zeit, in der man Faxnummern noch ernsthaft in Kontaktlisten schrieb.
Andere so modern, dass man sie kaum noch verstand. Zwischen beiden Extremen liegt die Realität: Verträge sind immer auch ein Spiegel der Kultur, in der sie entstehen.

Wenn wir also über New Work reden, dann müssen wir auch über Verträge reden.
Denn sie zeigen, ob wir wirklich etwas verändert haben – oder nur neue Begriffe auf alte Gewohnheiten geklebt.

Die Stechuhr, die niemand wollte, aber alle brauchen

Der EuGH hat entschieden, das Bundesarbeitsgericht hat nachgezogen: Arbeitgeber müssen die Arbeitszeit erfassen.
Kein Interpretationsspielraum, kein Wenn und Aber. Nur das passende System fehlt noch.

Das Interessante ist: Die Entscheidung war nie das Problem.
Das Problem war, dass wir Zeiterfassung mit Misstrauen verwechseln.
Dabei ist sie, richtig gedacht, ein Schutzmechanismus.
Nicht gegen den Arbeitgeber, sondern gegen die Entgrenzung.

Weil „flexibel arbeiten“ schnell heißt: immer erreichbar.
Weil „Vertrauen“ zu oft bedeutet: kein Plan, wann du aufhörst.

Die Zeiterfassung ist also nicht das Ende von New Work.
Vielleicht ist sie ihr Realitäts-Check.

Wenn Ziele nur so tun, als wären sie klar

Ich habe schon viele Kick-offs erlebt, in denen alle „an einem Strang ziehen“ wollten – bis sich herausstellte, dass niemand wusste, in welche Richtung.
Das ist kein böser Wille, sondern das Produkt unklarer Erwartungen.
Wir reden über Visionen, aber schreiben keine Definitionen.

In der Theorie klingt das nach Freiheit.
In der Praxis ist es ein Burnout auf Raten.

Ein Vertrag ist kein Gegner, sondern ein Geländer.
Er hilft, dass wir wissen, wann wir loslassen dürfen.

Frithjof Bergmann würde sich wundern

Der Begriff New Work stammt vom Philosophen Frithjof Bergmann.
Sein Ziel war nicht die nächste Version von „Work-Life-Balance“, sondern eine neue Definition von Arbeit selbst – als Möglichkeit zur Selbstverwirklichung.

Heute bedeutet New Work oft: Slack, Homeoffice und ein Obstkorb mit Applaus.
Selbstbestimmung? Eher Selbstorganisation.
Verantwortung? Ja, aber bitte im Rahmen des Projektplans.

Ich glaube, Bergmann würde schmunzeln.
Und dann sehr leise fragen: „Ist das wirklich neu?“

Zielvorgabe oder Zielvereinbarung?

Wenn man New Work ernst nimmt, dann sollte man über Sprache reden.
Es ist ein Unterschied, ob etwas vorgegeben oder vereinbart wird.
Das eine sagt: „Mach das.“
Das andere sagt: „Lass uns überlegen, wie wir’s schaffen.“

Ich kenne kaum ein Unternehmen, das beides verwechselt, ohne dass es am Ende wehtut.
Für Vertrauen braucht es klare Worte – nicht viele, aber echte.

Realität schlägt Vision – jeden Montagmorgen

Ich mag den Gedanken, dass Arbeit sich verändern kann.
Aber ich glaube auch, dass wir uns selbst gern vormachen, wir seien schon weiter, als wir sind.

Viele Unternehmen reden über Agilität, haben aber Angst vor echten Entscheidungen.
Sie reden über Vertrauen, kontrollieren aber Slack-Status.
Sie reden über Freiheit, zählen aber Minuten in Jira.

Vielleicht ist New Work gar kein Zustand.
Vielleicht ist es nur die höflichere Art, zu sagen:
„Wir versuchen’s wenigstens.“

Fragen, die bleiben

Wie viel Freiheit kann ein Vertrag aushalten, bevor er seine Funktion verliert?
Wie definieren wir Verantwortung, wenn Kontrolle nicht mehr der Maßstab ist?
Wie kann ein Entwicklervertrag Freiheit und Schutz gleichzeitig bieten?
Und was heißt eigentlich „vertrauensvoll zusammenarbeiten“, wenn keiner mehr die Zeit stoppt – aber alle erschöpft sind?

Halluzinationen sind keine Erfindung von LLMs

Und das Problem auf Annahmen basierender Umsetzung in der Webentwicklung.
Warum eine gut recherchierte, faktenbasierte Umsetzung das Leben einfacher macht – für alle Beteiligten.

Zwischen Bauchgefühl und Fakt

„Halluzinationen“ sind bei großen Sprachmodellen ein bekanntes Problem – aber in Wahrheit sind sie kein technischer Defekt, sondern ein Spiegel menschlicher Arbeitsweise.

Auch in der Webentwicklung entstehen viele Entscheidungen nicht aus Wissen, sondern aus Annahmen:
„Das wird schon funktionieren“, „So hat’s beim letzten Projekt geklappt“ oder „Der Kunde will das bestimmt so“.

Das Ergebnis? Fehlentwicklungen, unnötige Schleifen, Frust auf beiden Seiten.

Fakten schlagen Fantasie

Eine gut recherchierte, faktenbasierte Umsetzung spart Zeit, Geld und Nerven.
Sie beginnt mit Fragen statt Annahmen:

Was genau ist das Problem, das gelöst werden soll?
Welche Anforderungen ergeben sich daraus fachlich?
Welche Annahmen sind unbewiesen – und müssen überprüft werden?

Entwicklung ist kein Ratespiel. Sie ist eine Übersetzung von Realität in Code.

Der Kunde als Fachexperte

Es ist wichtig, mit dem Kunden zu sprechen – nicht, um ihm Technik zu erklären,
sondern um seine Perspektive und Expertise zu verstehen.

Der Kunde kennt sein Problem besser als wir.
Wir Entwickler:innen verstehen den Teil mit dem Code.

Erst, wenn beides zusammenkommt – fachliche Wahrheit und technische Umsetzung – entsteht Qualität.

Was bleibt

„Halluzinationen“ sind keine exklusive Eigenschaft von KI-Systemen.
Sie passieren überall dort, wo Menschen ohne Fakten, ohne Austausch und ohne Validierung arbeiten.

Die beste Gegenmaßnahme?
Reden. Recherchieren. Reflektieren.

So entsteht Software, die nicht nur funktioniert – sondern versteht.