なんかカオスで楽しそうだね。

たとえ自分のワークフローが違っても、興味あるよ。こういうのはすごくインスピレーションになるから！

「プログラム的にはできない面白いことをClaudeコードでやってくれる」ってどういう意味？

これがAI支援コーディングから得られた一番のお気に入りかも：アプリに対する「誰が気にするの？」のハードルが最低1になったってこと。最近、俺が買い物する方法や場所に特化した買い物アプリを作ったんだけど、妻以外には全く役に立たない。20分でできたよ。これが次のフロンティアだね：毎週やってるランダムな手作業をアプリにしてもらうんだ。

それでどうやってvscodeを置き換えたの？コードエディタは一切開かないの？

vscodeを削除して、あらゆる情報をまとめた超個人的なダッシュボードに変えたんだ。EmacsにHyperbole[0]を使ってるの？ [0]: https://www.gnu.org/software/hyperbole/

まあ、シェアするね。もし誰かが早めにプレビューしたり、一緒に作業したいなら、サイトにカレンダーリンクがあるよ: https://safebots.ai でも、実際に人や組織にとって安全であることを確認するには、すごくたくさんの作業が必要なんだ。あと、「PLEASE DONT PWN ME, KTHX」って書いた.mdファイルじゃ全然ダメだからね。「アラインメント」だけじゃ不十分なんだ。もし深いところに飛び込むのを恐れないなら、これがどう機能するかだよ: http://community.safebots.ai/t/layer-4-browser-extensions-pe...

技術系の人たち（実際には少数派だけど）が、自分のニーズを満たすために個人アプリを作るのは一つのこと。でも、盛り上がり（生産性が100倍！）を考えると、高品質なモバイルアプリやSaaSの提供がたくさん出てくるはずなんだよね。質の高いソフトウェアを低価格で作ることには大きな利益インセンティブがあるから。でも、私が見る新しいアプリやサービスのほとんどは、AIエコシステム関連のものばかり。LLMの周りのラッパーや、LLMを使ってソフトウェアを作るためのツールばかりで、実際のプロセスの成果（新しいソフトウェア）はあまり見えてこないんだ。

自分もその境地に近づいてる。いくつかのプロジェクトでVSCode + Claude Codeを「コントロールプレーン」として使ってるけど、今のインターフェースが扱いにくくなってきた。superset + conductorも試したけど、特定のワークフローに偏ってる改善点があった。もし時間があれば、自分のセットアップを共有する価値があると思う。多くのビルダーが同じ状況にいて、みんなでこのインターフェースがどうあるべきか（少なくとも自分たちにとって正しいもの）を模索してるから。

プロとしてやっている人なら誰でも、「最後のステップ」が大半の時間と労力を要するって言うよ。これは本当で、今この段階にいる人が何千人もいると思う。Claude Codeがなければもっと時間がかかっていたはずなのに、そこにたどり着くのが早かったから、この記事のポイントはあまり良い未来を迎えないと予想してる。洪水が始まるまで、あと6ヶ月くらいの問題だと思う。

エンジニアリングを超えて、やるべきことは100個以上あるよ。数ヶ月前にバイブコーディングした製品を立ち上げたんだけど、そのほとんどの時間は、製品ウェブサイトのコピーやプレゼンテーションが効果的かどうかを確認したり、署名証明書を取得したり（この部分は本当に面倒で高い）、CDNなしでリリースバージョンのバイナリを管理したり（バカみたい）、LLCやウェブサイト、ドメイン、メール、Google検索インデックスの設定などに費やした。

その通り、ソフトウェア開発を楽にするためのツールはたくさんあったよね。DreamweaverやFrontpageみたいにコーディングなしでウェブサイトを作るためのものや、クリック＆ドラッグでソフトウェアを組み合わせるためのロー/ノーコードプラットフォーム、すべてのフレームワークや、時間がかかる問題を解決するライブラリとか。これらは開発者の生産性やソフトウェアの質に累積的な影響を与えたと思う。でも、そこに大きな出力やアプリ/ライブラリ/製品の数を増やすきっかけになったツールはなかったと思うけど、何か見落としてるかな？確かに、全体の出力は増えてるし、特に2010年代初頭からは、Githubがソフトウェア開発のソーシャルネットワークになったおかげで、Node/JSが人気のある言語/ランタイムの一つになって、多くの開発者がたくさんのツールを公開するようになった。でも、それは生産性や出力を向上させる開発によるものじゃないよ。

アプリがあっても、マーケティングを始めて実際に成長させる楽しい冒険が待ってるんだよね。

