Harness-Engineering: Codex in einer agentenzentrierten Welt

In den letzten fünf Monaten hat unser Team ein Experiment durchgeführt: Wir haben eine interne Beta eines Softwareprodukts entwickelt und ausgeliefert – mit 0 Zeilen manuell geschriebenem Code.

Das Produkt hat interne tägliche Nutzer:innen und externe Alphatester:innen. Es wird versendet, bereitgestellt, geht kaputt und wird repariert. Der Unterschied ist, dass jede Codezeile – Anwendungslogik, Tests, CI-Konfiguration, Dokumentation, Überwachbarkeit und internes Tooling – von Codex geschrieben wurde. Wir schätzen, dass wir dies in etwa einem Zehntel der Zeit erstellt haben, die es gedauert hätte, den Code manuell zu schreiben.

Menschen lenken. Agenten führen aus.

Wir haben diese Einschränkung bewusst gewählt, um genau das zu entwickeln, was notwendig ist, um die Ingenieursgeschwindigkeit um ein Vielfaches zu steigern. Wir hatten Wochen Zeit, um das zu liefern, was schließlich eine Million Codezeilen umfasste. Um das zu erreichen, mussten wir verstehen, was sich ändert, wenn die Hauptaufgabe eines Softwareentwicklungsteams nicht mehr das Schreiben von Code ist, sondern das Entwerfen von Umgebungen, das Spezifizieren von Absichten und das Erstellen von Feedback-Schleifen, die es Codex-Agenten ermöglichen, zuverlässig zu arbeiten.

In diesem Beitrag geht es darum, was wir beim Aufbau eines brandneuen Produkts mit einem Team von Agenten gelernt haben – was schiefging, was sich verstärkte und wie wir unsere wirklich knappe Ressource maximieren können: menschliche Zeit und Aufmerksamkeit.

Der erste Commit in ein leeres Repository erfolgte Ende August 2025.

Das anfängliche Gerüst – Repository-Struktur, CI-Konfiguration, Formatierungsregeln, Paketmanager-Setup und Anwendungs-Framework – wurde von der Codex CLI mit GPT‑5 generiert, geleitet von einer kleinen Auswahl bestehender Vorlagen. Sogar die ursprüngliche AGENTS.md-Datei, die den Agenten erklärt, wie sie im Repository arbeiten sollen, wurde von Codex selbst geschrieben.

Es gab keinen bereits vorhandenen, von Menschen geschriebenen Code, an dem sich das System hätte orientieren können. Von Anfang an wurde das Repository vom Agenten geprägt.

Fünf Monate später enthält das Repository ungefähr eine Million Codezeilen, verteilt auf Anwendungslogik, Infrastruktur, Tooling, Dokumentation und interne Entwicklertools. In diesem Zeitraum wurden rund 1.500 Pull Requests eröffnet und zusammengeführt, wobei ein kleines Team von nur drei Ingenieur:innen Codex vorangetrieben hat. Dies entspricht einem durchschnittlichen Durchsatz von 3,5 PRs pro Ingenieur:in und Tag, und überraschenderweise hat sich der Durchsatz erhöht, während das Team auf inzwischen sieben Ingenieur:innen angewachsen ist. Wichtig ist, dass dies nicht nur um des Outputs willen geschah: Das Produkt wurde intern von Hunderten von Nutzer:innen verwendet, darunter auch tägliche interne Power-User.

Während des gesamten Entwicklungsprozesses haben Menschen nie direkt Code beigesteuert. Das wurde zu einer Kernphilosophie für das Team: kein manuell geschriebener Code.

Der Mangel an praktischer menschlicher Programmierung führte zu einer anderen Art von Ingenieurarbeit, die sich auf Systeme, Gerüste und Hebelwirkung konzentriert.

Die frühen Fortschritte waren langsamer als erwartet, nicht weil Codex unfähig war, sondern weil die Umgebung nicht ausreichend spezifiziert war. Dem Agenten fehlten die Tools, Abstraktionen und die interne Struktur, die notwendig waren, um Fortschritte in Richtung hochgesteckter Ziele zu machen. Die Hauptaufgabe unseres Engineering-Teams wurde es, die Agenten zu befähigen, nützliche Arbeit zu leisten.

