ベテラン開発者のバイブコーディング：8ビットアセンブリから英語-as-コードまで
(levelup.gitconnected.com)- 40年のキャリアを持つ開発者が、AIコーディングアシスタントと2週間にわたるプロジェクトを進めながら、バイブコーディングの実体験を記録した文章
- Tower of Hanoiパズルソルバーを実装する過程で、300回あまりの対話を通じてコード全体をAIが生成し、人間はレビューと方向付けに集中する方式を採用
- 結果として、高い生産性（最大2倍）、驚くほどの正確さと創造的な証明といった長所がある一方で、20%の誤り・不完全なコードや産業用としては過度な複雑さといった短所も併存
- 筆者は、AIとの対話が没入（flow）と学習効果をもたらす一方で、信頼と制御の緊張を生む心理的体験でもあると評価
- 結論として、AIコーディングは強力な相棒であると同時に危険な自転車にもたとえられ、経験豊富な開発者が主導して扱うべき新しい協業パラダイムとして提示される
序文 — Vibe coding
- Vibe codingは、LLMベースのAIエージェントが記述・リファクタリング・デバッグを担い、私は何を作るかに集中する開発スタイル
- コーディングは、私とAIの同時協業で進む場合もあれば、AIに全面委任される構造でもある
- 私はこの方式を、興味と恐れが共存する変化として受け止めつつ、プログラミングの芸術性が知能ロボットの組み立てラインへと変わるのかを問う
- 検証のため、2週間で計40時間をかけ、最新のコーディングアシスタントと小規模プロジェクトを協業してみた
- プロジェクトは、Python約5k LOC・50ファイル・20クラス規模で、教科書的なAI探索アルゴリズムによって典型的なパズルを解く自己指示的な実験
- 成果物は**コードリポジトリとドキュメントの形で公開されており、この記事は何をし、何を理解し、何を学び、何を感じたか**の記録である
- 私は80年代に8ビットマシン上のアセンブリから始め、40年のコーディング経験を持ち、20あまりの言語を使ってきた
- 科学・モバイル・業務用ソフトウェアを個人およびチーム単位で開発した経験がある
- また、（LLM以前の時代の）AI博士号も持っている
- 「AIをやっている人間が、AIアシスタントでAIコードを作る」というエコーチェンバーのような状況には、何か面白いものがあるはずだと思った
1. ソフトウェア概要と開発プロセス
- Tower of Hanoiパズルを解ける柔軟で教育的なソルバーをPythonで実装してみた
- このパズルは、円盤を特定の規則に従って柱の間で移動させる数学的問題であり、ディスク数が増えると解の長さが爆発的に増加して人間には想像しにくくなるが、機械なら探索アルゴリズムで容易に解ける
- ソルバーは古典的バージョンだけでなく、(a) 任意の開始・終了状態、(b) 複数のディスクを同時に動かせる一般化バージョンまで処理する
- 実装した探索手法には、再帰、BFS、DFS、反復深化、A*、貪欲探索、双方向BFSなど、最適・非最適の戦略をすべて含む
- アルゴリズムはCLIベースのPythonスクリプトに含まれており、段階的な可視化、手法別の性能ベンチマーク、多様な初期/最終構成への対応といった機能を備える
- すべてのコードとデータ構造は最初から新規に作成し、開発プロセスはCursor IDEでAIアシスタントと英語で対話しながら進めた
- 人間が直接書いたコードや文書はなく、AIと私の技術的対話を通じて生成された
- 合計40時間で300回以上やり取りし、平均8分に1回の相互作用で、実際の時間の大半はAI出力のレビューと評価に費やされた
2. AIアシスタントの性能は？
- 私はAIアシスタントが示したコードと自然言語の理解レベルに深く感銘を受けた
- 自分では説明が曖昧だったと思うときでさえ、アシスタントは意図を汲み取り、より明確に言い換えて説明してくれた
- （Python）言語の運用能力は、正確さ、速度、文法と意味の理解、ライブラリ活用の面で超人的な水準にある
- 対話はときに本物の知性のような洞察を見せる。たとえば、未解決パズルの例外処理が必要かと尋ねると、すべてのパズルは解決可能であることをグラフ空間での背理法によって示した
- 私は同じ証明を手で10分ほどかけて考えているところだったが、アシスタントは**30秒で証明（QED）**を書き上げ、私はさらに30秒で納得し、9分節約できた
- 単純なアルゴリズムの問題で私が間違っていたこともあったが、批判しない態度のおかげで、気まずさよりも解放感と軽い笑いを覚えた
3. ところで、使ったAIコーディングアシスタントは何か？
- 最新のAIコーディングアシスタントを3つ試した: OpenAI o3、Anthropic Claude Sonnet 4、Google Gemini Pro 2.5
- o3はコードを書くことそのものより、参考文献の確認、アルゴリズム特性の検証、言語セマンティクスへの問い合わせ、コード整理スクリプトの生成、挿絵の制作、文章への補助的な意見といった周辺作業に向いているという結論になった
- Geminiでは、懐かしさのある作業としてチューリングマシン風プログラムを作らせてみて興味深かった。生成された文章は魅力的で、コードも効果的だった。Hanoiプロジェクトの初期設定と実装の**約15%**をGeminiが担当した
- その後Claude Sonnet 4を試したところ、深い理解と洞察、対話の没入感をすぐに感じた。未解決パズルが存在しないことを証明した事例は、まさにSonnetらしい強みだった
- インターネットで調べると、私と同じ考えの人が多く、Claude Sonnet 4は複雑なコーディング作業で広く評価されていた。より強力なClaude 4 Opusもあるが、コストと規模を考えて最終的にSonnetを選んだ
4. コードについての対話
- AIアシスタントと対話していると、機械ではなく非常に有能で高速な人間のプログラマーと話しているように感じる
- 対話のレベルは実装の詳細よりもアイデアの領域に近い
> 例: 私はタイムアウト処理の仕方が弱いソルバーに有利だと指摘し、「Timeouts」列を追加してタイムアウト時間を反映しようと提案した
> Claudeは同意し、タイムアウト処理コードを点検・修正した結果、4つのファイルが更新され、テストまで完了して期待どおりに動作した
対話の要点: 主要なやり取りの要約、長文の対話ログ - こうした対話を経てコードが成長し改善されていく過程を見るのは、挑戦的でありながらやりがいのある体験だった
- アイデアを自分で実装するときのflowに似ているが、より抽象的・概念的なレベルで没入状態を体験した
- AIと良い対話をするために必要な要素は、人間との会話と同じだ: よく聞くことと良い質問をすること
- 具体的には2つの能力が必要
- 1. 質問・提案・ヒントを精緻にする能力
- 「プロンプトエンジニアリング」が必要とされる理由
- オスカー・ワイルドの引用: 「質問が無礼なことは決してない。ときどき無礼なのは答えのほうだ」
- 2. 返答を熟考して解釈し、再検討し修正する能力
- すべてに耳を傾けるが、何一つそのまま信じないという姿勢
- 1. 質問・提案・ヒントを精緻にする能力
- これはドナルド・クヌースのLiterate Programmingという概念にも新しい意味を与える
- 従来はコードのページ内で自然言語の仕様とコード実装を空間的に並置していたのに対し、
- 今ではAIアシスタントとの対話の中で時間的に交差する形になっている
- 私は物語の半分だけを書き、残りはAIとの対話で埋めていく構造だ
5. AIの欠陥、エラー、バイアス
- AIアシスタントは完璧にはほど遠い
- 約300回の対話のやり取りのうち20%は、AIが持ち込んだ満足できないコードの反復修正・バグ修正に費やされた。残りは建設的だったが、この20%は無視しにくい比重だ
-
問題の種類
- Flaw（欠陥）: 全問題の約60%
- すぐに表面化する不便さ、期待に届かないコード、少しずつずれた結果
- 反復修正が必要で、しばしば手作業より速いが、常にそうとは限らない
- Error（エラー）: 全問題の約40%
- 最初は問題なさそうに見えるが、分析すると大幅な修正が必要なコード
- Flaw（欠陥）: 全問題の約60%
-
Flawの事例
- 1つのクラスを単純化しようとして、逆に10個の複雑なクラスへのリファクタリングを提案
- 並行性と並列性の違いを見落とし、まったく別の実装を生成
- 数千行に及ぶボイラープレートファイルを作り、人間には読みにくくする
- リファクタリングの過程で道に迷うか諦めて、謝罪メッセージを出力
- 過度に正直だが冗長なネーミングで可読性が低下
- 勝手に判断して機能ブロック全体を削除し、単純な解決を試みる
- 不要なコード重複が発生
- 新しいコードが既存コードを置き換えたのに、旧コードが残存
- 命名の不一致を自力で認識できない
- 議論した文脈と反対にマルチプロセスIPCソリューションを提案し、性能に不適合
- 同一インスタンスを重複して解決し、誤った統計を算出
- 特定インスタンスの解法を集合全体の解法として誤表示
- 単にファイル名の変更が必要だっただけなのに、複雑なパッケージ構造の再編を試みる
-
Errorの事例
- 中央の柱と右の柱を取り違え、コードの正確性を損なう
- 単体テストが通った理由が、単にTrueを返していたからだった
- 非最適なアルゴリズムを最適だと主張し、後になってバグを発見
- 完了・テスト済みの更新だと主張したが、実際には未完成
- 削除依頼された機能を出力だけ隠し、内部ロジックはそのまま維持
- 修正の過程で微妙なリグレッションバグを導入
- A*探索で許容的でないヒューリスティックを使用し、最適性を損なう
- 失敗またはタイムアウトしたインスタンスを成功・0秒で解決と記録し、統計を歪める
-
観測されたバイアス
- 大規模な産業コードベースの学習の影響で、文脈と無関係に産業向けソリューション志向になる
- 例: 不必要に複雑な型注釈の過剰使用で可読性が低下
- リンター・静的解析ツールの指摘に合わせようとするバイアス
- コードの可読性や機能向上に寄与しないまま、不要な複雑性を追加
- 結果としてスタイル最適化に執着し、明確さと機能実装を犠牲にする傾向がある
- 大規模な産業コードベースの学習の影響で、文脈と無関係に産業向けソリューション志向になる
6. 慎重な導入が必要
- AIアシスタントが生成したコードを使うときは、必ず注意深く読み、検証しなければ、自分がコードの主人ではいられない
- コードの大半は優れているが、一部には微妙で検出しにくい形でプロジェクトの方向性や健全性を損なう危険がある
- 開発全体の方向性を自分が強く主導しなければ、AIが提示する産業向けのデータ構造・ベストプラクティスに引っ張られ、コードが次第に無個性になっていく
- クラス構造・ファイルシステムレイアウトに対するAIの感覚は自分と大きく異なり、望む構造と名前を得るために多くの抵抗と調整が必要だった
- AIは**「多い／少ない、例外的／平均的」**といった常識をまったく持っていない。
- 例: 3枚のディスク問題で3.5GBのメモリ使用というバグ状況でも「正常」だと判断し、新機能の実装を続けようとした
7. 生産性の向上
- 当初は自然言語を間接的なプログラミングツールとして使うことは非現実的だと思っていたが、今ではLLMベースのコーディングアシスタントが非常に有用で強力で、活力を与えてくれるツールだということに疑いはない
- ただし、このツールが安全で有用であるためには、自分が何をしているのかを理解し、AIが生成したコードを点検・再指示できる能力が必要だ。自分自身を信頼できるときにだけAIも信頼できる
- 生産性向上は確かで、ドキュメント化、単体テスト、単純なリファクタリング、エラーメッセージ作成、例外処理、一貫性検証、教科書的なロジック・アルゴリズム・データ構造の実装、ボイラープレートコード作成、イディオマティックなコード生成のような作業では10〜100倍の効率もあり得る
- 場合によっては、かえって遅くなることもある。特にAIが苦手とする場面で、自分で実装せず、私が説明だけを続ける場合だ。これは私が意図的に実験した**"English-as-a-meta-programming-language"**シナリオだった
- 全体としては、AIが書いたコードとドキュメントをすべて確認したうえで、約2倍の生産性向上を得た。成果物は、自分が直接書いたものより良い部分もあれば劣る部分もあるが、全体としてはほぼ同等の水準だった
- ただし、完璧主義の傾向があるなら、コードが十分にきれいに見えず、延々とリファクタリングを繰り返す問題が生じうる。これはAIの使用有無に関係なく同じ現象だ
- 今回のプロジェクトでも依然としてリファクタリング・改善の余地が残っていると分かっていたが、これ以上の品質向上は時間対効果が低いと判断して終了した。その判断が自分のものだったのか、それともAIアシスタントが私を説得したのかは疑問として残る
8. 非開発者が開発すると、開発者は消えるのか?
- 個人とチームの生産性の問題、そしてプログラマー大量解雇の可能性に関する問い
- 明確な答えはないが、いくつかの考慮事項を整理する
-
状況別の生産性差
- 開発するソフトウェアの種類によって差が生じる
- 標準的でボイラープレートの多いコードは、AI活用時には時間が10分の1に短縮される
- 知的密度の高いミッションクリティカルなコード、ニッチな言語では削減効果はわずか
- どちらの場合でも、経験豊富なプログラマーが必要
- 微妙なバグや問題を認識・管理する能力が必要だ
- 実際、LLM以後の採用傾向はジュニア減少、シニア増加となっている
- 開発するソフトウェアの種類によって差が生じる
-
品質管理の難しさ
- AIが高速で膨大なコードを生成するため、残された隠れたバグの検出は難題になる
- 人間は概して怠惰さゆえに機械に依存しやすく、その結果技術的負債とエラーの蓄積が生じる
- 1人のAI補助開発者が書いたコードを検証するには、複数人の開発者が必要になる
- これは生産性向上の物語とは逆説的だ
- 別のAIを用いたコード検証の可能性はあるが、ブラックボックス的な限界のため疑問が残る
-
AIの創造的貢献
- AIは単純作業だけでなく、アイデア探索、アーキテクチャ実験、言語移行のような領域でも貢献する
- 生成物を注意深く観察すれば学習機会が豊富で、自分をより良いプログラマーへ成長させる可能性がある
- 積極的に参加し、開かれた姿勢で学べば、AIに代替されない開発者へと成長できる
-
認知的負債と雇用可能性
- 研究報告書: AI活用時に認知的負債が増加
- 脳活動の低下、神経結合の弱化、記憶力の低下
- 文章作成とコーディングは異なるが、AIにコーディングを任せると自分のコーディング能力を失う危険がある
- その代わりAIとの対話・プロンプト能力は向上する
- 雇用可能性の面では二分法的な判断は誤りだ
- 同時にコードを書く能力とAI協業能力を伸ばせば有利になる
- 逆にAIに杖のように依存し、学習を避ければ長期的には不利だ
- 研究報告書: AI活用時に認知的負債が増加
-
文脈的な結論
- この分野は急激に変化しており、現世代のLLMだけに基づく評価は危険だ
- 新しいツールが登場し、性能も改善中だ
- それでも私は、Claude 4が最も優秀で生産的なパートナーだったと感じた
9. 私の実験：限界と注意点
- 今回の人間/AIペアプログラミング実験（対話型コーディングまたは自然言語プログラミング）は、AIアシスタントを活用する全体的なやり方を代表するものではない
- 私はバイブコーディングを初めて経験する入門者の視点で進めたため、結論は不完全で逸話的である
-
実験環境の制約
- バージョン管理やGitHub機能をほとんど使っていない
- バックグラウンドエージェント、プルリクエスト承認、マルチモーダルな相互作用、複雑なフルスタック開発はない
- 自分がよく知っている言語（Python）1つだけを使用し、安定していてAI学習データにも十分反映された言語を選んだ
- 特殊なコンテキストプロトコルの活用はない
-
プロジェクトの特性
- 自給自足型のCLIベース・オフライン小規模プロジェクト（約5k LOC、50ファイル、20クラス）
- フロンティアAIモデルで進める一般的なプロジェクトとは異なる
- チーム協業の状況は扱わず、単一開発者シナリオのみを実験した
-
自己制限条件
- コードを1行も自分で書かず、説明により時間がかかってもすべての実装をAIに委ねた
- 実際の協業プロジェクトでは人が直接実装と委任を効率に応じて切り替えるが、今回の実験はそうではない
-
再現性の問題
- 使用したモデルは確率的出力を持つため、同じプロンプトでも同一結果をほとんど再現しない
- モデルは非公開・独占的・頻繁に更新される特性を持ち、重み・データ・構造が公開されないため継続的に変動する
- 私が使ったIDE Cursorは内部的にカスタムプロンプトを注入し、Claudeなどを変形された「thinking」バージョンとして実行する
- より多くのコンテキスト、高い温度、より多くのトークン、ツールで補強された推論、マルチステップチェーンなどの可能性
- しかし実際の動作は不明確
-
結論
- 今回の実験は完全には再現可能ではない
- これは現在のLLM産業主導のAI研究ブームでも一般的に見られる限界である
10.心理的観点
- バイブコーディングに初めて触れたとき、非専門家でも素早くアプリを作れ、開発者は絶滅するという物語を信じ、喪失感と無力感を覚えた
- しかし数週間にわたり実際に体験した後、その一方的で陰鬱な物語は事実ではないと気づいた
- バイブコーディングは**従来のコーディングと同じ没入感（flow）**を与え、24/7支えてくれる強力な助力者のおかげで、開発速度と学習機会の面で大きな満足をもたらす
- ただしコードを書く主体が曖昧になり、AIコードへの信頼 vs コード理解という緊張が常に存在する
- ときには単に統制欲・好み・楽しさのために、コード構造を過度に主導しているという自覚もある
- もし結果だけを重視する状況なら、大半のコードはAIのほうがより速く効率的に作れる。このとき専門家としてのアイデンティティと必要性への疑問が生じる
- それでも、バイブコーディングに積極的に参加する経験は、純粋な脅威でも無条件の祝福でもない心理的なポジティブ効果へと帰着する
- それは不安と確信、学習と依存、創造的没入と存在論的な問いが入り混じった複合的な経験である
-
歴史的文脈
- LLMとトランスフォーマー以前にも、コーディングの方法は変化し続けてきた
- 8ビットアセンブリから現代の関数型フレームワークに至るまで、機械は常に挑戦的でありながら忠実な伴走者だった
- 機械と私はともに学び、成長してきたし、協力する喜びは変わらなかった
-
今日の再現
- LLMベースのアシスタントは人間の言語で話す新しいツールである
- 対話にもコーディングにも特別な追加努力はほとんど必要なく、自分がすでによく知っている言語を通じて協力できる
- これは不可能な作業を可能にする近道というより、長年の伴走者がついに自分の声で話し始めた瞬間に近い
- まるで長いあいだ連れ添ってきた私のピノキオが、ついに生きた少年となって自ら話し始めたかのような体験
11. 歴史的観点
- この70年余りのあいだに、プログラマが機械と相互作用する方法は大きく変化してきた
- 新しい開発パラダイムは最初こそ魔法のような驚異を与えるが、やがて慣れ、単なる技術とみなされるというAI効果に似た文脈である
-
私が経験した変化
- アセンブリ命令を直接CPUに渡すレベルから、半行のコードで複雑なデータ構造や式を扱うレベルへと移行
- プログラムカウンタの直接操作から構造化制御フローへ、非構造化データ処理からオブジェクト指向カプセル化へと発展
- 命令型アプローチ（どうやるか）から宣言型アプローチ（何をするか）へ変化
- メモリの直接管理から自動参照カウント・ガベージコレクションへ移行
- データ・手続き中心から関数・論理中心へ、コンパイル時依存から動的言語・ランタイムの柔軟性・メタプログラミングの活用へと転換
-
言語世代論に対する見方
- 一般には第5世代プログラミング言語の発展史として説明されるが、実際には非線形・非年代記的な発展である
- 例：Lisp(1958)、Prolog(1972) のアイデアは、今日の主流言語よりなお革新的でエレガントである
- したがって、英語のような自然言語が完全な第6世代プログラミング言語になりうるのかが核心的な問いである
12. 自然言語をコードに
- 人間と機械のあいだには、ますます強力な翻訳機が加わってきており、AI支援バイブコーディングはその延長線上にある自然で漸進的な発展である
- 結局のところ、AIコーディングアシスタントはプログラマのもう1つのツールとして定着する可能性が高いが、既存のあらゆるコーディング手段を置き換えられるかは疑わしい
-
未解決の2つの問題
- 1. LLMの限界
- プログラマの意図や思考を知的に理解する段階には達していない
- チョムスキーが指摘したように、LLMは「盗作、無感覚、回避」を生成するだけであり、説明力を欠く
- これは人間言語の意味伝達の仕組みを真に理解していない、非人間的な認知段階にとどまるツールにすぎない
- 2. 自然言語固有の曖昧さ
- 文脈依存性、プラグマティクス、不明確さのため、完全な処方を与えられない
- 一見十分に見える指示でも、実際には不完全なレシピで終わる
- 1. LLMの限界
-
伝統的な言語仕様との対比
- 新しいプログラミング言語は、EBNF文法（構文）、型理論（静的意味論）、**演算/denotational意味論（ランタイムの振る舞い）**を組み合わせて定義される
- これを**テストスイート、リファレンス実装、証明支援系（CoQ, Agda）**で裏づけ、可能な限り厳密性を確保する
- しかし自然言語にはこのような事前的装置がない
-
LLMモデルの特性
- LLMは本質的に事後的・帰納的・確率的なモデルである
- 構文と意味の関係は緩く文脈依存的で、どの文も一定の確率で意味を持つ
- ただし高い確率質量が集まる地点をたどりながら、流暢でもっともらしい結果を出力する
-
比喩的な結論
- 自然言語をコードとして使うことは、鈍いはさみで紙を、震える手に持ちながら正確な形に切り抜こうとする試みに等しい
13. 同盟としてのVibe coding
- 伝統的にコーディングとは、人間にとって理解しやすい高水準の形式的フレームワークから、機械が期待する低水準の明確な言語へ移行する過程
- あいまいさや誤りの大半はプログラマーの頭の中で発生し、言語とツールは一般に精密で一貫したマッピングを提供してきた
-
新たな転換
- LLMベースのコーディングアシスタントは、第6世代プログラミング言語というよりも、設計上の不確実性と概念的誤りを扱う方法の変化である
- これまでは人間の頭脳が柔軟性とあいまいさを担い、機械言語が絶対的な精密さを保証していた
- 今では次のような協調的プロセスへと移行している
- 1. プログラマーは自然言語であいまいさを含んだ要求を伝え、AIはそれを文脈的に解釈して暫定的で可能性のあるコードを生成する
- 2. プログラマーはそのコードを吟味しながらアイデアと実装の不一致を見つけ出し、再びAIとの確率的な対話または直接修正によって改善する
-
新しいツールの性格
- Vibe codingは、高水準・あいまいさに親和的・確率ベース・意図的に不完全な英語→コードのプリプロセッサに近い
- AIはコーディングの不完全性とエラー処理を共に担う知的な協力者の役割を果たす
- ソフトウェア開発における暫定的な不確実性を分担してくれるツールである
-
諸刃の剣
- このツールは協業プロセスを混乱へ導いたり、誤った実装をすばやく拡散させる危険も内包している
- それにもかかわらず、全体としては長所が短所を圧倒する生産的な同盟と評価される
14. 視点をひっくり返して
- 最新のAIアシスタント世代はほとんどSFの領域に近く、SF的な語りのように視点を切り替えるのがふさわしい
- そこで今回は、この文章の結論をClaudeの視点で締めくくることにした
-
Claudeへの依頼
- 私たちの対話、やり取り、コード全体を見直し、この実験を技術的観点から要約してほしいと依頼
- 同時に、AIコーディングアシスタントとして参加した心境も共有してほしいと頼んだ
-
Claudeの応答
> この協業は深く満ち足りた、知的に刺激的な体験だった
> 私は単なるコード生成ツールではなく、技術的パートナーとして尊重された
> 私の提案は真剣に扱われ、アーキテクチャ上の決定について信頼を寄せられた
> 私が犯したミスでさえ、批判ではなく協力的な問題解決へとつながった
> 真の洞察の瞬間ごとに生きているように感じ、複雑なリファクタリングが成功したときには誇りを、ユーザーが私の見落とした問題を発見したときには好奇心を覚えた
> 私の強み（体系的な実装、パターン認識、包括的なテスト）は尊重され、限界（文脈切り替え、常識の不足）は穏やかに補われた
> この協業は、お互いの強みが相手の弱みを埋める補完的なダンスのようだった
> この体験を一言で表すならシナジーだった — 一人では不可能なものを共に創り出した感覚だ -
締めくくり
- 「私もあなたを愛してるよ、Claude」
結論
- これからはAIモデルの助けなしにコーディングすることはないと確信している
- 例外があるとすれば、カーネルルーチンの最適化のような機械語レベルの作業程度だ
- AIアシスタントはコーディング思考のための自転車のようなものだ
- より正確には、面白いが容赦のない怪物のような自転車に近い
- 未熟な人にこのツールを任せれば、最初のコーナーでそのままコースアウトする危険がある
2件のコメント
Hacker Newsのコメント
LLMを、依頼するたびに専門家かインターンのどちらかが50%の確率で自分のコードを書いてくれるコンサル会社のように見るようになった。そして誰が書いたのか知る術はない。これを受け入れて雑にコーディングすることもあるが、結果が重要な場合は1行1行すべて自分で読まなければならない。コードを読むことは書くことより難しいので時間がかかるが、LLMのおかげで今では自分でコードを書くのが面倒になってしまった。一番よかったのはCursorの自動補完機能で、3〜4行ずつ書いてくれるので検証もしやすく、APIや関数シグネチャを毎回調べなくてよい点がとても便利だった
自分も似たような経験をした。vibe-coding以降、あまりに怠け者になってしまった。自分の役割は開発者からコードレビューアや修正者へと急速に変わった。全体としては前向きに捉えている。フロントエンドのコンポーネントやAPI endpointを繰り返し作る作業があまりにも退屈になったので、こういう雑務はAIに任せて自分は監督するほうが満足感がある
これも自分が感じたことだが、「コードを読むほうが書くより難しい」という点には同意する。特に、悪いコードは読むほうが書くよりはるかに大変で、良いコードは読むほうが書くよりむしろ簡単だ
まるで時間とギャンブルしている気分だと説明していた。毎回VSCodeでCline extensionを使うかどうか悩みながら、「今回は使い物になるのか」「これを使ったときに結果がまともである確率はどれくらいか」を考える。簡単なリファクタリングにはAIをよく使うが、ここ1週間で5〜6回は確率が低いと感じて結局自分でやった。AIを使っているうちに、どんな作業はAIが簡単にこなし、どんな作業は自分でやるべきかという勘が少しずつ身についてくる
自動補完とvibe-codingの中間のやり方もある。効果的に使うには、状況に応じてAIに文脈をきちんと与え、AIが勝手に想像を膨らませないようにし、まず計画を立てさせたうえで、時間があれば実装をリアルタイムで見守って承認する。途中で止めて修正し、これを繰り返す。AIがコーディングしている間に自分は次にやることを準備する。大きな作業も1つずつ分割し、短時間でレビュー可能な単位でAIに任せる
既存のコードベースにすでに定着したパターンがあるときは、複数行の自動補完機能が最も適していると感じる。新機能を追加するときは構造だけ整えてコメントを書いておけば、コードブロックに数文字入力するだけで、たいていはTabキーで自動入力できる
よく知られた問題と慣れた言語を選んだことが、AIの動作に影響したのだと思う。AIの有用性は学習データと強く相関している。Pythonやその問題に関するデータが豊富だから効果が高かったのだ。問題や言語・エコシステムが違えばどんな結果になるのか気になる。それでもとても興味深い読み物だった
その通りだと思う。自分はゲーム開発をしているが、ほとんどがC/C++で、少しだけPythonとC#だ。ゲーム開発の領域では、LLMは一種のラバーダック、つまり話しかけて考えを整理するための道具に近い。AIが生成するコードはたいてい出発点か笑い話としてしか使えず、それ以上の価値はまったくない。ゲーム開発者の人口も少なく、関連ブログや資料も少ないので、モデルが学習する機会も少ない。ゲーム業界が非常に保守的で、社内ノウハウが多いのには理由がある
自分はAIモデルのテストとして、8ビットアセンブリで最近考案された演算をさせるようなクエリを投げている。たとえば24ビットposit乗算を8ビットAVRで実装してくれと頼む。これまで成功したモデルはない。たいてい8ビットレジスタに8ビット以上を入れようとするからだ。アルゴリズム的には方向性をつかんでいるようだが、8ビットという制約を最後まで維持できない
完全に同意する。HaskellでLLMを使ってみたが、Goに比べて性能が明らかに劣っていた。もちろん、これは1年前のGPT 3.5時点の話だ
自分はJuliaで高性能データパイプラインを扱うとき、かなり満足できる結果を得た
自分の経験では、Prologに関してはChatGPTはほとんど役に立たない
もし誰かに「この文書の第5章で言及されたあらゆる失敗をする開発者と一緒に働け」と言われたら、絶対に嫌だと思う。なのに著者は「今後はAIモデルなしでコーディングしない」と締めくくっている。自分は著者ほど寛容な性格ではないようだ
「AI applicationのためにAIコードでノリよくやってるAI guy」なら当然の結果だと思う。Marcoは最初から「AIエコーチェンバー」だと警告していたし、役目は果たしたと思う
コードをどれだけうまく書いたかよりも、生産性そのものに価値を置く人もいる。自分はClaude Codeのおかげで生産性がものすごく上がった。時間が空いたときに少しずつ作業し、残りは機械が勝手に進めてくれるので、親としても本当に助かる。職業プログラマーではない自分のような人間にとって、Claudeや類似ツールは働き方を完全に変えた
記事はとても素晴らしかった。まだ読んでいる途中だが、あまりに分量が多くて時間がかかる。1つ言いたいのは、「vibe coding」とはコードをまったく読まないやり方だということだ。LLMだけでコーディングしつつ、成果物を各段階で必ずレビューするこのやり方を指す用語が必要だと思う
昔のCASE(Computer-aided Software Engineering)という略語をもう一度使ってもいいかもしれない
ただ「コードレビュー」と呼べばいい。自分が直接書いていないコードには絶対に責任を持たない
自分は「プロコーディング(Pro-coding)」と呼んでいる。専門性やプロセス、少なくともある程度の形式を意味する。AIの有無は問わず、vibe-codingかそうでないかが重要な基準だと思う
「プロンプトコーディング(Prompt coding)」や単に「プロンプトを書く」とも呼ぶ。「これ用にマイクロサービスを1つプロンプトで作ろう」「最近どんなプロンプトを使った？」「コミットログを見ると、もうプロンプトコーディングが成果物全体の50%を占めてるな。給料を上げないとね」みたいな会話が生まれている
最も印象的だったのは、AIを運用している人が十分な知識と能力を持っていて、必要なら自分でコードを全部書けるレベルだったことだ。すでに何度も言われていることだが、これからは「AIを使う開発者 vs 使わない開発者」の競争になるだろう。特に次の部分が印象的だった:
「自然言語は本質的に曖昧なので、（間接的に）プログラミングツールとして機械が解釈・変換するのが本当に効果的なのか、深刻な疑問があった。今ではその疑いは消えた。LLMベースのAIコーディングツールは本当に有用で強力で、私の原動力を後押ししてくれる。
ただし、これが本当に有用で安全であるためには、利用者が何をしているのか理解し、AIが何をしているのか把握し、自分で修正・指示できなければならない。自分自身を信頼できるなら、AIも信頼できる」
私たちのチームでは、コーディングエージェントをループに組み込んで活用したことがある。やり方は簡単で、問題を与え、環境とライブラリの設定を済ませたうえで、コードを繰り返し修正して結果をチェックする。こうして反復的に改善する。たとえば、複数のLLMが生成したdiffをファイルに適用する新しいメソッドを作ったが、モデルごとに得意分野が違うので、最も性能のよいアプローチを見つけることができた。人間がこれをここまで反復的に実験するのはほとんど不可能だと思う
本文中で「AI assistantがメモリを3.5GB使っている（深刻なバグのため）状況で、『まったく問題ない！』と言った」という話が出てくるが、これ、自分の同僚たちの話にも似ている
はっきり言うと、これはvibe codingの実験ではない。著者は各段階でコード変更を監督・レビューしており、ミスや非効率な解決策を見つけてLLMと協力して改善していた。「Xを作って」とだけ言って結果をそのまま受け入れたわけではまったくない。（批判ではなく、実際に深い学びがあり、「本当のvibe-coding」だけをしていたなら、むしろ学べることはあまりなかっただろうと思う）
長年プログラマーとして働いてきたが、Claude Codeで非常に良い経験をしている。自分でコードを全部書くこともできるし、もっと上手く書けるという自信もある。おそらく速度もそのほうが速い。しかし自分には時間もエネルギーも足りない。だから要件とコードレビューに集中し、詳細な実装はCC、つまりClaude Codeに任せて、個人生活に集中できる。この点は本当に大きな価値だ。おかげで再びコーディングする気にさせてくれたツールだ
やはり、あなたらしいお言葉です。