Meine Reise zur Einführung von AI

• Mitchell Hashimoto, der nach seinem Exit bei HashiCorp an Ghostty arbeitet, beschreibt den Prozess, wie er AI-Tools in seine tatsächliche Arbeit integriert hat
• Er unterteilt den Weg in drei Phasen: Ineffizienz → Anpassung → Produktivitätssteigerung, und dokumentiert die Irrtümer und Lernprozesse in jeder Phase konkret
• Nachdem er die Grenzen des chatbot-basierten Codings erkannt hatte, entdeckte er den eigentlichen Nutzen beim Wechsel zu agentenbasierten Tools
• Durch das Training, zuvor manuell abgeschlossene Commits mit einem Agenten nachzubilden, erkannte er, dass Aufgabenzerlegung, die Trennung von Planung und Ausführung sowie automatische Verifikation entscheidend sind
• Indem er die letzten 30 Minuten des Arbeitstags für nächtliche automatisierte Aufgaben nutzt und einfache, wiederholbare Arbeit an Agenten delegiert, erzielt er eine reale Produktivitätssteigerung
• Derzeit befindet er sich in einer Phase, in der immer ein Agent läuft, kombiniert mit „Harness Engineering“ zur Fehlervermeidung, um die Effizienz der Zusammenarbeit zwischen AI und Mensch zu maximieren

---

Hintergrund der Einführung und Vorgehensweise

• Bei der Einführung neuer Tools müsse man immer drei Phasen durchlaufen: Ineffizienz → Anpassung → Innovation
  • Da man an bestehende Workflows gewöhnt ist, ist die anfängliche Einführung unbequem, führt aber langfristig zu höherer Produktivität
• Statt überzogener Erwartungen oder Kritik an AI-Tools vermittelt er eine ausgewogene Perspektive auf Basis realer Nutzungserfahrungen

Schritt 1: Weg vom Chatbot

• Coding über Chatbot-Interfaces wie ChatGPT oder Gemini stützt sich auf Vorwissen, und da die Fehlerkorrektur von wiederholtem menschlichem Feedback abhängt, ist es ineffizient
• Ein Screenshot der Command Palette von Zed, den er in Gemini eingefügt und in SwiftUI nachgebaut bekam, war sein erster „Wow-Moment“ und wurde zur Grundlage der macOS-Command-Palette von Ghostty
• Im Kontext von Brownfield-Projekten (bestehende Codebasen) erzeugten Chatbots jedoch häufig schlechte Ergebnisse, und das Kopieren und Einfügen von Code und Ausgaben war ineffizienter, als die Arbeit direkt selbst zu erledigen
• Um echten Nutzen zu erzielen, müsse man unbedingt Agenten einsetzen; Agenten sind Tools, bei denen ein LLM wiederholt externe Aktionen aufrufen kann und dafür mindestens Dateien lesen, Programme ausführen und HTTP-Anfragen stellen können muss

Schritt 2: Die eigene Arbeit mit einem Agenten nachbilden

• Als er Claude Code zum ersten Mal nutzte, war er mit den Ergebnissen unzufrieden, und die Nacharbeit dauerte länger, als es selbst zu tun
• Statt aufzugeben, wiederholte er ein Training, bei dem er manuelle Commits mit einem Agenten identisch reproduzieren ließ
  • Es war ein schmerzhafter Prozess, dieselbe Arbeit zweimal zu machen (manuell + Agent), aber Reibung bei der Einführung neuer Werkzeuge ist natürlich
• Dabei entdeckte er drei zentrale Prinzipien:
  • Sitzungen in klare, ausführbare Teilaufgaben zerlegen
  • Bei unklaren Anforderungen Planungssitzung und Ausführungssitzung trennen
  • Dem Agenten Möglichkeiten zur Verifikation der Arbeit geben, damit er Fehler selbst korrigieren und Regressionen vermeiden kann
• Auch zu wissen, wann man Agenten nicht einsetzen sollte, indem man ihre Schwächen versteht, war ein großer Effizienzgewinn
• In dieser Phase spürte er zwar noch keine Netto-Effizienzsteigerung, akzeptierte den Agenten aber zufrieden als Werkzeug

Schritt 3: Agenten zum Tagesabschluss einsetzen

