今日ついに AI にブラウザ持たせて色々作業させるやつをやってみたら、すごい大量のバグを見つけてきてすごい
MCP って要するに dynamic に tool call (function calling) を足せるっていう話だから、やっぱり便利な気がする。
Coding Agent はまあ CLI 叩くで代用すれば良いかもしれないけど、Coding じゃない Agent は普通 CLI 叩くなんて許可されないので、MCP でカスタマイズするのがお行儀が良さそう。
MCP がワークしてなく感じるのは、Coding Agent に MCP を刺すのがイマイチ (そもそも Coding Agent は与えられてる裁量がデカすぎる) という話でしかなくて、一般の chatbot に合理的かつ dynamic に機能を足すプロトコルとして MCP は理にかなっていると思う。
ソースコード読まない派がひとしきり騒いだ後でソースコード読む派が大量に現れたので、やっぱり読む派の方が多そう
web ページのデザインの比較をしたい時に、agent に幾つか挙げさせて、その上で「全部ブラウザで開いて」って言って、ブラウザタブ8個とか開かせるのがすごい気持ち良い
日本の X の AI 界隈、ソースコードは読まないのが正みたいな方向に行ってるけど、普通に work しないと思う。
読んだ方が AI がやっている事を具体的に理解できる。読まないで挙動だけから判断してたら間接的にしか分からない。
読んでれば何か起きた時にすぐに気づける。読んでないと間違いに気づくのが遅れるし、間接的にしか分からないので、現象の切り分けの難易度が上がる。
https://deno.com/blog/v2.8#settimeout-and-setinterval
Deno 2.8、setTimeout と setInterval が Node の Timeout オブジェクトを返すようになってしまった。実害がありそうな breaking change で、とても微妙な気がする。
release note のコメント「breaking change だけど実質影響はない」みたいに書かれているけど、あまり調べた形跡がない。というかちゃんと調べたら大きい実害が発見されるはず (Record<string, number> に setTimeout の返り値入れてるとかあるはず)。だいたい WPT が落ちるようになる変更が実害じゃないという考え方がちょっとおかしい。
sanitizer off by default はめちゃくちゃビミョいなぁ・・・
https://deno.com/blog/v2.8#sanitizers-off-by-default
自分は on by default を想定して今までテスト書いてきているので、いちいち全部 on にして回らないといけない・・・
https://x.com/kenn/status/2058435100380209639
「ソースコードを1行も読まない」で「複雑性は管理する」っていうのはどういう事だろう。中身を読まないで挙動だけでみていたら中身が複雑かどうかは分からないのでは。
中身を一切見ないコーディングが vibe coding で、それではワークしないことが分かってきたので agentic engineering にシフトしようというのが今の流れのはず
In Deno, now PRs can be approved by bots.
https://github.com/denoland/deno/pull/32944
In this case, Bartek creates a PR with claude, and it's approved by claude controled by Bartek. It's essentially a self-merged PR in a traditional sense.
grafana で初めて本格的なダッシュボード作ったけど、これって、複雑すぎる事象を無理やり GUI に落とし込んだ事で迷いの森のようになったアプリケーションという感じだ。Photoshop とか MS Office と同じ匂いがする。
codex をちょびちょび使ってるけど、何をやっているか、何を考えているかがすごく分かりやすい感じがする。モデルの違いというよりは、ハーネス側がうまく/丁寧に作られているような印象を受ける。
arxiv を引用しまくった「凄そうな記事」を誰でも一瞬で錬成できてしまう。技術記事の内容のインフレが起きてる
claude desktop から remote host 上で session 動かすようにしたらめちゃくちゃ快適だ。
claude の session 本体 (プロセス) が remote で動くようになるので、PC を閉じても session が動きぱなしになってくれる。尚且つ PC を開けたら自動で繋ぎに行ってくれる。
昨日まで remote 内の tmux 内で作業してたけど、それだと window 切り替え等が面倒で「今どこだっけ」の認知コストが高かった。claude desktop から繋げることで普通の chat AI 使う感覚で session に繋ぎ直せる。楽。
尚且つ、画面の表現力が上がって diff などが見やすいし、コピペとか、スクロールバックも terminal よりやりやすくて快適。
知識を問うスクリーニングはもはやほとんど意味がないような気がする。それは AI に聞けば全部すぐ分かる。
それよりもモチベーションとか好みとか趣向とか AI を使っても変えられない属性を見る方が重要な気がする。
Codex 使い始めてみた (とりあえずデスクトップアプリデフォルトのgpt-5.5 medium)。Claude Code (Opus 4.7) より何をやっているかの開示が多くて、安心してみていられる感じがする。
作業自体は少し Claude Code (Opus 4.7) より遅いような気がするけど、何となく丁寧に作業してくれている感じがする。Codex の方が良いエンジニアのマナーがハーネスに丁寧に埋め込まれているような印象。Claude Code は雑に頼むと作業が雑になるイメージがある。
ブランチの同じ状態に対して kt:simplify を掛けてみたら、Opus 4.7 の方が適切な改善点を見つけられたケースがあった。地頭自体は Opus 4.7 の方が上かもしれない
最近サプライチェーン攻撃が起きまくっているけど、アタッカー側が AI で脆弱性探してるから見つかりやすくなってるていうのはありそう。
で、ここまでサプライチェーン攻撃が起きると、そもそも誰が作ったか分からないエコシステムに乗るのが危ないという話になってくる (すでに昔からなってる) 訳で、今や AI に欲しい依存に等しい機能を都度作って貰えば、別にエコシステムに依存する必要がなくなるので、そもそもエコシステムの物をダイレクトにインストールして使うみたいな事がアンチパターン視されるようになるかもしれない。
実際、hono 使いたければ、hono を参考に hono と同じライブラリ書いて、っていうプロンプト (厳密には、どうやってポートするかもうちょっと指示した方が良さそう) をスキル化して回せば、公開レジストリに依存せずにそのライブラリを使うことが出来る。そしてサプライチェーンリスクが無くなる。
みんな(ソフトウェア業界)がすごい勢いで変わっている
Codex デスクトップアプリ初めて使った。めちゃくちゃ良い。今までターミナルで Agent 並べてたのは何だったんだという感じになった
自分のスキルが 0 に近い分野のことを AI にやらせても結局自分がボトルネックになってうまくいかない感じがする (自分がその分野の「当たり前」をキャッチアップすることにほとんどの時間が消費される)
ほとんどの作業をやるのが AI だとしても、AI にやらせることが自分が元々得意な事であった方が成果が出易い感じがする。
昔大企業に属していた時に、ソフトウェアを知ってるディレクターの開発チームと、知らないディレクターの開発チームでは、前者の方が圧倒的にパフォーマンスが良かったのと同じように、中で起こっていることを理解している人が指揮するのと、理解してない人が指揮するのではパフォーマンスが圧倒的に違う。
An argument against, or a note to, "Coding is solved".
If a target program can be described precisely in natural language, coding agents can write it for you.
If there is no natural language vocabulary to describe it, then you suddenly need to write that program in programming language.
--
Let's call the first category A software, and the 2nd B software.
What I've been always interested in is B software. I loved software engineering because it can find something extraordinay, amazing, which is undiscoverable without programming language vocabulary.
To me, software engineering is about exploring something which cannot be written by coding agents.
Coding is solved. https://www.lennysnewsletter.com/p/head-of-claude-code-what-happens
A bold claim. I partially agree with it in a sense that coding agents can now make an exact program when we can prompt it very clearly and exactly. If you can describe your program completely precisely, then you can let agents write it.
However such process isn't the only part of software creation.
I've been building bw, a 2d top down exploration game, for about 2 years. I have very picky preference about every detail of it. The process of making it is like process of paiting a large picture. I write a line of code, and get the feedback from it, and then evaluate it against my preferences. Sometimes take it, and sometimes discard it just like painters removing or keeping lines while drawing.
There are very complex and entangled correlation between code, result, and my preference in the creation of bw. I'm almost certain nobody can make a prompt to coding agents which produces the current state of bw. I actually already tried that and already failed. There's too much details and the amount I needed to ask to the coding agent was very close to (or maybe more than) what I need to write in programming language.
chappy, OS っていう単語をメチャクチャ比喩的に使ってくるな。何の学習データに引きずられてるんだろう
Claude Managed Agent って Claude Code 使える訳ではないのか
Babysitting dumb AI is not a fun task..
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 に解説させた方がより適切な情報が得られる印象がある。人間はドキュメント書くのを面倒くさがりがちだし、大体の人間はドキュメントを書くのが下手。人間が手でソフトウェアドキュメント書く時代は終わりかもしれない