ハクソク

世界を動かす技術を、日本語で。

ソフトウェアのエマックス化

22時間前原文(sockpuppet.org)

概要

  • Markdownビューア の重要性と現状の不満点
  • AIエージェント によるネイティブUI開発の進化
  • Emacs文化 の「Emacsification」が広がる現象
  • 個人向けソフトウェア開発と プログラマビリティ の新時代
  • 今後の 開発体験 とコミュニティの変化への期待

Markdownビューアの必要性と現状の課題

  • Markdown はソフトウェア開発の共通言語
  • TUI（ターミナルUI）ツールの復権による Markdown閲覧体験の悪化
    • 例：glowやMarklessなど優秀なTUIビューアの存在
    • 端末の 等幅フォント による読みにくさ
  • macOS向けの グラフィカルUIエディタ （Obsidian, Typora, Bear等）は読みやすいが「エディタ」であり、環境を乱される問題
  • App StoreのMarkdownビューアは 機能不足や使い勝手の悪さ が目立つ
    • 検索機能やコピペ不可、課金要素など
  • 「まともなMarkdownビューア」を探すのは 時間の無駄 との気付き

AIエージェントによるMarkdownビューア開発体験

  • Claudeなど AIエージェント を活用し、短時間で高品質なMarkdownビューア（MDV.app）を開発
    • 事前準備：Macbook, Xcode, git, Claude設定, Swift/macOSデザイン習得
    • 実装自体は 30分程度の対話 で完成
  • MDV.appの主な特徴
    • テキストの選択・コピー、全文検索、SQLite FTSインデックス
    • ホットキー付きブックマーク、目次ナビゲーション
    • ドキュメント間の位置記憶、カラーテーマ、タイポグラフィ
    • .mdファイルをダブルクリックするだけで快適な閲覧体験

Electronアプリの問題点とネイティブUIへの回帰

  • Electronアプリ （例：Signal）は見た目はネイティブでも実体はChromiumベース
    • 多くの現代UIアプリがElectron依存
    • 画面のフリッカーやパフォーマンス低下 などの問題
  • 本来のネイティブUI開発は 人材難や難易度の高さ が課題
  • ClaudeのようなAIは SwiftUI開発者としても優秀 で、これまでの課題を解決

Emacs文化の拡張と「Emacsification」

  • Emacs文化 ：個人のためのソフトウェアを自作し、他人のアイデアを参考に改善
    • elispで作られたアプリケーションが個人のニーズに合わせて進化
  • Emacsの弱点： UIの醜さ・遅さ・発見性の悪さ
  • AIエージェントの登場で Emacs文化が一般化
    • ネイティブUIも個人仕様で 自在にカスタマイズ可能
  • これからのソフトウェアは「 Emacsified」＝個人仕様・アイデア重視
    • ソースコードよりも プロンプトや発想 が価値を持つ時代へ

個人向けソフトウェアと新しい開発体験

  • AI時代の開発は「 構築(building)」より「 設定(configuring)」に近い
  • 個人の課題解決 に特化したソフトウェアが簡単に作れる
  • 使い捨て・忘れ去られることも多いが、時に 他人にも有用なツール が生まれる
  • 新しい開発体験
    • 副業プロジェクトやニッチなツール の完成率向上
    • 使いやすく、楽しいソフトウェアが増える
  • Emacs自身の存在意義 も相対的に薄れる可能性
  • ターミナルアプリの改善余地 が大幅に広がる
    • 例：iostatやbpftraceの可視化体験の劇的向上
  • ネイティブUI開発 の楽しさと可能性
    • 個人のための「 馬鹿げたほど特化したツール」を気軽に作り、共有する文化の到来

まとめ：今後の展望

  • AIとエージェント技術 による個人向けソフトウェア開発の革新
  • Emacsification によるアイデア共有とプログラマビリティの拡張
  • ネイティブUI開発 の民主化と新しい開発者体験
  • コミュニティの変化 と、より面白い「オタク向けソフトウェア」の増加への期待

Hackerたちの意見

記事は主にスタンドアロンのソフトウェアについてだけど、僕が重視しているワークフローツールの一つは拡張性なんだよね。誰かのneovimプラグインをちょっと試してみて、実際に必要かどうかを判断できるし、必要なら自分の思考モデルにぴったり合うようにカスタマイズできる。自分が欲しいちょっとした機能を追加したり、あまり興味がない便利な機能を取り除いたりもできるし。あと、サプライチェーンの問題についてもあまり心配しなくてよくなった。これまでに、始めた頃に使っていたプラグインの90%を置き換えたよ。それに、面倒なNIH症状からもいい気分転換になるしね。

