ハクソク

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

コードを書けよ

223日前原文(antonz.org)

概要

  • AI活用 のアドバイスが増えている現状
  • 問題分割やプロンプト改善だけに頼る危険性
  • 実際にコードを書く ことの重要性
  • AIは補助として活用する姿勢
  • エンジニア本来の役割 を見失わないことの提案

AI時代のプログラミング助言再考

  • 最近よく聞くアドバイス：「問題を小さく分解」「具体的な要件設定」「適切なAIモデル選択」「プロンプトの反復改善」
  • 問題分解 は有効だが、 プロンプト反復 には依存しすぎない姿勢
  • 実際のコード作成に積極的に関与することが肝要
    • AIに初期バージョンを生成させ、自分で リファクタリング
    • 自分で初版を書き、AIに レビュー・改善 を依頼
    • 重要部分は自分で書き、 残りをAI に任せる
    • コードの アウトライン を作り、AIに詳細部分を補完させる
  • AI任せ にせず、工程に自ら関与する姿勢が良い結果を生む

プロンプト反復の落とし穴

  • AIが 一発または二発目 で期待通り動作すれば問題なし
  • それ以上 プロンプト改善 に時間をかけるのは非効率
  • コードを書いてからAIに戻ることで 成果向上
  • AI活用 自体は推奨、ただし「英語でプログラミング」的な無限ループは回避
  • 曖昧さ・遅さ・ストレス の原因となるため、実装作業を重視

エンジニアとしての本分

  • 手を動かしてコードを書く ことが本来の強み
  • ソフトウェアエンジニア としての役割を忘れず、プロンプト職人にならない意識
  • AIは 補助ツール として積極活用しつつも、主導権は自分に

まとめ・推奨行動

  • AIと協働 しつつ、コード作成の主導権を持つ姿勢
  • 無限プロンプト改善 の罠に陥らず、実装作業を優先
  • エンジニアの本質 を見失わない
  • 新着記事の購読推奨

Hackerたちの意見

AIをペアリングバディとして使ってるんだ。APIやアルゴリズムをすぐに調べてくれるし、リファクタリングやDRYを理解してる賢いテキストエディタみたいな感じ。でも、アーキテクチャを決めたりテストを書くのは自分でやってるよ。自分にはうまくいってる。この記事が批判してるのは、ソフトウェア工場みたいに使うことだね。欲しいものをプロンプトとして与えて、間違ったらプロンプトを修正するっていう。プログラミングが仕様の問題なら、プログラミング言語から自然言語にシフトするだけじゃ解決しないのは分かる。

└

4] そうなんだけど… AIは生のプログラミング言語よりも、私たちの業界についての文脈をずっと多く持ってるんだ。「購入イベントのためにストライプのWebhookプロセッサを追加して」って言えば、どのライブラリをインポートするか、APIコールの構造、イベントの形、ストライプ関連のデータベーステーブル、APIの冪等性の問題とか、全部わかってる。だから、指定しなきゃいけないことはあるけど、通常の言語よりも、やってるタスクに関連する暗黙の理解や知識がたくさん引き出せるんだよね。

今、HNのフロントページには「クソコードを書け」と「バカなコードを書け」があるけど、「良いコードを書け」はないね。

└

7] 良いコードなんて幻想だよ。

└

問題を解決する最初の5回は、その問題について十分に理解してないから、良いコードを書くことができないんだよね。

著者にちょっと同意するな。十分なコーディング経験がある自分には、AIにコードを書かせることからあまり価値（もちろん、楽しみも）を感じない。ただ、少しでも不慣れな環境で作業する時には貴重だよ。問題を解決するために使える（たいていは間違ったり不完全な）コードの例を提供してくれるから、メインの「エネルギーバリア」を乗り越えられる。例えば、新しいプログラミング言語の広大な標準ライブラリをナビゲートしたり、物事のやり方を示すイディオム的な例を提供してくれる。自分は何をしたいかは分かってるけど、特定のフレームワークや言語でそれを表現するための正確な構文は分からないんだ。

└

3] Context7っていう製品があって、APIの使い方を実践的に簡潔に示してくれるんだ（具体的な例はここを見てね: https://context7.com/tailwindlabs/tailwindcss.com）。これはLLMがより良い例を提供するために使うことを想定してるんだよね。例えば、モデルのトレーニングデータにあるライブラリの新しいバージョンを使うとか。よく考えるんだけど、MCPサーバーを使うよりも、ドキュメントを漁るよりも、この高信号対雑音のリソースを自分でクエリしたいなって思うことがある。良いドキュメントリソースがあるとき、LLMはどんな追加価値を提供してくれるんだろう？