• Er führte ein Muster ein, jeden Tag die letzten 30 Minuten für das Starten von Agentenarbeit zu reservieren
  • Die Hypothese: Wenn Agenten außerhalb der eigenen Arbeitszeit Fortschritt machen, entsteht Effizienzgewinn
• Drei Arten von Aufgaben erwiesen sich als effektiv:
  • Deep-Research-Sessions: Untersuchung einer bestimmten lizenzierten Bibliothek in einer bestimmten Sprache, mit Zusammenfassungen über Vor- und Nachteile, Entwicklungsaktivität und Reaktionen der Community über mehrere Seiten hinweg
  • Erkundung vager Ideen mit parallelen Agenten: nicht für einen Release, sondern um für die Arbeit am nächsten Tag unbekannte Variablen aufzudecken
  • Klassifizierung und Review von Issues und PRs: mit gh (GitHub CLI) führt er Issue-Triage durch parallele Agenten aus; die Agenten antworten nicht direkt, sondern erzeugen nur einen Bericht zur Durchsicht am nächsten Tag
• Er ließ Agenten nicht die ganze Nacht in Schleifen laufen; die meisten Aufgaben waren innerhalb von 30 Minuten abgeschlossen
• Indem er die ermüdende Zeit am Ende des Tages in Agentenarbeit umwandelte, sicherte er sich am nächsten Morgen einen „Warm-Start“-Effekt

Schritt 4: Verlässliche Delegation von Aufgaben

• Nachdem er Aufgaben identifiziert hatte, die Agenten mit hoher Wahrscheinlichkeit gut erledigen, delegiert er diese an Background-Agenten und konzentriert sich selbst auf andere Arbeit
• Jeden Morgen filtert er die Triage-Ergebnisse der vorherigen Nacht manuell und wählt Issues aus, die sich für Agenten eignen, die dann jeweils einzeln ausgeführt werden
• In dieser Zeit arbeitet er selbst direkt an tiefem Denken auf die frühere, nicht-AI-gestützte Weise, statt in sozialen Medien oder Videos zu versinken
• Entscheidend ist es, Desktop-Benachrichtigungen des Agenten auszuschalten: Da Context Switching teuer ist, ist es effizienter, wenn nicht der Agent den Menschen unterbricht, sondern dieser bei natürlichen Pausen nachsieht
• Als Reaktion auf Anthropics Forschungspaper zur Skill-Bildung: Auf Skill-Bildung bei an Agenten delegierten Aufgaben verzichtet er, aber bei Arbeiten, die er weiterhin manuell erledigt, setzt sich Skill-Bildung natürlich fort
• In dieser Phase erreichte er ein Niveau, „von dem es kein Zurück mehr gibt“; der größte Vorteil ist, dass er sich auf die Arbeit konzentrieren kann, die ihm Spaß macht

Schritt 5: Harness Engineering

• Am effizientesten sind Agenten dann, wenn sie beim ersten Versuch das richtige Ergebnis liefern oder nur minimale Korrekturen benötigen
• Jedes Mal, wenn ein Agent einen Fehler macht, eine Lösung so zu konstruieren, dass derselbe Fehler nie wieder passiert, ist das Konzept des „Harness Engineering“
• Es gibt zwei Formen:
  • Implizite Verbesserungen des Promptings (AGENTS.md): Wenn ein Agent falsche Befehle ausführt oder die falsche API findet, wird das in der Datei AGENTS.md festgehalten, um das Problem zu lösen — im Ghostty-Repository gibt es reale Beispiele
  • Programmgesteuerte Tools: Skripte für Screenshot-Erfassung, gefilterte Testläufe usw. schreiben und in AGENTS.md auf die Existenz dieser Tools hinweisen
• Er befindet sich derzeit in dieser Phase und investiert aktiv in die Vermeidung schlechten Agentenverhaltens sowie in die Verifikation guten Verhaltens

Schritt 6: Immer einen Agenten laufen lassen

• Parallel zu Schritt 5 setzt er sich das Ziel, immer einen Agenten im Hintergrund laufen zu haben
• Er bevorzugt langsame Modelle, die wie der deep mode von Amp (auf Basis von GPT-5.2-Codex) länger als 30 Minuten brauchen, aber hochwertige Ergebnisse liefern
• Derzeit lässt er nicht mehrere Agenten parallel laufen und hält die Balance zwischen einem Agenten und manueller Arbeit für passend
• Tatsächlich läuft nur während etwa 10–20 % der Arbeitszeit ein Background-Agent, und er arbeitet daran, diesen Anteil zu erhöhen
• Das Ausführen eines Agenten ist nicht das Ziel an sich; er sollte nur dann laufen, wenn es wirklich hilfreiche Aufgaben gibt, und hochwertige delegierbare Workflows zu schaffen, ist auch unabhängig von AI wichtig

