70%完成の罠：AIアシストコーディングのための30%最終チャレンジ

ここ数年、AIによる開発に深く関わってきて、興味深い現象に気づいた。エンジニアがAIを使うことで生産性が大幅に向上したと報告する一方で、私たちが日常的に使っている実際のソフトウェアが大幅に改善されたようには見えないのだ。何が起こっているのだろうか？

その答えは、私たちが直視すべきソフトウェア開発に関する基本的な事実を明らかにしている。私の発見を紹介しよう。

開発者が実際にAIをどのように使っているか

私は、チームがAIを使って開発する方法について、2つの異なるパターンを観察してきた。私たちはそれを「ガイド」と「イテレーター」と呼んでいる。どちらも、エンジニア（そして技術者でないユーザーでさえも）がアイデアから実行（またはMVP）までのギャップを埋める手助けをする。

ファシリテーター：ゼロからMVPへ

Bolt、v0、screenshot-to-code AIなどのツールは、新しいプロジェクトをブートストラップする方法に革命をもたらしている。これらのチームは通常

• デザインや大まかなコンセプトから始める
• AIを使って完全な初期コードベースを生成する
• 数週間ではなく、数時間から数日でプロトタイプを完成させる！
• 迅速な検証と反復に重点を置く

その結果は印象的なものになる。最近、あるインディーズ開発者が ボルト Figmaのデザインを、非常に短期間で動くウェブ・アプリケーションにした。まだ本番には間に合いませんが、最初のユーザー・フィードバックを得るには十分です。

イテレーター：日々の開発

第二陣営は、カーソル、クライン、コパイロット、そして ウインドサーフ このようなツールを日々の開発ワークフローに活用する。劇的ではないが、より大きな変革をもたらす可能性がある。これらの開発者は

• コード補完と提案にAIを使う
• 複雑な再構成タスクにAIを活用する
• テストとドキュメントの作成
• AIを「ペアプログラマー」として問題解決に役立てる

しかし、問題はここからだ。どちらのアプローチも開発を大幅に加速させることができるが、すぐには目に見えない隠れたコストがかかる。

AIスピード」の隠れたコスト

シニア・エンジニアが カーソル もしかしたら コパイロット このようなAIツールになると、まるで魔法のように見える。テストや文書化を含め、機能全体を数分で構築できるのだ。しかしよく見ると、重大なことに気づくだろう。常にそうなのだ：

• 生成されたコードを、より小さく、より焦点を絞ったモジュールにリファクタリングする。
• AIミッシング・エッジ・ケース処理の追加
• 型定義とインターフェースの強化
• 建築の決断を問う
• 包括的なエラー処理の追加

AIは彼らの実装を加速させるが、保守可能なコードを維持するのは彼らの専門知識なのだ。

ジュニア・エンジニアは、こうした重要なステップを見逃すことが多い。彼らはAIのアウトプットを受け入れやすく、私が「トランプの家のコード」と呼んでいるようなコードになる。

知的パラドックス

AIツールは初心者よりも経験豊富な開発者を助けるということだ。AIはコーディングを民主化すべきではないだろうか？

現実には、AIはあなたのチームに非常に熱心なジュニア開発者がいるようなものだ。彼らはすぐにコードを書くことができるが、常に監督と修正が必要だ。知れば知るほど、より良い指導ができる。

これが、私が「知識のパラドックス」と呼ぶものを生み出している：

• シニアは、すでに知っていることを加速させるためにAIを使う
• AIを使って何をすべきかを学ぼうとする後輩たち
• 結果は大きく違った

私はシニア・エンジニアがAIを使っているのを見ている：

• すでに理解しているアイデアを迅速にプロトタイプ化
• 基本的な実装を作成し、それを改良する。
• 既知の問題の代替案を探る
• 定型的なコーディング作業を自動化

同時に、後輩たちはよくこう言う：