└

5] うん、あんまりLLMを活用してないけど、vscodeの拡張を書くためにAPIを調べるのに使ったことはある。生成されたコードはそのまま使えなかったけど、動くコードに変えられる例をくれたんだ。個々のAPIコールを調べることなくね。昔はWindows APIを調べるのにも使ったな、何十年もWindowsのコードを書いてなかったから。（パイプ、フォーク、エグゼックの相当するものね。）生成されたコードにはリソースリークがあったけど、それに気づいたし、始めるには十分だった。Stack Overflowにもその答えがあったと思う。あと、面白いことに、コパイロットに自分の作った言語（Idris/Agdaに似てる）でパーサータイプのモナド実装を生成させたら、かなり近いものができたよ。

└

ほんの少しでも不慣れな環境で操作しているときは非常に貴重だね。 車のナビやGoogleマップみたいなもんだよ。地元では面倒であまり役に立たないけど、旅行中や不慣れな場所ではすごく助かる。

2ヶ月くらい前に、会社がCursor/claude AIのライセンスを取得したんだ。最初は何ができるのか理解するのがすごく楽しかった。特にリファクタリングみたいなことには本当に強力だと思った。でも、だんだん邪魔に感じるようになった。最初はTABからctrl+spaceに自動挿入のバインドを変更しないといけなかった。コードをタブでインデントしようとすると、ブランモ！って感じで行が挿入されて、消すのに余計な手間がかかることに。次に、AIが生成したオートコンプリートを読むのに時間を取られることに気づいた。ポップアップして、生成されたものを読むために集中を移して、それが自分の欲しいものか判断して、元々何を打ってたか思い出そうとする。だから、全部オフにした。文脈を意識したチャットにはまだアクセスできるけど、オートコンプリート機能は使ってない。そしたら、もっと記憶できて、コードを理解するのも増えた（驚き）。コードにもっと関わるようになったし、理解しようとする努力も増えたかも。もしかしたら、記憶力や注意力、コンテキストを切り替える能力が自分より優れてる人もいるかもね。若い人たちは、気を散らすものや注意を奪うコンテンツに慣れてるからかもしれない。

└

うん、自分もオートコンプリートは無効にしてる。自分にとっては、知ってる分野で作業してる時に一番役立つ。例えば、暗号技術は知ってるけど、Node.jsの暗号APIは知らないから、Claudeはそのコードを書く時にすごく助かる。

└

Cursorが大好きで、オートコンプリートもすごく役立つんだけど、時には邪魔になるよね。ホットキーを再バインドしようと思わなかったのが不思議。ありがとう。

└

もっと記憶できて、コードを理解するのも増えた（驚き）。自動運転のクルーズコントロールを使った時の感覚に似てる。速度を見る代わりに、交通の流れを見て、ずっと先の車を見てた。構文を処理する部分はオフになってるけど、コードを読む時は「データフロー」の部分が100%働いてる。

└

オートコンプリートの一番最悪なところは、ただインデントするためにタブを押したい時に、行の終わりで何かをオートコンプリートしようとするところだね。

└

1年前くらいに同僚とオートコンプリートとチャットについて話したのを覚えてるんだけど、基本的にはオートコンプリートの方がいいって意見で一致してたんだ。でも、Claude Codeを数ヶ月使ってみて、意見が逆転した気がする。オートコンプリートを好んでいたのは、当時のChat/Agent ModeやClaude Sonnet 3.5の弱点によるもので、オートコンプリート自体の強みじゃなかったと思う。今は、自分でコードを書くときはオートコンプリートなしでやってる。助けが必要なときは、ターミナルでClaude Codeを開いて手伝ってもらう感じ。君が言ったように、オートコンプリートには変な効果があって、コードを考える代わりに、LLMが提案してくることを無意識に理解しようとしてしまって、結局時間の無駄になることが多いんだよね。

└

2] オートコンプリートはこの記事が話してることとは全然違う。これはプロンプトの洗練のループについて言及していて、定義上、Agent Modeタイプの統合を指してる。オートコンプリートにはプロンプトがないからね。オートコンプリートが邪魔になることもあるけど、それをAIコーディング全般が悪いと混同しないでほしい。全く別の機能だから。

└

