Robots-First Engineering

Software wurde für Menschen gebaut. Das Dateisystem. Das Terminal. JSON. Git. Code-Reviews. Alles davon wurde durch das geformt, was ein Mensch an einer Tastatur verarbeiten kann.

Was, wenn du das wegwirfst und für Maschinen neu anfängst?

Das ist Robots-First Engineering. Und das ist die Richtung, in die sich die autonome Software-Entwicklung bereits bewegt.

Entwicklung ist kein Engineering mehr

Hier ist die Aufspaltung, die den ganzen Job neu rahmt:

Software-Entwicklung ist jetzt Maschinenarbeit. Code schreiben. Tests ausführen. Committen. Agenten erledigen das bereits. Nennen wir es ungefähr 10 Dollar pro Stunde, kein Schlaf, keine Pausen.

Software-Engineering ist die menschliche Schicht, die diese Maschine zuverlässig hält. Rails. Failure Domains. Verifikationsschleifen. Back-Pressure. Die gesamte Klempnerarbeit, in der der Agent läuft.

Dein Job hat sich unter deinen Füßen verändert. Du lädst keine Fracht mehr aufs Schiff. Der Versandcontainer ist aufgetaucht. Jetzt fährst du die Lokomotive und hältst sie auf der Strecke.

Dieser mentale Flip trennt Engineers, die in der neuen Welt aufblühen, von denen, die darin versinken.

Schraubenzieher vor Presslufthammer

Autonomes Engineering hat Stufen. Überspring sie und du scheiterst.

Der Schraubenzieher. Manuelle Arbeit. Du schreibst Specs von Hand. Du verwaltest den Kontext eng. Du steuerst Suche und Verknüpfung selbst. Das Ziel ist zu lernen, wie das System auf den Rails bleibt, bevor du ihm die Schlüssel gibst.

Der Presslufthammer. Volle Fahrt. Ralph-Schleifen laufen unbeaufsichtigt. Orchestrierte Flotten. Parallele Agenten. Overnight-Builds, die bis zum Morgen Features liefern.

Die meisten Engineers machen denselben Fehler. Sie greifen zum Presslufthammer, bevor sie den Schraubenzieher angefasst haben.

Direkt zur vollen Automatisierung springen ohne die Grundlagen und der Output ist Müll. Der Schraubenzieher ist das, was dir lehrt, was der Presslufthammer braucht.

Erst manuell gehen. Herausfinden, warum die Dinge zusammenhalten. Dann nach den Powertools greifen.

Loom: Ein Stack, der für Agenten gebaut ist

Loom zeigt auf den nächsten Schritt: eine Software-Umgebung, die sich um Agenten statt um Menschen neu aufbaut.

Die Designregel ist streng. Für jeden Teil des Stacks stell drei Fragen:

1. Wurde das für Menschen designed?
2. Wenn ja, kann es weg?
3. Wenn es wegfällt, was haben wir verloren und wie ersetzen wir es?

Ein paar Annahmen, die den Test nicht bestehen:

• Unix-Userspace und TTY-Konventionen. Agenten sitzen nicht an Terminals. Gilt davon noch irgendetwas?
• Agile-Rituale und Prozesse. Sprints existieren, weil Menschen in Wochen planen. Agenten nicht.
• JSON als Datenformat. Jedes Anführungszeichen und jede eckige Klammer verbrennt Tokens. Ist JSON das richtige Wire-Format?
• Code-Review-Workflows. Kann eine Verifikationsschleife eine Review-Warteschlange ersetzen?

Looms Teile umfassen:

• Code-Hosting, GitHub-ähnlich, aber für Agenten geformt
• Quellcodeverwaltung über JJ, das besser mit Maschinen-Workflows funktioniert
• Codespace-ähnliche Remote-Sandboxes
• Multi-LLM "Alloying", mehrere Provider gleichzeitig ausführen
• Aktor- und Pub-Sub-Nachrichtenmuster
• Verkettung im Stil von Erlang/OTP

Die Kernidee. Loops, die zu Chains zusammengesetzt werden. Loops auf Loops auf Loops. Jede eng und fokussiert. Das Ganze verhält sich als ein reaktives System.

Kontextfenster sind nur Arrays

Ein Kernprinzip für das robots-first Denken:

Ein Kontextfenster ist ein Array. Je weniger von diesem Array du füllst, desto weniger muss es gleiten, und desto besser wird der Output.

Mehr Kontext reinschütten und du bekommst:

• Mehr Gleiten
• Frühere Kompaktierung
• Kompaktierung, die Daten verliert
• Fehlende Anker
• Drift

Deshalb funktionieren Ralph-Schleifen überhaupt. Die Schleife ist so designed, dass sie das Array deterministisch betreibt. Halt das Array schlank. Kompaktierung ausweichen. Den Pin halten.