└

僕も同じだよ。正直言うと、初めて空の設定でEmacsを立ち上げたときは、ひどい見た目だった。でも、プラグインを追加したり、自分の独特なワークフローをサポートするコードを加えていくうちに、だんだん無視できないくらい生活の中で強力になっていくんだ。13年間ずっと手放せなかったよ。AIが開発体験を支配するようになって、Emacsやneovimはさらに良くなった。今はAIに自分のカスタムワークフローを設定に組み込んでもらえるからね。Emacs/neovimはすべてのワークフローツールのゴールドスタンダードであるべきだと思う。

著者はここで本当にチャンスを逃した気がするな。「ソフトウェアのエマクス化」

LLMの時代のおかげで、個人ソフトウェアを作ることに完全に取り組んでるよ。[0] でも正直言うと、Emacsを使っていた時間が「個人ソフトウェアを作る」ことを教えてくれたわけじゃないんだ。僕のEmacsの設定はすごく脆弱で、WindowsとmacOSで使おうとすると悪夢だった。大学のプロジェクトは、org-modeと何かのワークフローを使って美しいLaTeXファイルを作るための、なんとも言えない組み合わせで書かれていて、再コンパイルの方法なんて教えられないよ（もし試みるなら、LLMにLaTeXに翻訳してもらうかも）。僕は生活のメンテナンスをできるだけ少なくしたいし、すべてのことに自分のソフトウェアを作るのは必ずしもそれに合ってるわけじゃない。[0]: NETFXアプリケーションをRustで書き直したのは、20分のインストール時間が気に障ったから: https://github.com/bevan-philip/wlan-optimizer

└

自分の生活はできるだけメンテナンスが少ない方がいいんだけど、すべてのソフトウェアを自分で作るのはそれに合わないこともあるんだよね。だから、LLMは個人用ソフトを作るには十分だけど、維持するにはまだ足りないのかな？

└

「ツールを作る時間がないと言ってる人は、実際には作らない余裕がない人たちだ。」

└

15年間、Linux、Windows、macOSで同じEmacsの設定を使ってる。正直、これがコンピュータライフの中で一番の宝物だよ。

└

自分の生活はできるだけメンテナンスが少ない方がいい。正直、これがどういう意味か全然共感できない。俺はプログラマーだから、毎日の仕事はコンピュータシステムの挙動を変えることなんだ。ローカル、リモート、クラウド、組み込みとかね。要件は変わるし、スコープも揺れるし、問題の領域は進化する。成長したり縮んだり、蓄積は避けられない。言語スタックやデータタイプ、フォーマット、CLIやウェブツール、プロトコル、パラダイム、OSSやプロプライエタリアプリの間をルーチンで移動しなきゃいけない。だから、常に適応し続けなきゃならないし、コントロールプレーンもその変化に追いつかなきゃ。自動化が鍵だよ。そういう考え方を持たないといけない。ちょっとした煩わしさはすべて自動化できるし、すべきなんだ。これは俺のワークフローの終わりのない、止まらない変革だよ。ツールの継続的なメンテナンスなんだ。でも、これは面倒な反応的メンテナンスじゃない。自分のために常にソフトウェアを作りたくないプログラマーだと思うのは妄想だよ。レストランでしかコンロを使いたくない料理人みたいなもんだ。Emacsは料理人の自宅のキッチンだよ。メンテナンスには二種類あると思う：反応的（壊れたものを直す、変化に追いつく）と生成的（ツールを進化する理解に合わせて形作る）。プログラマーは本能的に前者が嫌いで、後者に惹かれるべきだと思う。Emacsは生成的メンテナンスにほぼ唯一適してる。ツールと作業が同じ基盤を共有してるからね。Emacsに関する不満は分かるよ。「設定が面倒すぎる」っていうのはよくあることで、たいていは「価値を得る前に投資したくない」ってことなんだけど、正直それは賢い戦略的思考じゃない。Emacsをキャリアや人生を通じてのメンテナンス負担を最小限にするための普遍的なツールとして扱うのが大事だよ。