Aktueller Stand und Perspektive

• Er erzielt mit AI-Tools Ergebnisse und verfolgt dabei einen realitätsbasierten, ausgewogenen Blick
• Er arbeitet nicht für ein AI-Unternehmen, investiert nicht in eines und berät keines; unabhängig davon, ob AI bleibt oder verschwindet, ist seine Kernmotivation die Freude am Bauen als Software-Handwerker
• Hinsichtlich der Skill-Bildungsprobleme bei Junior-Entwicklern mit schwachen Grundlagen ist er tief besorgt
• Da sich Modelle sehr schnell weiterentwickeln, müsse die Einschätzung dessen, was Agenten nicht können, fortlaufend neu überprüft werden
• Ob man AI nutzt oder nicht, ist eine persönliche Entscheidung; dieser Text dient dem persönlichen Teilen eines Beispiels dafür, wie man Werkzeuge erkundet und einsetzt

[GN⁺]

Hacker-News-Kommentare

• Der Schlüssel ist, Sessions in klare und umsetzbare Arbeitseinheiten zu zerlegen
  Wenn man zu detaillierte Anweisungen gibt, gibt es keinen Grund, ein LLM zu verwenden; ist die Anfrage umgekehrt zu breit wie „Bau mir eine Facebook-App für Hunde“, kommt nur ein nutzloser Prototyp heraus
  Letztlich besteht erfolgreiche Nutzung von Code-LLMs darin, genau diesen passenden Umfang zu finden

  • Der Teil, der mir bei AI-Tools am meisten Spaß macht, ist genau diese Intuitionsbildung
    Ein Gefühl dafür zu entwickeln, welche Aufgaben gute Ergebnisse liefern, und den Umfang daran anzupassen, macht ähnlich Spaß wie die Modularisierung beim Programmieren
  • Ich bin mit zu großen Anfragen wie dem Beispiel „Facebook for dogs“ gescheitert
    Bei Lovable wirkte schon das Onboarding so, als würde es Fehlschläge provozieren, während es mit Claude Code viel erfolgreicher war, klein aufzuteilen und schrittweise vorzugehen
  • Wenn man ein LLM nur dafür nutzt, Beispiele für for-Syntax zu finden, ist das praktisch, weil es Kontextwechsel reduziert
    Anfangs habe ich es oft einfach als Hilfe beim Schreiben einfacher Codes genutzt
  • Je besser die Modelle werden, desto mehr steigt gefühlt alle 6–8 Wochen die obere Grenze dieses passenden Umfangs
  • Manchmal habe ich gesagt „Gib die Ausgabe aus“, und die Reaktion war wirklich nur, print(output) hinzuzufügen
    Zwischen natürlicher Sprache und Code hin- und herzuarbeiten fühlt sich sogar psychologisch angenehmer an

• 2025 war das Jahr, in dem AI-Coding-Tools wirklich in die praktische Phase eingetreten sind
  Frühe Modelle wie GPT-3 haben früher nur Potenzial angedeutet, was übertriebenen Hype und Skepsis erzeugt hat
  Jetzt integrieren jedoch viele Entwickler AI tatsächlich in ihre Workflows
  Wer noch skeptisch ist, sollte Mitchells Artikel lesen und Claude Code selbst ausprobieren

  • Ich sehe das genauso. Ich frage mich, an welchen Zeitpunkt wir uns in zehn Jahren als Wendepunkt erinnern werden
    Früher war oft von „Datenlimits“ die Rede, aber mit Claude Code, Sonnet 4.5 und Opus 4.5 hat sich die Stimmung komplett gedreht
  • Ich frage mich, ob es einen Grund gibt, Claude Code statt Codex oder Gemini zu verwenden
    Die beiden Modelle wirkten ähnlich, aber wegen Berichten, dass bei Claude die Nutzungslimits im Tarif schnell aufgebraucht sind, habe ich es noch nicht ausprobiert
  • Trotzdem mache ich mir weiterhin Sorgen über eine hypegetriebene Branchenstruktur
    Ich fürchte, dass Führungskräfte nur auf Tempo und Menge schauen und dabei Berge von unwartbarem Code produzieren