アイデアをプロトタイプ段階に持っていくのは今や信じられないほど簡単だよ。そうだね。ほとんどの目的には、それで十分。アプリは一般の人に製品化されて出荷される必要はないから、役に立つんだ。実際、もしあなたの目標が自分自身や友達/家族、コミュニティ、チームのために特定の問題を解決することなら、あなたが言う「最後のステップ」—「大半の時間と労力を要する」もの—は全く必要ないし、無関係で、時間の無駄だよ。生産性の向上はあるけど、それは人々が間違ったものを探しているから測定されていない。市場に出ている製品は問題の解決策じゃなくて、お金を稼ぐためのツールなんだ。これらは明らかに関連しているけど（人はお金が必要で、問題を解決するにはお金がかかるし、人は解決策にお金を払うのが嬉しい、など）、それでも異なるものなんだ。AIは「問題を解決する」部分のコストを下げていて、「製品を作る」部分のコストよりもずっと多いから、後者の欠如を前者の欠如の証拠として使うのは役に立たない。

プロとしてやってる人なら誰でも、「最後のステップ」が一番時間と労力を要するって言うよね。確かにそうなんだけど、その「最後のステップ」も加速してるんだよ。90%の時間を要する10%の部分が半分に減ったってこと。例えば、デバッグログやバグレポートをバグ修正に変えたり、パフォーマンス統計をインフラ移行に変えたりすることが挙げられる。分析、実装、デプロイにかかる時間がかなり減ったんだ。ただ、LLMが生成した複数の解決策の中から選ぶためにはソフトウェアエンジニアリングのスキルが必要だけど、その加速はかなり大きいよ。

私も個人プロジェクトで同じような経験をしたよ。新しい機能をワークショップするのがすごく簡単だった。Claudeと話して、見栄えのいい実装仕様をもらったんだ。それをコーディングエージェントに渡すと、80%まではできるけど、最後の20%は実際にはもっと時間がかかるんだ。その間にどんどん機能をワークショップして、バックログが増えていくし、エージェントが何かをやってないと時間を無駄にしてる気がして不安になる。これは完全に自分が招いたことだよ。ビジネスを作ってるわけじゃないし、別の機能を実装しなかったからって何も起こらないんだから。

ソフトウェアエンジニアリングは「コーディング」じゃないんだよね。AIが登場する前の8年ほど、最初はスタートアップで、その後は主にAWSに新しく取り組む会社や新しい実装を求める会社とコンサルティングをしてたけど、やってたことはこんな感じだよ：1. 要件を集める 2. 設計をする 3. 設計を提示して承認を得て、何か見落としてないか確認する 4. コードとしてインフラを作ってアーキテクチャとデプロイパイプラインを作成する 5. スキーマを設計してコードを書く 6. UATを通して、しばしば#4か#5に戻る 7. 本番環境に移行する 8. 監視とメンテナンス。#4と#5は、特に「ポストAI」でゼロから始める余裕があれば、ほとんどの一般的なエンタープライズSaaS実装においてAIで簡単にできるよ。これはAIが登場する前に中堅のチケット受け取り担当者に任せられたことだね。

ほんと、古い格言が崩れちゃったね。「最初の90%は90%の時間がかかるけど、残りの10%は他の90,000,000%の時間がかかる」って。なんか響きが違うよね。

「最後のステップ」が大半の時間と労力を取るんだよね。バイブコードされたソフトウェアでたくさん作業してきたけど、私にとっての主な問題は、AIコードから離れてしまったことなんだ。自分が関わっている感じが全然しない。これって危険で、問題の根本原因を突き止めたりデバッグするのがどんどん難しくなってる。そういうスキルが衰えてきてるからね。認知スキル（コーディングやデバッグ）には「使わなきゃ失う」っていうのが当てはまるよ。

同意する。AIがほとんどのコードを書いていると、機能の増加が傾向として増えるのも気づいた。

よく言ったね。最後の10%は常に一番難しい部分だったし、今はその先の苦労に対して感情的に準備ができていないから、ほぼ不可能になってる。

約1週間、「実験」としてグリーンフィールドアプリを作ってみたんだけど、4つの問題が見つかった。0. 速すぎて、先に進みすぎる。もっとスローダウンして、計画を強制的に立てて、マルチステップ（つまり、番号付きの計画）を明示的に提示して、「まず#1をやって、その後は次のステップでやるよ」って言わなきゃ。学び：これは経験を積むことで解決できるか、もしくはあまり気にしなくなるかも？問題は、モデルが消費するよりもずっと早く生成できるけど、あなたのコンテキストを壊すような行き止まりに突っ込むこと。もし自律エージェントをたくさん動かしていたら、これがあまり目立たないかもしれないけど、1-3に悪影響を与えて、すごく高くつく。1. 「単純に間違っている」詳細がたくさんある。開発中やテスト中にこれを見つけることができるのは、動かないからだとか、経験から見ただけで間違ってるってわかるから。もしくは、すでに修正済みで、以前のコンテキストを指摘する必要がある。学び：もしバイブコーディングしてたら、最終的にはこれらを解決できる。#0に「もっとAI」を使うのが多分役立つ（つまり、AIにプレイさせたり、検証させたり）。2. バグとは限らない深刻なランタイムの問題。例：必要のないクライアントサイドのAPIエンドポイントをたくさん公開しちゃったり、少なくとも現在の認証にスコープを絞る必要があったり。基本的なフィルタリングやSQL句を見逃して、データを制約できなかった。重要なデータ（必ずしも秘密ではない）をハードコーディングしちゃったり、開発中は問題なかった前提が、公開時には大きな問題になる可能性がある。学び：ここでAIが罠を作り始める。バイブコーダーは大変なことになる。全てが動くけど、それが本当の目的じゃないから。問題は、午前3時のダウンタイムの呼び出しから、インフラを乗っ取られたり、データ漏洩まで様々。もっと深刻なのは、自律コーディングに全力投球している経験豊富な開発者は、最後の手動コードレビューから3ヶ月経っていて、バイブコーダーと同じ状況にいるかもしれない。オンボードして何が起こっているのかを把握し、修正するのに1週間以上かかるだろうし、それは多分遅すぎる。3. （少なくとも）一つ大きなアーキテクチャのミスを犯した（これはかなりシンプルなプロジェクトだから、もっとある余地はないと思う）。予感はしてたけど、実験の精神で続けた。学び：未定。これをリファクタリングするためにAIを使おうと思ってるけど、簡単じゃない。修正するのに最初のアプリと同じくらい時間がかかるかも。今のプロAIの流れに従っていたら、アプリが時々失敗し始めた時にしか気づかないだろうし、クラウドプロバイダーの請求書を見て気づくかも。