「個人ソフトウェア」、つまり自分のために書くプログラムは、1960年代のホームコンピューティングの元々のビジョンだったんだ。PCは本当に予想されていなかったけど、みんなが家にコンピュータ端末を持っていて、必要なことをするプログラムを書くという考えだった。プログラミングは誰でも学べるくらい簡単になると想像されていたんだ。まだそこには達していないけど、LLMのおかげで近づいてきてるね。

└

僕は非コンピュータ専門家として、まさにそれをLLMに使ってるよ。

└

LLMは問題の探求に最適だと思う。特にGoogleの衰退を考えると、タスクを達成するための何かをLLMに出させるのが、実際にインターネットで見つけるよりも難しくなくなってきたと思う。でも、そのタスクが繰り返されるか修正される場合、LLMはプリビルドソフトウェアに対して常に不利だと思う。たとえそのプリビルドソフトウェアが誰かがLLMを使って出力を受け取って、それを受け入れテストに通すだけのものであっても、多くの人は奇妙なエッジケースのデバッグの面倒を避けたいし、「自分も開発者だ！」という新しさはすぐに薄れてしまう。ビジネスクリティカルなロジックを持つエクセルシートの奇妙なグレーゾーンが、LLMがそのロジックを理解できないほど複雑にして、実際のエンジニアリングリソースに押し付けられるのが消えるのは楽しみだ。痛みを伴うかもしれないけど、たぶんそれが最善だと思う…でも、日常的に使う実際のツールについては、そのツールが機能するという保証が、AIの盛り上がりが理解している以上に価値があると思う。

└

まだ取られていない道、それはHyperCardsやVisual Basics、Macromind DirectorsやFlashesの完全な開花だと思う。つまり、非専門家が良く考えられたビルディングブロックと理解しやすいメタファーを使って、著作環境で興味深いソフトウェアを作るというアイデアだ。偶然の複雑さや過剰設計の層を取り除いてね。このビジョンでは、ソフトウェアは依然として慎重な論理的思考を必要とするけど、その思考を実行可能なコードに翻訳するのがずっと楽になる。ツールやビルドシステムの悪夢もなくね。代わりに、私たちのために複雑な呪文を再生産し、再結合できる強力なモデルを発明してしまった。複雑さはまだそこにあるし、非専門家には依然として理解できないけど、もしかしたら彼らがその一部を排除する手助けをしてくれるかもしれない？その道はまだ可能だと思うし、LLMの世界ともうまく補完し合えるかもしれない。LLMが個々の人間がまだ簡単に理解し、手動で修正できるソフトウェアを生成するのを助ける形でね。

└

プログラミングは誰でも学べるくらい簡単になると思われてたけど、LLM（大規模言語モデル）はそれからますます遠ざかってる気がする。結局、StackOverflowの情報をコピー＆ペーストするだけだからね。80年代中頃には、みんながコンピュータを持っててBASICプロンプトで始めたから、プログラミングを学ぶのがもっと身近だったと思う。

└

これは未来において大きなことになると思う。みんなが自分専用の超特化したアプリを持つか、同じアプリ内で異なるUIやビジュアライゼーションを持つことになるかも。アプリケーションの全体的なアイデアがもっと流動的になるよね。もしアプリが動的言語で作られてるなら、ユーザーに自分でコードを書き直させて、新しい機能を追加させるのもアリじゃない？

└

あなたが言ってる状況についての俺の不安は、みんなが独自のアプリやファイルシステムを持つことで、共通のファイルフォーマットがなくなってしまうことだ。そうなると、移行やコラボレーションが面倒になる。多分、ほとんどの人が怠け者だからそこまでにはならないと思うけど、考慮すべき点ではあるよね。

└

これを多くの友達に言ったけど、みんな笑ってる。でも、コンピュータを使うってことは、明らかに「コンピュータがプログラムを作ってくれる」ってことになると思う。私たちはそれについて考えたり、知ったりすることもないだろう。私にとっては、いつかの問題では

この記事は、LLMによるコーディングがもたらすまだ実現されていない変革の一つを示唆してると思う。ElectronやReact Nativeをやめて、LLMにFigmaやワイヤーフレーム、動作仕様を各プラットフォームの本格的なアプリに変換させることができるようになるのかな？CRUDアプリの場合、API仕様やUIモックアップ、あるいはすでにコーディングされたプラットフォームの写真があれば、かなりのところまでいけると思う。LLMが得意とする明確なタスクだし、同様に多くの同等性テストも自動化できるはず。まだ「いつかAndroidも追加するかも」とか「Mac/Linuxユーザーが足りない」とか言い訳が通用するのかな？パスワードリセットのようなあまり使われないフローをiOSアプリに組み込む代わりに、ランダムなWebViewを使うのは正当化できるの？デバイス上に非自明なロジックがあるアプリには、LLMがGoやRustのようなクロスコンパイルが簡単な言語に書き換えるのにかなりの可能性を示してるよ。

