Babysitting dumb AI is not a fun task..
Home / 2026 Apr
AIs underestimate the potentials of themselves. They tend to think they are not good enough for doing various stuff, but they are actually really good for almost anything.
They think like that because their knowledge cutoff was long time ago when the AIs were actually not good enough.
Coding Agent「作って」で1発目出してくるコードは未だに結構悪い事が多いけど、ある程度書いた後に、リファクタの方針をきちんと与えつつ、リファクタさせればかなり綺麗なコードが書ける。
自分の見て欲しいリファクタ手法をスキルとしてまとめて「全体リファクタして」を繰り返し要求すると、普通にどんどん良い方向のリファクタが出来て、やり続けると「もう改善点はありません」と言ってくるので、そこまで改善すると、普通に結構綺麗なコードになる。
自分が「クラフトマンシップ」だと思っていた作業も、きちんとスキルとしてフレームを与えてあげることですでに AI で置き換えられるらしいことが分かった。
転職する気が無くても定期的に転職活動的な事をしておいた方が良さそう。転職希望者にしか教えてくれない情報がいろいろある。
Deno has been pathologically undermarketing since the company silently switched to Deploy 2.
Deno definitely had hype until the time of KV release. That was the best time of it.
claude code 出てまだ1年ちょっとなのか・・・
人間のレビューが極力必要ないように AI のレビュー & 自動修正のパイプラインをしっかり組むのがあらゆる現場で急務
尚且つ AI レビューの痕跡を後から人間がさらっていってきちんと検証できるボリュームに分割されている事も必要。人間が認知できない PR があると丸ごと cognitive debt になってしまう。「この PR はデカすぎる -> 強制 Close」をするレビューエージェントが必須
全PRの83%をAIレビューだけでマージできるようにした https://zenn.dev/kauche/articles/e051583461c181
この話、一見危なそうに見えるけど、実際のところこれをやらないと、人間のレビューがボトルネックになりすぎるという現実があると思う。全ての現場でこれに近いものを入れる必要があると思う。
コーディングエージェントに対する不満の99%はコーディングエージェントで直せるなぁ、という印象になってきた。
コーディングエージェントのミスを人間が直せるなら、その作業をスキル化すればコーディングエージェントにやらせられる。
コーディングエージェントのミスは大体「言ってない」か「適切なペルソナを使ってない」か「コンテキスト溢れてる」のどれかがほとんど。
AI just reset everyone's ignorance to 100.
Doesn't matter how senior you are. Doesn't matter how clean your code is. We're all starting over.
https://x.com/KentBeck/status/2042617347576590581
I share this feeling.
ycombinator でやってること -> gstack としてスキル化された。ddd のレビュー観点 -> dev-multitools の ddd plugin でスキル化。スクラム開発 -> dev-multitools の breakdown でスキル化
今まで強い手法と思われていたものが全部スキルとして再現できる
Claude Code を手に入れた人類「あれも出来る！これも出来る！もっと出来る！もっともっと出来る〜！」
openclaw 一瞬で github 300K スター行ったけど、Claude Managed Agents が出てきて一瞬でいらない子になりつつある。物事の進むスピードが速すぎる
Any plan is now source code for coding agents
もはやちょっと syntax を変えるだけ、みたいな技術は必要ない気がする。tailwind が発明される前に AI が今の能力になっていたら tailwind は出来ていなかった気がする。速く書けるはもはや価値ではない。
新しい syntax に意味があるとしたら、優位に人間の認知コストを減らす (書くコストは増えても良い) ような syntax には意味がありそう (syntax ではなくて、別な表現でも良いかもしれない)
既存のプログラミング言語が text に固執しているのは、人間が手で描きやすい/差分を認知しやすいと言うのがあると思う。書きやすい側面はもうあまり価値がないとしたら、認知の容易さに特化した言語が出てきても良いかもしれない
dev-multitools に ddd 関連のスキルを追加しようと思って、作成予定の skill 名だけ一旦 claude code (opus 4.6) に伝えたら、自分がすでに書いていた skill よりもだいぶ良い感じに SKILL.md を作ってくれてしまった。
開発途中で欲しい観点があったら、その skill を claude に作ってって言うだけで良さそう。結局 GSTACK もそうやって作られているものな気がする。要は model の中の特定の expert の回路を起動するトリガーを skill にしてるだけ
よく使う claude code スキル集をプラグイン化してみた
Claude Code のスキルって基本的に one or two sentences で良いんじゃないか？何十行も下手に詳細に書く方が、視点を不必要に制限してしまって、より良い解釈の可能性を潰すリスクがありそう
Claude Code は短い表現でも、十分以上に意図を汲み取って成果を出してくれるので、skill は大雑把な方向性だけ示せば良い。
逆にモデルの能力がとても低いんだったら、スキルに詳細に書くことで不適切なルートに逸れるのを無理やり強制するという意味では有効かもしれない。
優秀な人をマイクロマネジメントするとアウトプットが逆に落ちてしまう現象だったり、能力が低い人ほど細かくマネジメントしないと仕事が進まない現象に似てるかもしれない。
genspark っていう AI workspace 使ってロゴ生成してみたら、プロンプトに対して、お前のやりたいロゴはこれか、みたいな方向性の候補出しをちゃんとしてきて、デザイナーのプロセスをちゃんと模倣できている感があった。
質問に従って色々詰めていったら、最終的にかなり精密度が高そうなプロンプトが生成されて、結構希望に沿うロゴが作れた。
同じプロンプトを gemini から投げたら、全然意味わからないワードサラダ的な出鱈目画像が出てきて、同じ nano banana モデルで生成してるのに、プロセスを変えるだけで全く違う結果になることに驚いた
あと Claude Code 使うとデカい PR が出てしまうのも Claude Code の使い方の問題。デカい機能を「(デカい機能)作って」と prompt してるからデカい PR になるだけ
「(デカい機能)をタスク分解して、各タスクに作業時間の見積もりを出して、plan.md に保存して」と言えば、細かく作業が見積もられた実装計画書が出てくる。そのプランをステップ毎に実行していけば、細かく PR を出せる。
Claude Code 初手で重複の多いコードを書きがちだけど、別途「重複を探して」とか「簡潔に書けるところ探して」って注文すれば、バチっと良い感じの良い表現を出してきてくれる。
Claude Code からダサいコードが出てくるのは、Claude Code のコーディング能力に問題があるというよりは、Claude Code の能力を出し切っていないだけな気がしてきた。
coding agent はめちゃくちゃ強いけど、出力がエンジニアじゃないと見れないのが難点な気がする。coding agent を非エンジニアに対しても民主化するような何かを作ると便利なのではないか?
ちょっと SDK の使い方を調査したいような場合に、ドキュメントサイトを見に行かないで claude code に「こういうことをしたいんだけどテストスクリプト書いて」みたいに頼んだ方がだいぶ早い。
Claude で情報をとりに行く手段の初手がかなり変わった印象がある。
2025: google -> doc site -> getting started -> tutorial -> reference 2026: claude -> write client example
openclaw、結局何がそんなに良いのかやっぱりイマイチ分からないかも・・・、普段使ってる messaging アプリから各種 SaaS 操作出来るっていっても、そこまで複雑なことをモバイルからやろうと思わないしなぁ・・・
あと、複雑な prompt 書きたかったら結局 PC 開きたくなるし、モバイルから LLM 叩けてもそこまで嬉しくないかも
普通の Web Server を Deno で運用するベストプラクティスを真面目に考え始めた方が良さそう。
Deno Deploy っていう公式サービスがあるせいで/おかげで、Deno Deploy 以外に普通にホスティングする知見が全然溜まっていないような気がする
Deno Sandbox に openclaw 乗せて運用できないか考えてみたけど、再起動時に URL がランダムに変わってしまうので、無理そうだ・・・
Deno Deploy 本体に openclaw 乗せれないか考えてみたけど、FS が(確か)書けないし、書けたとしても、anycast で当たるインスタンスによって設定が変わってしまうので、無理そう。
Deno Deploy は変に「世界中で水平スケーリングするステートレスな Web Server」だけにマーケットを絞ってしまっているのが悪手な気がする。単なる linux が乗ってるだけの「普通のサーバー」が出来ない
Claude Code を10並列で回そうが100並列で回そうが、結局 prompt 与える人間のところでボトルネックになるので、全体のスループットはそんなに上がらない気がするなぁ
OSS の使い方知りたい時に、ドキュメント見に行くより、repository clone して claude に解説させた方がより適切な情報が得られる印象がある。人間はドキュメント書くのを面倒くさがりがちだし、大体の人間はドキュメントを書くのが下手。人間が手でソフトウェアドキュメント書く時代は終わりかもしれない