• 誤った、あるいは時代遅れの解決策の受け入れ
• セキュリティとパフォーマンスに関する重要な考慮事項が欠けている
• AIが生成したコードのデバッグが困難
• 十分に理解していない脆弱なシステムの構築

70%問題：AIの学習曲線のパラドックス

最近、私が注目したツイートは、私が現場で観察してきたことを完璧に捉えている。非エンジニアがAIを使ってコーディングすると、挫折するような障害にぶつかる。彼らは70%を驚くべき速さで完成させることができるが、最終的に30%は収穫逓増の練習になる。

この "70%の質問 "は、AI支援開発の現状に関するいくつかの重要な情報を明らかにしている。当初、進歩は素晴らしいものだと感じていた。自分が欲しいものを説明すれば、v0やボルトのようなAIツールが、印象的に見える動くプロトタイプを生成してくれた。しかしその後、現実が見えてきた。

2段階後退モード

次に予測可能なパターンが起こる：

• あなたは小さなバグを修正しようとした。
• AIは合理的と思われる変更を提案した。
• この修正によって、別のものが壊れてしまった。
• あなたはAIに新しい問題の解決を依頼した。
• その結果、2つの疑問が生じる。
• 何度も何度も

このサイクルは非エンジニアにとって特に苦痛である。なぜなら、彼らは実際に何が間違っていたのかを理解するためのメンタルモデルを持っていないからである。経験豊富な開発者は、エラーに遭遇したとき、長年のパターン認識に基づいて潜在的な原因と解決策を推測することができる。このような背景がなければ、本質的に、完全に理解していないコードでモグラたたきゲームをしているようなものだ。

ラーニング・パラドックスの続き

AIコーディング・ツールを非エンジニアにとって使いやすくしているもの、つまり複雑さに対処する能力を表しているものが、実は学習の妨げになっているのだ。コードが「表示」されても、その根底にある原理を理解していない場合：

• デバッグのスキルが身につかない。
• 基本的なパターンを学ぶことを見逃している
• 建築上の決定を外挿することはできない
• コードの保守や開発が苦手な方

これでは、問題に対処するための専門知識を自分で開発するのではなく、問題を解決するためにAIに戻り続けなければならないという依存関係が生まれてしまう。

知識格差

私が見てきた中で、AIコーディングツールを使って最も成功している非エンジニアは、ハイブリッドなアプローチを取っている：

1. AIによるラピッドプロトタイピング
2. 時間をかけて、生成されたコードがどのように機能するかを理解する。
3. AIを使いながらプログラミングの基本概念を学ぶ
4. ステップ・バイ・ステップで知識ベースを構築する
5. 単なるコードジェネレーターではなく、学習ツールとしてAIを使う

しかし、これには忍耐と献身が必要であり、多くの人がAIツールの使用によって達成したいと考えていることとは正反対である。

将来への示唆

70%問題」は、現在のAIコーディングツールがそのようなものであると見なすのが最善であることを示唆している：

• 経験豊富な開発者のためのプロトタイプ・アクセラレーター
• 開発を理解するための学習教材
• アイデアを素早く検証できるMVPジェネレーター

しかし、多くの人が望んでいるコーディングの民主化の解決策にはまだなっていない。最終的に30%は、ソフトウェアを生産可能で、保守可能で、ロバストにする部分であるが、まだ本物のエンジニアリングの知識が必要である。

良いニュースは？ツールが改善されれば、その差は縮まるかもしれない。しかし今のところ、最も現実的なアプローチは、学習を完全に置き換えるのではなく、学習を加速させるためにAIを使うことだ。

実際に機能するもの：実用的なモデル

何十ものチームを観察してきた私が、一貫して効果があると見てきたのは次のようなことだ：

1.AI初稿モデル

• AIに基本的な実装を生成させる
• モジュール化のための手動レビューとリファクタリング
• 包括的なエラー処理の追加
• 包括的なテストを書く
• 重要な決定事項の文書化

2.継続的対話モデル

