GDD - 「ガスライティング駆動開発」の時代

 (tonsky.me)
12 ポイント 投稿者 GN⁺ 2025-07-21 | 6件のコメント | WhatsAppで共有
  • 最近のコンピュータ利用者は、自分の意思とは無関係に、数多くの意味のない作業を繰り返し実行し、コンピュータに言われるがまま従っている
  • LLMが開発者のAPI設計のやり方に影響を与え、実際にAIが提案した機能を開発者が受け入れ、まもなくコードの大半をAIが書くようになるという予測まで現れている
  • たとえば、SoundsliceはChatGPTが誤って案内した機能を実際に追加した
  • これは、LLMが数多くのAPIを分析し、開発者が最初に思い浮かべそうな直感的な設計を提案するため
  • 新しいアイデアや独特なアプローチを開発する際にはLLMは適していないが、多くの場合、最も当然な設計に従うことが効果的でありうる
  • いまやAIがツールの利用だけでなく、ツールの設計方法まで主導する時代に入りつつある

Gaslight-driven development

日常化した無意味な作業

  • この10年、コンピュータを使う人々は、会員登録、メール認証、Cookie同意、CAPTCHA入力など、本質的には不要な作業を繰り返してきた
  • ユーザーは望んでいなくても、コンピュータが命じるとおりに従うしかなかった
  • こうした反復作業を通じて、私たちはすでにある程度、機械に言われるまま従う生活に慣れてしまっている

LLMが変える開発の現実

この現象の意味

  • この変化が肯定的なのか否定的なのか判断しにくい
  • 一方で、LLMは数多くのAPIを学習してきたため、開発者にとって「最も直感的」な方法を提案する効果がある
  • 初心者の視点（newbie’s POV）でAPIをテストできる新しい方法でもある
    • 以前は開発者がミスをすると自分でドキュメントを調べて修正していたが、いまはLLMが誤った使用例を継続的に提示することで、開発者側も問題をより早く認識できる

限界と悩み

  • 革新的な作業にはこのアプローチは向いていない
    • LLMは馴染みのないパターンや、まったく新しい概念を理解できない
  • 結局、APIのような領域では「平凡さ」が最善なのかもしれない
    • 多くの状況では複雑に設計するよりも、AIと開発者の双方が直感的に理解できる形のほうが有利だ

結論: 新しい時代の始まり

  • AIはもはや与えられたツールを使うだけにとどまらず、ツール自体がどう設計されるべきかについて意見を持ち始めている
  • そしてその意見はしばしば、「もともとそうだったかのように」開発者や組織をガスライティングする形にもなりうる
  • 今後はAIの期待と常識に合わせた開発が自然な標準になる可能性が高まっている

関連記事

6件のコメント

 
ffdd270 2025-07-21

たまに、経路依存性という大きな概念に、LLM依存性という強力な釘が打ち込まれているように感じることがあります。『以前から使っていたから』が『LLMが好むから』へと変わっていく感覚は、結局どうなっていくのでしょうか……
 
kandk 2025-07-21

以前から使っていたものを、LLMが学習したんですよね..
 
jujumilk3 2025-07-21

「もうコンピューターの電源を切っても大丈夫です」
 
rosen 2025-07-21

完璧な比喩!!
 
