見出し画像

サービス開発 based on o1 Pro の限界

ただの殴り書き。

ChatGPT o1 Pro mode、契約して使っている。用途はふとした時の壁打ちなどもあるが、それはもともと精度高いのがわかっていたから特別今更試すことでもない。
2024年12月中旬時点でソフトウェアサービスの開発をどこまでこれに依存できるのか、限界を知っておきたいから試している。

多くの人に見られることを想定していないし、作っているものがこれだよというのを紹介する気持ちもないのでめっちゃ雑にかく。

動機

生成AIでの開発はよく「プロトタイピングに向いてる」「関数単位での生成やテストには向いてる」と言われる。
でもプロトタイピングなんて人それぞれ作るものの品質がまちまちで何を指しているのかわからない。
評価の仕方として上記の表現が曖昧に感じていたので、厳密な限界を体感したかった。

加えて、PdM系の人とエンジニアで何やら生成AIへの熱量の差があるのも気になっていた。PdM系の人はめっちゃ嬉しそうで、エンジニアの人もまあ嬉しそうだけど「Copilotに日々依存してます」「テストの生成は便利」という感じで、地に足はついているが自分としては「もっと上を目指せるんじゃないか?」と思うことが多かった。

「今まで要件は決められたけど自分で実装ができなかった人が、その嬉しさのあまり過剰に評価しているのか?」「あるいは自分で実装するスピードが速い人たちが過小評価しているのか?」とモヤモヤしていたので、ある程度コードは書いたことがある(はず)の身としてモヤモヤを解消してみよう、と思った。
驚き屋が多い昨今、自分で体験して自分なりの物差しで新しい手段を評価すべきなのである。

なお、今回作ったものはGoのAPIとTypeScriptのクライアント、あとGoのクライアントSDKで、GoのAPI内に任意のJavaScriptを実行する基盤とかも内包しているため簡単なものではないはず。

結論

  • 開発計画(手順と詳細項目の列挙)の立案への効果は抜群。自分でやるより優秀。

    • 一番恩恵があるのはプロジェクトマネジメントの担当者では?となった。

  • 限界が来始めたと感じたのは以下のタイミング。

    • クライアントサイドとサーバーサイドの疎通でトライアンドエラーをした時(3往復くらいできつい)。

    • 何パターンか実装を列挙してもらって、手元で試してどれかを選び取る試行錯誤を数回重ねた時。

    • 仕様に修正が入って計画が狂った時。

    • issueが多いツールを選定してしまって、バグを踏みやすくなった時。

  • 上記を加味すると、エラーが少なく進められる枯れた技術(体感的にはサーバーサイド側)での開発は開発計画からデリバリーまで、自分で実装したら1、2ヶ月かかりそうなものは1日でできる。

  • ツールはo1 Proだけで割と十分で、強いていえばCursorを使うくらいで良い。

    • よく「v0で画面を作ってBoltでAPIを立ち上げ!」とかいうけど、開発支援系ツールで一足飛びで成果物が出てきてもそれは計画・仕様のレビューが十分ではないかもしれない。段階的に実装や仕様を相談しないとレビューできず、果ては運用責任を全うできない。

※ここでいう「限界を迎える」というのは、レビューコストが急増し、自力での開発の方がスピードや成果物の品質の揺らぎが小さくなる状態を指している。

補足

ほぼ結論に書いてある通り、機能の複雑さというより試行錯誤によって現在の実装や元のコードベースの状態を正確に呼び出せなくなった時にレビューコストが跳ね上がる。

よくAIは「壁打ちに向いてる」なんてことも言われるが、それは正解がない時や現在の状態を正確に記憶する必要がない場合である。
「今のコードがどういう状態なのか」を常に保持できるようになったら、トライアンドエラーに耐えられるようになるはずだが、CursorのComposerの機能やo1 Proの能力でもまだまだ3往復くらいのトライアンドエラーで厳しくなってしまう。

トライアンドエラーは前述のような、クライアント・サーバーサイドを行き来して「どっちの話してんねん」となる場合だけではなく、一度テストや外部SDKなどを実装したことで、修正対象に依存する機能が2つくらい出始めるとそれを無視したコードを出してきておしまいになる。

あと、例えばGoだとパッケージの階層をめっちゃ切ったコードとかは難しいと思う。2階層でも厳しい。厳しいというのは動かなくなるのではなく、当初細かくinternalなパッケージを切っていたのに、突然ハンドラーの層に全部の関数を実装し始めたりする。
あとエントリーポイントになっているmain.goの修正漏れとかが激しくなる。

とまあ、「こっちの実装が動かなくなっているから直してね」という指示を与え続けないといけなくなり、突然視野の狭さを感じることになる。

なんて色々冷ややかな目線を送ったが、総じて感動している。
o1 Pro以前と比べると遥かに優秀で、先程書いた通りの「クライアント・サーバーを行き来する」「テストやSDKなどを実装して依存関係が膨らむ」までは実はエラー修正などはほぼうまく行っていた。単一のプロジェクトにおける持久力が高い。

返ってくる実装計画やコードの内容が思った以上に良く、楽しくてずっと対話していた。お風呂入る前や寝る前に質問を投げて、風呂上がりや深夜トイレに行くために起きた時に確認して、また質問を投げるという生活をしてみている。

新しいことを考えた時に、その実現手段が明確でないと、ただの妄言で自分を大きく見せるか、実現しないのではないかというじっとりとした不安を心に持ち続けることになる。
こうした不安が消える希望を感じる。叩きの実装を出してもらって、技術の名前を後から知ることができる。実現できないことなんかないんじゃないかと錯覚させられるのも無理はない。

楽しいですね。現場で使われている方、皆さんの現場ではどんなことが起こっていますか?Xなどでお話しできれば嬉しいです。よかったら感想や事例、教えてください。

https://x.com/__timakin__

いいなと思ったら応援しよう!