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.

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:

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

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?

Quellen & Lesestoff

  • EuGH-Urteil C-55/18 – Pflicht zur Arbeitszeiterfassung (BMAS)
  • BAG 1 ABR 22/21 – Dokumentationspflicht (BAG)
  • APuZ 46/2023 – New Work und die Zukunft der Arbeit (bpb.de)
  • Haufe: Vertrauensarbeitszeit und Zeiterfassung (haufe.de)
  • Bertelsmann Stiftung: New Work – Potenziale & Stolpersteine (PDF)

Nachtrag: Vielleicht ist das alles gar kein Widerspruch – sondern einfach nur Arbeit, die endlich ehrlich wird.