In der Praxis bedeutete das, tiefenorientiert zu arbeiten: größere Ziele in kleinere Bausteine (Design, Code, Review, Test usw.) zu zerlegen, den Agenten dazu zu bringen, diese Bausteine zu konstruieren, und sie zu verwenden, um komplexere Aufgaben freizuschalten. Wenn etwas fehlschlug, war die Lösung fast nie „streng dich mehr an“. Da der einzige Weg, Fortschritte zu erzielen, darin bestand, Codex die Arbeit machen zu lassen, übernahmen menschliche Ingenieur:innen stets die Aufgabe und fragten: „Welche Fähigkeit fehlt, und wie machen wir sie sowohl verständlich als auch durchsetzbar für den Agenten?“

Menschen interagieren fast ausschließlich über Prompts mit dem System: Ein:e Ingenieur:in beschreibt eine Aufgabe, führt den Agenten aus und erlaubt ihm, einen Pull Request zu öffnen. Um einen PR abzuschließen, instruieren wir Codex, seine eigenen Änderungen lokal zu überprüfen, zusätzliche spezifische Agenten-Reviews sowohl lokal als auch in der Cloud anzufordern, auf jegliches Feedback von Menschen oder Agenten zu reagieren und in einer Schleife zu iterieren, bis alle Agenten-Reviewer zufrieden sind (effektiv ist das eine Ralph Wiggum Loop⁠(wird in einem neuen Fenster geöffnet)). Codex verwendet unsere Standard-Entwicklungstools direkt (gh, lokale Skripte und im Repository eingebettete Skills), um Kontext zu sammeln, ohne dass Menschen etwas per Copy-and-Paste in die CLI einfügen müssen.

Menschen können Pull Requests überprüfen, sind aber nicht dazu verpflichtet. Im Laufe der Zeit haben wir fast den gesamten Überprüfungsaufwand darauf verlagert, dass er von Agent zu Agent abgewickelt wird.

Als der Code-Durchsatz zunahm, wurde unser Engpass die Kapazität der menschlichen QA. Da die feste Einschränkung die menschliche Zeit und Aufmerksamkeit war, haben wir daran gearbeitet, dem Agenten mehr Fähigkeiten zu geben, indem wir Dinge wie die Anwendungs-UI, Protokolle und Anwendungsmetriken selbst direkt für Codex lesbar gemacht haben.

Zum Beispiel haben wir die App pro Git-Worktree bootfähig gemacht, sodass Codex eine Instanz pro Änderung starten und steuern kann. Wir haben außerdem das Chrome DevTools Protocol in die Agent-Laufzeit integriert und Fähigkeiten für die Arbeit mit DOM-Snapshots, Screenshots und Navigation erstellt. Dadurch konnte Codex Bugs reproduzieren, Fixes validieren und direkt über das UI-Verhalten nachdenken.

Wir haben dasselbe für Observability-Tooling gemacht. Logs, Metriken und Traces werden Codex über einen lokalen Observability-Stack bereitgestellt, der für jeden einzelnen Worktree ephemer ist. Codex arbeitet an einer vollständig isolierten Version dieser App, einschließlich ihrer Logs und Metriken, die entfernt werden, sobald die Aufgabe abgeschlossen ist. Agenten können Logs mit LogQL und Metriken mit PromQL abfragen. Mit diesem verfügbaren Kontext werden Prompts wie „Stelle sicher, dass der Dienststart in unter 800 ms abgeschlossen ist“ oder „kein Abschnitt in diesen vier kritischen User Journeys überschreitet zwei Sekunden“ umsetzbar.

Wir sehen regelmäßig, dass einzelne Codex-Läufe an einer einzelnen Aufgabe über sechs Stunden arbeiten (oft während die Menschen schlafen).

Das Kontextmanagement gehört zu den größten Herausforderungen, um Agenten bei umfangreichen und komplexen Aufgaben effektiv einzusetzen. Eine der ersten Lektionen, die wir gelernt haben, war einfach: Gib Codex eine Karte, nicht ein 1000-seitiges Handbuch.

Wir haben den Ansatz „one big AGENTS.md⁠(wird in einem neuen Fenster geöffnet)“ ausprobiert ausprobiert. Es scheiterte auf vorhersehbare Weise:

• Kontext ist eine knappe Ressource. Eine riesige Anweisungsdatei verdrängt die eigentliche Aufgabe, den Code und die relevanten Dokumente – sodass der Agent entweder wichtige Einschränkungen übersieht oder mit der Optimierung für die falschen beginnt.
• Zu viel Anleitung wird zu keiner Anleitung. Wenn alles „wichtig“ ist, ist nichts wichtig. Agenten neigen dazu, lokal Muster zu erkennen, anstatt bewusst zu navigieren.
• Es verrottet sofort. Ein monolithisches Handbuch wird zu einem Friedhof veralteter Regeln. Agenten können nicht erkennen, was noch wahr ist, Menschen hören auf, es zu pflegen, und die Datei wird still und leise zu einer attraktiven Gefahrenquelle.
• Es ist schwer zu überprüfen. Ein einzelner Blob eignet sich nicht für mechanische Überprüfungen (Abdeckung, Aktualität, Zuständigkeit, Querverweise), daher ist Drift unvermeidlich.

Anstatt AGENTS.md als Enzyklopädie zu betrachten, sehen wir es als das Inhaltsverzeichnis.

Die Wissensdatenbank des Repository befindet sich in einem strukturierten docs/-Verzeichnis, das als System of Record behandelt wird. Eine kurze AGENTS.md (ungefähr 100 Zeilen) wird in den Kontext eingefügt und dient hauptsächlich als Karte, mit Verweisen auf tieferliegende Wahrheitsquellen an anderer Stelle.

Die Designdokumentation wird katalogisiert und indexiert, einschließlich des Verifizierungsstatus und einer Reihe von Kernüberzeugungen, die agentenbasierte Betriebsprinzipien definieren. Architekturdokumentation⁠(wird in einem neuen Fenster geöffnet) bietet eine Übersicht über Domänen und die Paketschichtung. Ein Qualitätsdokument bewertet jeden Produktbereich und jede Architekturschicht und verfolgt Lücken im Laufe der Zeit.

Pläne werden als Artefakte erster Klasse behandelt. Ephemere, leichtgewichtige Pläne werden für kleine Änderungen verwendet, während komplexe Arbeiten in Ausführungsplänen⁠(wird in einem neuen Fenster geöffnet) mit Fortschritts- und Entscheidungsprotokollen erfasst werden, die in das Repository eingecheckt werden. Aktive Pläne, abgeschlossene Pläne und bekannte technische Altlasten sind alle versioniert und gemeinsam abgelegt, sodass Agenten arbeiten können, ohne auf externen Kontext angewiesen zu sein.

Dies ermöglicht progressive Offenlegung: Agenten beginnen mit einem kleinen, stabilen Einstiegspunkt und lernen, wo sie als Nächstes nachsehen sollen, anstatt von Anfang an überfordert zu werden.

Wir setzen dies mechanisch durch. Dedizierte Linter und CI-Jobs überprüfen, dass die Wissensdatenbank aktuell, querverlinkt und korrekt strukturiert ist. Ein wiederkehrender „doc-gardening“-Agent durchsucht veraltete oder obsolet gewordene Dokumentationen, die das tatsächliche Verhalten des Codes nicht widerspiegeln, und erstellt Korrektur-Pull-Requests.

Mit der Weiterentwicklung der Codebasis musste sich auch das Framework von Codex für Designentscheidungen weiterentwickeln.

Da das Repository vollständig agentengeneriert ist, ist es zuerst auf die Lesbarkeit von Codex optimiert. So wie Teams die Navigierbarkeit ihres Codes für neue Ingenieur:innen verbessern wollen, war es das Ziel unserer menschlichen Ingenieur:innen, es einem Agenten zu ermöglichen, über die gesamte Geschäftsdomäne direkt aus dem Repository selbst zu schlussfolgern.

Aus Sicht des Agenten existiert alles, worauf er während der Ausführung nicht im Kontext zugreifen kann, effektiv nicht. Wissen, das in Google Docs, Chat-Threads oder in den Köpfen von Menschen steckt, ist für das System nicht zugänglich. Repository-local, versionierte Artefakte (z. B. Code, Markdown, Schemas, ausführbare Pläne) sind alles, was er sehen kann.

Wir haben gelernt, dass wir im Laufe der Zeit immer mehr Kontext in das Repository einbringen mussten. Diese Slack-Diskussion, die das Team auf ein architektonisches Muster abgestimmt hat? Wenn es für den Agenten nicht auffindbar ist, ist es genauso unlesbar, wie es für einen neuen Mitarbeitenden, der drei Monate später hinzukommt, unbekannt wäre.

