- Der gesamte Entwicklungsprozess der nicht störenden automatischen Update-Benachrichtigung von Ghostty unter macOS wurde offengelegt. Die Funktion wurde überwiegend mit AI-Agentic-Coding-Tools entwickelt und in 16 Sessions mit Token-Kosten von 15,98 US-Dollar in etwa 8 Stunden zu einem tatsächlich releasefähigen Feature fertiggestellt.
- Auslöser für die Umstellung war ein Vorfall während einer OpenAI-Keynote, bei dem ein Ghostty-Update-Prompt die Demo störte. Deshalb fiel die Entscheidung für einen nicht-modalen Ansatz, der den Update-Status über ein kleines GUI-Element in der Titelleiste oder am unteren Fensterrand anzeigt, ohne die Arbeit zu unterbrechen.
- Noch vor dem Einsatz von AI wurde zunächst ein grober Backend-/Frontend-Plan erarbeitet, unter Nutzung des Custom-UI-Protokolls des Sparkle-Frameworks und von Titlebar-Accessory-Controllern; die AI diente anschließend als Prototyping-Werkzeug.
- Zum Einsatz kam ein schrittweiser Ansatz mit UI-Prototyping, Kurswechseln bei erfolgloser Fehlersuche und wiederholten Cleanup-Sessions (Dokumentation, Refactoring), um die Leistung künftiger AI-Sessions zu verbessern und etwa Simulationscode zu erzeugen.
- Hervorgehoben wird der Wert einer asynchronen Arbeitsweise, bei der man während der Arbeit der AI andere Dinge wie das Vorbereiten des Familienfrühstücks erledigen kann; zugleich galt die Regel, sämtlichen AI-generierten Code vor dem Release gründlich manuell zu prüfen und keinen Code auszuliefern, den man nicht versteht.
Funktionsüberblick
- Das fertige Feature ist eine nicht störende Update-Benachrichtigung unter macOS
- Der Update-Status wird innerhalb des Terminalfensters angezeigt, ohne die Arbeit zu stören, etwa durch das Erzeugen eines Fensters oder das Übernehmen des Fokus.
- Der Bedarf an einer besseren UX wurde durch den Vorfall deutlich, bei dem während einer OpenAI-Keynote ein Ghostty-Update-Prompt erschien.
- Es wurde entschieden, die Update-Benachrichtigung nicht invasiv zu gestalten.
- Statt eines Popup-Fensters sollte irgendwo ein kleines nicht-modales GUI-Element erscheinen, das den Nutzer nicht unterbricht.
- Standardmäßig sollte die Benachrichtigung rechts in der Titelleiste erscheinen; je nach Stil, etwa bei ausgeblendeter Titelleiste, sollten Alternativen wie ein Overlay am unteren Fensterrand bereitstehen.
- Im gesamten Entwicklungsprozess wurden AI-Agenten eingesetzt, kombiniert mit einer Strategie als menschengeführtes Hilfswerkzeug, bei der manuelle Korrekturen, Feinschliff und finales Review direkt durchgeführt werden.
Planung vor dem AI-Einsatz
- Noch bevor AI-Tools gestartet wurden, wurde zunächst ein grober Plan erstellt.
- Nachdem eine grobe Idee für das Backend vorlag, wurde das Frontend konzipiert.
- Es gab die vage Idee, einen kleinen Button in die Titelleiste einzubetten.
- Zwar war bekannt, dass macOS über Titlebar-Accessory-Controller Custom UI in der Titelleiste unterstützt, doch das konkrete Erscheinungsbild und Bediengefühl waren noch unklar.
- Mit einem ausreichenden Ausgangspunkt konnte begonnen werden.
- AI ist ein sehr guter Prototyper, daher reicht es zum Start oft schon, zu wissen, was man noch nicht weiß.
- Es gab bereits ein ausreichend starkes Gespür für das große Ganze.
Erste Session: UI-Prototyping
- Der Start-Prompt der ersten Agentic-Coding-Session
SPUUserDriver anpassen, um eine nicht invasive Update-Benachrichtigung und die Aktivierung der Installation anzufordern- Die Arbeit auf UI-Aufgaben beschränken
- Einen Plan für SwiftUI-Views anfordern, die die verschiedenen von
SPUUserDriver benötigten Zustände darstellen können
- Einen Plan anfordern, diese rechts oben in der Titelleiste eines macOS-Fensters anzuzeigen
- Was ist Oracle? – ein schreibgeschützter Sub-Agent speziell für Amp, der ein langsameres und teureres Modell verwendet und im Allgemeinen besser im Denken ist
- Es wurde entschieden, sich zuerst auf den UI-Prototyp zu konzentrieren.
- Der Agent wurde nicht einfach beauftragt, die komplette Funktion zu bauen.
- Erstens war noch unklar, wie UI/UX überhaupt aussehen sollte, sodass man von der AI nicht konsistent erwarten konnte, dies neben anderen Änderungen sauber umzusetzen.
- Zweitens sind kleinere Arbeitspakete leichter zu prüfen, zu verstehen und iterativ weiterzuentwickeln.
- Es wurde darum gebeten, zunächst nur einen Plan zu schreiben und keinen Code.
- Da die Anfrage relativ vage war, war es wichtig, den Plan zu prüfen, bevor viel Arbeit geleistet und viele Tokens verbraucht werden.
- Tipp: Einen umfassenden Plan interaktiv mit einem Agenten zu erarbeiten, ist ein wichtiger erster Schritt bei nicht trivialen Aufgaben.
- In der Regel kann man so etwas in einer Datei wie
spec.md speichern und in späteren Sessions etwa anfragen: „Beziehe dich auf @spec.md und führe eine bestimmte Aufgabe aus“.
- Der Agent legte einen hinreichend überzeugenden Plan vor, woraufhin die Umsetzung freigegeben wurde.
- Die erzeugte UI ging stark in die richtige Richtung.
- Es gab viele Feinschliff-Probleme wie Abstände oder Farben, aber beim Anblick der UI sprang der Funke der Inspiration über, wie das Gewünschte aussehen könnte.
- Tipp: AI wird sehr häufig gezielt zur Inspiration eingesetzt. In diesem Fall blieb ein großer Teil des erzeugten UI-Codes erhalten, aber es kommt ebenso oft vor, dass man dem Agenten einen Prompt gibt, alles verwirft und anschließend manuell neu aufsetzt.
- Die kreative „Zero-to-One“-Phase ist sehr schwierig und zeitaufwendig, und AI eignet sich hervorragend als Muse.
Auf ein Hindernis gestoßen
- In den Chats 11 bis 14 wurde die Slop-Zone erreicht.
- Der vom Agenten erzeugte Code hatte gravierende Bugs, und die Versuche, sie zu beheben, scheiterten vollständig.
- Auch ich wusste nicht, wie sich das Problem lösen ließ.
- Es gab mehrere Hail-Mary-Versuche zur Bugbehebung.
- Wenn der Agent das Problem löst, kann man den Ansatz untersuchen und daraus lernen.
- Wenn es scheitert, entstehen kaum Kosten.
- Falls der Agent es zwar löst, man die Lösung aber nicht versteht, wird sie zurückgerollt; Code, den man nicht versteht, wird nicht ausgeliefert.
- Während die Fehlversuche liefen, wurde in andere Tabs gewechselt, um das Problem zu recherchieren und selbst zu lösen.
- An diesem Punkt wurde erkannt, dass man einen Schritt zurücktreten, die bisherige Arbeit prüfen und einen eigenen Plan aufstellen musste.
- Zeit, sich selbst weiterzubilden und kritisch zu denken.
- AI war nicht länger die Lösung, sondern eine Belastung.
Cleanup-Sessions
- Die nächsten Sessions wurden darauf verwendet, den Agenten beim Aufräumen des Codes anzuleiten.
- Zweite Session: Einige Methoden an einen besseren Ort verschieben
- Funktionen für Hintergrundfüllung, Vordergrund und Badge wurden aus
UpdateAccessoryView.swift nach UpdateViewModel.swift verschoben und allgemeiner gefasst.
- Dritte Session: Dokumentation zum Code hinzufügen
- Die Dokumentation von
UpdateBadge.swift wurde aktualisiert.
- Tipp: Das Ergänzen von Dokumentation bestätigt das eigene Verständnis des Codes erneut und hilft dabei, künftige Agenten zu schulen, die diesen Code lesen und ändern sollen.
- Agenten arbeiten deutlich besser, wenn sie sowohl natürlichsprachige Erklärungen als auch Code vorliegen haben.
- Vierte Session: Das ViewModel an einen app-weiten Ort verschieben
- Ursprünglich war die Arbeit im Fenster-Scope angesiedelt, aber Update-Informationen gehören auf App-Ebene.
- In diesem Zuge wurden typischerweise auch kleinere manuelle Änderungen vorgenommen.
- Die Bedeutung der Cleanup-Phase
- Um effektiv aufzuräumen, braucht man ein ziemlich gutes Verständnis des Codes, was verhindert, dass AI-generierter Code blind übernommen wird.
- Besser strukturierter und dokumentierter Code verbessert die Leistung künftiger Agentic-Sessions.
- Das wurde scherzhaft als „Anti-Slop-Session“ bezeichnet.
Auf Bugs stoßen
- Zeit, zu dem in frühen Sessions entdeckten Bug zurückzukehren
- Noch einmal einige Sessions darauf verwendet, damit der Agent das Problem versteht
- Vage begonnen und den Ansatz schrittweise immer konkreter gemacht
- Erste vage Session: Bei standardmäßigen nativen Tabs ist die Update-Accessory-View nicht sichtbar; sie sollte dauerhaft in der Titelleiste sichtbar bleiben – gescheitert
- Zweite konkretere Session: Constraints der Tab-Leiste in TerminalTabsTitlebarTahoe.swift aktualisieren, sodass der rechte Rand der Tab-Leiste am linken Rand der Update-Accessory-View ausgerichtet wird – gescheitert
- Dritter Versuch mit einem anderen konkreten Ansatz: TitlebarTabsTahoeTerminalWindow.swift ändern, damit die Tab-Leiste zur oberen statt zur unteren Accessory-View wird, um die Tabs in die Titelleiste zu setzen – gescheitert
- Letzter Versuch: Rechtes Accessory-View und Layout kollidieren mit der Konfiguration der Update-Accessory-View in TerminalWindow.swift; kann man erzwingen, dass die Tab-Leiste immer links von der Update-Benachrichtigung erscheint – gescheitert
- Während dieses gesamten Prozesses auch versucht, das Problem durch manuelle Recherche und eigene Arbeit selbst zu lösen
- Die konkreteren Prompts basierten auf dem, was dabei gelernt wurde
- Insgesamt funktionierte es klar erkennbar nicht
- Zu dem Schluss gekommen, dass es allein nicht lösbar ist, und deshalb den Kurs gewechselt
- Für den problematischen Titelleistenstil die Update-Benachrichtigung nicht in der Titelleiste, sondern in der unteren rechten Ecke über der Content-View des Fensters platzieren
- Ghostty hat eine Konfiguration, mit der die Titelleiste vollständig ausgeblendet werden kann, daher musste das ohnehin unterstützt werden
- Selbst wenn das Problem mit dem Titelleistenstil später gelöst werden könnte, müsste dieser andere Modus weiterhin unterstützt werden
- Nächste Session mit diesem Plan fortgesetzt und einen sehr konkreten Prompt verwendet
- Das Update-System erweitert, damit auch in TerminalView.swift ein Overlay-Ansatz unterstützt wird
- Die Update-Benachrichtigung sollte am unteren Fensterrand erscheinen und über dem Text angezeigt werden (also keine Größenänderung der Terminal-View)
- Alle Klick-Aktionen identisch zur Accessory-View
- Wirklich sehr gut umgesetzt; später noch viel manuelle Feinarbeit bei Richtlinienfragen gemacht (Verschieben, Umbenennen usw.), aber die Kernarbeit war solide
Backend starten
- Das UI fühlte sich gut genug an
- Ich habe viele Richtlinienprobleme notiert, die ich später angehen wollte, wollte aber zunächst zur Backend-Arbeit übergehen, um unbekannte Unbekannte zu entdecken, die den Plan noch durchkreuzen könnten
- Manuell eine Scaffold-Datei mit unvollständigen Funktionen und verschiedenen
TODO-Kommentaren erstellt. Neue Session gestartet
- Darum gebeten, UpdateDriver.swift zu vervollständigen und die Sparkle-Dokumentation zu lesen, um die Funktion zu verstehen
- Tipp: KI ist sehr gut darin, Lücken zu füllen oder den Rest der Eule zu zeichnen
- Dieses Muster, Scaffolding mit beschreibenden Funktionsnamen, Parametern, Todo-Kommentaren usw. zu erstellen, ist sehr verbreitet und funktioniert gut
- In Wirklichkeit eine sehr schlechte Arbeit geleistet und diesen Code komplett verworfen
- Der erzeugte Code funktionierte, war aber offensichtlich der falsche Ansatz
- Er vermischte viele unterschiedliche Verantwortlichkeiten, und die Art, wie Zustand im Driver gespeichert wurde, war klar falsch
- Als ich untersucht habe, was erstellt worden war, wurde klar, dass das View-Model auf eine nicht optimale Weise strukturiert war
- Deshalb in einen Cleanup-Modus gewechselt, um der KI (und auch einem Menschen, falls man sich für manuelles Schreiben entscheidet) ein besseres Framework zu geben
Großer Re-Cleanup
- Meiner Erfahrung nach wird die Sauberkeit von UI-Frontend und Business-Logic-Backend oft von der Qualität des View-Models dazwischen bestimmt
- Zeit darauf verwendet, das View-Model manuell umzustrukturieren
- Von einer Struct mit vielen Optionals auf eine Tagged Union umgestellt, einige Typnamen geändert und Dinge verschoben
- Aus Erfahrung wusste ich, dass diese kleine manuelle Arbeit in der Mitte den Agenten in künftigen Sessions sowohl im Frontend als auch im Backend zum Erfolg führen würde
- Nachdem die Umstrukturierung abgeschlossen war, habe ich den Agenten als Erstes erneut gebeten, den Rest der Eule zu vervollständigen
- Diesmal die Änderungen prüfen lassen, abhängigen Code auf den neuen Stil aktualisieren und alten Code entfernen
- Eine Reihe von marathonartigen Cleanup-Sessions fortgesetzt
Simulation
- In der ersten UI-Session den Agenten gebeten, Demo-Code zu erzeugen, damit man das UI tatsächlich sehen kann, ohne echte Update-Prüfungen auszuführen
- Der Update-Flow hat mehrere Szenarien, und bis zu diesem Punkt war nur der Happy Path getestet worden
- In der nächsten Session den Simulationscode in eine eigene Datei ausgelagert und den Agenten gebeten, mehr Szenarien zu erzeugen
- Den Update-Simulationscode aus AppDelegate.swift in eine eigene Datei unter Features/Update ausgelagert
- Mehrere Simulationsszenarien eingebaut (Happy Path, nicht gefunden, Fehler usw.), damit sich verschiedene Demos leicht ausprobieren lassen
- Tipp: Der Agent ist hervorragend darin, Tests und Simulationen zu erzeugen
- Der hier erzeugte Simulationscode ist ehrlich gesagt ziemlich schrecklich, aber er funktioniert, und da er nicht Teil des Release-Binaries ist, spielt die Qualität keine große Rolle
- Nicht einmal aufgeräumt, über die in der Session sichtbaren Grundlagen hinaus
- Verschiedene Simulationen ausgeführt und mehrere UX-Verbesserungen entdeckt
Letzte Meile
- Zu diesem Zeitpunkt gab es ein funktionierendes Backend und Frontend, und alles musste nur noch verbunden werden
- In der nächsten Session den Agenten mit folgendem Prompt beauftragt
- Eine UpdateController-Klasse für den Updater-Typ erstellen, analog zu Sparkles SPUStandardUpdaterController.m
- Etwas Hin und Her und manuelle Feinarbeit waren nötig, aber es wurde erreicht
- Danach kleine Verbesserungen hinzugefügt
- Für den aktualisierbaren Zustand mit Appcast ein SUAppcastItem betrachten und, falls gesetzt, weitere relevante Metadaten anzeigen
- Zum Beispiel die Content-Length für die Größe
Sonst noch etwas?
- Für den Agenten gilt: Der letzte Prompt sollte immer fragen, was noch übersehen wurde
- Diesen Schritt ausführen, unabhängig davon, ob der Code manuell direkt geschrieben wurde oder nicht
- Gibt es weitere Verbesserungen, die sich in der Features/Update-Funktion umsetzen lassen, ohne Code zu schreiben, als Oracle-Beratung, und welche Codeteile wären für zusätzliche Unit-Tests geeignet?
- Da die tatsächlichen Probleme hervorgehoben wurden, darum bitten, sie zu implementieren
- Ich habe festgestellt, dass es einfacher ist, dem Agenten zu sagen, er solle „alles erledigen“, statt nach konkreten Maßnahmen zu fragen, da sich das später in optionalen Commits leicht aufräumen lässt
- Das Lustige an dieser Session war, dass der Agent wirklich begann, in ein völlig verrücktes Kaninchenloch abzutauchen, sodass ich eingreifen und ihn stoppen musste
- „Stopp, stopp, stopp. Alle Main-Actor-Einträge abbrechen.“
- Ich habe außerdem bemerkt, dass es einen besseren Weg gibt, etwas zu lösen, das ich ziemlich schlecht umgesetzt hatte
- Bei Fehlermeldungen gibt es in SwiftUI doch sicher einen Standardweg, statt sie abzuschneiden; es braucht ein zusätzliches UI-Element, mit dem man die vollständige Meldung sehen kann
Kosten und Zeit
- Die Arbeit bestand insgesamt aus 16 separaten Sessions in Amp, mit 15,98 $ Token-Kosten
- Ich würde normalerweise nicht behaupten, ob das teuer oder günstig ist, aber persönlich habe ich in den zwei Tagen, die ich für diese Funktion aufgewendet habe, im Café mehr ausgegeben
- Meine insgesamt tatsächlich aufgewendete Zeit für diese Funktion schätze ich auf etwa 8 Stunden
- Zwischen dem ersten und letzten Commit lagen zwar 3 Tage, aber ich habe pro Tag nur etwa 4 Stunden am Computer gearbeitet
- Ich habe nicht die gesamte Zeit nur für diese Funktion aufgewendet
- Während ich an dieser Funktion arbeitete, habe ich zum Beispiel Ghostty-Updates ausgeliefert, war eine Stunde lang Gast bei ThePrimeagen und habe bei der jährlichen firmenweiten Veranstaltung von Zoo eine Gastpräsentation gehalten
- Ich habe ein Kleinkind zu Hause, daher ist „Computerzeit“ stark geplant und sehr begrenzt
- Daher ist die Schätzung von 8 Stunden eher großzügig
- Viele Menschen im Internet diskutieren darüber, ob AI einen schneller arbeiten lässt
- In diesem Fall glaube ich, dass ich es schneller ausgeliefert habe, als wenn ich alles selbst gemacht hätte
- Vor allem, weil die banalen SwiftUI-Styling-Iterationen für mich persönlich zu langweilig und zeitaufwendig sind und AI darin einfach sehr gut ist
- Mehr noch als die Debatte über schneller/langsamer ist das mein Lieblingspunkt: AI kann für mich arbeiten, während ich etwas anderes mache
- Ein Foto von einer der Cleanup-Sessions, während ich Frühstück für die Familie gemacht habe
- Es gibt alle möglichen Einwände wie „Ich will beim Kochen nicht coden“ oder „Sei präsenter“
- Wenn man das so machen möchte, ist das völlig in Ordnung; in meinem Fall war ich in diesem konkreten Beispiel die erste Person im Haus, die aufgestanden ist, während alle anderen noch schliefen, und habe Frühstück vorbereitet
- Ich mache das nicht in jedem wachen Moment
- Fazit: Für mich funktioniert es
- Ich versuche überhaupt nicht, dich zu überzeugen
- Ich habe keinerlei finanzielle Verbindung zu irgendeinem AI-Unternehmen
- Als jemand, der mit AI-Tools viel Erfolg hat und gerne darüber spricht, werde ich ständig gebeten, Beispiele zu teilen
- Genau das mache ich hier
Fazit
- Die Funktion ist schön geworden, funktioniert hervorragend und wurde nach einer abschließenden manuellen Prüfung gemergt
- „Abschließende manuelle Prüfung“ ist sehr, sehr, sehr wichtig — keinen von AI geschriebenen Code ohne gründliche manuelle Prüfung deployen
- Für Ghostty-Nutzer, die Tip-Releases verwenden, ist sie jetzt verfügbar
- Für Nutzer getaggter Releases ist sie in Ghostty 1.3 verfügbar
- Ich bin ein offener Verfechter der Wichtigkeit, agentische Coding-Sessions öffentlich zu teilen
- Ein Grund dafür ist, dass es eine unglaublich wirkungsvolle Methode ist, anderen beizubringen, wie man diese Tools effektiv einsetzt
- Ich hoffe, dass dieser Beitrag dabei hilft, das zu zeigen
2 Kommentare
Hacker-News-Kommentare
Ich nutze AI oft als Inspirationswerkzeug; auch dieses Mal habe ich viel des UI-Codes so beibehalten, wie die AI ihn erzeugt hat, aber gelegentlich habe ich den Agenten etwas machen lassen, alles verworfen und dann selbst neu geschrieben (von Hand!). Die kreative "Zero-to-One"-Phase ist immer sehr schwierig und zeitaufwendig, daher ist AI als meine Muse wirklich hervorragend. Das ist genau der größte Vorteil von Code-Agenten. Viele machen sich Sorgen um Wartbarkeit oder Verhedderung bei AI-zentrierten Projekten, aber das ist mir egal. Wenn ich nur schnell an den Punkt komme, an dem ich die Funktionen eines Projekts tatsächlich ein wenig anfassen und weiter verbessern kann, nimmt es danach richtig Fahrt auf. Bis zu diesem "goldenen Moment" entstehen für mich die teuersten 80 % des Programmierens. Deshalb verstehe ich ehrlich gesagt die Gegenargumente gegen Code-Agenten nicht so recht. Selbst wenn am Ende nur Code übrig bleibt, den man komplett wegwirft, hat das für mich offensichtlich einen Wert. PS: Bacon muss unbedingt gewogen werden
Ich habe mich kürzlich mit jemandem über dieses Thema unterhalten, und ich stimme im Großen und Ganzen ebenfalls zu. Diese Tools sind großartig darin, ohne großen Aufwand Prototypen zu erstellen, mit denen man Interaktionen direkt ausprobieren und Ideen testen kann. Es gibt aber zwei Probleme. Erstens ist es ohnehin schon unerquicklich, andere davon zu überzeugen, dass ein Prototyp, der oberflächlich fast fertig aussieht, in Wahrheit noch weit von Production-Readiness entfernt ist, und LLM-basierter Code ist noch viel weiter von der Produktion entfernt als Prototypen, die ich früher auf die alte Art gebaut habe. Zweitens lerne ich bei Prototypen, die ich von Hand baue, direkt etwas über den Tech-Stack oder die Implementierung. Das Hauptziel ist zwar, schnell etwas zu bauen, aber dabei sammle ich viele technische Erkenntnisse, und oft bestimmt mein Prototyp sogar die technische Richtung. Bei LLM-basierten Prototypen ist der Code selbst dagegen fast nutzlos, und wenn man wirklich etwas daraus machen will, muss man fast von vorn anfangen. Die Idee wurde validiert, aber Technik und Design praktisch gar nicht. Trotzdem halte ich sie weiterhin für nützlich. Ich glaube an "Prototypen schnell bauen", und mit LLMs konnte ich sogar ziemlich große Systeme fast sofort zusammensetzen. Man braucht aber einen konzeptionellen Wechsel im Prozess. Nicht-LLM-Prototypen entsprechen vielleicht Schritt 4 oder 5 von 10, LLM-Prototypen eher Schritt 2. Das ist nicht schlimm, aber man muss seine Erwartungen daran anpassen, dass nach dem Prototypen mehr Arbeit übrig bleibt als früher
Dein Wertmaßstab, dass es "sobald man das Projekt ein Stück weit zum Laufen gebracht hat sofort vorangeht", ist hier entscheidend. Für mich ist gerade die "Zero-to-One"-Phase am lohnendsten und macht am meisten Spaß. Dann ist so viel möglich, und man kann etwas schaffen, das es vorher nicht gab. Wenn AI die Richtung im Voraus festlegt, habe ich das Gefühl, einen großen Teil dieser Kreativität zu verlieren
Aus deiner Sicht scheint die Angst vor der leeren Seite ein großes Problem zu sein. Ich kann gut nachvollziehen, dass ein Werkzeug, das das beseitigt, viel zur Produktivität beiträgt. Aber nicht alle haben dasselbe Problem. Softwareentwicklung ist eine sehr persönliche Tätigkeit, daher können Workflows und Erfahrungen stark variieren. Es geht nicht darum, dass die Methode der einen Person besser ist als die der anderen, sondern darum, dass für jede Person andere Werkzeuge passen und dass man die jeweiligen Erfahrungen so anerkennt und ihnen vertraut, wie sie sind. In der LLM-Debatte neigen beide Seiten dazu anzunehmen, dass sie und ihr Gegenüber gleich ticken
Ich habe diese Woche ein Interview über Mitchells Entwickler-Setup gesehen, und auf die Frage, warum er neovim nutzt, sagte er: "Ich will keine Tools, die für mich Code schreiben." Das fand ich bemerkenswert. Nicht als Kritik, sondern weil man beachten sollte, dass selbst ein hervorragender Entwickler wie Mitchell im Gegensatz zu früherem Intellisense in LLMs einen Wert sieht
Ich erkläre Kollegen das als "Cunningham’s Law auf mich selbst anwenden" Cunningham's Law: 'Der schnellste Weg, im Internet die richtige Antwort zu bekommen, ist nicht, eine Frage zu stellen, sondern eine falsche Antwort zu posten'. Wenn ich gedankenlos auf einen leeren Bildschirm starre, sitze ich lange einfach nur da, aber sobald etwas da ist, das man kritisieren kann, werde ich sofort produktiv
Ich respektiere Mitchells Reaktion auf den OpenAI-Vorfall aufrichtig, auch wenn sie für ghostty in eine positive Richtung geht. Ich habe fast nie erlebt, dass ein Softwareanbieter aktiv versucht, Frust oder Verärgerung bei Nutzern zu verringern, besonders wenn man an Dinge wie MS Auto Update denkt; das ist eine sehr willkommene Veränderung. Außerdem zeigt dieser Beitrag einen verantwortungsvollen Einsatz von AI beim Programmieren; meiner Ansicht nach passt das überhaupt nicht zur ursprünglichen, überzogen verwendeten Definition von vibe coding
Ich finde schon der Begriff "vibe coding" passt hier diesmal überhaupt nicht. Der Ausdruck wird inflationär und überall verwendet
Ich stimme der Aussage über den "verantwortungsvollen Einsatz von AI beim Programmieren" zu. Das ist kein vibe coding, sondern das, was simonw hier erstmals als vibe engineering beschrieben hat. Verwandter Beitrag
Übrigens hat Ghostty kürzlich die Pflicht eingeführt, die Nutzung von AI-Coding-Tools offenzulegen zugehöriger PR-Link
Dieser Beitrag zeigt, warum AI-Agenten gerade bei der Arbeit mit UI-Frameworks so stark sind. Ich entwickle selbst Apps mit Rust und GTK, und mein Workflow ist sehr ähnlich. Es ist nicht so, dass ich nicht wüsste, wie man etwas implementiert, sondern dass mir AI bei UI-Framework-Arbeit enorm hilft, weil sie den repetitiven und langweiligen Teil von Suchen und Ausprobieren größtenteils übernimmt. Mitchell versteht den gesamten Code während des ganzen Prozesses. Er weiß bereits, was er tun muss, und deshalb ist das etwas völlig anderes als das, was man "vibe coding" nennt. Bis man Experte wird, gibt es keinen separaten Shortcut. Ich mag Ghostty wirklich sehr
Dank LLMs macht Coden wieder Spaß. Im Job helfen mir LLMs beim schwierigsten ersten Schritt, also beim Einstieg, sodass ich sehr schnell loslegen kann. Auch beim Verstehen einer neuen Codebasis oder beim Schreiben langweiliger Teile sind sie wirklich nützlich. Aber der eigentliche Spaß beginnt bei Side Projects. Man kann spontane Ideen wirklich sehr schnell umsetzen. Ich muss nicht mehr stundenlang Boilerplate-Code schreiben oder mit Tooling kämpfen. Bereiche, mit denen ich nicht vertraut bin, delegiere ich an den Agenten, oder ich lasse mir per Prompt auf einen Schlag eine Funktion erzeugen und rolle sofort zurück, wenn mir das Ergebnis nicht gefällt
Etwas off-topic, aber ich verstehe nicht, warum fast alle Apps immer noch ein eigenes Update-Framework brauchen. Könnte man das nicht in App Stores oder Paketmanager integrieren?
Im macOS-Ökosystem ist das ziemlich schwierig
Unter Ubuntu zum Beispiel ist das ziemlich praktisch. Wenn man die neueste Version direkt herunterlädt und installiert, bekommt man danach weiterhin automatisch Updates
Genau den Teil, von dem du selbst sagst, dass du nicht gut darin bist — also die Zero-to-One-Phase — wirst du nie selbst lernen, wenn du ihn an AI abgibst. Wenn du das auch in Zukunft selbst können willst, musst du genau das gezielt üben
Ghostty war wirklich gut, und ich war fast so weit, iTerm aufzugeben, aber dann habe ich cmd-f gedrückt und es passierte nichts, also habe ich es wieder gelassen Issue- und Feedback-Seite
Ich frage mich, worüber in Beiträgen zu ghostty wohl gesprochen worden wäre, wenn cmd-f von Anfang an da gewesen wäre. Es wird langsam etwas ermüdend, das in jedem Post zu hören. Eigentlich könnte es viel interessantere Diskussionen über LLM-Tools oder Coding-Stile geben, aber am Ende reden dann doch wieder alle nur über cmd-f
Lustigerweise habe ich letztes Wochenende mit Claude eine Suchfunktion für Ghostty implementiert. Für die eigentliche Suche gab es schon Code, der irgendwie halbwegs funktionierte, daher ging es größtenteils darum, die UI anzubinden. In zwei Sessions (insgesamt etwa 10 Stunden) habe ich grundlegende Suche, Hervorhebung sowie Vor-/Zurückspringen zwischen Treffern im Linux-Frontend zum Laufen gebracht. Diese Suchfunktion ist noch ganz klar WIP und für normale Nutzung noch nicht bereit. Bei der Arbeit daran habe ich gemerkt, wie komplex es ist, selbst so eine scheinbar "grundlegende" Funktion mit streamendem Text funktionieren zu lassen
Mir war Ghostty auch zu minimalistisch, deshalb bin ich leider schnell wieder zu Warp zurückgekehrt. Zur Info: Die Standardgröße des Scrollback-Buffers in Ghostty liegt bei etwa 10 MB, lässt sich in den Einstellungen aber beliebig anpassen
Diese Suchfunktion ist mit Zieltermin März 2026 für v1.3 vorgesehen Roadmap-Link
Bei der Stelle im Artikel, wo es heißt "Schauen wir uns an, was zur Ergänzung dieser Funktion geführt hat", musste ich wieder daran denken, wie viele Unannehmlichkeiten wir im OS einfach hinnehmen. Präsentationen und Screen-Sharing sind seit Jahrzehnten selbstverständlich, und trotzdem ist es immer noch schwer, selbst nur eine grundlegende Einstellung durchzusetzen, bei der ausschließlich das Präsentationsfenster auf dem Bildschirm sichtbar gemacht wird
Das ist Ghostty, ein Tool, dem HashiCorp-Mitgründer Mitchell Hashimoto derzeit fast den Großteil seiner Zeit widmet.
Ghostty 1.0 veröffentlicht – schneller, plattformübergreifender Terminal-Emulator
libghostty kommt
Er tritt für agentisches Coding ein und sagt, dass Session-Sharing wirklich wichtig ist,
und die meisten Links führen offenbar zu AMP-Sessions. Amp - Tool für agentisches Coding