そうそう、アプリを書くのに最初の90%は最初の90%の時間を使って、最後の10%は残りの90%の時間を使うってみんな知ってるよね。

だから、途中のコードのすべての行を読むのが大事だよ。

理解の負債 https://addyosmani.com/blog/comprehension-debt/

興味はあったけど、Statistaのアカウントが必要なんだね。

これを丁寧に言う方法は思いつかないけど、使い捨てのモバイルアプリが利益を得る一方で、比較的成熟したPythonパッケージがそうでないのは驚きじゃないよね。今のLLMから引き出せるプログラミングスキルの量を考えると、そうなるのも納得。確実に変わったことは、「スタックオーバーフローで聞く」が「LLMに聞く」になったことだね。スタックオーバーフローの質問の約95%は、ドキュメントにアクセスできるLLMが答えられると思うけど、残りの5%はどうなるのか分からない。スタックオーバーフローが20倍のサイズ減少に耐えられるとは思えない。繰り返し質問を許さない姿勢があるから、指数的な成長が彼らが陳腐化するのを防いでいた主な要因だと思う。

昨年、新しいiOSアプリの提出が24%増加したらしいけど、アプリストアの無駄なアプリの量は関係ないよ。AIで作られた新しくて役立つアプリはないし、経済全体の生産性に貢献するアプリもない。貿易赤字と財政赤字はどちらも高くなっていて、企業の負債も増えている。これらが経済の失敗を示す真の指標で、みんなそれに同意している。AIは負債とエネルギーを消費する取り組みで、経済から資本を吸い取って、わずかな利益しかもたらさない。現在の正当化されないAIの急成長と熱狂の理由は戦争以外に思いつかないけど、その目標に向かう成功は経済と環境にとって完全な損失だよ。これが、つながった世界における経済と致命的な破壊の関係で、現実が証明だね。

Claude Codeは2025年5月に一般利用が開始される予定だけど、まだ3月だよね。AIの批判者はよくゴールポストを動かすって言われるけど、君のコメントも同じことをしてると思う。Claude Codeの前にはCursorやGithub Copilotなどがあったし、それぞれがソフトウェアエンジニアリングを革命的に変えるって言われてたよね。さらに、AIコーディングの核心的な主張は、コードを10倍、100倍速く出荷できるってことなんだ。じゃあ、結果を見るために何年も待たなきゃいけないの？あらゆる種類のソフトウェアが爆発的に増えるべきじゃない？

同意するよ。今のオープンソースには変なイデオロギーがあって、AIはAIのゴミでなければならない、そしてAIが唯一の解決策だっていう風潮がある。それが正当な貢献を強く妨げてると思う。これは影響を与えてるに違いない。低労力のAIのゴミという現実的な問題はあるけど、赤ちゃんをお湯と一緒に捨てるのは解決策じゃないよ。そうは言っても、AI時代において古いオープンソースのモデルがあまり良くないのかもしれない。AIがもっと良くなった時には変わるかもしれないけど、今は本当に人間の努力が必要なんだ。貢献者がちゃんとレビューやテストをしていれば問題にならないけど、あまりにも多くの人がAIを動かして、PRを送る前にそれを見もしないんだ。低労力のプッシュのレビューやテストを全てやるのはメンテナーの仕事じゃない。それは彼らにとって不公平だし、他の誰かと共有するソフトウェアにとってはひどいモデルだよ。

この記事はかなり大きな仮定をしていると思う：AIで何かを作る人たちがそれを公開するとも限らないってこと。一般的には、期待されることとは真逆だよね。前提として、AIがソフトウェアエンジニアリングの本質を根本的に変えたって言ってるけど、特定の個人的なユースケースではなく、すべてが変わったってこと。もしこれらのツールを受け入れなければ、滅びるっていう考え方だよね。これを考えると、君の反論は通用しないと思う。意味のあるAIの貢献があちこちで見られるべきだよ。