Der Pin ist deine Spec. Der stabile Referenzpunkt, auf den der Agent immer wieder zeigt. Jede Iteration liest ihn erneut. Ohne den Pin fangen Agenten an, Dinge zu erfinden.

Specs als Lookup-Tabellen

Robots-First-Specs sind keine Docs. Sie sind Lookup-Tabellen, die für die Agentensuche optimiert sind.

Eine gute Spec sieht so aus:

## User Authentication
 
**Also known as**: login, sign-in, auth, session management, identity
 
**Related files**: src/auth/, src/middleware/session.ts
 
**Key patterns**: JWT tokens, refresh rotation, secure cookies
 
**What NOT to do**: Don't implement custom crypto, don't store passwords in plain text

Das "also known as"-Feld hebt die Such-Trefferquote. Wenn der Agent nach "login" sucht, landet er auf der Auth-Spec. Mehr Synonyme, mehr Treffer. Mehr Treffer, weniger Erfindung.

Die Spec wird der Referenzrahmen für das gesamte Feature. Agenten schauen nach, was existiert, statt zu raten, was sein könnte.

Verknüpfung schlägt schicke Formate

Viele Engineers übergestalten ihre Pläne. Verschachtelte JSON-Schemas. Aufgabenhierarchien. Aufwändige Formatierung.

Die Robots-First-Sichtweise: enge Verknüpfung gewinnt über schicke Formate.

Was wirklich funktioniert:

• Bullet Points mit konkreten Referenzen
• Den genauen Spec-Abschnitt zitieren
• Auf die genaue Datei zeigen
• Spezifische Hunks referenzieren (Claude liest Dateien in Hunks)

## Implementation Plan
 
- [ ] Add JWT validation middleware
 
  - Spec: auth-spec.md#token-validation
  - File: src/middleware/auth.ts (lines 45-60)
  - Pattern: Follow existing rate-limit middleware structure
 
- [ ] Create refresh token endpoint
  - Spec: auth-spec.md#refresh-flow
  - File: src/routes/auth/refresh.ts (new file)
  - Pattern: Match existing /auth/login endpoint structure

Jetzt sucht der Agent mit Präzision. Er findet die richtigen Hunks. Er kopiert das Muster, das bereits im Repo ist. Er hört auf zu erfinden.

Der Robots-First Stack

Hier wird die Idee radikal. Besitz den ganzen Stack und du kannst ihn für Maschinen optimieren:

Serialisierung. JSON ist nicht token-effizient. Jedes Anführungszeichen, jede geschweifte Klammer, jedes Komma kostet Tokens. Ein binäres Format oder ein für Agenten entwickeltes Textformat könnte diese Kosten stark senken.

User Space. Warum sollte ein Agent Unix-Userspace erben? TTY wurde für Menschen an Terminals gebaut. Agenten brauchen keine Terminal-Emulation.

Garbage Collection. Was bedeutet Speicherverwaltung, wenn dein "Prozess" ein zustandsloser API-Aufruf ist? Die üblichen Annahmen hören auf zu gelten.

Message Passing. Erlang und OTP kommen zurück. Aktoren. Supervisor-Bäume. Let-it-crash. Die Muster passen sauber auf das Orchestrieren von Agenten.

Wenn du den Stack besitzt, kannst du:

• Tokenisierung optimieren
• Kosten stark senken
• Schnellere reaktive Pipes bauen
• Günstiger laufen als das nächste Team

Das ist Wettbewerbsvorteilsgelände.

Weavers: Agenten ohne Menschen in der Schleife

Das Ziel von Robots-First Engineering hat einen Namen: Weavers.

Ein Weaver ist ein autonomer Agent, der:

• Code hinter Feature-Flags liefert
• Ohne Code-Review deployt
• Produkt-Analytics beobachtet
• Entscheidet, ob eine Änderung die Fehler behoben hat
• Entscheidet, ob er weiter voranschreiten soll
• Eigenständig iteriert

Niemand steht darüber. Volle Autonomie.

Gruselig, ja. Das ist die richtige erste Reaktion. Jetzt bleib kurz damit.

Jeden Einwand, den du aufzählen kannst, ist ein Engineering-Problem, das gebaut werden muss. Was, wenn es die Produktion bricht? Entwickle einen Rollback. Was, wenn es eine schlechte Entscheidung trifft? Entwickle eine Verifikationsschleife. Was, wenn es von den Rails rutscht? Entwickle Back-Pressure.

Der neue Job des Software-Engineerings. Engineer die Bedenken weg.

Schreib deine Einwände auf. Dann baue die Systeme, die sie neutralisieren. Das ist die Arbeit jetzt.

Back-Pressure Engineering

Autonome Schleifen erzeugen Fehlermodi. Dein Job wird zum Verlegen der Rails:

• Constraints in der Spec hinzufügen
• Die Planverknüpfung enger machen
• Suchführung verbessern
• Die Gates erhöhen (Tests, Linting, Formatierung, Security Scans)