• 異なるタスクごとに新しいAIチャットを起動
• 文脈を重視し、最小限に抑える
• 頻繁なレビューと変更点の提出
• 緊密なフィードバック・ループの維持

3. "信頼するが検証する "モデル

• AIによる初期コード生成
• すべてのクリティカル・パスを手動でレビュー
• エッジケースの自動テスト
• 定期的なセキュリティ監査の実施

未来への展望：AIの本当の未来は？

こうした課題にもかかわらず、私はソフトウェア開発におけるAIの役割について楽観的だ。重要なのは、AIが本当に得意とすることを理解することだ：

1. 加速度既知
   AIは、私たちがすでに理解しているパターンを実現する手助けをするのが得意だ。無限に忍耐強い双子のプログラマーがいて、そのプログラマーがとても速くタイピングできるようなものだ。
2. 可能性を探る
   AIはアイデアを素早くプロトタイプ化し、さまざまなアプローチを探求するのに適している。コンセプトを素早くテストできるサンドボックスを持っているようなものだ。
3. オートメーション・ルーチン
   AIはサンプルや通常のコーディング作業に費やす時間を大幅に削減し、興味深い問題に集中できるようにする。

それはあなたにとってどういう意味ですか？

もしあなたがAIによる開発を始めたばかりなら、私がお勧めするのは以下の通りだ：

1. 小さく始める
   • 孤立した、明確に定義されたタスクにAIを使う
   • 生成されたコードの各行をレビューする
   • 段階的な機能強化
2. モジュール性の維持
   • すべてを小さく、焦点を絞った文書に分割する
   • コンポーネント間の明確なインターフェイスを維持する
   • モジュール境界の文書化
3. 自分の経験を信じなさい。
   • AIを判断の代わりに使うのではなく、加速させるために使う
   • 違和感のあるコード生成に疑問
   • 技術基準の維持

エージェント・ソフトウェア工学の台頭

2025年を迎え、AIによる開発の状況は劇的に変化している。現在のツールは、プロトタイプの作成と反復の方法を変えてきたが、私は、さらに重要な変化、すなわちエージェント・ベースのソフトウェア・エンジニアリングの台頭の兆しにあると信じている。

エージェント」とはどういう意味だろうか？これらのシステムは、単にプロンプトに応答するだけでなく、自律性を高めながらソリューションを計画し、実行し、反復する。

Cursor/Cline/v0/Boltについての私の考えも含め、プロキシについてもっと知りたいなら、私に興味があるかもしれない。

私たちはすでにこの進化の初期段階を目の当たりにしている：

対応者から協力者へ

現在のツールは、主に私たちのコマンドを待っている。しかし、アップデートされた機能を見てみよう。 クロード (a) コンピュータにおけるコンピュータの使用。 クライン ブラウザを自動的に起動し、テストを実行する機能。これらは単なる美化されたオートコンプリートではなく、実際にタスクを理解し、率先して問題を解決してくれる。

デバッグについて考えてみよう。これらのエージェントは単に修正を提案するだけではない：

• 潜在的な問題の積極的な特定
• テスト・スイートの立ち上げと実行
• UI要素の検査とスクリーンショットのキャプチャ
• 改善策の提案と実施
• ソリューションが機能することを確認する（これは大きな問題になる可能性がある）

マルチモーダルの未来

次世代ツールは、単にコードを扱うだけでなく、シームレスに統合できるかもしれない：

• 視覚的理解（UIスクリーンショット、モデル、ダイアグラム）
• 口頭言語対話
• 環境との連動（ブラウザ、ターミナル、API）

このマルチモーダルな能力とは、人間のようにソフトウェアを理解し使用できることを意味する。

自律的だが誘導される

私がこれらのツールを使って得た重要な洞察は、未来はAIが開発者に取って代わるということではなく、AIが人間の指導や専門知識を尊重しながらも主導権を握ることができる、ますます有能な協力者になるということだ。

2025年に最も効果的なチームは、学習するチームかもしれない：