└

そうだよ。できるよ。今すぐにでも動くし、めっちゃうまくいく。俺の元々の辛口意見は、今の時点でSwiftUIを学ぶ意味ってあるの？ってこと。大抵のタスクに関しては、「Microsoft Wordを本当に、ほんとに上手に学ぶ」っていうのと同じカテゴリーに入るスキルだと思う。そうする時間をかける人は尊敬するけど、結果はほとんど変わらないんじゃないかな。プログラミング全般についてはそうは思わないけど、今は専門化する理由が、うーん、もっと複雑になってきてる気がする。

楽しい記事だった。LLMの助けでネイティブソフトウェアがもっとアクセスしやすくなるっていうの、同じように感じてた。でも、アプリを試してみたら、大きめのMarkdownファイルを開いた瞬間にスクロールが止まって、アプリがクラッシュしちゃった。小さな概念実証を作るのは簡単だけど、パフォーマンスと信頼性はまだ難しいね。編集：誤字

これ、まさにその通りで、誰にでも言ってるんだけど...(今はリンクがないのが恥ずかしいな。まあ、恥は書くためにはいいことだし、嫉妬もね！) ソフトウェア制作が今やすごく簡単になって、すべてが.emacsファイル（「ドットエマックス」と発音するよ）になってる。つまり、各個人が自分だけの、無限にカスタマイズ可能なソフトウェアのコクーンを持ってるってこと。OPのtptacekが言うように、「既存のソリューションをインストールするより、自分の解決策を作る方が簡単」なんだよね。似たような比喩として、Lisp全般がある。Lispに対する古典的な批判—俺は全然同意しなかったけど、よく聞いたことがあるやつ—は、マクロがあるからLispはすごく柔軟で、プログラマーはみんな自分だけのプライベートな言語にしてしまうってこと。これに関連して、Mark Tarverの2007年の記事「バイポーラーLispプログラマー」があって、長年にわたって多くの議論があった（https://hn.algolia.com/?query=comments%3E0%20The%20Bipolar%2...）。彼は「素晴らしいバイポーラの心」（BBM）について書いてて、その紹介の仕方や公正かどうかは置いといて、最近よく言われる「AI精神病」にも関連してて面白い。Tarverの記事から（https://www.marktarver.com/bipolar.html）：「捨て去りデザイン」というフレーズはBBMにぴったりで、Lispコミュニティから来てる。Lispは簡単にものを捨てられるから、これを当たり前に思うのは簡単だよね。10年前にLispのGUIを探してたとき、9つの異なる選択肢があったけど、どれもちゃんとしたドキュメントがなくて、バグもあった。基本的に、各人が自分の解決策を実装して、それが自分にはうまくいったからそれでいいって感じ。これがBBMの態度だよね。自分にはうまくいくし、理解できる。誰かの助けを必要としない、あるいは求めないっていうのもそう。これって2026年っぽいよね？彼は続けて言う。「C/C++のアプローチは全然違う。ピンセットと接着剤で何かをするのはめちゃくちゃ難しいから、重要なことをするのは本当に大きな成果になる。ドキュメントも必要だし、規模の大きなCプロジェクトでは助けが必要になるから、社交的になって他の人と一緒に働くことになる。そうしないと、どこにも行けないからね。雇用主の視点から見ると、10人がコミュニケーションを取り、ドキュメントをちゃんと作り、一緒に働く方が、1人のBBMがLispをハッキングしてるよりも好ましい。」--- 生産がこんなに簡単だと、消費がボトルネックになる[1]、そして突然、共有が問題になる。これがEmacsの比喩が良い理由だよね。.emacsファイルは指紋のように個人的なものだ。自分のにスニペットをコピーすることはあっても、他の人のを使う理由はないよね（初心者として始める以外は）。自分のを作るだけだし、これらのコクーンがカスタマイズされるほど、他の誰かが理解するのが難しくなるし、理解したいとも思わなくなる。誰かのコクーンを学ぶのが認知コストが高すぎるからではなく、自分のを生成する方が簡単だから。誰かの服を着るのが不快なように、嗅覚も関わってくる。これをAI精神病ではなく、AIソリプシズムと呼びたい。ソフトウェアの世界では、構成管理（最も退屈なフレーズ）が難しい部分になってきてるのが面白い。どうやってソースを共有してバージョン管理するの？そもそもソースって何？プロンプトなの？OPが最後に言ってるのは、「どこかで共有するか、もっと良いのは、作成に使ったプロンプトとスクリーンショットだけを共有すること」だよね。でも、Show HNでこれを使うかどうか試しに聞いたとき、生成したコードを共有するだけじゃなくて、プロンプトを共有するべきだって意見が多かった（ここにまとめてある：https://news.ycombinator.com/item?id=47213630）。こういうダイナミクスが、Githubが抱えているパイプが破裂するような圧力の背後にあるんだろうね。Githubの後継がどうなるかは不明だけど、賢い友人が指摘するように、必ず必要になるだろう。こういうプロジェクトやスタートアップが出てきてるけど、まだ馬なし車の段階にいる気がする。もっと重要なのは、チームワークはどうなるの？もしみんながBBMになったら、あるいは、みんながBBMの個人的な軍隊を持ってて、常にマニックな状態で、私たちのためだけにものを生成するために待機しているとしたら、どうやって一緒に働くの？コクーン同士はどうやってコミュニケーションを取るの？AIソリプシストのチームってどんな感じ？矛盾してるように聞こえるよね。俺の感覚では、AI駆動のエージェント開発の最前線にいる多くのソフトウェアチームやスタートアップが、今まさにこれに取り組んでると思う。哲学的なだけじゃなくて、実際的に、例えば、俺の生成したコードが君の生成したコードとどう組み合わさるのかってこと。こういう摩擦があると、生成されたコードの生産性向上の一部（どれくらい？誰が言える？）を返すことになると思う。こういう影響は時間が経つにつれて現れると思うけど、まだ多くの人が公に話してないのが残念だね。誰もが拍手をやめて座る最初の人になりたくないけど、面白い話ができないのはつまらないし、代わりにこれが初めてのフリーランチ、唯一の欠点のないアップサイドだと偽らなきゃいけないのは残念だよ。議論が退屈になって、進化が遅くなるかもしれない。実験がアイソレートされて行われてるからね。これが新しいツールで最も真剣でリアルで先進的な作業をしている人たち（編集：ソフトウェア開発の分野で）だから、欠点についての話がすべてシニカルな人たちに任されるのは残念だ。彼らがどんな良いポイントを生成するかはともかく、AIがソフトウェア開発に価値がないというのは明らかに間違ってる。AIが人類を滅ぼす話をするのは簡単だけど、バグの数が増えたり、生産性がしばらくしてから横ばいになる話をするのは難しい。とにかく、実際に何が起こっているのか知りたいし、人々がそれにどう対処しているのか、そしてそれが時間とともにどう発展するのかを知りたい。ミートアップに行かなきゃいけないのかな？