Wenn Outputs schlecht werden, ist der Fix eine weitere Schleife:

• Refactor-Schleife
• Konventions-Schleife
• Security-Schleife
• i18n-Schleife

Back-Pressure hält den Generator auf der Strecke. Die Lokomotive bleibt in der Linie, weil du die Linie engineered hast.

Die Skalierungsleiter

Robots-First Engineering skaliert durch Komposition. Vier Sprossen.

Level 1: Manuelle Grundlagen

• Specs durch Gespräch generieren
• Constraints von Hand enger machen
• Kontext so klein wie möglich halten
• An der Tastatur bleiben

Level 2: Unbeaufsichtigtes Looping

• while true Läufe
• Ein Ziel pro Iteration
• Automatisierte Tests plus Commit und Push
• Checkpointed State

Level 3: Multi-Loop-Orchestrierung

• Mehrere Schleifen laufen gleichzeitig
• Reaktive Chains zwischen ihnen verkabelt
• Aktor- und Pub-Sub-Muster

Level 4: Autonome Produktsysteme

• Weavers, die Features liefern
• Analytics, die Entscheidungen treiben
• Keine Review-Warteschlange
• End-to-End-Produktautonomie

Jede Sprosse ruht auf der darunter. Zu Level 4 springen ohne Level 1 bis 3 funktioniert nicht.

Der Mentalitätswechsel

Robots-First Engineering braucht einen anderen Kopf:

Alte Denkweise. "Wie schreibe ich diesen Code?" Neue Denkweise. "Wie entwerfe ich ein System, das diesen Code zuverlässig schreibt?"

Alte Denkweise. "Wie reviewe ich diesen PR?" Neue Denkweise. "Wie baue ich Verifikation, die Review sinnlos macht?"

Alte Denkweise. "Wie debugge ich dieses Problem?" Neue Denkweise. "Wie entwickle ich Feedback-Schleifen, die diese Art von Bug stoppen?"

Du schreibst keinen Code mehr. Du entwirfst autonome Systeme. Du bist ein Lokomotiv-Engineer, kein Hafenarbeiter.

Heute loslegen

Du brauchst Loom nicht, um robots-first zu denken. Fang mit Fragen an:

1. Welche menschlichen Annahmen backe ich ein? Prüfe deine Workflows. Welche Schritte existieren nur, weil ein Mensch derjenige war, der sie getan hat?

2. Was könnte zu einer Lookup-Tabelle werden? Deine Specs. Deine Muster. Deine Konventionen. Kannst du sie so formen, dass ein Agent sie durchsuchen kann?

3. Wo ist die Verknüpfung schwach? Die meisten Pläne zeigen locker auf Dinge. Kannst du stattdessen Dateipfade, Zeilenbereiche und Hunks hardcoden?

4. Wo ist der Back-Pressure? Wenn der Agent seitwärts geht, was fängt ihn auf? Baue diese Bremsen, bevor du sie brauchst.

5. Was würde volle Autonomie brauchen? Stell dir vor, du trittst aus der Schleife heraus. Was fällt auseinander? Diese Fehlschläge sind deine nächsten Engineering-Prioritäten.

Wohin das führt

Das ist 2026. Schnall dich an.

Die Lücke zwischen Teams, die zuverlässige autonome Schleifen laufen lassen können, und Teams, die das nicht können, wird schnell größer. Die Ökonomie ist klar. Automatisierte Entwicklung kostet ungefähr 10 Dollar pro Stunde. Menschliche Entwickler sind 100 Dollar und mehr.

Teams, die robots-first bauen, liefern in einem ganz anderen Tempo. Sie laufen günstiger. Sie iterieren schneller. Ihre Verbesserungen summieren sich, während sie schlafen.

Engineers, die an human-first Workflows festhalten, werden zurückfallen. Nicht weil ihre Fähigkeiten schlecht sind. Weil ihr Optimierungsziel falsch ist.

Software-Engineering hat sich gerade verändert. Es hat sich schon vorher verändert. Es wird sich wieder verändern.

Die Engineers, denen es gut geht, sind diejenigen, die jede Veränderung als eine weitere Chance sehen, von Grundprinzipien aus zu entwerfen. Das war schon immer so. Es ist jetzt nur schwerer zu ignorieren.

Fang mit dem Schraubenzieher an. Bring die Grundlagen in Ordnung. Dann greif nach dem Presslufthammer.

Die Lokomotive wartet.

Weiterführende Lektüre

• Ralph-Wiggum-Technik. Das Fundament für autonome Schleifen
• Thread-basiertes Engineering. Ein Framework zum Skalieren von Agenten-Arbeit
• Autonome Agenten-Schleifen. Ralph plus Threads zusammen
• Feedback-Schleifen. Verifikationsmuster, die Schleifen ehrlich halten
• Context Engineering. Das Array verwalten