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

生成AIコーディングツールとエージェントは私には合わない

概要

  • Generative AIツールによるコーディング経験を技術的観点から共有
  • AIツールは私の作業速度や生産性を向上させない主張
  • コード品質や責任問題に対する懸念の強調
  • 人間によるコードとAI生成コードの違いについて説明
  • AIツールとインターンの違いに関する考察

Generative AIツールによるコーディング体験とその評価

  • Generative AIツール の利用に関する質問が多いため、見解を文章化
  • 本記事は AI推進派でも反対派でもない 立場からの個人的経験の共有
  • AIに関する賛否両論の記事は既に多く、重複を避けたい意図
  • 技術的観点を重視した 中立的な体験談 の提示

AIは作業速度を上げない理由

  • GenAIツール は私の作業速度向上に寄与しない実感
  • AIによるコード生成は便利に見えるが、 最終的な責任は自分 にある
  • AI生成コードの徹底的なレビュー が必須で、これには多くの時間がかかる
  • コードレビューは 自分で書くのと同等かそれ以上の労力 が必要
  • Joel Spolskyの「 読む方が書くより難しい」という業界の格言の引用
  • AIをブラックボックスとして扱い、 レビューを省略するのは危険 との認識
  • 契約や法的責任 が絡む場合、品質やリスク管理が特に重要
  • 品質低下やリスク増大を容認しない 限り、AIで効率化は不可能

AIは「生産性の掛け算」にはならない理由

  • GenAIツールが「 生産性の掛け算」と主張する人もいるが、 客観的なデータはない
  • レビューを省略することで効率化しているだけとの見解
  • 新しい言語や技術の習得 もAIに任せず、自分で学ぶことを重視
  • 学習自体がエンジニアの醍醐味 であり、AIに委ねるつもりはない
  • AI活用による時短は 責任問題や品質維持の観点から成立しない

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

  • オープンソースの 人間による貢献 も厳密にレビューしており、時間短縮にはならない
  • 人間とのやり取りから得られる 新しい発想や共同作業の価値 を重視
  • AIエージェントによる大量PR生成は コスト増加や手間増大 につながる懸念
  • AI生成の低品質なPR が増加し、「不気味の谷」的な違和感を感じることも
  • 提出者に 説明責任を求めても反応が薄い ケースが多い

AIとインターンの違い

  • AIツールを「 インターン」のように扱うべきという意見への反論
  • インターンは 成長し学習する が、AIは毎回リセットされる
  • インターンへの指導は 将来的な投資 となるが、AIにはその効果がない
  • 知識の蓄積や自律的成長 ができない点でAIはインターンとは異なる

結論

  • GenAIツールのコーディング活用には 技術的な課題と責任問題 が伴う
  • AIで効率化・生産性向上を謳う人は、 品質基準の緩和自己利益 が動機である場合も
  • AIによる「ただ乗り」的な恩恵は存在しない との立場
  • 記事を読んでくれた方への感謝と、 Buy me a coffee による支援の呼びかけ

Hackerたちの意見

自分が書いてないコードをレビューするのにかかる時間は、自分でコードを書くのと同じくらい、もしくはそれ以上かかることが多い。Claude Codeをよく使っている者として、これには同意する。LLMは素晴らしいけど、彼らにコントロールを譲るほど、実際にコードを出すのに時間がかかる気がする。今のところ、私にとっての主な利点はRSIの症状が軽減されたことだけど、実際の時間の節約は大げさに言われてることが多い(その瞬間は早く感じるけどね)。

誰かクールなハイブリッドインターフェース作ってる人いる?実を言うと、全部を会話形式の英語でやりたいわけじゃないんだよね。

ここには、自分で書いたコードは著者とは違うコンテキストからレビューされる必要がないという暗黙の前提がある。古い表現に「自分の仕事がサイコパスに読まれることを想定してコードを書け」というのがあって、その後に「彼らがあなたの住んでる場所を知ってるのは、未来のあなただから」ってジョークがある。生成AIコーディングは、ずっと持っておくべきマインドセットを強制するんだ。受け入れ基準から始めて、正しさを厳密に検証する方法を考える(理想的にはコードレビューよりも回帰テストを通じて)、そしてレビューのプロセスを使って一貫したプラクティスを考え出す(それを文書化してLLMが参照できるようにする)。必ずしも早くなるわけじゃないけど、朝起きて、すでに複数のLLMにレビューされた、しっかり文書化されたPRを見て、成功したテストがついてるのを見ると、ずっと集中すべきことに時間を使ってる気がする。

コードをレビューしなきゃいけないの?正直に言うと、OPが考えてるように、私はしばしばざっとレビューするだけなんだ。でも、仕様書を書くために使わせることもある(私が掘り下げたものに関しては、かなり良いものが多い)し、結果はいつも慎重にレビューしてテストしてる。プロジェクトには、全くレビューしてない非AIコードもたくさんある、つまり、インストールした無数のオープンソースライブラリとかね。

