Skip to content
eclair's note
Go back

【日記】AI駆動でライブラリを作ってみた所感とか

Edit on GitHub

この記事は25/11/26に書いたメモ書きを今更記事化したものです。

25/11/26の日記

Agent駆動でライブラリを作成した。
自力ではほぼコードを書いてない。指示を出して、AIに95%ぐらい書かせた。

ライブラリはC#のSource Generator+Analyzer(CodeFix)。
C#の知識がない人向けに説明すると、すでにあるコード等を元にボイラープレートコードを自動生成したり、コードの問題点を検出・自動修正を提供する仕組みを提供することができる。
ただし複雑な構文解析を行う必要があり、色々と大変。C#の構文を扱うためのRoslynというAPIを使用する必要があるが、これがかなり難解。
正直RoslynのAPIを考えたくないのでAIにやらせた。

結果としてはかなり満足。AI駆動開発も全然やれる。
最初はClaude Code, レート制限にぶち当たってからはGitHub Copilot Agentをメインで使用。

各AIの所感

  • Claude Code
    • 頭が良い。複雑なタスク(大規模リファクタリング)をやりきれる。
    • ただしレート制限が厳しい。Proプラン(20$)だと頻繁にレート制限にぶち当たる。
      • 3-4時間程度のリミットには頻繁に当たった。これはちょっと待てばいいのでまだいい。
      • 1週間のレート制限に当たって、これは厳しいと感じ乗り換えた。
      • 置き換え先をどうするか悩み中。Copilot Agentだけだとできないタスクも確かにある。Codexあたりが良いかな
  • GitHub Copilot Agent
    • Claude Codeほど頭は良くない。Copilotが30分かけて解決しないタスクでもClaudeだと一瞬で解決することもある。
    • ただ、レート制限がかなり緩い。
      • 30-40分動かすのに1リクエスト使用し、それが月300回(Pro)使えるのでかなり余裕がある。
    • 愚直にコードを書く・要求している真意をあまり考慮してくれない傾向がある
      • 1セッションあたりが長いという構造上の問題もある。
      • テストケースやeditorconfig・コメントでレールを敷いてあげる必要がある。

最初のポイント

  • 設計は自分で考える。少なくともAPIの使用感は自分で考える。
  • それをベースにTASK.mdとして作成したい機能を箇条書きでAIに与える。
  • 自分の場合はコードベースの雛形(フォルダ構造とか)は事前に用意しておいた。
  • はっきり言ってここが人間のバリューそのものなので(コードはAIが書いてくれるからね!)、時間をかけて考える。

機能を追加したりバグ修正するときのポイント

  • 最小再現例・発生するバグ・期待する動作を明確に箇条書きでIssueとして立てる。
  • AIにそれを読ませてコードを書かせる。
  • 必ずテストケースを追加させる。内部の挙動はまともに追えないのを前提とした(RoslynのAPIわからないし)。
  • 生成された結果は必ず自分でレビューする。GitHub Codespace上で動かして、バグが直っていることを確認。
    • コードにはあまり踏み込まない。読めないので(ry
    • ただし、明らかに間違っていたり、もっとよくできそうな案があればそれは指摘。
      • 一例として、三項演算子絡みのバグを提示したとき、三項演算子に限定して修正してきたことがあった。
    • 目の前の課題を愚直に解決する傾向がある(特にCopilot Agent)ので、出来上がったコードの流れは確認すべき。
      • 例えば単純なパターンマッチングだけでやろうとしてないか?など。
  • 理想的には、Agentに指示を出すときはテストケースを用意したほうがいい。
    • ただ毎回これを自力でやるのは大変なので、実際にはPR作成してもらった後に気に食わない・間違ってるポイントのみテストケースを追加するようにした。
    • Agent的にはすでにあるテストはMUST TO BEなので(存在さえしてくれれば)高い確率で従ってくれる。
  • 修正時の生成物で、細部が気に入らないときはさっさと取り込んだほうがいい。
    • これは人間相手でも同じですね。
    • そのうえで細部を修正するIssueを立てる→もう一度AIに投げる。
      • これは人間相手にはできないですね。流石に。

感想

  • AIに指示を出すスキルが重要
    • 散々言われている話ではあるが、「どうしたいか」を常に考えてそれを伝えるほうが重要。
    • 幸い、自分はこれは向いていると思う。コードを書くことより成果物のことを考えるのが好きなので。
  • テストコードを書くのは必須
    • 内部の挙動を追うのは無理と思ったほうがいい。
      • 生成される量が多すぎる。
      • 設計は動的に変化する。
    • そこで、テストコードを書かせて、動作保証を確立する。
    • 今回はライブラリなので簡単だったが、フロントエンド系の開発だともっと大変そう。
  • レビューに時間をかけるべき
    • 自分でコードを書かない分、レビューに時間がかかる。
    • ただ、流れだけでも把握しないと非効率的なことを普通にやってくるので、時間をかけてでも見るべき。
  • 上記を踏まえて
    • コードを書ける、というだけではバリューは低い。ただし高度な知識があればやれる
      • 今回のケースなら、RoslynのAPIを完全に把握できてれば仕事はありそう。
      • ただし付け焼き刃程度の知識なら、AIに任せたほうが早い。
    • そうはいっても、ド素人がいきなりさわれるとは思えない
      • ある程度の知識がないと、指示を出せない。結果を検証できない。理想像を伝えられない。
      • よく言われる話ではあるが、ジュニアとシニアの差がより顕著になると思う。

細かいTIPS

  • Copilot Agentを使うとブランチが増えまくるのでこの記事を参考に定期的にクリーンアップしてあげると良い。
  • 検証を速やかに行うために、よく使うコマンドはscriptsにまとめてそれを叩くだけにした。
    • 例えばsrc/以下に限定してビルドするコマンドや、生成物をクリーンアップするコマンドなど。
  • Copilot Agentは簡単なIssueを与えると10分程度で解決してくれるが、使用するリクエスト数は時間をかけたときと変わらない。
    • なのでいくつかのタスクをまとめて与えたほうがリクエスト効率が良い。
    • ただ、当たり前ではあるがクオリティは下がるので難易度を推測して割り振ると良い。(このあたり、人間相手と何も変わらないですね)

26/01/21追記

  • AIを使った開発はだいぶとっ散らかる。もうメンテできない。

    • 1から書き直すことを検討している。
    • 機能としては便利だっただけに、なおさら。
  • パフォーマンスが劣悪なことに気づいてしまった。

    • これはSourceGeneratorというニッチ分野だからというのもあるが、普通に落とし穴に引っかかった。
  • 勉強は欠かせない。

  • あと、GH Copilot Agentが20分以上稼働しなくなった気がする。

    • 正確にはプロンプト次第だけど、途中で切り上げることが増えた気がする。
    • これはモデルにClaudeCodeを使ってるからかも。

Edit on GitHub
Share this post on:

Previous Post
【C#】Prismaのような書き心地をEFCoreでも実現!Linqraftの紹介
Next Post
【日記】Cloudflared経由で外部からSSH接続するメモ