【1日1zenn - day16】生成AIをエンジニア初学者が使うデメリット
今日は趣向を変えて、表題について言語化していこうと思います。
以下のようなPOSTを見かけました。
自分はまさに「最後の30%」に苦しめられた結果、この1日1zennという取り組みを始めるに至っています。
AIについて語る記事は数あれど、
非エンジニアかつ品質高いコードを求められる環境に身を置く人間のサンプルは置いておいて損はないかと思ったので、これを機に筆を執ろうかと。
またエンジニアの世界に飛び込んだタイミングでGPT-4oが使えるようになっていたので、AIネイティブ世代みたいに言えるかもしれません。
前提
自己紹介
元々自分はミニ広告代理店を作ったりしていて、マーケ中心で動いてきました。
しかし自分の会社に天井を感じたため、IT事業会社にPdMとして就職させてもらい、手挙げ性でエンジニア兼務もつけてもらって今に至ります。
プログラミング完全未経験の文系で、今までプログラミングっぽいもので触れたのは広告の計測タグ設置くらい。
正真正銘、プログラミング初学者です。
詳しくは以下の記事で振り返ってます。
8月に配属されて、今1月頭なので、実務経験は5ヶ月くらいですかね。
PdMとの兼務で行なっているので、5ヶ月フルではなく3ヶ月目くらいの密度かもしれません。
行っている業務
特定業界向けのSaaSの企画と開発を行っています。
その業界は数分の障害でも大きな損失を生み得るので、可読性やテスト含めてコードの品質が特に問われます。
自分は最初、そういったリスクを発生しにくい小さな案件を企画から開発まで任せてもらい、後述する理由で障害を発生させました。
ハルシネーションも要因の一つだったため、基礎理解を養うために1日1zennというこの取り組みを始めています。
感じたメリット
ある程度の挙動はかなりの速度で作れる
期待値と違う挙動になったり、エラーになったりしても、その事象と該当するコードを貼り付けると回答が返ってきます。
何回かやり取りが発生することもありますが、体感80%くらいは解消でき、期待値通りの挙動にすることができます。
分解すると以下2つの組み合わせです。
叩き台となるコードを即座に出せる
初学者には、何をどう実装するか目星をつけるのがまず難しかったりします。
そこを、AIを使えば叩き台コードを複数パターン、メリットデメリットと併せて提案させることもできます。
あとはそのコードで使っているライブラリをブラウザ検索したり、メリットデメリットを深堀りするような質問をAIに投げかけて曖昧なところを払拭すれば、実装方針の目星が立ちます。
ある程度のエラーは一定の速度で解消できる
エラー文言と、エラーに関係しそうなコードを投げて、考えられる要因をAIに網羅的に吐き出してもらった上で、関係しそうな要因の解消方法を聞くと、大部分のエラーは解消できます。
要は、叩き台を出させた上で、期待値と異なる挙動は割と解消して行けるので、
『ある程度の挙動はかなりの速度で作れる』という状態になる感じです。
感じたデメリット
結構たくさんあります。
挙動やエラーとして表出しない部分を考慮できない
ここが根幹だと感じてます。
大前提『問いを立てられるか』が重要で、初学者には、挙動やエラーなど目にみえる部分からしかAIに問いを投げることができません。
そのため以下のような事象が発生しやすい。
不要なコードが紛れる
AIとのやり取りでコードを試行錯誤する中で、不要なコードが紛れることは非常に多いです。
そして一見そのコードが挙動やエラーに影響を与えていないと、その場で気づくことができません。
この不要なコードは可読性の低下や、次のような事象を発生させます。
SafariやWindowsなど端末違いで発生するバグに気づけない
たとえば以下で以前書いた事象も、不要なwidth:100%の存在によってSafariだけ描画が変わっており沼りました。
このコードも、自力で書いていたのであれば、わざわざ指定しなかったはずです。
(確かこの時はFigmaの開発モードで出てきたCSSを貼り付けた記憶があるのでAIマターではないけど)
またSafariバージョン18でCanvas APIのdrawImageの描画ロジックが変わっていたことで発生させてしまった障害も、AIのハルシネーションに由来するものでした。
この時はまずCanvasで描画される画像の画質が落ちるという事象が発生していて、目にみえるその事象を解消するためにAIと試行錯誤をする中で、Canvasのドキュメントには書かれていない使い方で画像サイズを拡大していたことが要因。
一般的に言われているdprをかけるだけでは画質直らなくてめちゃくちゃ試行錯誤していたのと、Safari18以外では発生しないことが重なって、気づくことができませんでした。
慣習に即した実装ができない
チーム内でよく使われる書き方に倣った方が、可読性もあがってバグを起こしそうな挙動をレビューバックしてもらいやすかったり、将来的に機能を追加実装する際の工数も下がったりします。
コーディング規約に全てまとまっている場合は、それもAIに投げると考慮してもらえたりもしますが、本当に全てまとまっているケースは少ないのではないでしょうか。
チーム固有の書き方ではなく「最近のエンジニアは普通こう書く」みたいなのは特に明文化されていなかったりもします。
よって、既存の似た処理を参照したり、指摘されたことをちゃんと習得していく中で最初はキャッチアップしていくイメージです。
沼るときは徹底的に沼る
これは不要なコードが紛れることが原因になる時もあるし、AIに投げていない他ファイルが原因の場合も多いです。
そして投げているコードの中に原因がある場合でも、経験があるエンジニアだったらすぐに気づけるようなことをAIが気づけないケースも、実はめちゃくちゃ多かったりします。なんでだろ。
しかし、課題解決能力が養われないみたいなのも根本要因に感じます。
品質・速度が向上しない。成長できない。
いつもAIに聞いてコピペし、期待値と異なる挙動もAIで解消していると、マジで成長できません。
一端のエンジニアになるつもりがないなら問題にならないかもしれませんが、エンジニアとしてやっていくつもりなら致命的です。
3~4ヶ月もコードを書いていれば何も考えずに秒で書けるような処理も身に付いていなかったりして、いちいちAIに聞いてしまう分、速度が上がらない。
AIに聞いてもすぐに叩き台は出せますが、それを続けていると結局AIの出すアウトプットに依存してしまい、AIに聞くまでもないようなことまでAIに頼ってしまうようになります。これは多分まじでなる。
短期的な納期を優先させると、どうしても模範回答を見てコピペしちゃうように力学がかかるんですよね。
その結果、何ヶ月エンジニアやったところで初心者レベルの知識を脱却できない。
すると品質も速度も向上しない、エンジニアとして価値がないコピペマシーンが出来上がります。
例えば以下の記事で書いたような内容です。
const handleClick = useHandleClickIcon()
この書き方だと、handleClickで実行されるのはuseHandleClickIcon()というメソッド自体です。
しかし本来実行したいのがuseHandleClickIcon()の中の戻り値であるuseCallback関数だった場合、以下のような書き方が必要です。
const handleClick = () => {
useHandleClickIcon()
}
<div onClick={() => handleClick()}>
何を当たり前なこと言ってんねん、という感じですが、自分はアロー関数についてもよく理解しないままコピペしまくってました。絶大なる反省です。
初学者どうAIと向き合うのがいいか
ここから感じた自分なりの対策を書きます。
叩き台のコードは聞いてもいいが、コピペしない
正直まだ自分のレベルだと、初見のチケットに着手する段階では、何のライブラリやメソッドで何をするか、目星を付けることが難しかったりします。
なので目星をつけるところまではAIに頼りつつ、コピペはしないで見ながら書く。
その際、不要だと判断できたコードは書かなかったり、自分の理解していない記法やメソッドが登場したら、必ず一度公式ドキュメントや記事を調べるようにします。
と言っても、ガチ初学者の場合は不要なコードを自力で判断できなかったり、10行中8行で知らない処理が出てくるみたいな話になったりもするので、全部調べるのではなく、特に気になったものを調べるとかが限界な気がする。
しかし必ず一つでいいから調べることを徹底していると、10行中8行わからなかったものが5行になり、3行になり、徐々にちょうどいい学びサイズになっていきます。
なるべくググり、公式ドキュメントや記事を見る
結局公式ドキュメントが正義、ということに改めて気づけました。
と言っても初心者からすると公式ドキュメントが何を言ってるのかわからない場合も多く、見るべき箇所がどこなのか目星を立てるのが難しいです。
なので、自然言語でわかりやすく書かれたzennやQiitaは重宝しますし、概要はAIに聞いてもいいと思ってます。
しかしそうして理解の土台を得られた後の工程として、必ず公式ドキュメントを参照しましょう。特にAIに聞いた後のファクトチェックは、めちゃくちゃ重要です。
それでもわからない場合は公式ドキュメントをコピペしてAIにサンプルコードを10個くらい出してもらって解説してもらうのがおすすめ。
学習の習慣を作る
短期的な品質・速度と、中長期的な品質・速度のバランスは、個人的にはかなり難しいと感じています。
短期を優先させてAIに頼ると、上述してきたようなデメリットを一生食らい続けるハメになりますし、中長期を優先させると1日中調べるハメになり、納期内で何も納品できません。
なので自分は、業務内でも一定調べつつですが、ちゃんと理解するのに時間がかかりそうなものはメモっておき、業務後にこの1日1zennとして調べたり試しに作ってみたりするようにし始めました。
1日1zennくらいの気持ちで設けておくと、AI模範回答を見たい気持ちを優先させた場合でも知識を身につけていける実感があるので、短期と中長期のいいバランスを取れそうな感じがしてます。
必ず一つは自分で仮説を立てる
課題解決能力みたいなのを養うために、期待値と異なる挙動に対して仮説を立てるのも意識的に行う必要があります。
これは中長期的な成長だけでなく、仮説とセットでAIに聞いた方がいいアウトプットになったりするので、短期的にも役立ちます。
まあ最初はガチで仮説が出ない場合も多いと思うので、そこは徐々に頑張りましょう。
初学者おすすめのAIプロンプト
ここからはTipsとして、私がユーザー辞書に登録している文言を貼っていきます。
今まで自分なりにチューニングしてきてますが、プロンプトエンジニアとかちゃんと知識があるわけじゃないので、もっと効率いい書き方はあると思います。
今度プロンプト系も1日1zennで調べようかな。
知識の概要を解説してほしいとき
初学者と入力した際の予測変換に以下を登録しています。
初学者の理解を促進させるように、具体的な使用例や仕組みの解説、周辺知識の補足を交えながら詳しく説明してください。
「〇〇というメソッドについて、初学者」と打つだけでかなり手厚く出力してくれます。
一番使ってるプロンプトです。
たとえば既存コードのわからない部分をコピペして聞く場合は、『一行ずつ』というのを手動で追加して以下のように聞きます。
/*
既存コード
*/
上記の処理について、初学者の理解を促進させるように、具体的な使用例や仕組みの解説、周辺知識の補足を交えながら1行ずつ詳しく説明してください。
叩き台を出力してほしいとき
メリデメと入力した際の予測変換に以下を登録しています。
以下の処理や挙動を実装する方法をメリットデメリット併せて網羅的に複数提案してください。
大体既存コードを貼り付けて、以下みたいに聞くことが多いです。
/*
既存コード
*/
上記の既存コードに対し、新たに以下の処理や挙動を実装する方法とコードをメリットデメリット併せて網羅的に複数提案してください。
/*
やりたいこと
*/
メリデメを出力してもらうのが結構キモで、こうするとあらかじめ考慮すべき点をキャッチアップしやすくなります。
その結果、既存コードに影響がありそうな部分や期待値と異なる挙動になりやすい部分を把握した状態で叩き台を見ることができます。
要は上述してきたようなデメリットを未然に防ぎやすくなる感じです。
エラーを解消したいとき
解消方法と入力した際の予測変換に以下を登録しています。
上記のコードについて、以下のような事象が発生しています。
この事象の要因として考えられるものを網羅的に複数提案し、それぞれの要因を検証する方法と考えられる対策をメリットデメリットと併せて網羅的に複数出力してください。
こうすると、まじで結構網羅的に提案してくれて、そこに出てきたキーワードでググったり公式ドキュメントを掘ったりすると解消できる場合が結構あります。
AIのアウトプットの品質を上げたいとき
あなたはと入力した際の予測変換に以下を登録しています。
(普段のやり取りで「あなたは」ってあまり使うことがないので、予測変換に登録して困ったことはないです)
私はエンジニア初学者で、初めてアサインされた案件で を扱っています。
あなたは に熟練したエンジニアで、繰り返しセミナーや勉強会などにも登壇して解説している、プレイヤーとしても教育者としても能力が高いエンジニアです。
以下の問いに対し、
これと初学者を組み合わせて使っています。
眉唾に思えるかもしれませんが、こうするとわかりやすさが結構変わってくる時があります。
おわりに
AIにめちゃくちゃ頼った結果、バグを起こしたり一切成長できなかったりしたエンジニア初学者目線での、AIとの向き合い方です。
多分熟練したらより解像度高く振り返れるかもしれないけど、今の解像度を記録する意味でも一定意義あるかなと思ったのでこんな感じ。
明日からはまた普通に1日1zennやるかな。
作りたいフロント挙動があるのと、エラーハンドリングやKotlinのテストライブラリ系を調べなきゃという感じがしてます。
Discussion