RSIの症状は、起きてる時も寝てる時もずっと腕を温かく保つことで解決したよ。もしかしたら、あなたにも効果があるかも?

問題をデバッグするのにはいつもClaude Codeを使ってる。AIが数分で直せるのに、自分でやろうとする意味がないよ(最初にテストを書けば簡単に確認できるし)。o3の新しい検索機能は、私が非常に効率的にやっても少なくとも30分かかることを5分でやってくれる。何を言おうと、時間の節約は本物だよ。

ある程度、従来のコーディングとAIコーディングは同じじゃないから、どちらかが得意な人がいるのは驚くことじゃない。著者は基本的に、自分はAIコーディングよりもコーディングの方がずっと得意だと言ってる。でも、AIコーディングも自分で磨けるスキルだってことを理解するのが大事だよ。単に「最高のツールを選んで放っておく」ってわけじゃない。プロンプトの管理やコンテキストの管理は、意外と多くの人が思ってる以上にスキルが必要なんだ。手動コーディングが好きかもしれないけど、AIコーディングが苦手なだけかもしれないし、上達すれば好きになるかもしれない。とはいえ、AIにソフトウェアの大部分を任せることにはまだ懐疑的なんだ。実際にそれがうまくいくって言ってる人にも会ったけどね。今は「AIに大部分の雑務をやらせて、管理や高レベルのソフトウェアデザインをしっかりやる」方がいいと思ってる。ちょっと絵を描くのと写真撮影の違いみたいなもので、その視点で見ると、多くの絵描きが写真を好まない理由がわかる。

手動コーディングが好きかもしれないけど、AIコーディングが苦手なだけかもしれないし、上達すれば好きになるかもしれない。 でも、どれくらいの時間を費やせば「上手くなる」って言えるの?無料トライアルやちょっとしたお金を使った感じだと、ROIが見合ってるとは思えない。

でも、AIコーディングは自分で身につけられるスキルだってことを理解するのが大事だよ。単に一番いいツールを選んで放っておくってわけじゃない。プロンプトの管理やコンテキストの管理は、みんなが思ってるよりもずっと高いスキルが求められるんだ。いや、そんなことないよ。数分(もしくはもうちょっと時間がかかるかもしれないけど、主に設定に時間を使う場合)で習得できることなんだから。GDBやUNIXをIDEとして使うみたいに、本を一冊読まないと始められないってことはないんだ。 > ちょっと絵を描くことと写真を撮ることに似てるかも。そういう視点で見ると、絵を描く人が写真を好まない理由が明らかになる。構図やポーズなど、共通する原則はたくさんあるけど、出力が違うから別の活動なんだよね。誰も二つを混同しないし、絵を描いてるときに「瞬間を捉えよう」とは思わない。意図は世界に観察を共有することなんだ。

スキルの上限は「高い」かもしれないけど、ピアニストになるために何年も練習するのとは違うよね。世界で最も経験豊富なAIコーダーでも、こういうやり方での実践は約3年くらいで、その多くはモデルが変わったせいで役に立たなくなってる。何十年も経験のある先生もいないしね。

でも、それは学ぶ価値のあるスキルなのかな?出力の質はどれくらい向上するの?今日のモデルやツール、そして未来のものにどれだけ移転可能なの?今のAIプログラミングツールを見る限り、開発されるスキルが、来年には見られるツールに移転するとは思えないな。

「ある程度、従来のコーディングとAIコーディングは同じではない。LLMベースのコーディングは、単純な自動補完の強化を超えて、ジュニアを管理するか、仕事を外注するのに近い。定義やプロンプトを与え、いくつかの作業が行われ、プロンプトを洗練させて繰り返す(または自分で問題を修正する)、外部の人間と同じように。」主な違いは、ターンアラウンドタイム(LLMに有利)、信頼性(人間に有利だけど、迅速なターンアラウンドでかなり緩和される)、そして(これは時間が経てば解消されると思うけど、そんなに時間はかからないかも)「大きな絵」の仕事に対する有用性の欠如だね。これが私が使うことに対する(いくつかの)反対理由の一つだ。私は自分がやっていることの細かい部分を理解したいし、プログラミングやデータベースのいじり、インフラの構築が楽しかったからやってた。何年も人を管理するのを避けてきたのも、同じ理由で給料が減るのを知ってたからだ。私は tinkerer でありたいのであって、 tinkerer のマネージャーにはなりたくない。AGIができたら、一緒に働けるように呼んでね。 -------- [1] そう、私はこれらのことをAIと呼ぶのにはちょっと頑固なんだ。次の10年で、これらは一般的にAIとは見なされなくなると思う。何かがAIと呼ばれるのは、それがAGIに近づいたときだけだよ。

Hacker Newsで議論の続きを見る