GN⁺ 2025-07-21
Hacker Newsの意見
  • LLMが実在しないAPIエンドポイントを勧めてくる状況で、それを受けてわざわざそのエンドポイントを実装し、わざと421: Misdirected Requestステータスコードを返したらどうなるか想像してみた。あるいは実際の501: Not Implementedを使う手もある。もし501だとニュアンスが合わないなら、513: Your Coding Assistant Is Wrongという新しいステータスコードを提案したい
    HTTPステータスコードのWiki
    • 513: Your Coding Assistant Is Wrongというアイデアがとても面白かった。おかげで楽しめた。一方でHTTP 407 Hallucinationも推したい。サーバーがリクエスト自体は理解しているが、現実とは一致しないと判断した、という意味だ
    • この話は、自分にはGPSが間違っていると知らせる面白い警告標識の事例ともつながった
      GPS is wrongの事例
    • 513ステータスコードの導入に一票。すでに418コードもあるのだから、513があってもいいと思う
    • もしこういういたずらをしたいなら、ぜひ418レスポンスを使ってほしい。もっと広く使われてほしい
  • 複数のユーザーが同じページを見ているのをリアルタイムで見るのは面白いが、出入りし続けるユーザー表示のせいで文章を読むのがとてもつらかった
    • こういう固定要素やsticky要素を一気に消してくれるbookmarkletをブックマークバーに入れてある。これを使うとページ上の固定/sticky要素が全部消え、スクロールも復活するのでよく使っている
      （JavaScriptコードあり）
    • 自分も同じように不便だったので、右クリックしてInspectで開発者ツールを開き、下のコードをコンソールに貼り付けるとそのユーザー表示領域が消える 
      document.getElementById("presence")?.remove();
      なぜ脳がわざわざこうした動きに敏感に反応するのか気になるなら、捕食者検知の本能に関係している
      科学論文リンク, 神経科学のWiki
    • Chess Royaleというゲームを思い出した。アバターと旗で似たような体験があったが、本当によくできたゲームだったのに、Ubisoftが時々やるようにサービス終了してしまった。惜しまれる名作だ
      Chess Royaleのスクリーンショット
    • 昔、背景にカーソルが大量にあったページではなかったかと思う。このレベルになると、わざと気が散るように作ったジョーク的なデザインコンセプトだと思う
    • uBlockのようなツールでページ要素を消そうとして、もぐらたたきのように高速で繰り返される状況を経験した
  • Instantではtx.update関数がエンティティの挿入と更新を両方担当するようになっているが、LLMはずっとtx.createを書くので、結局tx.create関数も作った。こういう紛らわしい部分で、LLMだけでなく実際の開発者たちも無駄に多くの時間を費やしてきたのではないかと思う
    • そもそもtx.createが最初から存在しなかったなら、誰かが時間を無駄にすることもなかったのではないか
  • 挿入と更新の両方をサポートする関数なら、updateよりputと名付けるほうが正しいと思う。updateは誤解を招きうる
    • そういう場合はupsertが適切だと思う
    • putという名前は既存内容を上書きすることを示唆し、upsertは挿入/更新の両方を意味する、という違いがある
  • LLMが間違ったテキストを出力したからといって、自分がコードを1行変える前に宇宙が熱的死を迎えそうだ。こんなばかげた理由でコードを変えなければならないという発想が、自分には滑稽で受け入れがたい
  • ポストの主張には同意しない。本当に私たちはコンピュータの望む通りに従うべきなのか、その発想自体に疑問がある
    ユーザーがメール認証や会員登録をする理由も、コンピュータに命じられたからではなく、人間による設計上の選択だったと思う
    • こうした内容をthesis（論旨）と呼ぶこと自体が寛大すぎる解釈だと思う。自分はその部分を見てすぐページを閉じた
  • 最近チームと一緒に、これからのコーディング原則について面白い会話をしたことがある
    今後はコードの可読性やSOLID原則、複雑性に集中するのではなく、自分が使うagentic IDEがコードコンテキストをどれだけうまくインデックスできるか、モデルがそのコードからどれだけ良い生成能力を見せられるかのほうが重要になりそうだ
    コード変更の速度が非常に速くなるぶん、コードの保守性がむしろ中核的な指標になり、プロンプトとコードの整合性や、偶然うまく噛み合ったコードの有用性がより注目される世界が来るだろう
  • もし誰かが一貫して自信ありげに、新しい（実際には虚偽の）開発アドバイスを、自分が作った製品について言いふらしていたら、企業としてそんな想像上の機能をそのまま追加し、困惑したブログ記事を書くのだろうかと疑問に思う
    • 自分がいっそLLMのように振る舞って的外れなミスをしても、自信満々に言い張ればみんなそのまま理解してくれるのだろうかと気になる
    • 実際のところ、“Clean Code”の著者であるMr Martinもこういうスタイルではないかと振り返ってしまう
    • もしその人が自分の顧客の90%に影響力を持っているなら、たぶん本当にその想像上の機能を導入するかもしれない
    • たいていの企業は、その不要な機能が絶対に必要だと自信満々に主張しそうだ
  • LLMとのすばらしい友情の始まりのようにも感じる。fractional CTOとして働いていて最ももどかしいのは、クライアントごとに環境名のような細かな命名規則がすべてバラバラなことだ
    たとえばAWSの領域にはdev``prodがあり、Expoにはtest``productionがあるので、複数のプロジェクトを行き来すると、思った以上に頭を使わされる
    LLMもこうした問題をはるかに大きな規模で経験しているのだろうと思う
    こうした不要なAPI命名/挙動の混乱に使われていた脳のシナプスを、本当に意味のあることへもっと回せるなら、それが最善だと思う
    • コンピュータサイエンスには難しい問題が3つあるというジョークがある――キャッシュ無効化、名前付け、そしてoff-by-oneエラーだ
      LLMがどれだけ賢く名前を付けても、incoherent stochastic process（首尾一貫しない確率的過程）に基づく以上、問題は残る
      そして、なぜ環境の命名が統一されていないのか真面目に問い直したことがあるのか、と聞きたい
      以前CTOだった立場からすると、こうした点は組織内のコミュニケーションや基準不足など、改善すべき兆候だと思う
      実際に文化を改善し、メンバーの意識も高められるのだから、簡単に直せるこの種のことをLLMに任せるのではなく、もっと直接面倒を見るべきだと言いたい
  • 関連リンクとして
    以前のHacker News議論を見る
 
dkmin 2025-07-21

Soundsliceのバイラルな成功