バイブコーディングを活用した高度なGhostty機能実装事例の共有

 (mitchellh.com)
7 ポイント 投稿者 GN⁺ 2025-10-13 | 2件のコメント | WhatsAppで共有
  • Ghostty の macOS向け 非干渉型の自動アップデート通知機能を、主に AI エージェンティックコーディングツールを活用して開発した全工程を公開し、16セッションで 15.98ドルのトークン費用、約8時間で実際に配布可能な機能を完成させた
  • OpenAI のキーノート中に Ghostty のアップデートプロンプトがデモを妨げた出来事をきっかけに、作業を中断させず タイトルバーやウィンドウ下部に小さな GUI 要素でアップデート状態を表示する非モーダル方式への転換を決定
  • AI を使い始める前に、Sparkle フレームワークの カスタム UI プロトコルとタイトルバーアクセサリコントローラを活用した大まかなバックエンド／フロントエンド計画を先に立て、AI をプロトタイピングツールとして活用
  • UI プロトタイピング、バグ解決に失敗した際の方針転換、反復的な クリーンアップセッション（ドキュメント化、リファクタリング）を通じて、今後の AI セッションの性能向上、シミュレーションコード生成など、段階的なアプローチを使用
  • AI が作業している間に家族の朝食準備など別のことができる 非同期的な作業スタイルの価値を強調し、すべての AI 生成コードは徹底した手動レビュー後にのみ配布し、理解できないコードは配布しないという原則を守った

機能概要

  • 完成した機能は、macOS 上でウィンドウを隠さない 非干渉型アップデート通知
    • ウィンドウを生成したりフォーカスを奪ったりすることなく、ターミナルウィンドウ内にアップデート状態を表示
    • OpenAI のキーノート中に Ghostty のアップデートプロンプトが出現した出来事をきっかけに、UX 改善の必要性を確認
  • アップデート通知を 非侵襲的にすることを決定
    • ポップアップウィンドウの代わりに、ユーザーを邪魔しない小さな非モーダル GUI 要素をどこかに表示する方針
    • 通知表示位置は タイトルバー右側を基本としつつ、タイトルバー非表示などスタイルに応じて ウィンドウ下部オーバーレイなどの代替も提供
  • 開発プロセス全体で AI エージェントを活用しつつ、直接の 手動修正・磨き込み・最終レビューを並行して行う 人間主導の補助ツール戦略を採用

AI 使用前の計画立案

  • AI ツールを立ち上げる前に、まず 大まかな計画を立案
  • バックエンドの大まかなアイデアを得た後でフロントエンドを構想
    • タイトルバーに小さなボタンを埋め込むという漠然としたアイデア
    • macOS が タイトルバーアクセサリコントローラを通じてタイトルバー上のカスタム UI をサポートしていることは知っていたが、具体的な見た目や感触は不明だった
  • 十分な出発点を確保して開始可能
    • AI は非常に優れたプロトタイパーなので、自分が何を知らないかを把握しているだけでも始めるには十分
    • 全体像について十分に強い感覚を持っていた

最初のセッション: UI プロトタイピング

  • 最初のエージェンティックコーディングセッションの開始プロンプト
    • SPUUserDriver をカスタマイズして、非侵襲的なアップデート通知とインストール有効化の要求を実装
    • UI 作業のみに限定
    • SPUUserDriver が要求するさまざまな状態を表示できる SwiftUI ビューの作成計画を要求
    • macOS ウィンドウのタイトルバー右上に表示する計画の策定を要求
    • Oracle とは? - Amp 専用の読み取り専用サブエージェントで、より遅く高コストなモデルを使用し、一般的に思考力に優れる
  • まず UI プロトタイプに集中することを決定
    • エージェントに機能全体の構築は依頼しなかった
    • 第一に、UI/UX がどのような形であるべきかをまだ把握していなかったため、AI に他の変更の中で一貫してそれを行わせることは期待できなかった
    • 第二に、小さな作業単位のほうがレビュー、理解、反復を行いやすい
  • 計画だけを書くよう依頼し、コードは書かないよう指示
    • 比較的あいまいな依頼なので、多くの作業（および大量のトークン消費）を行う前に計画をレビューすることが重要
    • ヒント: エージェントと包括的な計画を対話的に作ることは、非自明な作業における重要な第一歩
    • 通常は spec.md のようなファイルに保存し、今後のセッションで「@spec.md を参照して 何らかの作業 を実行して」と依頼できる
  • エージェントが十分に納得できる計画を提示し、実装の進行を許可
    • 生成された UI は方向性が非常に良かった
    • 多くの磨き込み課題（間隔、色など）はあったが、UI を見て自分の望むものへのひらめきを得た
    • ヒント: 着想を得るために AI を非常によく使う。このケースでは生成された UI コードの多く（すべてではない）を残したが、エージェントにプロンプトを与えて全部捨て、その後手動でやり直すことも非常によくある
    • 創作における「ゼロからワン」の段階は非常に難しく時間がかかり、AI はミューズとして優れた役割を果たす

