Akihiro Okuno

Claude Codeを意図通り動かすの本当に難しいなー。whatを伝えた方がいいので最初はwhatを伝えるんだけど、作業途中にhowで見過ごせないミスがあるとhowを指摘せざるを得なくて、そうすると最初のwhatをすぐに忘れてしまうからまたwhatを伝え直す、みたいな無限ループに簡単にはまってしまう。

分かる気がします。 人間のレビューがボトルネックになるので工数は減ってもスピードはさほど変わらない気がします。

これは本当にそう。 最初のスタートダッシュは速いから、未経験でもアプリを作っていけるぞ！となりがちだけど、コンテキストの限界もあってアプリが本格的になればなるほど開発がうまくいかなくなっていく。…

なむさん。 結局細かく要件定義を固めて、確認しながら積み上げていくしかない。

まさに。そして、気づかずに"ゴミ"をクライアントに納品するのは、プロとして致命的。 そのリスクを回避する、最もシンプルなAI活用術がこれです。 AIには「構成案と骨子」だけを作らせる。…

なんかそんな気がする。

生成AIは「手が早くて何でも知ってて賢い」ように見えて、 実際は「覚えている分野すらうろ覚えで、ある程度以上の論理は理解してないアホ」であることを悟るんですね、 私を含む生成AI利用者は……

そうやねん 結果的に20〜30%粒度くらいまでかなぁ

今開催中の SIGMOD '25 の Bernstein 先生 (MSR) の話, これまでのトランザクション研究の流れがまとまっていてとても参考になる. 近日中にarXivにてロングバージョンが公開されるらしい. microsoft.com/en-us/research… doi.org/10.1145/372221…

よく技術的負債をBS,PLのメタファーで考察することがあるけど、AIに任せっぱなしの開発は、急激に資産を増やせるけどかなりの割合で負債という自己資本比率が低い状態で、その割には知見やよい設計基盤という形で利益を出して純資産に還元していくROIも低い、というかなりやばめのBS,PLの状態になって…

ほんとにこれ。動くものはできるが、負債を積んでる感覚ある。

これめちゃくちゃ分かります。特にセキュリティ重要な箇所の実装が怖すぎてデプロイずっと躊躇してます。

設計を省きがちなモダン志向の開発もずっとこの問題を抱えていると思う。設計視点で解析すると課題が明らかな場合でも当事者にはなかなか話が通じないので観点のギャップがあるのだろう。 大枠からテスト駆動でやれば対処できそうだけど致命的な要件バグが最後に出てきたら終わるし難しいところ。

Geminiのresearchがそんな感じだった...🥺 知らない分野だと情報量と文章のそれっぽさに圧倒されるけれども、知ってる分野だと概ねそれっぽくとも、「ん？」というところがいっぱい...

既存のコードを疑わないんだよな。そこが致命的な気もする。

> コードを積み上げていくような分野でこのやり方をやると負債が返しきれない速度でたまっていっていずれ破綻する 使い捨てのスクリプト、makefileな普段書かない設定ファイル、Terraformのresource毎の定義を覚えきるの不可能な場合には、すごくいい相棒。

こないだまで肉屋やってた奴にヒアリングシートをAI頼みで作らせたらゴミ出してきて、他の相談事でもすげぇ適当ぶっこかれてたりするので、コイツわかってねえとジャッジされたらめっちゃ手抜かれるというのを痛感してる

やはり、見える部分と裏側のロジックは全く違う世界線なんだな。 UIは流行り廃りがあるから変更するする頻度は高め。大事なビジネスロジックは変更する頻度は少ない。大事なロジックを頻繁にいじくりかえすだけでビジネス側に相当なインパクトかかるだろうし。 結局はどうつきあうかなんだな。

そうなりますよねぇ… ･人間側が賢くなる ･LLMが賢くなるまで待つ 以外に選択肢あるのだろうか。

これ 自分が詳しくない分野で日曜大工したいときにはめっちゃ役立つんだけど、専門分野だと、何もわかってないな…になってすごいストレス増える