• Der Ansatz „Don’t draw the owl“ deckt sich auch mit meinen Erfahrungen
  Das Problem war, dass LLMs immer stärker von realen Einschränkungen wegdriften
  Deshalb habe ich Chat für Architektur- und Designgespräche getrennt und Agenten nur mit engen, überprüfbaren Diff-Aufgaben betraut
  Als dieser Loop stabil wurde, war es kein Spielzeug mehr, sondern ein echter Hebel, und ich habe damit mehrfach Features in echten Projekten ausgeliefert

  • Ich habe den Hinweis bekommen, dass der Stil des Artikels wie ein LLM klingt
    Es ist interessant, dass solche schematischen Satzstrukturen inzwischen auch unter Menschen zunehmen
  • Man denkt dabei auch, dass dieser Ansatz im Grunde nicht anders ist als die Art, wie wir schon immer Software hätten entwickeln sollen

• Es wird viel über Opus 4.5 gesprochen, also habe ich es selbst ausprobiert und dabei gespürt, dass das Agenten-Paradigma tatsächlich deutlich nützlicher geworden ist
  Noch nutze ich es vor allem für einfache Aufgaben, bin aber zufrieden damit

• LLMs passen nicht zu mir
  Denkvermögen und Kreativität sind das, was uns Menschen ausmacht, und wenn man das an Maschinen abgibt, schwächt man sich selbst, finde ich
  Als Rails-Entwickler habe ich Zed sowie Claude Sonnet 4.x und Opus verwendet, aber ich habe deutlich gemerkt, dass meine Fähigkeit, RSpec zu schreiben, nachlässt
  Am Ende bin ich zu neovim zurückgekehrt und arbeite ohne Agenten
  Bequemlichkeit kann am Ende zu einer Verkümmerung des Denkens führen
  LLMs sind das beste Bequemlichkeitswerkzeug, das Menschen je gebaut haben, aber ich entscheide mich dafür, meine Fähigkeiten und mein Denken zu erhalten

• Dieser Artikel wirkt viel praktischer und weniger überzogen als andere Frontpage-Beiträge

  • Endlich gibt es eine Schritt-für-Schritt-Anleitung, der auch Skeptiker folgen können
    Statt Übertreibungen wie „Ich habe per Vibe Coding ein OS gebaut“ ist das hier ein realistischer Ansatz

• Es ist interessant, dass alle eine ähnliche AI-Nutzungsreise durchlaufen
  Man verwendet mehrere Modelle parallel auf verschiedene Teile der Codebasis und lässt die Modelle sich gegenseitig validieren
  Ich mache zwar immer noch oft git reset, lerne aber allmählich bessere Wege, das zu vermeiden
  Es fühlt sich an, als lebten wir im Zeitalter der Autovervollständigung fürs Gehirn

• Jemand sagte, „ein Agent muss Dateien lesen, Programme ausführen und HTTP-Anfragen stellen können“,
  und das ist fast dasselbe wie Simon Willisons „tödliche Triade“

  • Deshalb habe ich nicht vor, so etwas jemals auf meiner lokalen Maschine laufen zu lassen

• Es ist nervig, einem Agenten ständig Verbesserungspunkte mitteilen zu müssen
  Jedes Mal muss man agent.md anpassen und Feedback eintragen; es wäre schön, wenn er selbst lernen und sich verbessern würde

  • Aber was für den einen eine Verbesserung ist, kann für jemand anderen ein Code Smell sein
    Ein paar Zeilen in AGENTS.md hinzuzufügen, ist keine große Sache
    Wenn man einen /fix-Befehl erstellt, der automatisch korrigiert und dokumentiert, spart das ziemlich viel Zeit
  • Ich gebe dagegen sogar gern Feedback
    Es gibt mir das Gefühl, dass ich die Kontrolle über das Engineering habe
    Besonders gefällt mir, dass man Recherche zu neuen Features und ihre Umsetzung schnell iterieren kann

• Wer sehen will, wie so ein Ansatz in der Praxis aussieht,
  sollte sich den früheren Blogbeitrag des OP „Non-trivial Vibing“ und die dazugehörige HN-Diskussion ansehen