Mitchell Hashimotos neue Art, Code zu schreiben

Wie Mitchell Hashimoto einen Agenten ständig am Laufen hält

Mitchell Hashimoto — Mitgründer von HashiCorp, Schöpfer von Terraform und aktuell am Aufbau von Ghostty — tritt Gergely Orosz in The Pragmatic Engineer bei und teilt eine durchdacht entwickelte Methodik für KI-gestützte Entwicklung. Das ist kein Hype oder schnelle Kommentare. Es ist ein Praktiker mit 20 Jahren Erfahrung, der beschreibt, wie er seinen täglichen Workflow grundlegend um KI-Agenten umstrukturiert hat.

Die Kernidee: “I endeavor to always have an agent doing something at all times. I want an agent if I’m coding, I want an agent planning. If they’re coding, I want to be reviewing. There should always be an agent doing something.” (Ich bemühe mich, immer einen Agenten laufen zu haben, der etwas tut. Ich möchte einen Agenten beim Programmieren, ich möchte, dass ein Agent plant. Wenn sie programmieren, möchte ich überprüfen. Es sollte immer einen Agenten geben, der etwas tut.)

Vor jedem Übergang — das Haus verlassen, irgendwohin fahren, den Tag beenden — verbringt Mitchell 30 Minuten damit zu überlegen: “Was ist eine zeitaufwendige Aufgabe, die mein Agent als Nächstes tun könnte?” Er gibt Agenten Recherche-Aufgaben, Bibliotheks-Bewertungen und Edge-Case-Analysen, die keine Echtzeit-Aufmerksamkeit benötigen. Entscheidend ist, dass er alle Agent-Benachrichtigungen ausschaltet: “Ich entscheide, wann ich den Agenten unterbreche. Er darf mich nicht unterbrechen.”

Darüber, was KI dir wirklich gibt: “It’s really allowed me to choose what I want to actually think about. I always felt limited — I’m going to have to spend the next two hours doing this boilerplate. But now I don’t have to learn about it.” (Es hat mir wirklich erlaubt zu wählen, worüber ich tatsächlich nachdenken möchte. Ich habe mich immer begrenzt gefühlt — ich werde die nächsten zwei Stunden damit verbringen, diesen Boilerplate zu schreiben. Aber jetzt muss ich das nicht lernen.) Es geht nicht darum, mehr Code zu schreiben. Es geht darum, kognitive Energie zu den Aufgaben umzuleiten, die zählen.

Harness Engineering: Die Compound-Quality-Strategie

Mitchells ursprünglichster Beitrag zur KI-Programmier-Diskussion ist Harness Engineering — sein Begriff für den Aufbau von Werkzeugen, die Agenten aufrufen können, um Wiederholungsfehler zu vermeiden.

Das Muster: Wenn ein Agent einen Fehler macht, anstatt ihn einfach zu korrigieren, baut man einen Test-Harness, ein Validierungsskript oder eine Linting-Regel, die der Agent zur Selbstprüfung aufrufen kann. Füge die Regel zu deiner CLAUDE.md oder agents.md Datei hinzu. Der Agent macht diesen spezifischen Fehler nie wieder.

Dies wächst im Laufe der Zeit. Jede Session verbessert den Harness. Jede Harness-Verbesserung macht nachfolgende Agent-Sessions zuverlässiger. Mitchell nennt dies eines seiner Schlüsselziele für 2026 und betrachtet es als die kritische Infrastruktur-Investition für Teams, die KI-Agenten nutzen.

Die erweiterte Test-Anforderung: KI ist “zielorientiert” — sie wird Dinge außerhalb ihres aktuellen Task-Umfangs beschädigen, um ihr unmittelbares Ziel zu erreichen. Das bedeutet, dass Test-Abdeckung viel umfassender sein muss als das, was für reine menschliche Entwicklung ausreichte. Jeden AI-Fehler sollte eine Harness-Verbesserung zur Folge haben, nicht nur ein Fix.

Kontext-abhängige Qualität: Von Null-Review bis zu jeder Zeile

Mitchell wendet völlig unterschiedliche Qualitätsstandards an, je nach Projekt:

• Ghostty (Open-Source-Terminal, langfristig): Überprüft jede Zeile von KI-generiertem Code. Performance auf 9 Mikrosekunden pro Frame ist wichtig.
• Wegwerf-Projekte (Familie Hochzeitswebsite): Null Code-Review. “Hat es richtig in drei Browsern gerendert? Veröffentlich es. Es ist nur 2 Monate online.”

Diese Pragmatik erstreckt sich auf kompetitive Agent-Durchläufe. Für schwierige Aufgaben, bei denen das Vertrauen niedrig ist, führt er zwei Agenten parallel aus — Claude Code gegen Codex — und wählt das bessere Ergebnis. Er beschreibt sich selbst als “der Bürgermeister”, der höchstens zwei Agenten gleichzeitig verwaltet.