壁にぶつかる

  • チャット 11〜14 で スロップゾーンに突入
    • エージェントが生成したコードに重大なバグがあり、修正に完全に失敗
    • 自分も修正方法が分からなかった
  • バグ修正のために何度かヘイルメリー的な試みを実施
    • エージェントが解決できれば、それを調べて学べる
    • 失敗してもコストはほとんどかからない
    • エージェントが解決しても理解できなければ差し戻す、理解できないコードは配布しない
    • 失敗している間はタブを切り替えて問題を検索し、自力で解決を試みた
  • この時点で、一歩引いて行った作業を見直し、自分自身の計画を立てる必要があると認識
    • 自分を教育し、批判的に考えるための時間
    • AI はもはや解決策ではなく負債だった

クリーンアップセッション

  • 次の数セッションは、エージェントを導いてコード整理に費やした
  • 第2セッション: いくつかのメソッドをより適切な場所へ移動
    • フィル背景、前景、バッジ関数を UpdateAccessoryView.swift から UpdateViewModel.swift へ移し、より汎用化
  • 第3セッション: コードにドキュメントを追加
    • UpdateBadge.swift のドキュメントを更新
    • ヒント: ドキュメント追加は、コードに対する自分の理解を再確認し、このコードを読んで修正できる将来のエージェントの教育にも役立つ
    • エージェントは自然言語の説明とコードの両方があると、はるかに良い性能を発揮する
  • 第4セッション: ビューモデルをアプリ全体の位置へ移動
    • 元の作業ではウィンドウスコープに置いていたが、アップデート情報はアプリスコープであるため
    • この過程では通常、些細な手動変更もあわせて行う
  • クリーンアップ段階の重要性
    • 効果的に整理するにはコードへのかなり良い理解が必要であり、そのため AI が書いたコードを盲目的に受け入れないよう強制される
    • より良く整理され文書化されたコードは、今後のエージェンティックセッションの性能向上に役立つ
  • これを冗談交じりに 「アンチ・スロップセッション」 と呼んでいる

バグとの対峙

  • 初期セッションで見つけたバグに戻る時間
    • エージェントにこれを把握させるために、再び数セッションを消費
    • 曖昧に始めて、アプローチ方法を徐々により具体的にしていった
  • 1つ目の 曖昧なセッション: 標準のネイティブタブではアップデート用アクセサリービューが表示されず、ウィンドウのタイトルバーに常に表示されるようにすべきだったが、失敗
  • 2つ目の より具体的なセッション: TerminalTabsTitlebarTahoe.swift のタブバー制約を更新し、タブバーの右端をアップデート用アクセサリービューの左端に揃える - 失敗
  • 3つ目の 別の具体的アプローチの試行: TitlebarTabsTahoeTerminalWindow.swift を変更し、タブバーを下部アクセサリービューではなく上部アクセサリービューにして、タブをタイトルバー内に入れるのはどうか - 失敗
  • 最後の試行: 右側アクセサリービューとレイアウトが TerminalWindow.swift のアップデート用アクセサリービュー設定と衝突しており、タブバーが常にアップデート通知の左側に現れるよう制限できるか - 失敗
  • この全過程のあいだ、自力で解決しようと手動調査と人間の努力も試みた
    • より具体的なプロンプトは、その過程で学んだことに基づいていた
    • 全体としては明らかにうまく機能しなかった
  • 単独では解決できないと判断し、方向転換を決定
    • 問題のあるタイトルバースタイルでは、タイトルバーではなくウィンドウのコンテンツビュー上にオーバーレイされた右下隅にアップデート通知を配置
    • Ghostty にはタイトルバーを完全に隠す構成があるため、いずれにせよこれをサポートする必要がある
    • 後でタイトルバースタイルの問題を解決できたとしても、この別モードは引き続きサポートする必要がある
  • 次のセッション ではこの計画で進め、非常に具体的なプロンプトを使用
    • Update システムを拡張し、TerminalView.swift でオーバーレイ方式もサポート
    • アップデート通知はウィンドウ下部に表示され、テキストの上に重なるようにする（したがってターミナルビューのサイズ変更はなし）
    • すべてのクリック動作はアクセサリービューと同一
  • 本当にうまく実行し、その後に多くの手動ポリッシュ作業（移動、名前変更など）を行ったが、コア部分は堅牢だった

