Der Witz funktioniert, weil er in Wahrheit keiner ist
Nennen wir es Meteor development: Das Ziel wird zuerst verkündet, die Haltestellen ändern sich unterwegs, das Budget gilt als irgendwie lösbar, und engineering muss weiter Gleise legen, obwohl der Zug angeblich schon “gleich losfährt”.
Das Meme ist lustig, weil genau dieser Ablauf in echten Teams ständig vorkommt.
Ein Gründer verspricht ein Feature, bevor die Edge Cases überhaupt sichtbar sind. Das Produktteam zeichnet den Onboarding-Flow neu, nachdem Design schon weitergezogen ist. Führung sieht, dass AI den letzten Screen schnell gebaut hat, und schließt daraus, dass “noch eine Integration” wohl billig sein muss. Die Route bewegt sich ständig. Die Fristen nicht.
Die schlechte Nachricht: Kein Architektur-Pattern wird Menschen davon abhalten, unrealistische Erwartungen zu haben.
Die gute Nachricht: Unrealistische Erwartungen müssen nicht länger automatisch in engineering paralysis enden.
Der eigentliche Schmerz war nie nur die Erwartung
Schlechte Planung ist nervig. Sie verbrennt Zeit, erzeugt Druck und zwingt zu neuer Verhandlung. Aber allein zerstört sie die Lieferung noch nicht.
Was Teams wirklich bricht, ist der Moment, in dem jede späte Produktänderung zu einem Risiko für das ganze System wird.
Das ist der klassische Failure Mode schneller AI-generated Codebases. Version one geht so schnell live, dass alle anfangen zu glauben, jede spätere Änderung müsse genauso schnell sein. Dann kommt die Realität:
- der Auth-Provider muss getauscht werden
- Analytics muss optional werden
- ein Deep-Link-Path ist falsch
- eine Styling-Entscheidung hat sich über 40 Screens verteilt
- ein “kleines” Feature greift durch drei eigentlich unabhängige Module
Dann kämpft das Team nicht mehr nur mit unrealistischen Erwartungen. Es hängt zusätzlich an einer Codebase, die Veränderung nicht lokal absorbieren kann.
Das ist die doppelte Steuer. Das organisatorische Problem ist schon schwer genug. Das technische Problem verschärft es nur weiter.
Meteor development zerstört zuerst fragile Codebases
Darum trifft das Meme Engineers so präzise.
Wir haben alle dasselbe Muster gesehen:
- Die Route wird verkündet, bevor die Karte real ist.
- Der Umfang wächst weiter, während die Implementation schon läuft.
- Dieselbe Frist bleibt auf der Folie stehen.
- Engineering bekommt gesagt, es solle sich “einfach anpassen”.
Wenn das System schwache Boundaries hat, bedeutet “anpassen” in Wahrheit:
- AI-generated Abstractions rückzuentwickeln, die niemand bewusst entworfen hat
- Module zu entknoten, die in die Interna anderer Module greifen
- Regressions in Teilen der App zu reparieren, die niemand anfassen wollte
- eine Woche damit zu verlieren, die falsche Implementation zu bewahren
An diesem Punkt baut das Team kein Produkt mehr. Es betreibt Archäologie unter Fristen-Druck.
Genau diesen Teil müssen wir nicht länger akzeptieren.
Autotomy verändert den Failure Mode
Autotomy macht Fantasieschätzungen nicht realistisch. Es tut etwas Nützlicheres: Es hält das System austauschbar.
Die Kernidee ist einfach. Wenn ein Modul falsch ist, zu spät kommt oder nicht mehr zur Route passt, solltest du es abschneiden, ersetzen und weitergehen können.
Dafür braucht es ein paar nicht verhandelbare Grundlagen:
- Interfaces um volatile Services wie Auth, Analytics, Storage und Notifications
- einen Composition Root, der entscheidet, welche Implementation die App tatsächlich verwendet
- Dependency Boundaries, die verhindern, dass ein Screen Vendor-Details direkt importiert
- Contract Tests und deterministic checks, die Verhalten beim Austausch von Modulen absichern
- Dependency Tiers, damit optionale Tools sich nicht wie launch-kritische Infrastruktur verhalten
Wenn das steht, bleibt ein bewegliches Ziel lästig. Aber es wird nicht mehr existenziell.
Ein Provider-Wechsel wird zu einem Replacement hinter einem Interface. Ein Produkt-Umweg wird zu einem lokalen Rewrite statt zu einem systemweiten Refactor. Ein schlechtes AI-generated Modul wird zu etwas, das du löschst, nicht zu etwas, das du behutsam konservierst.
Wenn sich die Route ändert, kann Entwicklung trotzdem weitergehen
Das ist die praktische Verschiebung, die zählt.
Ohne Autotomy klingt Meteor development so:
“Wir haben den Onboarding-Plan wieder geändert, also müssen wir jetzt Auth, Profile State, Analytics, Styling und Navigation anfassen. Gib uns eine Woche, um herauszufinden, was kaputtgeht.”
Mit Autotomy klingt es eher so:
“Die Erwartung ist immer noch unrealistisch, aber die Änderung ist lokalisiert. Wir müssen Umfang oder Termin neu verhandeln, nicht die App neu bauen.”
Das ist ein deutlich besserer Failure Mode.
Natürlich musst du womöglich immer noch Lieferzusagen zurückweisen. Vielleicht musst du den Launch aufteilen, eine Haltestelle aus der Route streichen oder einer Last-Minute-Nebenstrecke ein Nein geben. Aber die Engineering-Organisation muss nicht doppelt leiden. Das menschliche Problem bleibt menschlich. Das Software-Problem bleibt handhabbar.
AI-Geschwindigkeit macht das wichtiger, nicht unwichtiger
AI coding ist einer der Gründe, warum Meteor development heute häufiger auftaucht.
Wenn Cursor oder Claude Code in Stunden die first version einer Feature erzeugen können, beginnt Führung anzunehmen, dass jede spätere Iteration sich genauso verhalten müsste. Man sieht Geschwindigkeit an der Oberfläche und verwechselt sie mit billigem Wandel in der Tiefe.
Das ist sie nicht.
AI ist hervorragend darin, Implementation zu füllen. Sie ist nicht dafür verantwortlich, das System strukturell sicher zu halten, wenn sich die Produktrealität ändert. Wenn die Codebase keine Boundaries hat, bringt dich AI speed nur schneller zur Fragilität.
Darum komme ich immer wieder auf denselben Punkt zurück: Die richtige Antwort auf AI-native development ist nicht mehr Optimismus. Sie ist mehr Ersetzbarkeit.
Schnell generieren. Boundaries erzwingen. Deterministisch validieren. Schlechte Module löschen, wenn sich die Route ändert. Den Auswirkungsradius lokal halten.
Mit dem Fantasie-Teil musst du immer noch selbst umgehen
Es gibt kein Framework, das in ein Planungsmeeting läuft und jemandem sagt, dass sein Starttermin erfunden ist.
Autotomy löst weder Priorisierung noch Wunsch-Roadmaps und verhindert auch nicht, dass ein Interessenvertreter noch eine weitere Station auf die Karte malt, nachdem der Bau begonnen hat.
Diesen Teil musst du weiterhin als Ingenieur und als Erwachsener handhaben.
Aber das sollte der einzige schwierige Teil sein.
Zur Arbeit sollte nicht auch noch gehören, eine Codebase wiederzubeleben, die jedes Mal kollabiert, wenn sich der Plan bewegt.
Vielleicht bleibt Meteor development dauerhaft so etwas wie organisatorisches Wetter. Gut. Dann soll es ein Meme über Erwartungsmanagement bleiben.
Mit Autotomy muss es kein Meme über Ingenieursleiden mehr sein.