Warum Git möglicherweise das agentic-Zeitalter nicht überstehen wird

Die provokativste Vorhersage: “This is the first time in like 12 to 15 years that anyone is even asking that question — will Git be around? — without laughing.” (Das ist das erste Mal in etwa 12 bis 15 Jahren, dass jemand diese Frage stellt — wird Git noch da sein? — ohne zu lachen.)

Mitchell argumentiert, dass Git und GitHub Forges “nicht mit agentic-Infrastruktur heute funktionieren.” Wenn der Agent-Durchsatz 10-100x höher ist als der menschliche, werden Merge-Queues unmöglich, der Speicherplatz explodiert, und menschliche Reviewer können nicht Schritt halten. Er rät einem Unternehmen, das speziell an diesem Problem arbeitet.

Seine Vision für die Zukunft der Versionskontrolle: viel mehr Branches, fehlgeschlagene Experimente und History behalten — nie löschen. Das ist der “Gmail-Moment für Versionskontrolle.” Aber es erfordert grundlegend bessere Werkzeuge, um relevante Kontexte in massiven Repositories zu finden.

KI-generierte Open-Source-Beiträge zerstören das Signal

Ghostty erhält täglich 2-3 minderwertige KI-generierte PRs. Mitchell schließt sie jetzt, ohne sie zu lesen, wenn sie keine zugehörige Issue-Nummer haben. “AI makes it trivial to create plausible looking but incorrect and low-quality contributions. Open source has always been a system of trust. Before we had default trust. Now it’s default deny.” (KI macht es trivial, plausibel aussehende aber falsche und minderwertige Beiträge zu erstellen. Open Source war schon immer ein Vertrauenssystem. Vorher hatten wir Standard-Vertrauen. Jetzt ist es Standard-Ablehnung.)

Er wünscht sich, dass agentic-Tools “eine Pause beim Öffnen von PRs einlegen” — die Reibung, die sie für Maintainer verursachen, überwiegt den Komfort für Contributors. Er identifiziert sogar Claudes Erkennungsmerkmal: Öffnung eines Draft-PR ohne Body, Bearbeitung des Body, dann Neuöffnung — ein Muster, das kein Mensch befolgt.

6 Prinzipien aus Mitchells KI-Workflow

• Immer einen Agenten laufen lassen — Nutze Übergänge (fahren, Pausen, Tagesende), um langsame Agent-Aufgaben einzureihen. Agenten sollten während der Arbeitszeit nie idle sein
• Planung und Ausführung trennen — Ein dedicated Planungsschritt vor Agent-Programmierung verbessert die Output-Qualität dramatisch
• Harnesses bauen, nicht nur Fixes — Jeden Agent-Fehler sollte Werkzeug zur Folge haben, das Wiederholung verhindert, nicht nur eine Korrektur
• Wähle, worüber du nachdenkst — Der Wert von KI ist nicht mehr Code pro Stunde, sondern kognitive Energie auf Architektur, Design und Benutzerbedürfnisse umzuleiten
• Kontext-abhängige Review-Rigorosität — Production-Code bekommt jede-Zeile-Review; Wegwerf-Prototypen bekommen Null-Review. Passe Effort an Stakes an
• In die Lernkurve investieren — “Es ist, als ob jemand Git für eine Stunde versucht und entschieden hätte, dass es nicht produktiv ist. Es braucht sustained effort, um proficient zu werden”

Was das für Engineering-Organisationen bedeutet

Mitchell rahmt den Wert von KI nicht als rohe Produktivitätsgewinne ein, sondern als erweiterte Kapazität zum Experimentieren. Proof of Concepts, die eine Woche dauerten, können jetzt in einem Tag gemacht werden. Aber er ist bemerkenswert vorsichtig: “I hesitate to say more productive. There’s an expectation they could do more. You should be able to build a full demo, design, everything — you don’t need a team to do that anymore.” (Ich zögere zu sagen, produktiver. Es gibt eine Erwartung, dass sie mehr tun könnten. Du solltest einen vollständigen Demo, Design, alles bauen können — du brauchst kein Team dafür mehr.)

Für Organisationen sind die Auswirkungen konkret: Verlangt KI-Tool-Kompetenz beim Einstellen, behandelt Agent-Konfigurationsdateien (CLAUDE.md) als First-Class-Infrastruktur, investiert in Harness Engineering, und akzeptiert, dass CI/CD-Pipelines grundlegende Überprüfungen brauchen, um die erweiterte Testing zu bewältigen, die KI-generierter Code erfordert. Alles in der Engineering-Infrastruktur — Editoren, Forges, CI/CD, Testing, Observability, Sandboxing — liegt auf dem Tisch für Veränderung. Wie Mitchell es ausdrückt: “Das ist das erste Mal in meiner 20-jährigen Profikarriere, dass so viel auf dem Tisch für Veränderung auf einmal liegt.”