TriTry

Github Copilotを使えばコーディングが一人でも比較的軽快に進む。

これは以前の記事で示した通りです。

しかし、「銀の玉」はありません。銀の玉はすべてを解決してくれるものという意味ですが、そういう代物ではありません。開発を通じてわかったことをいくつか書いていきます

モデルはClaude Sonnet 4を利用していますが、一般的に言われている「SQL」に弱いことは確実です。

このブログではタグを使って小分類を管理しています。

その上に「カテゴリ」という大分類、ヘッダにあるタブを追加しましたこのクエリの作成が手間取りました。

プロンプトには「タグにカテゴリを追加、このカテゴリでフィルタしてほしい」と書きました。人間であれば下記のような構文が思い浮かぶと思います

tags = getTag(article_id)

flag = false

for tag in tags:

article_category = getCategory(tag.id)

flag = (current_category == article_category) or flag

実際には効率を考えてwhile文を使うでしょうし呼び出しも検討します。

これのクエリを組むことができなっかた

解決方法はプロンプトを工夫するに尽きますが、このアルゴリズムを丁寧に書き示す必要がありました。

またデバッグ用の記事の種類や生じている事象を箇条書きで下記しまします

・記事ID「ｘｘｘｘ」はITモードに含まれないが含まれている

・記事ID「ｙｙｙｙ」はTriathlonモードと音楽モードに含まれる

このような情報を何度も書き込みます。

あとはGithub Copilotはコーディングに特化しているのでコマンドライン上でのデバッグコード生成しコードを生成を待ちます。

コードの問題個所を下記のように指摘することで、検索の範囲を狭め適正なコードに編集する助力にもなります

・l.4行目のif分岐がおかしい

こどのように検索範囲を限定するか、どこが誤りかを指摘しなければ正しいコーディングを生成することはできません。

つまり、コーディングエージェント利用者もレビュー能力がなくてはならないのです。

とはいえ、まだ駆け出しのエンジニアに一から指示を出すよりかは、実装スピードは依然速いままでしょう。

また、このSQLの問題以外に起きうる問題は「余計な変更」で、これは若手エンジニアがよくやってしまうことですので、コーディングエージェントであるが故のトラブルではありません。

コーディングエージェントの利用にはやはりコーディングスキルは必須になります。

レビュースキルはかなり高度なスキルで、これができるエンジニアは”チームリード”クラスです。社会人でいえば標準的には3～5年目です。

一方でコーディングエージェントに頼る開発を行えば、1年目のエンジニアの育成はできません。開発スピードとのトレードオフになってくるでしょう。

大企業では育成する余力はあるでしょうが、自社プロダクトを高速で開発する必要のあるベンチャーや3次受けくらいになる開発を受け持つ中堅SIerではコストが見合わない状態に陥るでしょう。

かといってスクールではこのスキルは学びきれない結果になります。

以前のキングダムに例えた記事でいうところ「勘」は現場以外では育ちにくいものです。王毅将軍も信に言ってましたよね。戦場で培うものだと。

今後AIを活用するうえでのIT業界全体を揺るがす課題だと思います