システム開発で生成AIを有効に使おうとしたら、生成AIが生成するコードを鼻歌混じりで完璧に仕上げられるだけのプログラミング力と、システム全体の最適な設計ができる技術力が必須の最低ラインとなる。
プログラミング力がなければ、生成AIが仕込む地雷に気付けないからシステムを地雷原にしてしまう。
そのレベルのエンジニアでは地雷除去は100%不可能なので、ぶっ壊れたまま走る暴走列車になるだろう。
その状態になったら、エンジニアたちは100%飛ぶ。
経営者の手の中に残るのは、ぶっ壊れて部品を撒き散らすサービスと、逃げ出さなきゃいけない状況なのにそれを認識できないほど低レベルの「バナナ」エンジニアの集団だ ( 大枚叩いて「世界をひっくり返す画期的なサービスを作ってる！」って思ってたらこれとか、まじウケる w )。
システム全体の最適な設計ができなければ、適切なプロンプトを捻り出せないので、整合性を保ったままサービスを成長させることは不可能だ。
現状、どこかで誰かが作ったような小さなツールなら、なんとかなりそうだと思う。
プログラミングレベルなら。
けど、成長させる前提のプロダクトに使うとか、正気の沙汰とは思えない。
小さなツールは AI のフレームの中でこなせるとしても、自社サービス、特に今までなかった類のサービスとなったら、フレームの外、現実に開いたものだからAI が扱える対象ではない。
だから合理的なものは出てこない。
具体的な指示を出してくれるように見えてるだろうが、過不足なく正しいかと聞かれたら、AI推しエンジニアにホルホルされたものを見た限りでは、ないわー、としか言いようがない。
AIの絵とかと似ていて、ぱっと見イケてそうで、よく見たら変。
絵のように、縦横の制限があって、各ドットの色の幅の制限もあって、多少色ずれがあっても大勢に影響がないものじゃなく、プログラムは一箇所+と-間違えただけでも致命的なものだから。
「テストも自動で生成できるんです！」
って、やたら本プログラムに迎合的なテストが生成されていたりするんだが、実装ベッタリの境界値テストとかより大事なテストが丸っと抜け落ちてたりするんだよね。
で、その重要性というか危険性を、エンジニアは理解も認識もできないままになったりする。
意味のないテストを延々と繰り返して、実環境で不具合障害が発生するたびに、場当たり的な対策をフジツボのように追加しまくってやった気になるのを運用だとか勘違いしたまま炎上地獄への坂道を転げ落ちていくんだよな。
大規模なサービスの設計は抽象度の高い部分を先に詰めないと、辻褄が合わなくなって破綻する。
初期リリースにはブーストが必要なのは確かだが、使いこなせない生成AIを使うと、書き初めで最初に筆を置く場所を適当にするのと同じくらい、取り返しのつかない事態に陥るだろう。
初期リリースこそ、全体設計と、サービスを支える基本モジュールを抽象的に、丁寧に作る必要がある。
「一旦リリースしてシェアを獲得してから作り直す」という選択肢も、一昔前ならあったけど、AI で嵩増ししたサービスの作り直しは、多分すでに合理的ではない。
再設計再実装の手間もそうだが、補助輪(AI)エンジニアに、移行作業の戦略策定設計実施ができるわけがないから。
AIを絶賛するエンジニアには2種類いる。
最低限のプログラミング力とシステム設計能力があって使いこなせるエンジニアと、ないけど称賛していれば自分もすごいエンジニアと思ってもらえると思ってる意識高い系(笑)エンジニアだ。
おいら自身、たまーに使うけど、チームメンバー全員に積極的に活用しろとは死んでも指示できない。
むしろ使用禁止を言い渡すだろう。
というか言い渡した。
どのレベルのエンジニアが書いたプログラムかという情報なしに、レビューとかしてたら時間がいくらあっても足りん。
特にプログラムを書けないことを誤魔化すためにAIを駆使する奴は、発覚したら即銃殺でも構わないと思ってる。
でも、ドキュメントをAIに食わせてナレッジ共有させるのは構わないですよねって？
ゴミドキュメントを大量生成させてAIに食わせても、結果はゴミ。
"Garbage in, garbage out"くらい知らんか？ w
まずちゃんとしたドキュメントを書いて、ちゃんと整理して、ちゃんと更新しろ。
それ以上のナレッジ共有はない。
そういうことができない人間が書くドキュメントが、有用なドキュメントなわけがないだろ w
で、表題の件。
自社サービスをボロボロにした張本人たちに建て直せるわけがない。
以上 w