Codex mehr Kontext zu geben bedeutet, die richtigen Informationen zu organisieren und offenzulegen, damit der Agent darüber schlussfolgern kann, anstatt ihn mit Ad-hoc-Anweisungen zu überfordern. Genauso wie du ein neues Teammitglied in Produktprinzipien, Engineering-Normen und Teamkultur einarbeitest (inklusive Emoji-Präferenzen), führt es zu besser abgestimmten Ergebnissen, wenn du dem Agenten diese Informationen gibst.

Diese Herangehensweise hat viele Kompromisse verdeutlicht. Wir bevorzugten Abhängigkeiten und Abstraktionen, die vollständig intern verstanden und im Repository nachvollzogen werden konnten. Technologien, die oft als „langweilig“ beschrieben werden, sind für Agenten aufgrund von Komponierbarkeit, API-Stabilität und ihrer Repräsentation im Trainingsdatensatz leichter zu modellieren. In einigen Fällen war es günstiger, den Agenten Teilmengen der Funktionalität neu implementieren zu lassen, als undurchsichtiges vorgelagertes Verhalten aus öffentlichen Bibliotheken zu umgehen. Zum Beispiel haben wir, anstatt ein generisches Paket im p-limit-Stil zu verwenden, unseren eigenen map-with-concurrency-Helper implementiert: Er ist eng in unsere OpenTelemetry-Instrumentierung integriert, hat 100 % Testabdeckung und verhält sich genau so, wie es unsere Runtime erwartet.

Mehr vom System in eine Form zu bringen, die der Agent direkt prüfen, validieren und ändern kann, erhöht die Hebelwirkung – nicht nur für Codex, sondern auch für andere Agenten (z. B. Aardvark), die ebenfalls an der Codebasis arbeiten.

Allein durch Dokumentation bleibt eine vollständig agentengenerierte Codebasis nicht kohärent. Indem wir Invarianten durchsetzen, anstatt Implementierungen zu mikromanagen, ermöglichen wir es den Agenten, schnell zu liefern, ohne das Fundament zu untergraben. Zum Beispiel verlangen wir von Codex, Datenstrukturen an der Grenze zu analysieren⁠(wird in einem neuen Fenster geöffnet), sind aber nicht vorschreibend, wie das geschehen soll (das Modell scheint Zod zu bevorzugen, aber wir haben diese spezielle Bibliothek nicht vorgegeben).

Agenten sind in Umgebungen mit strengen Grenzen und vorhersehbarer Struktur⁠(wird in einem neuen Fenster geöffnet) am effektivsten, daher haben wir die Anwendung um ein starres architektonisches Modell herum aufgebaut. Jeder Geschäftsbereich ist in eine feste Anzahl von Schichten unterteilt, mit streng geprüften Abhängigkeitsrichtungen und einer begrenzten Anzahl von zulässigen Kanten. Diese Einschränkungen werden mechanisch durch benutzerdefinierte Linter (natürlich von Codex generiert!) und strukturelle Tests erzwungen.

Das Diagramm unten zeigt die Regel: innerhalb jedes Geschäftsdomäne (z. B. App-Einstellungen) kann Code nur über eine feste Anzahl von Schichten „weitergeleitet“ werden (Typen → Konfiguration → Repo → Service → Runtime → UI). Querschnittsthemen (Auth, Konnektoren, Telemetrie, Feature-Flags) werden über eine einzige explizite Schnittstelle eingebunden: Provider. Alles andere ist nicht erlaubt und wird mechanisch durchgesetzt.

Das ist die Art von Architektur, die du normalerweise aufschiebst, bis du Hunderte von Ingenieur:innen hast. Bei Coding-Agenten ist es eine frühe Voraussetzung: Die Einschränkungen sind es, die Geschwindigkeit ohne Verfall oder architektonischen Drift ermöglichen.

