- エージェント・コーディングを試してみましたが、オンラインで見た内容と自分が実際に実装した結果の隔たりのせいで頭を抱えています。実際に前向きな結果をもたらすという証拠はあるのでしょうか？
- 誇大な宣伝を超えて、エージェント・コーディングをうまく実装できた方がいれば、どのように行ったのか詳しく共有してください
- 「うまく実装する」 とは、次のような意味です
- 技術的負債よりも多くの価値を生み出すこと
- アーキテクチャ責任者が承認できる程度に構造的に堅牢なコードを書くこと
- 最近は「アーキテクチャの検証」から「動作の検証」へ切り替えるべきだという主張とともに、コードレビューを最小限にする、あるいは完全になくす流れが見られます
- 実際には、これはコードを見ずにテストとCIを通過すればデプロイするという意味のように思えますが、このやり方が長期的に持続可能なのか疑問です
- 私の考えでは、Codexを使うと通常の経路では動作するものの、時間の経過とともに微妙でデバッグしにくいエラーが蓄積して「スパゲッティコード」になる可能性が高いです
- 既存のコードベースにCodexを適用してみると、ガイドラインを設定していてもいなくても、自分の時間の半分はCodexが生み出した微妙なエラーや重複コードの修正に使われてしまいます
- 先週末には、ペットフード通知用のiOSアプリをゼロから作り直してみましたが
- CodexにSwiftUIベースのアーキテクチャの青写真をまず調査して提案してもらい、何をどのように実装すべきかを説明する仕様をCodexと一緒に作成
- 最初の実装にはいくつかバグがあったものの、予想外に悪くはありませんでしたが、その後は急速に状況が悪化
- 残りの週末は、Codexが正しく動作し、新しいバグを作らずにバグを修正し、行き当たりばったりにコードを書くのではなくベストプラクティスを調査するよう仕向けることに費やしました
- 新しいガイドラインを見つけるたびにCodexに記録させましたが、状況は改善せず、結局は断念
- 個人的には、レビューされていないコードをデプロイするのは受け入れられません
- 何かがおかしい気がします。プロダクトはきちんと動くべきですが、コードの品質もまた高くあるべきです
1件のコメント
Hacker Newsの意見
LLMはコスト削減の鍵と見なされており、巨額の資金が懸かっている
著名なインフルエンサーや専門家も、「最先端」のイメージを保つために誇張した発言をすることがある
しかし実際には、LLMベース開発の最適なアプローチはまだ確立されていない
今は信仰のように信じるより、内部の動きを自分で見極めることが重要だと思う
こうした提案が無作為のユーザーにまで届いているということは、すでに大規模なマーケティングキャンペーンが進行中だという意味だ
単純なCRUD作業では楽しいが、複雑なプロジェクトではむしろフラストレーションを招く
今はベンチマーク競争とVC資金が集中していて、冷静な議論が難しい時期だ
まだ定量的な証拠は不足しているが、開発者が完全に消えることはなくても、開発のやり方は永遠に変わった
GoogleのあるPrincipal Engineerが、「Claude Codeが1年かかる仕事を1時間でやった」とツイートした
しかし後になって明らかになったのは、AIが作ったのは単なる**『おもちゃ版』だったということだ
このような誇張された発言が期待値を歪め**、失望を招いている
関連ツイートリンク
この6か月を振り返ると、インフラコード（例: Terraform）では10倍の効率を得られた
ただし、専門機能の開発は依然としてばらつきが大きい
それでも、繰り返し作業が減って生まれた時間でテスト・セキュリティの品質を高められた
何より、再びコーディングの楽しさを感じられるようになった
**補助コーディング(assisted coding)**の形が最も効率的だった
プロジェクトリンク
こうした個人プロジェクトこそ本当のゲームチェンジャーだと思う
私は既存アプリにエージェントを付ける方式で大きな成功を収めた
エージェントはアーキテクチャ設計には弱いが、すでに構造化されたコードでは非常によく動く
型システムが厳格で、テストカバレッジが広いほど効果が大きい
Claudeが作成したROADMAP.md、TASKS.md、STATUS.mdを基準に進めており、
驚くべきことに20%ほど完成している状態だ
一方でPythonやJSは弱い型システムのせいで信頼しにくい
最初から作るのは難しいが、明確な仕様を与えれば効率は高い
一方でPythonのオプショナル型付けは、むしろエラー伝播を引き起こす
私はLinux向けのリアルタイムBluetooth心拍数モニターをClaude Codeで100%書いた
プロジェクトリンク
純粋なCで書かれており、Webインターフェースとリアルタイムグラフまで1日で完成した
以前は失敗していたdBus–blueZ通信も、今回はうまく実装できた
ドキュメントにはSSEと書かれているが、内部的には通常のHTTPレスポンスを返しているだけだ
私は毎日Augment + Claude Opus 4.5を使っている
自分でコードをほとんど書かず、仕様ベースの反復作業でプロジェクトを完成させている
複数のエージェントを並列で回してレビューするやり方が特に効率的だ
明確な仕様作成と段階ごとのフィードバックが鍵になる
30年のキャリアで最も革命的な変化だと感じており、業界全体が変わると確信している
現在はClaudeで日英辞書プロジェクトを進めている
GitHubリンク, ウェブサイト
20年経験の開発者として、LLMのおかげで作業速度の予測が完全に外れるようになった
以前なら2週間かかった仕事が、今では2日で終わる
コードレビューとやり取りは必要だが、ほとんどの人間の開発者より優れていると感じる
LLMとの対話はシニア開発者と協業している感覚に近く、
私が長年コードレビューと業務の割り振りをしてきた経験が大いに役立っている
私が試した方法の中で最も安定していたのは、小さく明確な作業単位でClaudeに任せることだ
計画を立て、レビューし、実装後にまたレビューする、という形で繰り返す
完璧ではないが、行き詰まりを打開するのに非常に役立つ
ただしガイドラインはあまり守れないので、自分で検証して整理することが必須だ
1回に1関数ずつ任せ、その結果を踏まえてより良いアイデアを得る
しかし設計中心の問題になると限界がはっきりする
AI補助コーディングを誤解している人は多い
AIはチームメンバーではなくアシスタントだ
バグや誤動作を失敗と見るのではなく、熟練した開発者がその混乱を整理していく過程こそが本質だ
私も毎日Claudeを使っているが、AIが作るテストコードはしばしばひどい
実際には
expect(true).to.be(true)のような無意味なテストを量産する実装とテストを同時に任せると自己採点型の誤りが生じる