AIコード生成の限界と人間の感覚喪失に関する個人的ケーススタディ

 (github.com/jackdoe)
1 ポイント 投稿者 GN⁺ 2025-11-11 | 1件のコメント | WhatsAppで共有
  • RP2350 RISC-VコアをデバッグするためのSWDプロトコル実装ライブラリで、Raspberry Pi Pico2を使い、別のPicoをプローブとして用いる構成
  • コードの約**80%はAI（Claude）**によって生成されており、筆者はオシロスコープと文書を通じて基本プロトタイプを作成した後、AIにコードの拡張を任せた
  • プロジェクト進行中、AIコードの無意味なトークン構造、文脈の喪失、コードへの所有感の喪失などにより、強い嫌悪感と懐疑を経験
  • 一方で、AIを文書分析・データデコード・構造体生成などの補助ツールとして活用したときには肯定的な体験を得た
  • この事例は、AIコード生成の品質・感覚・所有の問題を浮き彫りにし、プログラミングの本質と人間の役割に対する根本的な問いを投げかける

0. VIBE CODE WARNING

  • 全コードの約80%が**AI生成（vibe coded）**で、READMEの大部分も自動生成
  • 筆者はオシロスコープと文書を参照してSBA、レジスタ読み書き、抽象コマンド、PROGBUFなどを自力で実装した後、ライブラリ化をAIに任せた
  • コードが1,000行から4,000行へと増えるにつれ、コード構造と意味を完全に見失い、自分が書いたコードだと感じられなくなった
  • AIがdap_read_mem32を誤って解釈し、プロトコルエラーと非論理的なコードが大量に発生
  • 結果として、1万行近いコードを10時間で完成させたが、達成感や成長実感はまったくなかった

AIコードと人間コードの違い

  • 人間が書いたコードは意図と目的を持つトークンで構成されているため理解できるが、AIコードのトークンは意味のない組み合わせとして読みにくい
  • AIコードの一部は人間より高品質に見える一方、そのすぐ下の行は見た目だけもっともらしい誤りコードであることがある
  • このような不均質さと感覚的な信頼の喪失が、プログラマの判断力を麻痺させる
  • コードが大きくなるほど、「良いコードか悪いコードかを感じ取る感覚（taste）」が失われ、精神的モデルと所有感が崩壊する

人間的な感情と懐疑

  • 筆者は「これはプログラミングなのか？」という問いを投げかけ、嫌悪感と羞恥心を表明
  • AIがコードを代わりに書く時代に、人間は何を作り、どこまで関与すべきなのかという存在論的な混乱を吐露
  • 単に「コードを書かないこと」が進歩なのか、「問題をモデリングしないこと」が効率なのかさえ確信が持てない
  • 自分はいまでも何かを自分の手で作りたいが、AI中心の開発環境ではその意味が薄れてしまったと述べる

AIの肯定的な活用経験

  • AIを文書分析、オシロスコープデータのデコード、C構造体の自動生成などに活用したときは、効率的で満足度が高かったと評価
  • 特に最初のレジスタを読み、SBAを通じてメモリを読めたときには本物の達成感を覚えた
  • つまり、AIをコード執筆者ではなく補助者として使うときには、肯定的な体験が可能

結論としての省察

  • AIコード生成は高速だが、意味・感覚・所有の喪失をもたらす
  • 人間が感じる「良いコードの味（taste）」が失われるとき、プログラミングの本質も揺らぐ
  • 筆者はこの現象が一時的な過渡期であることを願いつつ、「より良いプログラミング」とは何かを自分でもまだ答えられないと締めくくる

原文以降の技術セクション（1〜20）は、RP2350 RISC-Vデバッグプロトコルの詳細実装文書であり、SWD階層構造、DAP/DAPCレジスタ、PROGBUF実行、SBAアクセス、ハート制御、トレーシング、リセット、デュアルハート構造など、デバッグスタック全体の完全な技術仕様を含む。
しかし中核テーマは、「AIが生成したコードと人間の感覚の断絶」に関する**個人的ケーススタディ（Vibe Code Warning）**である。

関連記事

