🐍

Clineで試行錯誤

2025/03/06に公開

冒頭から完璧な蛇足

そもそもの話として 「AIを使ったシステム開発」 に対して、エンジニアとして如何なる態度を取るべきか、表裏含めたここ数年のエンジニア業界の重大トピックであった。「エンジニアの仕事がなくなってしまう!」などという悲観主義には首肯せざる理由があるし、いわゆる「AI驚き屋」みたいな軽薄な道化ムーブはしっかりとだるい。「何故なら〜」と戯言を繰る前に、我々はエンジニア。手を動かす必要がある。ChatGPT4以降、Claude Artifactsの衝撃を経て、Github Copilot、DevinやCursorなど、凄まじい勢いで異なるアプローチのソリューションが登場しているのは、皆が知るところ。そんな中、いくつか、これはいよいよしっかりと対峙せざるを得ないと考えさせられる記事が出てきたので、こうして重い腰を上げたのである。

https://note.com/shi3zblog/n/n983e29b30d34
https://zenn.dev/mizchi/articles/all-in-on-cline
https://www.oreilly.com/radar/the-end-of-programming-as-we-know-it/
https://zenn.dev/codeciao/articles/6d0a83e234a34a
https://zenn.dev/trysmr/articles/vscode_cline

(ちなみにオライリーの記事「The End of Programming as We Know It」は、R.E.M.の曲名をなぞらえているが、最近読んだトランプ関連の記事でも同じ曲を引用していたんだけど、そんな流行ってたの?そういえばトランプが一回目の選挙の際にその曲を演説で使用してバンド側から拒絶されるということもあったんすけど、そんな流行ってたんすねー)

https://www.youtube.com/watch?v=Z0GFRcFm-aY

さて、Cline

Devinは初期コストが高くてPoCに向かない、というのもあって、VSCodeのプラグインとして導入が容易なClineを試してみることに。

https://docs.cline.bot/

VSCodeユーザーには導入が容易。この辺を見てください。

  1. VSCodeの拡張機能「Cline」を検索してインストール
  2. OpenRouterのアカウントを作成して、APIキーを登録[1]
  3. 「Type your task here...」と控えめに待ち構えるテキストボックスにお悩みを投稿してやる

試しに、RemixからReact Router v7にアップデートした際のTSエラーを解消する、という聞くもやるも心からだるいタスクをお願いしてみた。エラー自体は、pnpm typecheckを実行することで、いくつか明示される。Firestoreから取得してきたDateやDocumentRefをシリアライズした際に、型に不整合が起きているということも確認済みだったのでその旨を伝える。(ちなみに、私は、AIに敬語使うタイプ)

お前の実力を見せてくれ

ファイル内の文脈を汲み取って、実装のサジェストをしてくれるGithub Copilotタイプや、Claude Artifactsのように、完成系をいきなり提示してくれるAIサービスを使用した経験があると、Clineの体験がそれとは大分異なることがわかる。 Clineは、暴走する。 プロンプトを投げた瞬間から、「pnpm typecheck俺の方でやってもいいっすか?」を皮切りに凄まじい勢いで暴走を始め、実行結果からエラーを拾い上げると「対象のファイル開いていいっすか?」開いたら開いたでゴリゴリと書き換えて「保存していいっすか?」「修正していいっすか?」。だんじりよろしく急カーブなど各所に痛々しい傷痕をはっきり残した後、主(俺のこと)の眼前に戻り、大抵はこんな風情である。

エラーを解消するために、別の処理を行います(Approve?)

もしくは

この内容を保存しますか?(Save?)

凄まじいスピードの試行錯誤。でもやっていることは俺たちと一緒。とりあえず与えられた情報を元に、設計を行ってから、ざっくりと粗めに組んでみる。問題が起こる。それを解決するために、再度素早く再設計を行い、実装する…。例の明け暮れが、とんでもないスピードで起こっている。

「使い物にならぬ」と切り捨てる前に、僕らにできる2・3のこと

結局、上記だんじり後のコードは本運用に回すことができなかった。TSのエラーは解消されたのだが、DocumentRefをデシリアライズする際の再帰処理に不具合があり、サーバーサイドでループが発生していた。これを再度Clineに突っ込むと、彼(彼女?)は再度暴れ牛のように嘶き、通りの向こうに消えるだろう。後に残されるのは甚大なコストとコードであり、その大量のDiffは次の祭りを予感させるものとなる。

さて、ではClineは(そしておそらくGithub CopilotのAgentモードや、CursorのYOLOモードは)、「使い物にならない」から無視しても良いのだろうか。 私は全くそうは思わなかった。 「AIがコードを書くようになって、エンジニアの仕事はなくなるのだろうか」という(実に退屈な)問いに、(色々言いたいことはあるけど略すと)「否」と応えていた私。このCline(たち)を実際に体験して、その思いは変質し、しかしより力強いものとなった。「否。に決まってる、ただしこのパラダイムシフトに気づかないでいると、地獄が待っている、だろう」 地獄が待っている。

