最近、すべてのIDEが使うのが痛いほど遅くなったので、ターミナルの設定を一新したよ（デバッガーとgitの統合がIntelliJの最後の砦だったけど、nvim-dapとlazygitを学ぶ時間をかけたら、素晴らしいものになった）。AIも、変な設定の落とし穴を理解するのに非常に役立ってる。あと、vimの複数カーソルのYAGNIを確認してくれてありがとう。最初にそれが必要だなんて全然思いつかなかったから。

まさにその通り。GUIツールの非構成可能性と非標準化が、私の主な問題だね。すべての問題を解決するために同じツールキットを使うのは大変だけど、最終的にはもっと効率的だと思う。ただ、これを売り込むのは難しい。コマンドラインツールのシンプルさを理解するのは、そうしたツールを使って解決できなかった問題を解決するまで簡単じゃないからね。

CLIアプリとTUIアプリの違いを考えると、この記事は特に後者について話していると思う。CLIアプリ（コマンドラインに重点を置く）とは、grepやsort、cp、git、ls、tarなどのことを指す。これらは通常、シェルでコマンドを書くことで操作するので、普通に使えるならスクリプトでも使える。つまり、これらをパイプラインに組み合わせることができる。TUIアプリとは、VimやEmacs、Tmux、Lynx、Tig、Midnight Commander、Claude Codeなど、使用中にターミナルを占有するインタラクティブなアプリのことを指す。これらをパイプラインに組み込むことはない。もっと正確に言うと、通常の使い方でパイプラインに使うことはない。使えるとしたら、アプリがTUIに加えてコマンドラインインターフェースを提供することに決めたからだろう。

コマンドラインを使って20年近くになるけど、そのうちの数年はvimをメインエディタとして使ってた。でも、結局Sublimeに移行してからは戻ってない。とはいえ、仕事ではコマンドラインをたくさん使ってる。ビルドやテストを実行する時は、Sublimeの「ビルドシステム」サポートを使う代わりに、いつもkonsoleウィンドウを開いてalt+tabしてる。vimを使うのは、sshが必要な時か、スマホでTermuxを使ってる時だけ。 > ここでの適切な議論は、多分これだと思う：ターミナルは、小さなCLIツールをパイプラインに組み合わせることで無限のユースケースをカバーするし、拡張可能なGUIツール（SublimeやVSCodeなど）も無限のユースケースをカバーするけど、より信頼性が高く再現可能な実行環境を提供してくれる。こういう議論が終わらない理由は、人々が一般的に閉鎖的になりがちだからだと思う。他人の立場に立つのは難しいし、自分が間違っている可能性を考えるのはもっと難しい。でも、結局これが重要なのは初心者だけ。十分な経験を積めば、何を使っても生産性のボトルネックは道具じゃなくなる（edを除いて…）。

ユーザーが成功の落とし穴に落ちるようにする これ以上付け加えることはないけど、この表現は素晴らしく印象的だと思った。

それはフレーミング次第だと思う。特にスキルを育てる楽しい仕事は、みんなが思ってるよりも価値がある。組織の観点からは、従業員のライフタイムエンゲージメントにおけるパフォーマンスの最高曲線を作ることが目標だし、従業員の観点からはキャリアが重要。これには関わる人たちの関係が大きく影響する。自分の視点から言うと、引越し屋が前日に働いてたら、筋肉が痛くて仕事が遅くなるから、ネットマイナスだと思う。引越し会社から見れば、もっと強くなって次の仕事ができるから良いけど、もしその日に辞めたり解雇されたら、また悪くなる。実際の評価は、マクロとSublimeの編集の違いじゃなくて、マクロを作る思考プロセスが他のことにどう影響するか、そして彼らがその前に何をしていたかだ。自分の経験では、誰もマクロを書いたりVimを学ぶために費やした時間を、実際に意味のある仕事に使うことはない。みんな退屈だったり燃え尽きて、今は楽しいと思える別のことを考えたいからやってる。問題は、従業員がランダムなスクリプトを書くことじゃなくて、彼らが現在のタスクに対して緊急感や関心を持っていないことだ。

ちょっと前に、こんな抽象的なことを考えたんだ。「うちの会社でCloudFrontを使ってる人たちは、実装の詳細なんて気にしてない。とりあえず、いくつかのパスがキャッシュされてればいいんだ」って。これを同僚に説明したら、時間はかかったけど理解してくれた。2ヶ月後、誰かがPRをマージして、俺のインターフェース「このパスとこのパスをキャッシュしてほしい」が、AWSの生のインターフェースをそのまま使うシンプルなパススルーに置き換えられた。同じことがS3バケットにも起こって、ほとんどの人が「X日後に自動でファイルを削除する」っていう機能だけを求めてるのに気づいた。俺は1年かけてマネージャーに「サービスを作る開発者はシンプルなデプロイボタンが欲しい」って説明し続けたけど、結局「インフラをコードとして教える」ことに力を入れた。結果的に、俺たちと関わってくれたのは一人だけで、その人はいつもAI生成のPRを送ってきて、エラーを見つけるとそれをChatGPTにコピペして、返ってきた答えを俺に送ってきた。プロジェクトは最終的に俺の元のアイデアにシフトしたけど、全くデザインもなく、非常に苦痛な方法で進んだ。マネージャーが「Xをサポートする必要はない」と言ったかと思えば、2ヶ月後には「Xのサポートを追加する」というJiraチケットが出てくるんだから。

設定可能性は、ツールがどれだけコアな仕事の機能や役割に重要かに依存すると思う。つまり、彼らや雇用主が価値を置くタスクを直接実行するのを助けるために非常に価値があるか、彼らがあまり価値を置かない問題を取り除くのをどれだけ許すかの違いだ。例えば、Gustoが給与計算や税金、書類の提出を処理してくれる方法が大好きで、基本的にその問題について考えたり、いじったりする必要がないから。でも、給与計算や会計、税金を専門にしている人にとっては、逆に害になることもある。彼らはそれに対抗しなければならないから（あるいは少し厳しく言えば、仕事が簡単すぎるから）。もう一つの大きな問題は、実際にお金を払う決定をするのは誰か、そしてそれが防御的（例えば、監査可能性、セキュリティ、望ましくない行動に対する制約）か創造的な目的に役立つかということ。創造的なものは魅力的だけど、定量化が難しくて、エンドユーザーはそれがどれだけ役立つか、あるいは彼らの役割にどれだけ重要かに対して、それほどお金を払う意欲がない。

道を開けることは重要だ。なぜなら、人々は毎日何十ものツールを使っているから。残念ながら、バランスを取るべきことがまだあって、それは人々に正しいことをさせることだ。正しく何かをすることで妨げられていると感じる人たちが必ずいるから、彼らはそれを時間の無駄だと感じている。