41 ポイント 投稿者 GN⁺ 2025-01-06 | 3件のコメント | WhatsAppで共有
  • 「AIコード分析に対する考え方を変えた混乱の実験」
  • 従来のAIがReactコードベースを分析する際に、しばしば失敗する状況を目にした
  • 原因は、ジュニア開発者が初めてコードを読むときのように、行単位でしか分析しない方式にあったと気づいた

ブートキャンプ時代とシニアのマインドセットの違い

  • ジュニア時代は、ファイルを順番に行単位で読んでいるうちに、すぐに道を見失うことが多い
  • シニア開発者は大規模なPRを見るとき、次のようなやり方を使う
    • まず重要なファイルを確認する
    • 機能ごとに変更点をまとめて把握する
    • 先に全体アーキテクチャを理解し、その後で詳細実装を見る
  • このアプローチをAIにも適用することにした

実験

  • ファイルを機能別にグループ化し、そのグループに関するコンテキスト情報を先にAIへ与える方法を試した
  • サンプルコードではFileGroupインターフェースを定義し、関連する機能とファイルサイズに応じてファイルをまとめて処理する
  • グループ単位でAIに「どの機能領域なのか、何を重点的に見るべきか」などを案内するプロンプトを構成した

驚くべき変化の瞬間

  • 以前は「JWTトークン認証ロジックが含まれている」程度の単純な応答しかしていなかったAIが
  • 「WebSocket接続などへの影響、最近マージされたPRに対するレースコンディションの可能性」など、シニア開発者レベルの洞察を示すようになった
  • AIがシステム全体の文脈を考慮して指摘し始めた

実際に変わった点

  • より複雑な機械学習モデルを使ったのではなく、シニア開発者のように考える順序をAIに与えたことが核心だった
    1. コンテキスト優先: まずシステム全体を理解する
    2. パターンマッチング: 類似ファイルをグループ化して、繰り返されるロジックを見つける
    3. 影響分析: 変更がシステム全体に与える影響を認識する
    4. 履歴の理解: 過去のコード変更の理由や文脈まで追跡する

予想外の副次効果

  • 単に狙った箇所だけを直すのではなく、次のようなインサイトも捉えるようになった
    • コピー&ペーストによる重複コードブロックの特定
    • 一貫しないエラー処理パターンへの警告
    • 潜在的なパフォーマンスボトルネックの可能性の把握
    • 利用パターンに基づくアーキテクチャ改善提案

なぜ重要なのか

  • 最近のAIベースIDEは、コードの自動生成に注力している
  • しかし、システム全体の文脈なしに単純な提案だけを行うのは、「入ったばかりのジュニア開発者」のように危険になり得る
  • 本当に重要なのは「深いコード理解」だ

残された問い

  • コンテキスト(履歴情報)をいつ更新し、いつ維持するかを決める問題
  • 互いに衝突するパターンが見つかったときにどう対応するか
  • 不確実性の高い分析結果をユーザーにどう表示するか

今後の方向性

  • シニア開発者のように、次のような感覚もAIに教えられるかを検討している
    • 技術的負債を事前に検知する能力
    • アーキテクチャ改善案を能動的に提案する力
    • 利用パターンからセキュリティ問題を検知する能力
    • チーム内部の非公式ルールを把握する感覚
  • 単に「より多くのコード」を生成するのではなく、「シニア開発者のようにコード全体を深く理解する方法」を教えることが最終的な目標だ

3件のコメント

 
savvykang 2025-01-06

コードベースの分析と改善のために投げかけるべき質問は、ある程度定型化されているのではないでしょうか。著者はかなり浮かれているようですね。

 
yangeok 2025-01-06

CursorでNotepadにプロジェクト全体の説明を書かせるのと同じ文脈のように見えますね

 
GN⁺ 2025-01-06
Hacker Newsの意見
  • コメント欄では人々が批判的。この記事は新しいツールの可能性についての短く前向きな結果を扱っており、率直で合理的な考えも含まれている

    • 「Senior vs Junior Developer」というナラティブはやや誇張されているかもしれないが、記事の本質は素晴らしい
    • 人々は脅威を感じて怒っているのだろうかと気になる
  • LLMが驚くべきことをするもう一つの例。しかし、あらゆる入力に対して一貫して正確に動作するシステムを構築するのは非常に難しい

    • 認証システムのファイル分析の例がある
    • このハードコードされた文字列は重要な役割を果たしているが、すべてのPRに対して正確かつ一貫して生成されるまでは特別ではない
    • さまざまなコードベースと実際のPRを通じて評価を設定する必要がある
  • コード作成において、より優れたエージェントシステムのための教訓があるはず

    • Claude/chatGPT などにコードを生成しないよう指示する。最初の構造を生成した後でコードを書かせる
  • 記事の最初の行を読んで、まるで宇宙人のように感じた。全文を読む必要はあるだろうが、既存のコードを順番に読むというのは奇妙に感じる

    • 「ジュニア開発者」に対する誤った認識が多い
  • 人間的要素の重要性を強調している。コードベースの文脈的理解がなければ、AIの警告が何を意味するのか分からない

    • 「共有パターン」が何なのか、なぜ競合状態を引き起こすのか理解しにくい
    • 認証変更と「再試行ロジック」のPRの関係が明確ではない
  • AIが存在しないAPIをでっち上げるのを防ぐのは難しい。うまく動くときは良いが、大半はうまく動かない

    • AIがうまく機能するのは、多くの人がすでに書いたコードを書いているときだ
  • コードの文脈と理解は、LLM生成コードの品質向上に重要

    • Bismuth製品は、ユーザーの要求に応じてプロジェクトを論理的な領域に分割し、シンボル情報を検索してコードベースを探索する
    • 競合製品のうち、このレベルの検索機能を提供しているものは一部だけ
  • John McCarthyの不満のように、これは実験や証明ではなく逸話だ

    • コミュニティが批判的思考と訓練を活用してくれることを望む
  • 結果は印象的。スタイルや統一性への批判はあるが、結果は有用に見える

    • タイトルから、AIが他人の作業を無視して自分の作業だけを強調する内容なのかと思った
  • この技術の重要な部分が記事から抜けているようだ。getFileContext()shouldStartNewGroup() の実装がない