バックエンド開始

  • UI は十分に良いと感じられた
    • 後で扱いたい多くのポリッシュ上の課題をメモしたが、主に計画にレンチを投げ込む可能性のある未知の未知を見つけるため、バックエンド作業に移りたかった
  • 未完成の関数やさまざまな TODO コメントを含むスキャフォールドファイルを手動で作成。新しいセッションを開始
    • UpdateDriver.swift を完成させるよう依頼し、Sparkle のドキュメントを読んで機能を理解させた
    • ヒント: AI は空欄補完や残りのフクロウを描くことが非常に得意
    • 説明的な関数名、引数、todo コメントなどでスキャフォールディングを作るパターンは非常に一般的で、うまく機能する
  • 実際には 非常にひどい仕事 をしたので、このコードはすべて捨てた
    • 生成されたコードは動いたが、明らかに間違ったアプローチだった
    • さまざまな関心事を混同しており、ドライバーに状態を保存するやり方も明らかに誤っていた
  • 実施内容を調べた結果、ビューモデルが最適ではない形で構造化されていることに気づいた
    • AI（および手書きすることを選んだ場合の人間）により良いフレームワークを提供するため、クリーンアップモードへギアチェンジ

大規模な再クリーンアップ

  • 経験上、UI フロントエンドとビジネスロジックのバックエンドの整然さは、しばしば 中間にあるビューモデルの品質 によって決まる
    • ビューモデルを手作業で再構成するのに時間を費やした
    • optional が多い構造体ではなくタグ付きユニオンへ移行し、一部の型名を変更・移動した
  • 経験上、この中間での小さな手作業が、将来のフロントエンドとバックエンドの両方のセッションでエージェントを成功へ導くと分かっていた
    • 再構造化を終えた後、最初にやったことはエージェントにもう一度フクロウを完成させてもらうことだった
    • 今回は変更点を確認し、依存コードを新しいスタイルに更新し、古いコードを削除した
  • 一連の マラソンクリーンアップセッション を継続

シミュレーション

  • 最初の UI セッションで、エージェントに実際のアップデート確認なしでも UI を実際に見られるよう、デモコードの生成を依頼
    • アップデートフローには複数のシナリオがあり、この時点まではハッピーパスしかテストしていなかった
  • 次のセッション でシミュレーションコードを専用ファイルに抽出し、エージェントにさらに多くのシナリオ生成を依頼
    • AppDelegate.swift のアップデートシミュレーションコードを Features/Update の専用ファイルへ抽出
    • 複数のシミュレーションシナリオ（ハッピーパス、見つからない、エラーなど）を含め、さまざまなデモを簡単に試せるようにした
    • ヒント: エージェントはテストとシミュレーション生成に優れている
    • ここで生成したシミュレーションコードは正直かなりひどいが、動作し、リリースバイナリの一部でもないので品質は重要ではない
    • セッションで見られる基本事項を超えては、整理すらしなかった
  • さまざまなシミュレーションを実行し、複数の UX 改善点を発見

最後のマイル

  • この時点で、動作するバックエンドとフロントエンドがあり、あとはすべてを接続する必要があった
  • 次のセッション でエージェントにプロンプト
    • Sparkle の SPUStandardUpdaterController.m と同等だが、updater 型向けの UpdateController クラスを作成
    • 少しの行き来と手動ポリッシュが必要だったが、到達できた
  • その後、小さな改善 を追加
    • appcast を持つ更新可能状態については SUAppcastItem を見て、設定されていれば他の関連メタデータも表示
    • たとえばサイズに関する content length