• AIエージェントに明確な境界線とガイドラインを設定する
• エージェントが作業できる強力なアーキテクチャパターンを構築する
• 人とAI能力間の効果的なフィードバックループの構築
• AIの自律性を活用しながら、手動による監督を維持する

英語優先の開発環境

アンドレイ・カルパシーが指摘するように：

"英語は最もホットな新しいプログラミング言語になりつつある"

これは、開発ツールとの関わり方における根本的な変化だ。自然言語で明確に考え、正確に伝える能力は、従来のコーディング・スキルと同じくらい重要になってきている。

代理店開発へのシフトは、私たちのスキルアップを必要とする：

• より強力なシステム設計とアーキテクチャ思考
• より良い要求仕様とコミュニケーション
• 品質保証とバリデーションへの注力の強化
• 人とAIのコラボレーションを強化

エンジニアリングとしてのソフトウェアの復活？

AIによってソフトウェアの迅速な構築がかつてないほど容易になる一方で、真に洗練された消費者品質の体験を創造する技術という重要なものが失われる危険性がある。

品質の罠を実証する

チームがAIを使って印象的なデモを素早く作り上げる。ハッピーパスは見事に実行されている。投資家やソーシャルネットワークはそれを絶賛する。しかし、実際のユーザーがクリックし始めたらどうだろう？それは物事が崩壊するときだ。

私はこの目で見てきた：

• 一般ユーザーには意味のないエラーメッセージ
• アプリケーションのクラッシュにつながるエッジケース
• 一度もクリーンアップされたことのない雑然としたUI状態
• アクセシビリティを完全に無視
• 低速デバイスでのパフォーマンスの問題

これらは単なるP2のバグではなく、人々が許容するソフトウェアと人々に愛されるソフトウェアの違いなのだ。

失われた装飾芸術

ユーザーがサポートに問い合わせる必要のない、真のセルフサービス・ソフトウェアを作るには、異なる考え方が必要だ：

• 誤った情報に取り憑かれている
• 低速接続でのテスト
• あらゆるエッジケースにエレガントに対応
• 機能を発見可能にする
• 実際の非技術系ユーザーによるテスト

このような細部へのこだわりは（おそらく）AIでは生み出せない。共感、経験、そして技術に対する深い関心から生まれるものだ。

パーソナル・ソフトウェア・ルネッサンス

私は、個人向けソフトウェア開発のルネサンスが起こると信じている。AIが生み出したMVPが市場に氾濫する中、際立つのは以下のような開発者によって作られた製品だろう。

• 誇り高きクラフトマンシップ
• 細部へのこだわり
• 完全なユーザー・エクスペリエンスに焦点を当てる
• エッジケースに対応
• 真のセルフサービス体験の創造

皮肉なことに、AIツールは実際にこのルネッサンスに貢献しているかもしれない。定型的なコーディング作業を処理することで、開発者は最も重要なこと、つまり実際にユーザーに役立ち、喜ばれるソフトウェアの作成に集中することができる。

下線

なぜなら、ソフトウェアの品質がコーディング速度によって制限されることは（おそらく）一度もなかったからだ。要件理解、保守可能なシステムの設計、エッジケースへの対処、セキュリティとパフォーマンスの確保など、ソフトウェア開発の難しい部分は、依然として人間の判断を必要とする。

AIが可能にするのは、私たちがより速く反復し、実験することであり、より速く探求することで、より良い解決策を導き出せるかもしれない。ただし、エンジニアリングの規律を守り、AIを優れたソフトウェアプラクティスの代替ではなく、ツールとして使う場合に限る。覚えておいてほしい：目標は、より多くのコードをより速く書くことではない。そうではなく、より良いソフトウェアを作ることが目標なのだ。賢く使えば、AIはその手助けをしてくれる。しかし、「より良い」とは何を意味し、どうすればそれを達成できるかを理解するのは、まだ私たち次第なのだ。

AIを活用した開発にはどのような経験がありますか？皆さんの体験談や洞察をコメントで聞かせてください。