In der Praxis setzen wir diese Regeln mit benutzerdefinierten Lintern und strukturellen Tests sowie einer kleinen Anzahl von „Geschmacksinvarianten“ durch. Zum Beispiel erzwingen wir statisch strukturiertes Logging, Namenskonventionen für Schemas und Typen, Dateigrößenbeschränkungen und plattformspezifische Zuverlässigkeitsanforderungen mit benutzerdefinierten Lints. Da die Lints benutzerdefiniert sind, schreiben wir die Fehlermeldungen so, dass wir Anweisungen zur Behebung in den Agentenkontext einfügen können.

In einem menschenzentrierten Arbeitsablauf könnten diese Regeln pedantisch oder einschränkend wirken. Mit Agenten werden sie zu Multiplikatoren: Sobald sie kodiert sind, wirken sie überall gleichzeitig.

Gleichzeitig machen wir deutlich, wo Einschränkungen wichtig sind und wo nicht. Das ähnelt der Leitung einer großen Engineering-Plattform-Organisation: Grenzen zentral durchsetzen, Autonomie lokal gewähren. Dir sind Grenzen, Korrektheit und Reproduzierbarkeit zutiefst wichtig. Innerhalb dieser Grenzen erlaubst du Teams – oder Agenten – erhebliche Freiheit, wie Lösungen formuliert werden.

Der resultierende Code entspricht nicht immer den stilistischen Vorlieben von Menschen, und das ist in Ordnung. Solange die Ausgabe korrekt, wartbar und für zukünftige Agentenläufe gut lesbar ist, erfüllt sie die Anforderungen.

Der menschliche Geschmack wird kontinuierlich in das System zurückgeführt. Überprüfungskommentare, Refactoring-Pull-Requests und benutzerseitige Bugs werden als Dokumentationsaktualisierungen erfasst oder direkt in Tooling integriert. Wenn die Dokumentation nicht ausreicht, setzen wir die Regel in Code um.

Als der Durchsatz von Codex zunahm, wurden viele konventionelle Engineering-Normen kontraproduktiv.

Das Repository arbeitet mit minimal blockierenden Merge-Gates. Pull Requests sind kurzlebig. Test-Flakes werden oft mit Folge-Läufen behandelt, anstatt den Fortschritt auf unbestimmte Zeit zu blockieren. In einem System, in dem der Durchsatz von Agenten die menschliche Aufmerksamkeit bei Weitem übersteigt, sind Korrekturen günstig, während Warten teuer ist.

Dies wäre in einer Umgebung mit geringem Durchsatz unverantwortlich. Hier ist es oft der richtige Kompromiss.

Wenn wir sagen, dass die Codebasis von Codex-Agenten generiert wird, meinen wir damit die gesamte Codebasis.

Agenten erzeugen:

• Produktcode und Tests
• CI-Konfiguration und Release-Tooling
• Interne Entwicklertools
• Dokumentation und Designgeschichte
• Bewertungswerkzeuge
• Review-Kommentare und Antworten
• Skripte, die das Repository selbst verwalten
• Definitionsdateien für das Produktionsdashboard

Menschen bleiben immer im Prozess eingebunden, arbeiten jedoch auf einer anderen Abstraktionsebene als früher. Wir priorisieren die Arbeit, übersetzen Feedback von Nutzer:innen in Akzeptanzkriterien und validieren die Ergebnisse. Wenn der Agent Schwierigkeiten hat, betrachten wir das als Signal: Wir identifizieren, was fehlt – Tools, Schutzmechanismen, Dokumentation – und speisen es zurück in das Repository, indem Codex selbst die Korrektur schreibt.

Agenten verwenden unsere Standard-Entwicklungstools direkt. Sie holen sich Review-Feedback, antworten inline, pushen Updates und squashen und mergen oft ihre eigenen Pull Requests.

Da immer mehr der Entwicklungsschleife direkt im System kodiert wurde – Tests, Validierung, Überprüfung, Feedback-Verarbeitung und Wiederherstellung –, hat das Repository kürzlich eine bedeutende Schwelle überschritten, ab der Codex ein neues Feature End-to-End vorantreiben kann.

Mit einem einzigen Prompt kann der Agent jetzt:

• Den aktuellen Stand der Codebasis prüfen
• Einen gemeldeten Bug reproduzieren
• Ein Video aufnehmen, das den Fehler zeigt
• Eine Lösung implementieren
• Die Behebung durch Ausführung der Anwendung prüfen
• Ein zweites Video aufnehmen, das die Lösung zeigt
• Einen Pull Request öffnen
• Auf Agenten- und menschliches Feedback reagieren
• Build-Fehler erkennen und beheben
• Nur an einen Menschen eskalieren, wenn ein Urteil erforderlich ist
• Die Änderung zusammenführen