8] 「AI」オートコンプリートは本当に厄介になってきた。いつも自分がやったことを二度考えようとして、逆に悪化させることが多い。エスケープキーを押して消そうとするけど、すぐにまた別の提案をしてくるから面倒くさい。邪魔になることが多くて、もうオフにしようかと思ってる。唯一役立つのは、似たような行がいくつかあって、最初の行を変更すると、残りの行も一緒に変えてくれるとき。ほとんどいつも正しいけど、時々微妙に間違ってて、なんでうまくいかなかったのか5分も考えちゃうことがある。その微妙なバグに気づくまでね。こんなのが自分でやるよりも良いと思う人がいるのが不思議だよ。

└

「注意を奪う」っていうのには完全に同意だわ。オートコンプリートをオンオフするホットキーを作るのがいいかもね。

6] 同じ古い問題を新しい顧客のためにN回目に解決してるわけじゃない限り、コードを書くまでその問題を完全には理解できないよ。新しい問題なら、コードを書いてみて、変なコーナーケースを発見して理解する必要がある。もし(N+M)回目で、過去M回AIを使ってコードを書いてきたなら、もうその問題を理解していないかもしれない。注意しておいて。ちゃんとコードを書け。

LLMを学ぶ気のないジュニアエンジニアみたいに扱うアプローチが一番いいアドバイスだと思う。経験豊富なエンジニアの直感をうまく活用してるしね。インターフェースやテストスイートにもっと時間をかけるべきだよ。AIには仕様に従って実装をうまくやらせればいい。インターフェースを実装しないのは間違いだし、テストに通らないのも間違い。ソフトウェアの業界で長く働いていると、学ぶ気がない人や指導できない人に出会うことがあるよね。それがLLMにも当てはまる。もしLLMが理解できないなら、時間を無駄にしない方がいい。多分、理解することはないから。別のモデルを試すか、他の人を巻き込む必要があるよ。無能で指導できない人に対処するのと同じようにね。ちなみに、ジュニアエンジニアに対するアドバイスは、自分の「ウェットウェア」をアピールして、実行時に学びや適応を示すことだよ。モデルはまだそれができないからね。

└

本当に面白いのは、出力をコピーして新しいプロンプトを始めて、「シニア/スタッフレベルのエンジニアの視点から、このコードの何が問題か？」って聞くと、LLMは自分のコードを新しい視点でボロクソに言うんだよね。技術的には既存のプロンプトでもできるけど、時々LLMは自分が決めた現実に突然こだわり始めることがある。何かしらの文脈を切り替えるときは、新しいプロンプトを始めるようにしてる。

AIに初期バージョンを作らせて、それを期待に合わせてリファクタリングする。 > 自分で初期バージョンを書いて、AIにレビューと改善を頼む。 > 重要な部分を書いて、残りはAIにやらせる。 > コードのアウトラインを書いて、AIに欠けている部分を埋めさせる。 すごくうまくまとめられてるね。これを付箋に書いてモニターの上に貼っておくよ。エージェントを使ってコードを生成するのを長い間ためらってたけど、ついに本当に使うことになって、これが自分の経験とすごく合ってる。驚いたのは、プロンプトを適切に狭くすると、モデルがどれだけ重要じゃないかってこと。あと、カーソルみたいなものでペアプログラミングするのがどれだけ難しいかにも驚いた。プロンプトが少しでもずれると、ビルドプロセスが10倍速くなるのが、最終的にはスパゲッティコードしか残らない完全な無駄になっちゃう感じ。とにかく、革命万歳！これが技術的にすごく的を射てて、ただのノーAIの愚痴じゃなかったのが嬉しい（そういうのも好きだけどね）。

現在のLLMコーディングツールを使うことに「流行から取り残されるのが怖い」って理由で耐えてる開発者がどれくらいいるんだろう。自分の経験では、問題に悩んでるとき、LLMは助けるよりも時間を無駄にする方が多い気がする。

AIとあまり繰り返し作業するのはお勧めしないな。逆に「マイルストーン」を設定して、小さな問題を独立して解決した方がいいよ。コンテキストウィンドウがいっぱいになったら、問題を再定義して、進捗をもとにAIにプロンプトを送るのがいい。新しいスタートで空のコンテキストから始める感じ。自分の経験では、どんなコーディングAIも最初はすごく良いコードから始まって、そこからどんどん悪くなっていくんだよね。

「分解することを学ぶ」って、最近聞いた中で一番ムカつくフレーズかも。問題を小さな部分に分けるのは「分解」じゃないよね。