└

ターバーの作品は初めて見たけど、面白かったし、的を射てた。そう、LLMはEmacsのクルフトをみんなに広めてる。ディスク上の使い捨て文化は、土の上のそれよりずっと心配が少ないよね。

└

この状況にはLLMが生成した文章の問題と共鳴する何かがある。GPT 5.5が悪い文章を書くわけじゃない（良い文章とは言えないけど、ひどくはない）。でも、一度そのテキストがGPT 5.5のものであることに気づくと、脳が「これはただのGPTの出力だよ。自分でGPT 5.5に質問すれば、もっと自分の知りたいことに合った答えが得られるよ」って思い始める。なんでこの特定のLLMとの会話の産物を読んでるんだろう？会話の内容が分かれば、自分でより良い会話ができるしね。多くのソフトウェアでも同じことが言えると思う。ある種の「味」があるのかもしれないけど、結局気にするのはアイデアや「レシピ」だよ。それに、毎月「Vibe HN」スレッドをやった方がいいよ。

└

もっと重要なのは、チームワークはどうなるの？ みんなが今やBBMになってしまったら、あるいは、みんなが個人のBBM軍を持っていて、常にマニアックな状態で、いつでも私たちのためだけに物を生み出すために待機しているとしたら、どうやって一緒に働くの？ コクーン同士はどうやってコミュニケーションを取るの？ AIのソリプシストたちのチームってどんな感じになるの？ 矛盾してるみたいだね。チームワークの一例として、プログラマーと研究者が一緒にUNIXシステムを作ったことがあるよ（https://www.cs.dartmouth.edu/~doug/reader.pdf）。これは製品ではなく、Cで書かれたツールを使って実用的な問題を解決するために最適化された環境なんだ（その間、BBMたちはボストンでLispに忙しかったけどね。;-) C++は全く別の話で、そっちはIDEが必要だよ。