ほかには？

  • エージェントに対する**最後のプロンプトは常に何を見落としているかを尋ねること**
    • コードを手動で直接書いたかどうかに関係なく、この作業を行う
    • Features/Update機能で加えられるほかの改善があるか、コードは書かないこと、Oracleコンサルティング、単体テストをさらに追加できるコード箇所を検討
  • 実際の問題を強調したうえで、実装するよう依頼
    • 後で任意のコミットで簡単に整理できるので、実行すべき具体的な項目を尋ねるよりも、エージェントに「全部やって」と伝えるほうが簡単だと分かった
  • このセッションで面白かったのは、エージェントが本当におかしな深みに入り始めたので、止めるために介入したこと
    • 「止まって、止まって、止まって。すべてのメインアクター項目を取り消して」
  • また、もっと良い方法があるのに、ややひどいやり方で実装していることも見つけた
    • エラーメッセージについては切り詰めるのではなく、SwiftUIの標準的な方法があるのではないか、全文を見られる追加のUI要素が必要

コストと時間

  • 作業は合計16の別セッションで、Ampで15.98ドルのトークンを消費
    • これが一般的に高いか安いかは推測しないが、個人的にはこの機能に費やした2日間のあいだにカフェでそれ以上使っている
  • この機能に費やした実作業時間の合計は約8時間と見積もっている
    • 最初と最後のコミットは3日にまたがっているが、1日にコンピュータに向かっていたのは約4時間だけ
    • すべての時間をこの機能だけに費やしたわけではない
    • たとえば、この機能を作業しているあいだにGhosttyアップデートの公開、ThePrimeagenへの1時間のゲスト出演、Zooの年次全社会議でのゲストプレゼンテーションなども行った
    • 家に幼児がいるので、「コンピュータの時間」はかなり計画的で、非常に限られている
    • したがって、8時間という見積もりはやや多めかもしれない
  • インターネット上では、AIがより速く作業できるようにするかどうかについて多くの人が議論している
    • このケースでは、全部を自分でやっていた場合よりも速くリリースできたと思う
    • 特に、些細なSwiftUIのスタイリングの反復作業は個人的にあまりにも退屈で時間がかかるし、AIはそれを非常にうまくこなすからだ
  • 速いか遅いかという議論よりも一番気に入っている点: AIは、私が別のことをしているあいだも代わりに働けること
    • 家族のために朝食を作っているあいだに、クリーンアップセッションの1つを動かしていた写真
    • 「料理中にコーディングしたくない」や「もっとその場に集中しろ」といった、あらゆる種類の反応がある
    • そうしたいならそれで構わないが、私の場合この具体例では、家で最初に起きた人間で、ほかのみんながまだ寝ているあいだに朝食を準備していただけだ
    • 起きている時間のすべてをこんなふうに過ごしているわけではない
  • 結論: 自分には効果がある
    • あなたを説得しようとしているわけではまったくない
    • どのAI企業とも金銭的なつながりはない
    • AIツールで多くの成功を収め、それについて話すのが好きな人間として、人からいつも実例を共有してほしいと頼まれる
    • それがここでやっていることだ

結論

  • 機能は美しく、うまく動作しており、最終的な手動レビューのあとでマージした
    • **「最終的な手動レビュー」**は非常に非常に非常に重要で、徹底した手動レビューなしにAIが書いたコードをデプロイしてはいけない
    • Ghosttyユーザーのうちtipリリースを使っている場合は、現在利用可能
    • タグ付きリリースを使っている場合は、Ghostty 1.3で利用可能
  • 私はエージェント型コーディングセッションを公開で共有することの重要性を率直に支持している
    • 理由の1つは、こうしたツールを効果的に使う方法について他の人を教育するうえで、信じられないほど強力な手段だからだ
    • この投稿がそれを示す助けになればと願っている

関連記事

