70%問題: AI支援コーディングの冷酷な真実

• 開発者がAIを活用する主なパターンは2つある
  • ブートストラッパー:
    • Bolt、v0、screenshot-to-code AI のようなツールを使って、初期プロトタイプを素早く生成する。
    • デザインやコンセプトを出発点としてAIを活用し、初期コードベースを生成して、数時間から数日で動くプロトタイプを開発する
  • イテレーター:
    • Cursor、Cline、Copilot、WindSurf のようなツールを日常の開発で使い、コード補完、複雑なリファクタリング、テスト、ドキュメント生成を行う

熟練開発者と初級開発者のAI活用の違い

• 熟練開発者: AIが提案したコードを継続的にリファクタリングし、エッジケースに対応し、型定義を強化し、アーキテクチャ上の判断を見直す
• 初級開発者: AIの出力をそのまま受け入れがちで、実環境で問題が起こりうる「トランプの家」のようなコードを生み出すリスクがある

AIツールの逆説: 知識の逆説

• 熟練開発者: すでに理解している作業をAIで加速する
• 初級開発者: 何をすべきかを学ぶためにAIを使おうとする
• 結果: 習熟度によってAI活用の効果は大きく変わる

非専門家がAIコーディングツールを使うときの70%問題

• 初期の進捗: AIツールを使えば、求める機能の70%を素早く実装できる
• 残り30%: 小さなバグを直そうとすると新たな問題が発生し、それを解決しようとしてさらに多くの問題を生む悪循環に陥ることがある

AIツールを効果的に活用するための戦略

• AIドラフトパターン: AIで基本実装を生成し、人手でレビューとリファクタリングを行う
• AIを学習ツールとして活用: 継続的な対話を通じてAIが生成したコードを理解し、基本的なプログラミング概念も一緒に学びながら、段階的に知識を積み上げる
• AIの限界を認識する: AIツールはプロトタイプ開発、学習支援、アイデア検証には有用だが、本番運用可能で保守しやすいソフトウェアを開発するには、依然として実際のエンジニアリング知識が必要である

エージェント型ソフトウェアエンジニアリングの台頭

• エージェント型システム: 命令に応答するだけでなく、計画し、実行し、反復できるシステムへと進化している
• 今後の展望: AIは開発者を置き換えるのではなく、ますます能動的な協力者として、人間の指示と専門性を尊重しながら主体的に問題を解決する方向へ進んでいる
• AIは、すでに分かっているパターンを実装する助けとなり、アイデアを素早くプロトタイプ化し、さまざまなアプローチを探るのに有用である
• 反復的で日常的なコーディング作業を自動化し、より興味深い問題に集中できるようにする

AIツール使用時の注意点

• ユーザー体験の重要性: AIを使って素早くデモを作ることはできるが、実際の利用時に発生しうるエラーメッセージ、エッジケース、UIの状態などを丁寧に扱わなければ、ユーザーに不便を与える可能性がある
• 職人精神の復活:
  • AIによってソフトウェア開発は速くなったが、本当に消費者品質の体験を作る技術を失うリスクがある。
  • AIツールは日常的なコーディング作業を処理することで、開発者が重要な細部に集中できるよう支援できる。

結論

• AIの役割:
  • AIはより多くのコードを素早く書くためではなく、より良いソフトウェアを構築するのに役立つ
  • AIはソフトウェア品質を劇的に向上させるわけではない。
• ソフトウェア開発の難しい部分には、依然として人間の判断が必要である。
• AIはより良い解決策を見つけるための高速な探索を可能にするが、優れたソフトウェア実践を置き換えることはできない。
• 人間の責任: AIを賢く使ってエンジニアリング原則を維持し、ソフトウェア品質を向上させることは、依然として人間の役割である

[dbs0829]

技術を活用するのは良いのですが、考えることまで委ねてしまう人があまりにも多く、特に教育の場などに行くとそれをより多く目にするので心配です。正直、私はそういう人たちとは一緒に働きたくありません。

[kandk]

IDEが開発者をダメにする、という議論に近いかもしれませんね..

[savvykang]

顧客が生成したAIコードを修正するのにうんざりです
AIが判断を始めると、もう打つ手がないように見えます

[iolothebard]

AIにフィードバックを与えると良くなっているように見えても……ある瞬間に壊れてしまう。その瞬間を見極めるコツが必要だ。そしてその瞬間が来たら、AIを捨てるのか、やり直すのかを選ばなければならない。

[yadameda]

production-ready（本文では「本番投入可能」）は、どう訳すと自然でしょうか?

実運用に投入できる水準
製品レベル

[kandk]

公開準備完了！

[binaryeast]

私は通常、출시 가능 または 출시準備完了 と訳すことが多いです。

[jhj0517]

「リリース可能」、いい感じですね！

[bus710]

「（実運用または顧客向けとして）デプロイ準備が整った」

くらいではどうでしょうか？

[savvykang]

実戦で検証されたものはどうでしょうか？

[soomtong]

実戦での検証は、battle tested とよく表現されるようです。

[GN⁺]

Hacker Newsの意見

• AIは過去のさまざまなツールと同様に、プログラミングの一部を代替しようとしてきた。しかし、本質的な作業には依然として人間の頭脳が必要である

  • AIは複雑性の管理のような本質的な作業を実行できない
  • AIは英語で対話できるため以前の試みより柔軟だが、それでも本質的な問題解決には限界がある

• AIはチームの情熱的なジュニア開発者のようなものだ

  • ジュニア開発者とAIツールはどちらもバグが多く、冗長なコードを書きがちな傾向がある
  • AIはフィードバックを通じて学習できないため、繰り返し同じミスをレビューし続ける必要がある

• AIツールを使って新しいツールを素早く開発できた

  • AIのおかげで数日かかる作業を数時間で完了できた
  • AIが作業全体の70%または42.5%を担ったとしても、大きな改善だった

• ジュニア開発者にとってAIは諸刃の剣である

  • AIを学習の近道として使うと、学習そのものを飛ばしてしまう
  • しかしAIをメンターとして使えば、深い学習が可能になる
  • AIがジュニア開発者の仕事を代替すると、採用の問題が発生する可能性がある

• 「信頼せよ、ただし検証せよ」というパターンが重要だ

  • AIが書いたコードがコンパイルされ、テストケースを通過したなら前向きなシグナルである
  • 例えば、RustのcsscolorparserをPythonにバインドしたプロジェクトがある

• AIはコードを素早く書けても、学習プロセス自体が速くなるわけではない

  • AIの助けでもっと早く成長できるが、それでも適切に構造化されたコードを書くには時間がかかる

• Copilotは複雑な作業では失敗する

  • AIはスケーラビリティに限界を見せている
  • 将来は量子コンピューティングのような技術が必要になるだろう

• GenAIは要件がよく分かっているソリューションでは、踏み込んだ結果を提供できる

  • 複雑な問題では50%程度の成果しか出せない
  • 詳細なタスクリストを作り、各タスクを個別に解決する方法を使っている

• AIの作業を検証することが重要だ

  • AIが提案したコードは実行可能だったが、セキュリティ上の問題があるライブラリを使っていた
  • AIのコードが実行可能でも、検証は必要である

• AIで生産性が大幅に向上したという人に実際に会うのは難しい

  • AIツールは便利だが、コーディングの一部にしか役立たない