1件のコメント

 
GN⁺ 2025-11-11
Hacker Newsのコメント

  • 「AIがプログラミングの楽しさを奪った」と言う人たちの感情には共感するが、私は**「やること」より「完成させること」のほうが重要だと考えている
    昔はガス灯をともしていた人が電灯によって職を失ったが、結局重要だったのは都市に    明かりを提供すること**だった
    私にとってAIは、アイデアを実現し結果を生み出すための道具だ。私は今でも「本物のプログラマー」たちと同じくらい時間と努力を注いでいるが、その焦点は問題定義、モジュール化、テスト、バグ修正、反復的改善にある

    • 「やること vs 完成させること」という二分法は危険な考え方だ
      人間が意味と尊厳、喜びを感じられる世界を作ることが重要だ。
      もしおいしい食べ物を食べるとして、それを作った人たちが苦しんでいたり、あるいは悪意ある勢力がロボットで作った料理だったりするなら、私は望まない。
      社会は人間のためのものであり、単なる効率のチェックリストではない
    • 「完成させること」とは何なのか。AIがもたらした速度と複雑さのせいで、結果の検証はますます難しくなっている
      個人プロジェクトならよいが、顧客やユーザー、株主がいる環境では証明可能な結果が必要だ
      ガス灯の比喩は適切ではない。AIは電気のような物理システムではなく、ソフトウェアだ。
      結局重要なのは問題解決だ。解決できていないなら、それは単なる労働にすぎない
    • ガス灯の比喩は不適切だ。ガス灯をともす仕事は創造的表現ではないが、コードを書くことは創造的な行為だ
      多くの人は単に便利なソフトウェアを作るためだけでなく、創作の楽しさのためにコードを書く
      「本物のプログラマー」たちも同じように、考え、定義し、テストし、修正することに時間を使っている
    • AIや技術が生み出しているもののかなりの部分は、実際には不要な仕事だ
      「スマート・デンタルフロス・ディスペンサー」や自動トイレットペーパー購入機、あるいはClippyのようなボットは、時間とエネルギーの無駄だ
    • 職人気質と知識との関係が重要だ
      単に結果を得ることよりも、学び理解する過程から得られる満足感のほうが大きい
      サバイバル記 Adrift, 76 Days at Sea を読み、深い知識が生死を分けるのだと感じた
      これは、データを自分でホスティングするか、集中型サービスに任せるかという問題にも似ている

  • インターネットで自分の考えを完璧に表現した文章を見ると、本当に慰められるような気持ちになる
    「プロンプトをこう調整しろ」という雑音ではなく、人間的な経験を語ってくれてありがとう

    • 私も同じだ。AIを長く使っていると、YouTubeを無意識にスクロールしているときのような空虚で目的のない感覚になる
      この状態から抜け出すには、一晩しっかり眠る必要がある
    • AIをExcelのように扱えばいいと考える人もいるが、私にはスロットマシンに近いと感じられる
      ほぼ正しい答えを返してくるが、心理的にはギャンブル機械に似た中毒性がある

  • 誰かが「AIで1万行のコードを10時間で書いたが、ひどいものだった」と言っていたが、その体験はアプローチ次第でまったく変わる
    プロンプトの構造化、計画、レビュー、テスト、速度調整など、あらゆる要素が人によって異なる
    多くの初心者開発者は「vibe coding」と呼ばれる即興的アプローチを試して失敗する

    • 私もエージェントシステムを調整しながら、新しい失敗の仕方を絶えず発見してきた
      疲労感が大きいので少し休んでおり、いつか自分でエージェントを作るつもりだ
      OpenAI、Microsoft、Anthropicのようなビッグテックにこうしたものを任せるのは危険だと感じる
    • まだvibe codingで作られた大規模オープンソースプロジェクトを見たことがない
      結局は言葉だけの流行語にすぎないと思う
    • そこまで努力して、結局**自分でコーディングするより速いのか？**と疑問に思う
      新しいライブラリを学びたくなくて、プロジェクト管理に逃げているようにも感じる
    • あなたの言うことは正しいが、「正しいアプローチ」が何なのかを具体的に説明してくれる人はいない
      以前話題になった 「Just Talk to It」 という記事も、細部は不足していた
    • vibe codingは結局計画能力の代理指標のようなものだ
      即興的であればあるほど、より徹底した計画が必要になる。あなたの言いたいことはそこか？

  • 公開されているコードは、もはや人間が作ったものではなくなりつつある
    こうしたコードが再び学習データに入れば、世界はさらに多くの無意味な成果物で埋め尽くされる危険がある
    すでに言語研究でも、機械生成テキストが多すぎてデータ収集が無意味になった事例がある

    • 大丈夫だと思う。AIはゴミのようなコードを大量に作るが、結局人間がその中から宝石を見つけ出す
      ほとんどの場合、いまだに人間が方向性を決めている
      もちろん12歳の子が「yolo 3d game now」と打ち込むなら心配だが、同時にそれはそれで面白そうでもある
    • 興味深い指摘だ。この現象はモデル汚染(model poisoning) に似た効果を生むかもしれない

  • vibe codingされたコードを読むと、まるで 「English as She is Spoke」 のように感じる
    文法は合っているが、人間の言語のようではないコードだ

  • 私も似たような感覚がある
    普段アプリを開発するときは、数日かけて頭の中にメンタルモデルができあがり、シャワー中でさえ構造を組み直したりする
    だが vibe coding をすると、この内的な文脈が失われ、コードを読むのが苦痛になる
    一方で、自分で書いたコードを読むのは楽しい

    • 私は今でもその感覚を持っているが、コードレベルではなくシステムレベルでだ
      システム間の接続やデータフローは理解しているが、実装の細部はぼやけている

  • 私も似た経験をしている。LLMはプログラミングの楽しさを減らした
    今のルーティンは「プロンプトを書く → 少し待つ → 繰り返す → コードレビュー」の連続だ
    コードの構造は理解しているが、自分の手で直接扱っていないため、理解の深さが浅くなる
    適切な訓練があれば可能かもしれないが、まだその段階には達していない

    • 私はLLMにコードは任せず、アイデアのブレインストーミングにだけ使っている
      テストコード生成には有用だ。良いテストを1つ自分で書き、残りはAIに任せて時間を節約する
    • 少なくともLLMが作ったコードについては、自動テストを自分で書いている
      そうすることで限界を把握し、よりよいシステム設計で書き直せる
      LLMの冗長なコードでも、過去の開発者たちが残した奇怪なコードよりはましだと感じる

  • 少し大げさな文章ではあるが、私も共感する
    LLMは既存コードの理解と要約、自動補完、非開発者のプロトタイピングには有用だが
    本番コードの作成には決して使うべきではない

  • 解決策はモデルをgroundingすることだ
    コードにおいては、テスト駆動開発(TDD) がその方法になる
    まずテストを書き、失敗を確認し、その理由を検証したうえでコードを書かせる
    そうすればコードの振る舞いの仕様書が生まれ、その後に人間やエージェントが参照できる文書になる

  • GitHubのREADMEを最後まで読んだところ、作者はコードの4分の3がAI生成物であると認めながら、なお著作権を主張していた
    人間が作っていないコンテンツは、法的に著作権保護を受けられないという判例がすでに存在する