2件のコメント

 
GN⁺ 2025-10-13
Hacker Newsのコメント

  • 私はよくAIを発想のための道具として使っている。今回もUIコードはかなりAIに生成してもらったものを残したが、ときどきエージェントにやらせて、全部捨ててから自分で書き直すこともある（手作業で！）。「ゼロから1」を生み出す創作段階はいつもとても難しく、時間もかかるので、AIが私のミューズ役をしてくれるのは本当に優れている。コードエージェントの最大の利点はまさにそこだ。多くの人がAI中心のプロジェクトの保守性や混沌を心配するが、私は気にしない。プロジェクトの機能をある程度実際に触れるようになり、継続して修正できる段階に素早く到達できさえすれば、その後は本当に勢いがつく。この「黄金の瞬間」までが、私にとってプログラミングで最もコストの高い80%だと思っている。だからコードエージェントへの反対意見が正直あまり理解できない。たとえ完全に捨てるコードしか残らなくても、それ自体に明らかな価値があると感じる。PS. ベーコンは必ず重さを量るべきだ

    • 最近この話題について誰かと話したが、私も大筋では同意する。こうしたツールは、インタラクションを実際に触りながらアイデアを試せるプロトタイプを簡単に作れる点がとても優れている。ただし問題が2つある。1つ目は、見た目はほとんど完成しているように見えるプロトタイプが実際には本番投入にはほど遠いと説得するのが、もともと厄介だということだが、LLMベースのコードは私が以前のやり方で作っていたプロトタイプよりもさらに本番から遠い。2つ目は、私が手で作るプロトタイプでは技術スタックや実装について自分で学べることだ。素早く作ることが主目的ではあるが、その過程で得られる技術的な学びが多く、しばしば私のプロトタイプが技術的な方向性まで左右する。一方でLLMベースのプロトタイプは、そのコード自体はほとんど役に立たず、実際に何かを始めるならほぼ最初からやり直す必要がある。アイデアの検証はできたが、技術や設計はまったく検証できていないという感覚だ。それでもなお有用だとは思う。私は「プロトタイプは素早く」という信条を持っていて、LLMの活用によってかなり大きなシステムでもほぼ即座に組み立てられた。ただ、プロセスの捉え方を変える必要がある。非LLMのプロトタイプは10段階中4〜5段階目くらいだが、LLMプロトタイプは2段階目に近い。これは悪いことではないが、プロトタイプの後に残っている作業量は以前より多いという点について期待値を調整する必要がある

    • 「自分でプロジェクトをある程度走らせられる段階まで持っていければ、すぐに前に進める」というあなたの価値観は重要だ。私にとっては、むしろ「ゼロから1」の段階こそがいちばんやりがいがあり、楽しい。この段階では可能性が本当に多く、これまで存在しなかった何かを生み出せるからだ。AIが先に方向を定めてしまうと、そうした創造性をかなり失ってしまう気がする

    • あなたの意見を見ると、真っ白なページへの恐怖が大きな悩みなのだと思う。それを取り除いてくれるツールが生産性に大きく貢献するという話には共感する。ただ、誰もが同じ悩みを持っているわけではない。ソフトウェア開発は非常に個人的な活動なので、各人のワークフローや経験は異なりうる。どちらのやり方が優れているという話ではなく、それぞれに合った道具があり、それぞれの経験をそのまま認めて信頼することが大切だ。LLMをめぐる論争では、両陣営とも自分と相手が同じだと仮定しがちだ

    • 今週、Mitchellの開発セットアップに関するインタビューを見たが、neovimを使う理由を聞かれて「自分の代わりにコードを書いてくれるツールは欲しくない」と言っていた部分が印象的だった。批判したいわけではなく、Mitchellのような優れた開発者でさえ、昔ながらのintellisenseとは違う形でLLMに価値を見出している点に注目する必要がある

    • 私は同僚に、これを「自分自身に対してCunninghamの法則を使っている」と説明している。Cunningham's Law: 'インターネットで正しい答えを得る最速の方法は、質問することではなく間違った答えを投稿することだ'。何もない空白の画面を前にすると、私はしばらくぼんやりしてしまうが、何か批判できる材料があるとすぐに生産的な状態に切り替わる

  • OpenAIの障害への対応に関するMitchellの意見は心から尊敬している。ghosttyにとっては前向きな方向ではあってもだ。ユーザーの不満やいらだち（特にMS Auto Updateのようなものを考えると）を能動的に減らそうとするソフトウェア企業はほとんど見たことがなく、とても歓迎すべき変化だ。また、この文章からはAIをプログラミングで責任を持って使っている様子がうかがえる。元々のvibe codingの定義（誇張して語られていたもの）にはまったく当てはまらないと思う

    • ここで「vibe coding」という言葉そのものが今回まったく合っていない概念だと思う。その用語は濫用され、あちこちで使われている

    • 「AIを責任を持ってプログラミングに使っている様子」という意見に同意する。これはvibe codingではなく、simonwがここで最初に示した vibe engineering だ。関連記事

  • 参考までに、Ghosttyでは最近、AIコーディングツールの使用を必ず開示することが義務化された。関連PRリンク

  • この記事は、なぜAIエージェントがUIフレームワーク作業で大きな強みを持つのかを示している。私もRustとGTKでアプリを開発しているが、ワークフローは非常によく似ている。私が実装方法を知らないわけではなく、AIがUIフレームワーク作業における反復的で退屈な検索や試行錯誤の大半を引き受けてくれるのでとても助かる。Mitchellは作業の全過程を通じてコード全体を理解している。すでに自分が何をすべきか分かっているという点で、いわゆる「vibe coding」とはまったく異なる。専門家になるまでに近道はない。Ghosttyは本当に気に入っている

  • LLMのおかげでコーディングがまた楽しくなった。仕事では、LLMが最も難しい最初の一歩、つまり開始段階を手伝ってくれるので、すぐに作業に取りかかれる。新しいコードベースを理解したり、退屈な部分を書いたりするときにも本当に役立つ。しかし本当の楽しさはサイドプロジェクトで始まる。思いつきのアイデアを本当に素早く実装できるようになった。もうボイラープレートコードを書くのに何時間も費やしたり、ツール周りでもがいたりする必要がない。自分にとって不慣れな部分はエージェントに委ねたり、一発のプロンプトで機能を出させてみて、結果が気に入らなければすぐ巻き戻したりできる

  • 少し脇道にそれる質問だが、なぜ今でもほとんどすべてのアプリが独自のアップデートフレームワークを持たなければならないのか分からない。App Storeやパッケージマネージャーにその機能を統合できないのだろうか？

    • macOSのエコシステムでは、こうした機能はかなり難しい

    • たとえばUbuntuでは、これはかなり便利だ。最新版を直接ダウンロードしてインストールすれば、その後は自動更新を受け続けられる

  • 結局、自分ではうまくできないと認めたまさにその部分、つまりゼロから1の段階は、AIに任せると永遠に自分で身につけられない領域になる。もし今後も自分でやってみたいなら、その点は自分で練習しなければならない

  • Ghosttyは本当に良くて、ほとんどiTermを捨てかけたのだが、cmd-fを押しても何も起きなかったので断念した。Issueとフィードバックのページ

    • もし最初からcmd-fがあったなら、ghosttyに関する記事でどんな話が交わされていたのか気になる。どの投稿でもこの話を聞くのは少しうんざりしてきた。実際にはLLMツールやコーディング手法についてもっと面白い議論があるはずなのに、結局みんなcmd-fの話ばかりしてしまう

    • 面白いことに、私は先週末Claudeを使ってGhosttyに検索機能を実装した。実際の検索処理については、すでに雑ながら動くコードがあったので、ほとんどはUIとの接続作業だった。2回のセッション（合計10時間ほど）で、基本的な検索・ハイライト・前後の一致項目への移動がLinuxフロントエンドで動くようにした。この検索機能はまだ明らかにWIPで、一般利用には準備不足の状態だ。作業しながら、このような「基本」機能に見えるものでも、ストリーミングテキスト上で動かすのがどれほど複雑かを痛感した

    • 私もGhosttyはミニマルすぎて、残念ながらすぐWarpに戻ってしまった。ちなみにGhosttyのデフォルトのスクロールバックバッファ容量は約10MBだが、設定でいくらでも調整できる

    • この検索機能は2026年3月の v1.3 を目標として予定されている。ロードマップリンク

  • 「この機能を追加するきっかけを見てみよう」という記事のくだりを見て、OS上で私たちがどれほど多くの不便を受け入れているかを改めて考えさせられた。プレゼンや画面共有はすでに何十年も当たり前の存在なのに、なぜいまだにプレゼン用ウィンドウだけを画面に表示させるよう強制する基本的な設定すら難しいのか不思議だ
 
xguru 2025-10-13

HashiCorp共同創業者のミッチェル・ハシモトが最近ほとんどの時間を注ぎ込んでいるツール、Ghosttyです。

Ghostty 1.0 リリース - 高速・クロスプラットフォームのターミナルエミュレーター
libghosttyがやってくる

エージェンティック・コーディングを支持しながら、セッション共有が本当に重要だと語っていますが、
リンクの大半がAMPセッションにつながっていますね Amp - エージェンティック・コーディングツール