Dieses Verhalten hängt stark von der spezifischen Struktur und vom Tooling dieses Repositorys ab und sollte nicht als verallgemeinerbar angenommen werden, ohne eine ähnliche Investition – zumindest noch nicht.

Vollständige Agentenautonomie führt auch zu neuartigen Problemen. Codex repliziert Muster, die bereits im Repository existieren – auch ungleichmäßige oder suboptimale. Im Laufe der Zeit führt dies unweigerlich zu einem Drift.

Anfangs haben Menschen dies manuell adressiert. Unser Team hat früher jeden Freitag (20 % der Woche) damit verbracht, „KI-Schrott“ aufzuräumen. Wenig überraschend ließ sich das nicht skalieren.

Stattdessen haben wir begonnen, das, was wir „goldene Prinzipien“ nennen, direkt in das Repository zu kodieren und einen wiederkehrenden Bereinigungsprozess aufzubauen. Diese Prinzipien sind meinungsstarke, mechanische Regeln, die die Codebasis lesbar und konsistent für zukünftige Agenten-Ausführungen halten. Zum Beispiel: (1) Wir bevorzugen gemeinsam genutzte Utility-Pakete gegenüber selbst entwickelten Hilfsprogrammen, um Invarianten zentral zu halten, und (2) wir analysieren Daten nicht „YOLO-Style“ –wir validieren Grenzen oder verlassen uns auf typisierte SDKs, damit der Agent nicht versehentlich auf vermuteten Strukturen aufbaut. In regelmäßigen Abständen führen wir eine Reihe von Codex-Hintergrundaufgaben aus, die nach Abweichungen suchen, Qualitätsbewertungen aktualisieren und gezielte Refactoring-Pull-Requests öffnen. Die meisten davon lassen sich in weniger als einer Minute überprüfen und automatisch zusammenführen.

Das funktioniert wie eine Müllabfuhr. Technische Altlasten sind wie ein hochverzinslicher Kredit: Es ist fast immer besser, sie kontinuierlich in kleinen Schritten abzubauen, als sie sich aufstauen zu lassen und sie dann in schmerzhaften Schüben anzugehen. Der menschliche Geschmack wird einmal erfasst und dann kontinuierlich in jeder Codezeile durchgesetzt. Das ermöglicht uns auch, schlechte Muster täglich zu erkennen und zu beheben, anstatt sie sich über Tage oder Wochen in der Codebasis ausbreiten zu lassen.

Diese Strategie hat bisher bis zur internen Einführung und Akzeptanz bei OpenAI gut funktioniert. Ein echtes Produkt für echte Nutzer:innen zu entwickeln, half uns, unsere Investitionen in der Realität zu verankern und uns auf langfristige Wartbarkeit auszurichten.

Was wir noch nicht wissen, ist, wie sich die architektonische Kohärenz über Jahre hinweg in einem vollständig agentengenerierten System entwickelt. Wir lernen noch, wo menschliches Urteilsvermögen den größten Einfluss hat und wie wir dieses Urteilsvermögen so kodieren können, dass es sich vervielfacht. Wir wissen auch nicht, wie sich dieses System entwickeln wird, während die Modelle im Laufe der Zeit immer leistungsfähiger werden.

Was klar geworden ist: Software zu entwickeln erfordert weiterhin Disziplin, aber die Disziplin zeigt sich eher im Gerüst als im Code. Tooling, Abstraktionen und Feedback-Schleifen, die die Codebasis kohärent halten, werden immer wichtiger.

Unsere schwierigsten Herausforderungen bestehen jetzt darin, Umgebungen, Feedback-Schleifen und Kontrollsysteme zu entwerfen, die Agenten dabei unterstützen, unser Ziel zu erreichen: komplexe, zuverlässige Software in großem Maßstab zu entwickeln und zu warten.

Da Agenten wie Codex größere Teile des Software-Lebenszyklus übernehmen, werden diese Fragen noch wichtiger. Wir hoffen, dass das Teilen einiger früherer Erkenntnisse dir hilft, zu entscheiden, wo du deine Energie investieren solltest, damit du einfach Dinge bauen kannst.