今日のソフトウェアは圧倒的にパッケージ化されていて、通常はプロフェッショナルなものだと思うけど、そろそろオタクたちが取り戻すべきだね：* ポッドキャストアプリ * 音楽再生アプリ * フィードリーダー * Blueskyクライアント * ノート取りアプリ * デスクトップのブックマーク/後で読むアプリ * チャットやインスタントメッセージング * タイムトラッカー * レシピ管理アプリ これらはすべて、Claudeから置き換え以上の結果が得られるものだよ。必ずしも最高ではないし、必ずしもグローバル競争力があるわけじゃないけど、自分の独特な作業スタイルにぴったり合ったアプリケーションだと思う。Music.appは本当に使いづらいし、使ってるとそれが俺に合うようにサービスを提供するのが大変だってわかる。でも、Appleはずっと前にMusic.appから意味のある部分をMusicKitに分離したんだ。なんでまだMusic.appを使ってるんだろう？MusicKitが今の本当の製品だよ。これは新しいことだね。

└

共通の要素：データは自分が所有するか、少なくともアクセスできるようにする必要がある。企業はコンテンツを所有し、アクセス方法をコントロールする壁のある庭を作るのが大好きで、これがパーソナライズされたインターフェースを不可能にしてる。もっと反発できるといいな。

└

たくさんのものが再評価されてるよ。「素晴らしいセルフホスティング」のGitHubリポジトリをチェックしてみて。ポッドキャストやオーディオブック、音楽は500種類のサブソニッククライアントがあって、その中には良いものも多いよ。面白いフィードリーダーもたくさんあるし、トーバルズのフィンにある砂の粒よりも多いかも（笑）。ノート取りも数えきれないくらいあるし、もちろんnvimやemacsを使えばいいよ。チャットも、組織が毎月何千ドルも節約できるような素晴らしいセルフホスティングの選択肢がたくさんある。ゼロから自分で作る代わりに、すでに解決されている問題を再発見するのではなく、FOSSプロジェクトに貢献したりフォークしたりするのはどう？ LLMのおかげで、大きなプロジェクトにスムーズに追いつくのが簡単になったしね。

└

私たちのソーシャルメディアは分散型で、ローカルファーストであるべきだと思う。どんなOSでも使えるカスタムクライアントを可能にするために。これがその実験だよ：https://github.com/dharmatech/9social 最初のクライアントはplan9用に書かれてる。これでデザインが正直になるんだ。（plan9/rc/acmeで動くなら…）動画デモもあるよ：https://youtu.be/q6qVnlCjcAI 現在の実装は3000行未満のコードでできてる。で、Emacsの話だけど… 9socialはOrg SocialというEmacsプロジェクトから大きなインスピレーションを受けてるんだ：https://github.com/tanrax/org-social

└

メールもリストに加えたいな。メールはまさに破壊を待ってる状態だよ。

vim README.md で十分だって思ってるのは私だけじゃないよね。等幅フォントが制限だなんて考えたことないし、むしろ好きなんだ。色付きのレンダリングもすごくいい感じで、サクッと解析するのに必要な視覚的な手助けはそれだけで十分。目次があると便利かもしれないけど、もし :Toc がまだないなら、作るべきだね。

└

マークダウンのテーブルは本当に読みづらいと思う。

大事なのはアイデアで、「ああ、これできるし、うまくいくよ」っていう観察だよね。 > > 私が話してるようなソフトウェアでは、ソースコードよりもプロンプトが欲しいんだ。そうだね。広い意味でプログラミングは複雑さや情報を管理することだよ。インターフェースや抽象を構築して、どの詳細がインターフェースにとって有用か（どれが無視できるか）を選ぶこと。LLMの「魔法」の部分は、無構造でごちゃごちゃした入力から有用な出力を得られることなんだ。これがプログラミングに影響を与えるのはちょっと驚きだね。たくさんのことが変わるけど（「これをするアプリを書いて」っていうのが「小さな」ことに対して実現可能になる）、ある意味で根本的な問題は残ってる。