エンジニアとは

元来、(人間の)エンジニアに求められている能力とは何か。私は 「コーディングという能力を用いて」「眼前の課題を解決する」能力 、と考える。無論、この回答は分解の余地を残している。コーディングとは何か。課題とは何か。エンジニアが行うべきは、課題という具象を抽象に分解し、その抽象を扱って、コードという具象に落とし込んでいく行為である。そして我々は、具象を扱うのに熟練を求められる。「○○やって」が、ある抽象を経由して、「むん」と動作する何某かの具象になっている。I/Oとしての俺たち。この行は読み飛ばして構わない。

AIの限界は、この具象化に際して、主たる責任を持ち得ないというところにある。彼ら(彼女ら?)の責任はどこまでも副次的なものであって、「成果物が正しく機能している」ということを責任持って保証するには第三者を必要とする。 この責任ある第三者は、幸運なことに、現段階では、我々人間にしか担当することができない。 この議論には、最終的に「生と死」にまで行き着く、神学的な側面がある。

この生産性が前提になる

では、中途の抽象はどうか。Clineは凄まじい。私から受け取った具象(プロンプト)を入り口に、とても精度の高い抽象と、精度の高い具象の変換を繰り返し、それを都度私に披露しながら、実に勝手に作業をやってのける。先述の通り、コストと膨大な成果物を撒き散らしながら。

これからの世界では、この圧倒的な生産性は前提となる。いくつかのAIエージェントを併用しながら、場面場面で実際にコーディングを行い、時にエージェントと並走しながら、コードを練り上げていくというスピードが前提となる世界は近い。本当はもう来ているのかもね⭐️。

俺たちに明日は…?

残念ながら、俺たちに明日はある(なければ、カルピス飲んで『ダイハード』観ながら昇天したかったよね。残念、そのパラディソはもうちょい先)。できること、やるべきことは何なのか。それをいくつか挙げて指針としたい。

  • コードを読む力をつける :AIエージェントの常軌を逸した試行錯誤の勢い。エンジニアは「Approve」「Save」を押下するのが目下の仕事となる。我々はボトルネックである。素早く、正しく、コードを読まなければいけない。コードが機能しないのは、我々エンジニアの責任であるということに矜持を持てるようになること
  • 正しく伝える :AIエージェントはStrictでSmartでStubbornである。ステークホルダー足る人間は、StrictでもSmartでもないし、Stubbornでは…ないと信じたい[2]。この非対称性の中でカロンたるのが我々エンジニアである。プロンプティングのエキスパート足る必要がある
  • いくつかのエンジンをワークフローの中で正しく機能させる :AIエージェントは疲れない(コストは食う)。コストを湯水のように消費することに躊躇する必要がない環境であれば、AIエージェント単体の生産性の総和には天井がない。しかし、現実という具象の門番である我々は、そうした生産物が正しくデリバリーされるワークフローを設計・運用する必要がある[3]

(余すことなく完璧な蛇足としての)結論

実際、このスピード感・生産量が一般的なものとなるには、現状「コスト問題」「ボトルネックである俺たち問題」が大きく立ちはだかっている。もうぐうの音も出ない。だけど、それが解消された頃には[4]、「AIを使わずにエンジニアリングしてる」というのがなかなかハードコアなスタンスになっているだろうなーと思う。遅くて、不正確で、しかしドメインに対しては誠実で、しかしとにかく遅い。それもそれで一興なスタンスではある[5]。しかし残念ながら、私は職業エンジニア。矜持もある。だから、この暴れ牛たるAIエージェントを手懐け、高速でフローするコーディングプロセスのど真ん中で酔いつぶれないよう、酔い止めをしっかりと飲み込むのだ。

脚注
  1. OpenAIと比較してみたりもしたんですが、断然Claude3.7が優秀でした ↩︎

  2. StrictでSmartな結果、Stubbornになってる人間のエンジニアを何人か見たことがあるが、それはマジでどうにかしたほうがいいよ ↩︎

  3. そこもAIに任せればいいじゃないか、という向きもあるかもしれないが、成果物の責任を取るのが人間の役割であるのならば、程度の差こそあれ、最終的には人間が担う必要のある領域である ↩︎

  4. 前者は「ムーアの法則」直撃世代としては、かならず解消されると信じてる。後者はAIが速すぎてしんどい問題。どのようなマインドセットが醸成されることになるのか予測が難しいが、いくつかの解決策(LLMモデル併用監視とか、エンジニアのチームビルディングで解消、とか)はあり、どれかが有効であれば。とにかく潰れないようにしたい ↩︎

  5. 私も、リッチな大企業が草の根を飲み込んでいく仕草には断固プロテストしたい ↩︎

Discussion