AI時代のコーディングと写経のメリット
いつもの雑談、まじめな技術。略して、いつまじラジオのJです。
レイハルです。
今日、僕の持ち込みの回ですが、テーマ、なんと、コーディングです。
なるほど。あれ?
最近、聞いたことある回かもしれないんですが、ただ、AI時代のコーディングです。
AI時代のコーディング。なるほど。
ということで、前回とはちょっと違う話です、当然ながら。
AI時代のコーディングですが、今や知らない分野もAIがコードを書いてくれます。
なので、僕は主にバックエンドをメインとしているので、正直フロントエンドの知見はあんまないんですよね。
とはいえ、AIのおかげで仕事はできてる風ではあるんですよ。
なので、AI時代、分かんなくても書けるっていうのが現状かなと思っています。
で、そのコーディングの回の時に、社協について話したじゃないですか、社協がいいねっていう話を、お互いいいよねっていう話をしたと思うんですけど、
なんで社協いいんですかね、上原さん的にどうです?
社協がいい理由?
はい。
何だろう。
何かしらいいと効果を感じているわけじゃないですか。
それはどこに行こうかを、なぜというか。
個人的には、書くっていうこと自体が考えを整理することなので、
普段の日本語を書くときもそうだけど、それと似たような感覚で書きながら考えて整理していってるからこそ、
そこに、その書かれてるコードについて詳しくなれるから、
普通に読んだよりもインプットされているというか、背景情報みたいなのが付加されているみたいなイメージ。
背景情報っていうか。
コンテキストというか、なぜこのコードになっているのかの理由みたいなのもセットで記録されているみたいな。
それが社協してるときはある気がするけど、厚みが違うのかな、やっぱ情報の。
厚み。
読んだだけだったら薄っぺらいそのコードの1個だけだけど、
社協してるときはこのステップに対して、どういった理由でこのコードになっているのかみたいな情報まで付加されるから、
それによって厚みがついて記録されているからいいのかな。
お胸に似た感じだと思っていて、3つほど。
それぞれ個人個人でメリットと思っている部分が違う可能性があるかなと思うんですが、僕が思う3つ。
まず社協の速度っていうところで、脳が理解する速度っていうのは見たり読む速度に比べて圧倒的に遅いわけじゃないですか。
当然ながら社協の速度も同じと、見る読むに比べて圧倒的に遅い。
なのでこの速度の差で脳みそに余裕であったり余白ができるのかなと。
なので書いてる最中にすでに先のコードも視界には入っているような状況があるんで、書きながら考えたりとか理解する時間っていうのは作れるのかなと思っています。
ただ読むだけだと、なんとなく理解した気になっていた部分を深く理解、考え、時間ができるっていうところが1つ。
もう1つが、ちょっと話は変わるんですが、エラーとかが出ることもあると思うんですね、社協してると。
そうすると、まず手元の本と画面のコードを見比べながら、タイプしてるのかなみたいな、疑ったりすると思うんですけど。
それが言わないなと思うと、じゃあなんでエラーが出るんだろうなみたいな、仮説を立てて検証するみたいな、っていうサイクルを回していくかなと思うんですけど。
そういった色々とコードを行ったり来たり見るとか、仮説を立てて検証するとか、そういったサイクルを回すことでより理解が深まっていくんだろうなとも思っている。
最後は構造を理解していけるかなと思っていて、ゆっくり社協していく中で色んなコードに触れていくと思うんですが、
そうすると意識的にか無意識にか、どんどん構造が、抽象的に構造が理解できてくるなと思っています。
なのでそれによって応用が効くようになってくるっていうところ、この辺が社協の良さなんじゃないかなと、社協によって得られる効果というか、
なんで効果が得られるのかと思っています。
なるほど。
はい。違和感ありますか?これを踏まえた上でこうじゃないか、あじゃないかみたいな。
今のは一番が、
速度の話?
時間的取りができる?そこにかける時間が増える?
増えることで考えたり理解したりする時間が生まれる。
あとはエラーが出たりすると、そこで色々と試したりしていく中でコードの理解が深まっていく。
最後が色んな構造に触れていく中で抽象化して構造化されていって、
じゃあこういう場合はこうなんだろうなっていう応用が効くようになってくる。
っていう3点。
あれ頑張ってあげればもうちょっとあるような気もするんですが、浮かんだりAIとやり取りしたりして出たところとしてはこの辺がそうだなって思ったところですね。
どうなんだろうな。
確かに理屈的にはそうなんだろうな。今言ってくれたようなことだと思うんだけど、
実際問題、じゃあ時間的ゆとりができたからって考えなければダメだし。
それは確かにそう。
まあでも社協…思考停止してる人もいるかもしれないんですが、社協してまで学ぼうとしてる人はある程度考えている人の割合が多いと思う。
なるほど。
どうかな。
でも社協した方がいいよって言われて社協してる人だっているかもしれないじゃない。
そういう人は多分最後までいかないんじゃないかな。
なるほど。
学校とかの教育で漢字めちゃくちゃ書きなさいって言われて、あれ社協みたいなもんだけどさ、あれもだってもうまじさ、作業じゃん。
この漢字の成り立ちとか、この漢字の何角だとかさ、考えながら書いてる子供なんていないと思うんだよね。
そうですね。
だからあれ意味ないと思うんだよね。
何か手癖で書けるようになってくる可能性はあるかもしれない。
それはある。全然覚えないわけじゃないけどさ。
効率の良さはわかんないですね、確かに。いいのか悪いのかは。
そもそもめっちゃ話ずれるけど、漢字1文字を覚えさせることに何の意味があるんだと。
と言います。
だって漢字って要するに文章を書く際にあったほうがコンパクトになるし、何だろうな、結構漢字でコンテキストを伝えたりするから、十五とかで。
そういうのが要するに何かよりよく文章を書くためにあるわけだから、そこの漢字1文字を取って200文字のやつに書いてきなさいとかって、まじあれ意味ないと思うんだよ。
そうなんでしょうけど、入りとしてはそうやらざるを得ない気もする。
あれだってさ、本当にやってた時、何だろうな、何してんだろうって思ったもん、まじで。
僕はその時は何にも考えてない人間だったから、何も思わずただ書いてます。
なるほどね。
そういうもんだとしか思ってない。
でもなんか、まだちょっとそれますけど、英語とかも単語1個覚えるより熟語で覚えるほうがいいみたいな。
いや、そうだね。
っていうのがあるから、どう使うかっていう文脈とかありきで学ぶほうがより実践的ではあるのかもしれないですね、確かに。
そうなんだよな。点でしかないからな。
そうですね。
線とか面で捉えられないからきついよね。
思考停止しちゃうと意味がないかもしれないけど、
そもそもね。
ある程度考えつつやっていくとか、
まあシンプルにその思考停止でも読む速度より写経する速度のほうが遅いんで、よりそれを見ていることで多少頭に入りやすいっていうのはあるはず。
それはある気がするね。
なので写経しないよりは思考停止で写経するほうが多分頭に入るかな。
まあまあまあ、覚えてる時間は長いんじゃない?そっちのほうが断然。
もろもろそういうメリットがあるかなと思っています。
写経2.0の概念と実践
で、ここからが今日の本題なんですけど、今回ドドンとテーマというかタイトルがあります。
写経2.0 AI時代の写経。
カッコはてなんですね。
AI時代の写経には両サイドに波が入っています。サブタイトルというのは。
何かっていうと、ちょっと写経、それ写経かみたいな話あるかもしれないんですが、2.0でバージョンアップしているのでそこはご了承ください。
なるほど。
写経2.0っていうのは、AIを先輩プログラマーとしてペアプロをしますと。
で、先輩がオペレーター、自分が後輩としてドライバーをしますと。
で、AIにアドバイスをもらいながら自分が実装するっていうものですね。
さっき冒頭で話したように、今AI時代、AIが基本書いてくれるんですけど、そうじゃなくて自分が書くっていう感じです。
なぜこれを写経2.0と呼んでいるかというと、さっきつらつらと話した写経の良さのエッセンスは入っているから。
やっぱりそのAIが書くコードを、AIがコードを書くんじゃなくて、自分でそのAIが言ってくれたもの。
完全な答えを言うんじゃなくて、ヒントを出してもらうイメージなんですが、そこで考えて、実際にコードとして落とし込んで、それをレビューしてもらう。
みたいなサイクルをどんどん回していくんですね、それをやるとき。
ゆっくり考える時間があったりとか、自分でコードを書いたり、うまくいかないときはまたエラーの検証したりとかをするっていう感じなので、
ここではこれらが写経のエッセンスを取り入れているので、これを写経2.0と今日は呼びます。
つまり写経要素としては?
本来的な写経、元の何かがあって写すみたいな作業はないんですが、
ないんだ。
2.0なんで。
あくまで写経をすることで何でそういう効果が得られるんだろうっていう、何で得られるかの部分を取り入れる。
さっき話した写経の速度。
AIがダーって実行しちゃうと、それを読むだけですけど、そうじゃなく自分が書くわけなので、そこのコードに触れる時間が長くなる。
考える時間も増えます。
エラーが出るときがあれば、なんでエラーなんだろうって考えたりして、ちょっと修正してみてっていうことをするし、
知らない分野の基本的に自分の知見ないところをペアプロする形になるんで、何度もペアプロしていく中で、
こういうときってこうすればいいんだっていう構造を理解していくというエッセンスを取り入れているということです。
写経じゃないよな。
AI時代の学習方法とかな気がするけど、
AIが問題を出してくれるってことだっけ?
何をAIがしてくれるんだっけ?
一旦写経2.0との出会いの話に入ってます。
このPodcastをいつまじラジオのホームページで作ろうかなって思ってるんです。
せっかくやるんだったら、自分使ったことない技術で楽しく作りたいなって思ったんですよね。
どうしようかなと思ったときに、AIに教えてもらいながら自分で書こうって思ったんです。
AIに任せれば作ってくれるんですが、それだったらそんなに面白くない。
一応軽く技術スタック的な話をすると、炎って言われてるんですか。
この会話詳しくないからわからないんですが、それでいい感じに。
ルーティングとかが得意なのかな?
全然知見ないんですが、なんとなく知ってる炎と、
あとバックエンドというか、一部バッジ処理みたいなのを書こうと思っていて、
それでラストを使ってみようみたいな。
あとここもまだ詳しくないんですが、クラウドフレアワーカーズであるものがある。
それ使ってみようみたいな。
ところで、これをAIに教えてもらいながらだったら、知見なくてもやっていけるだろうみたいな。
かつ多少ないとも興味のあるものだったんで、
ここで社境2.0の概念と出会いました。
これはいいと。
なるほど。
結構楽しかった。まだ全然進んでないんですが、結構楽しくやってるんで。
で、これ業務でも活かせるはいいと思ったわけですよ。
で、実際に、その前のウェッサーさんの人も何でしたっけ?
どういうふうにやるんだっけ?
入り口ってどう開始されるんだっけ?
なんで、そのいつまずDラジオのホームページを作るためのリポジトリにクラウドコード使ってるんですけど、
クラウドコードにスキル図を作っていて、実装用のスキル図みたいなのを作ってるんですけど、
そこではバックエンドの知見はあるんですけど、フロントエンドの知見は全然ないんですよみたいな。
なんで、教えてくださいみたいな。
で、こっちで書くんで、そっちは誘導するだけにしてくださいみたいなスキルを作ってやるんです。
それで実装するときに、AIに次はこうしていきましょうみたいな。
そのイシューも作ってるんで、イシューの貼り付けて、今回これ実装するんでということで、
じゃあまず何が必要そうですかみたいな感じで質問してくれたりとか、
じゃあとりあえずここの辺書いたら良さそうですねとか言ってくれたり。
みたいにしながら、こういう時ここに書かなきゃいけないんだ、こういう風に書くんだっていうのを学んでいってるって感じです。
なるほど。
これが結構いい感じにやれているっていう感じですね。
で、さっき言ったように、フロントエンドは僕苦手なんで、
AIに書いてもらってるんで、なんとかなってる風ではあるみたいな話を最初したんですけど、
ちょっと話飛ぶんですけど、今の組織のスタンス、そのAIを使うためのスタンスとしては、
AIに丸投げ、AIがコード書いて、AIがレビューしてみたいな感じではなくて、
人間が基本的には今はまだ見て判断しているっていうのが現状としてあって、
僕がフロントエンドを書くときは、人にレビューしてもらう以上、
人に説明できないといけないかなと思うので、
なんでそのAIが出してきたコードをババーンって出した後に、
自分が読んで、それが分かんないとこがいっぱいあるわけですよ。
その都度、なんでAIにこれなに、これなにって聞いてくるわけですよ。
っていう感じでやっていて、結構時間がかかるんですよね、これ。
なるほど。
しかも理解が断片的になってしまうので、どうしたもんかなみたいな。
今更AI使わずに開発するとかは多分ないなっていうのは思っていて、
でもこれあんまり理解してない割に結構時間かかってるなって思ったんで、
じゃあ時間かかるんだったら自分で、さっき言ったように
AIにペアアップしてもらって自分で書くでいいじゃんってなったわけですよ。
その方が結局時間がかかるんであれば、理解しながらステップアップして理解していけるだろうって思ったんで、
これをまだやり始めたばっかりなんですが、仕事でもやり始めていて、
これもまたちょっといいですね。
業務での写経2.0活用とハーネスエンジニアリング
それは良さそう。そのソリューションは、その話が聞きたかったな。
どういう意図でなんだろうな。
学習、最初の学習、サイト作りたいよりも明確だなって気がする。
そうですね。最初のサイトは楽しくやろうしかないんですが、
仕事に関しては自分のフロントエンドが苦手だっていうペインを解消するための手段として使っているんで、
これがまだ簡単なタスクでしかやってないんで、
もっと重いタスクになってきたときに、
AIが書いて後から理解していく方が圧倒的に早くなる可能性もあるはあるんですが、
とはいえ長い目で見ていけば、多分どこかしらのタイミングでペインするだろうとは思っています。
AIのコーディングスキルまでであれば、そのやり方の方が学習しやすいだろうなって思っていて、
言語に慣れて、要するにコーディングのスキルって汎用性が高いと僕は思っているので、
どの言語だとしても、だいたい考えないといけないこととか注意しないといけないことは一緒なんで、
そこまで言語レベル、その知識はどこかの言語で身につけたとして、
ただ言語を知らなければその汎用的なスキルも使えなかったりする、レビューで使えなかったりするから、
だからそこまである程度言語のことが理解できるようになれば、言語とかフレームワークのことが理解できるようになれば、
多分もしかしたらAIに書かせてレビューするっていう方が早くなる可能性があると思うんだね。
そうなんですよね。なのでこのスタンスを取るのは、バックエンドの時はこうはしない、する方がかえってやっぱり遅いから、
あくまでフロントエンド側の実装の時だけなんで、
まあ安藤さんが言う通りだなっていうのは実感としてもありますね。
というところで、話したいこととしてはこのぐらいなんですが、
ここからどう締めるかっていうのがうまいアイディアないんで、どうクローディングしていこうかなって迷っているんですが。
まじか。
いやなんで、今うちのプロダクトでAIを専門的にやってる人がいるわけですが、
まあ最近からそういう風にやりだしてるんですけど、
一つ今それのモニター的な感じで今入っていて、
まあこういうやり方も良さそうであればそこも一つ組み込んでもらうっていうのもありなのかもしれない。
ありだと思います。
なのでそういう実際に自分だけに閉じずに、まあいろいろと学ぶ方法とか、
場合によっては新卒みたいな人にも使えるかもしれないし、
結構AIの技術レベルが今後どんどん飛躍上がっていって、
本当にエンジニアが必要ないっていう未来が来るまでは使えるのかなと思うんで、
いい感じに活かしていきたいなと思います。
そうですね。今うちでもハーネスエンジニアリングっていう巷で流行りのものを、
僕の個人的な意見としては、
ハーネスエンジニアリングをゴリッゴリにやってる人たくさんいますと。
毎日X見てても俺の最強のハーネスって言ってる人がたくさんいるんですね。
でも僕は、全部全自動で、頼んだら全部いつの間にできてて、レビューもしてますみたいな、
完成してますっていうのに対して僕は懐疑的ですと。
正直そこで品質が担保されてるかもわからないし、
なんなら俺の最強のハーネスは結構出るんだけど、
それで事業としてどうなったの?組織としてどれくらいいいことが起きたの?
っていうのを示してる人はいるのかもしれないけど、
僕の観測上、今のところいないかなっていうのがあって、
やっぱ組織に所属している以上、
あとプロダクトを成長させている以上、
良くしていかないといけない。
ハーネスもAIも、所詮ただのツールに過ぎないんで、
良くするための。
だからハーネスを極めまくって、
なんか本質からずれてねって思うんでね。
市や業作しててすごい楽しいなって思ってるのは確かに良いことだと思うんだけど、
でも本来的にはだから事業とかプロダクトを良くするために、
そういうハーネスを組み込んでって考えるから、
すごくたくさんやるのは、
めちゃくちゃカスタマイズすることに対して怪異的なんだけど、
じゃあハーネスがいらないかと言われると、
いやそんなことはないと思っていて、
そのプロダクトに最適化されたハーネスであれば、
生産性を上げられるところは多分全然ある。
余地はあると思っていて、
だから今僕はそこを目指して一人アサインしてやってもらっていますと。
さっき言ってた、結局エンジニアのレベルがやっぱりあるんで、
エンジニアのレベルに合わせた、今みたいな話を聞くと、
エンジニアのレベルに合わせたハーネス、
要するにクロード、ドットクロードみたいなのを準備しといて、
この人は何年目なんで、このハーネスで開発をしてもらう、
こういう風にやってもらう、ユースケースみたいなのまで示すとか、
それを階層ごとフェーズごとに作れたら、
じゃあこの人にはこれをみたいな、
それがある意味での評価軸にもなるというか。
今の話を聞いてて、確かにそういう使い方は全然あるなって思ったのと、
ついでに言うと、
ハーネスエンジニアリングってすごいリードタイムが長いと思っていて、
どういうことかっていうと、
要するにプロダクトに最適化した環境を作って、
要するにコンテキストを覚えさせる、理解させるわけじゃない、
そのプロダクトの歴史を知ってもらうわけだから、
それ用に最適化されたスキルだとか、書き方だとかっていうのを、
一生懸命チューニングしていかないといけない。
これってめちゃくちゃ時間かかるっていうか、
こうやってみてダメ、今モニターでやってもらってるけど、
モニターの人たちからフィードバックをもらって、また追加してみたいな。
で、また新しくやって、こういう問題があって、
それを解決するためのスキルとかを組み込むとか、
フックみたいなのを取り込むみたいなことを、
結構長い期間をかけてやらないといけないと思うんだよね。
これしかも、一個のプロダクトで一個完成しちゃえば、
もういらないんだよね。
いって、ハーネスって、割りかし。
さっきのフェーズの問題があるけど、
要するになんか、継続的にこう、
一周とか、新機能みたいに、
なんか継続的にこう、作らないといけないものじゃなくて、
いわゆるインフラみたいなものだから、
で、これしかもリードタイムが長くて、
で、最後の完成形だけ見たら、
完成形だけ見て、こういうスキルがあってとかだけ見れたら、
なんとなく理解できた気になるじゃん。
でも実際に中に入ってやってみないと、
なんでそれこそ、この最後のハーネスも、
環境に関しても、最後の成果物も、
にも歴史があるんだよ。
なんでこうなってるのか。
で、知識として必要なものって、
さっきのコーディングとか、本を読むも一緒なんだけど、
そういう、背景を理解してたり、
その歴史を理解してることこそが、
いわゆるその、自分の血肉になってるんだと思うんだよ。
結果だけ見るんじゃなくて。
だから僕は、今ハーネスってめっちゃ流行ってるけど、
そこに飛び込めるチャンスがあるんなら、
一生懸命飛び込んでほしいなって。
いや、そうですね。
だいぶ遅くなって差し込むタイミングがなかったから遅いんですが、
ハーネスの説明だけもらっていいですか。
ハーネスエンジニアリング。
環境を構築するっていう、
OSって表現されたりもするけど、
なんかその、そもそもの前提として、
エージェントってまだ未完成というか、
まだまだ一人ではやっていけない、
野放しにはしてもいいものは作れないっていう前提があって、
でもエージェントはちゃんとガードレールを敷いてあげれば、
もう丁寧に丁寧にガードレールを敷いてあげれば、
その敷いたガードレールの上はちゃんと守って歩いて走ってくれるから、
それをそのプロダクトとか作りたいものにチューニングしてあげれば、
上手くいくよっていうのが今ハーネスエンジニアリングって呼ばれてる、
スキルとかルールとかっていうのですと。
でも今俺それ言ってて思ったのは、
ガードレールを敷く作業ってロジック書いてるのと変わんねえよなって思って。
まあまあそうかもしれません。
だからあれを使って、要するにロジックってさ決定論的じゃん。
決まってるじゃん。
でもエージェントとかAIが分かんないのって決定論じゃないじゃん。
分かんないじゃん。ロジックが不確実なものだから。
これはだからどれだけ決定論的にするためのものがハーネスなんだろうなって。
確かに。
なんか僕もよく分からずスキル書いてたときは、
そのコーディング例むっちゃ詳しく書いてて、
そうするとやっぱ大きくはそれなかったから、
でもたまに変なとこから取ってきて、
たまに変なときに取ってこられるとき気づけないんですよね。
そこは結構課題感を感じていて、
90%っていうのは100回やったら90回いいのが出るけど、
10回うまい、下手なのが出てくるというときに、
その10回を取りこぼす可能性が高いと思っていて。
なんでその取りこぼすっていうのは。
レビューを漏らすことがあると思っているので、
そこをどうにか何かしらの仕組みで、
その10%を拾えるようにもしなきゃいけないなとも思う。
そこもよろしくお願いしますっていう。
なるほど。
今は人間の自分でコードを書いた自分、
支持した自分も見るし、レビュアーも見るしで、
そこで今は防いでいるところはありますけど、
将来的にそこの高数率削減されていくことも、
可能性としては十分にあるのかなと思っていて、
そうなってきたときの話ですかね、どっちかっていうと。
なるほど。
レビュー観点とかっていうのは、確かに暗黙的ではあるが、
そういうなんだろうな、これまずいなっていうのとか、
これ多分根本的に設計の段階からちょっと間違ってる気がするなとか
っていうのだから、そういうのってどうなんだろうな、
結構レビューたくさんしてきた身としては、
割とすぐわかる。
すごいこれ瞑想してるコードだとかすぐわかるけど、
それを言語化してスキルにするっていうのは、
なかなか難しそうだなっていうのはちょっとだけ思ったけど、
できないことはないのかもな。
だから結構しっかり書いてあげなきゃ難しそうな気は今のところ。
たまにここの1行だけなんで古いメソッド読んでんだよみたいなとこあったりするから、
そういうのやっぱしんどいですね、探すのは。
確かにそれはしんどいな。
でも全然ある話だと思うんですよね、そういうのって。
だいぶ話が社境2.0から大きく逸れてるんですが。
今今日聞いた話で、
だからさっきのフェーズ分け、ハーネスの環境分ける、
人によって分けるっていうのは発想としてあんまなかったから、
確かに社境2.0の命名どうなのかって思っちゃうけど、
社境2.0で作られたそういう環境みたいなのは、
いって需要がありそうだし、今それこそ、
AIを使わせない企業みたいな、新人によって。
そういうのの打ち手にもなりそうだなっていう気がしたから。
使ってもいいけどこういう使い方してるって。
確かに確かに。
それはありだなって思った。
だからやっぱそのコードを書いていた時の楽しさを思い出せるんで。
そうだよね。
だから結構いいですね。
だからこのAI時代の勉強って難しいなと思ってたから、
簡単に出てくるから答えが。
しかもそれを見極めるだけの神秘感みたいなのはない状態でやってるから、
むずいよなと思っていたけど、
そのアプローチはすごくいい気がする。
いい回になりましたね。
ということで大きくそれたんで、
そろそろ終わっていこうかなと思います。
さっき言ったように社境2.0の拡張として
ハーネスエンジニアリングにも取り入れていけそうというのが
一つ収穫としてあったのかなと思いますので、
ぜひ皆さんもいろいろとAIとの学習方法を
試していっていただけたらなと思います。
じゃあ終わります。
ありがとうございました。
