著者のようなユーザー 彼はかなり面白い人だと思う。彼の作品は、これまで多くの人に影響を与えたんじゃないかな。

ブラムが最近いろいろやってるのを見ると嬉しいな。HNに二回目の登場だね。

彼のバックグラウンドを考えると、自分の立場を支持する証拠を示すべきだって分かるはずなのに（完全に裏付けのない愚痴を言う代わりに）。

ある人は、最大AIレベルは5にすべきだと言っている > もちろん、AIレベル2を超えると地に足がつかなくなると思っている人もいる この枠組みが時々細かさを失わせることがあると思う。人生のほとんどのことと同じように、これらのアプローチにはニュアンスがある。最近、私のメインプロジェクトでは「自律エンジニアリング」の概念に本当に傾いているので、AIレベル7が完璧だと思っている。出力に対して厳格なQAプロセスを通じて資格を与えられる限り（つまり、出力が正しく見えればコードが何をするかは重要ではない）。でも、このプロジェクトではAIの「ハンズオフ」メソッドに本当に傾いているけど、AIがどれだけうまくやるかによってレベル5や4に落ちる部分もある（特にフロントエンドデザイン）や、機能の重要性によって（私の場合はE2EE）。最も重要なのは、スケールを「上」や「下」に動かす必要がある時を認識し、構築しているシステムを理解することだよ。

今はレベル5だけど、たくさんのガードレールを実装してるし、nullがない型付き関数型言語を使ってるから。TDDの赤/緑もやってるし、仕様書を書くのにもかなりの時間をかけてる。ダイナミック言語でここまで安心できるとは思えないな。追加のツールと、もう一つの最大20アカウントがあればレベル7には行けるかもしれないけど、今作ってるプロダクトに対してはあまりにも気を使ってるから。もっと気にしないものなら別だけどね。個人的には、7以上を目指すなら、静的型付けで安全な（表面積が小さい）言語を選んだ方がいいと思うよ。自分でコードを書くことはないだろうし。

https://visidata.org/ai レベルのリストありがとう。これで、どういう風に進んでいるのか、他のエンジニアと比べて自分がどこにいるのかを理解するのに役立つよ。自分は大体AIレベル5くらいで、インターフェースを完全に理解してテストできるときにはAIレベル6に行くこともあるけど、実装は完全には理解してないかな。エージェントがチームメンバーとして働くのと、チームで作業するのとあまり変わらないよ。

面白いレベルの分解だね。いいと思う。ただ、レベル7がほとんどのプロジェクトに存在するとは思えないな。大抵の非トリビアルなプログラムには、実装に関する深い知識がないと仕様を作るのは不可能だよ。そんなの無理だよ。面白い問題のほとんどでは、仕様には実装の詳細やアーキテクチャ、重要なデータ構造が含まれなきゃいけない。結局、別の言語でコードを書いてるだけで、手動で構造体の宣言を書いた方が良かったってこともあるかもね。

面白いリストだね。これから数年で最も進歩するのは、そのリストの最高レベルに自分を押し上げる人たちだと思う。今は激しい変革の時期で、自分の生活スタイルが終わったことを受け入れたくないコーダーがたくさんいる。今でも鍛冶屋はいるけど、大半は工場や安い第三世界の労働で作られてる。今、コーディングでも同じことが起きてると思うけど、5年前のチーム全体がやってたことを、単独のビルダーやデザイナーができるようになるんだ。

仕事ではレベル4だけど、サイドプロジェクトは恥ずかしいことにレベル6に達しちゃった。機能をそのまま受け入れるのはすごく魅力的で、どう動いてるのか理解する時間を取らないで済むから。

これはコンテキストに特有のスケールでもあるね。私はコンピュータビジョンの分野で働いてる。周辺アプリ、UI、チェックアウトフローなどを作るのは、このスケールで簡単にレベル6/7（ごめん…）になる。レンダリングパイプラインやアルゴリズム、数学を作るのは、レベル2すらオフにしてる。深い集中状態には、それが価値以上の気を散らすものだからね。だから、少なくともそのギャップの一部は、人々が働いている分野の新しさや複雑さから来ていると思う。

それでも、Claude Code（など）がクリーンで構造化されたコードで作業する方が成功する可能性が高いのは確かだよ。人間のコーダーと同じようにね。短期的には大したことじゃないかもしれないけど、長期的にはまだ解決されていない問題だと思う。

「伝統的な“良い”コードのルールを全部無視しても、クレイジーに人気で成功するプロダクトを作れるってのは、いつも真実だよね。」

悪いコードは、動くうちは問題ない。でも、私の経験では、人間の場合、数ヶ月の時間枠であれば、悪いことをするよりも正しいことをする方が価値がある。数年になると、絶対に正しいことをした方がいいよ。そうしないと、本当に時間を無駄にしてるからね。「大規模なリファクタリング」じゃなくて、変更のタイミングで「この変更はなんか嫌なハックだな」って思った時のことを言ってるんだ。LLMについては、あんまりわからない。数年の経験しかないから。

毎日使う多くの製品の手書きコードを見たら、みんな驚くんじゃないかな。私は大企業やスタートアップで働いてきたけど、プロダクションに出るひどいコードには最初は驚かされたよ。これは誰かを批判するつもりじゃないし、私も悪いコードを出したことはあるから。締め切りは、私の意向に反しても存在し続けることがある。時には、顧客やマネージャーを喜ばせるためにハックを出さなきゃいけないし、そのハックをより良いコードに置き換えることはなかなか起こらない。ちなみに、私が書くほとんどの初稿はあまり良くない。私が愚かだと思うかもしれないけど、私だけじゃないと思う。きれいで最適化されたコードを書くのは、たいてい2回目か3回目のドラフトだから、最初のドラフトを終えるまで問題や前提を完全には理解してないと思う。私の個人プロジェクトでは、最初の10回くらいのコミットは結構ごちゃごちゃしてて、その後にクリーンアップ用のブランチを作って、コードを少しマシにするんだ。これは本質的に悪いことじゃないけど、たいていはコードの2回目や3回目のドラフトを作る時間が与えられないから、初めの「とりあえず動かす」ドラフトがプロダクションに出ちゃう。あまり好きじゃないし、BigCoで自分の名前がついたコードが漏れたら怖いけど、企業の世界ではそういうもんなんだよね。

「伝統的な「良い」コードのルールをすべて破りながら、クレイジーに人気で成功した製品を作れることを示している。私たちはすでにそれを知っていた。これは、知らなかった人や認めたくなかった人が、クレイジーに人気で成功した製品を作るのにそれが重要じゃないという証拠を持ったかのように思っていることで、良いプラクティスを支持する人たちへの「やっぱりね」って感じだ。成功して現金化できるものを作ることが目標なら、良いプラクティスや品質は全く関心の対象じゃなかった。これがYAGNI、move-fast-and-break-things、そしてworse-is-betterの基礎なんだ。少なくともベータマックス対VHSの時からこれを知っている（最近はWiB VHSの文化的知識は忘れられているかもしれないけど）。」

この製品はハイプの波に乗ってるね。だからこそ、めちゃくちゃ人気で成功してる。状況はViawebに似てる - Viawebもハイプの波に乗って、コードの状況は最悪だった（顧客の問題再現劇の間にバグを修正するPGの話を見てみて）。Viawebの買い手は何をしたかって？C++で書き直したんだ。歴史が繰り返されるなら、Anthropicの買い手も今のClaude Codeの実装に対して「C++で書き直して」って言うだろうね。

なんか文法警察みたいな人たちを思い出す。彼らは「見た目が醜い」ってことにこだわりすぎて、メッセージが見えないんだよね。このコードが急成長中の4000億ドル企業を支えてるってのに。リファクタリングは簡単だって認めてるけど、彼らもそれを知ってるはずなのに、まだ優先順位が低いって気づいてないんだ。

これ、100倍同意。うちの会社でM&AをやってるCTOなんだけど、たくさんの成功した会社のコードベースを見てきたけど、ほんとにエレガントなものは一つもなかった。利益を上げてる良い製品を持つ会社も含めてね。知ってる良いコードはオープンソースの領域かデモシーンにしかない。商業用のコードはほとんどクソだけど、それでもお金を稼いでる。

1. バイブコーディングは、人間の監視（または人間が書いたテストや仕様書の形での足場）がどれだけ関与しているかのスペクトラムだよ。
2. 「悪いコード」の問題は、製品の短期的な成功とは関係なく、時間をかけてそれをうまく進化させる能力に関係してる。つまり、長期的な成功についての話で、短期的な成功ではない。
3. たぶん最も重要なのは、Claude Codeはそのコアではかなりシンプルな製品で、ほとんどの価値はモデルから来ていて、自分自身のコードからは来ていない（コスト面でも同じことが言える）。Claude Codeは比較的リスクの低い製品なんだ。だから、悪いコードが引き起こす問題はこの場合あまり重要じゃなくて、Claude Codeが「バイブ感」の極端な端にないことでさらに管理されてるんだ。

この投稿を読んで、どれだけの人がこの妄想に陥っているのか、または不誠実なのか疑問に思う。私は40年間プログラマーをやっていて、ほとんどの会社では90%のコーダーがいわゆるスタックオーバーフローコーダーやグーグルコーダーだよ。正直なコーダーはそれを認めるし、AIはすでにその90%よりも優れている。かなり優れてるよ。少なくとも、多くのインフルエンサーコーダーは、実際にコードが素晴らしいってことを認め始めてる。私はコードレビュアーの方が多くて、実装を計画することが、実際にコードを書くよりもずっとワクワクする。ほとんどの人が私と同じように感じていると思うけど、まだ自分の仕事を失うのが怖いスタックオーバーフローコーダーもいる。彼らは失うだろうね。

ユーザーって、普通のユーザーとお金を払ってるユーザーのこと？それは重要な違いだね。

企業内で100人にアプリを配布するのはすでに地獄のような悪夢で、市民開発者が存在することは絶対にないと確信してる - それよりもシンギュラリティに達する方が早いだろうね。

実際、そうじゃないよ。エンタープライズ層に移ると、逆の問題が出てくる。ユーザーは少ないのに、CPU集約型やDB集約型の処理を迅速に行う必要があることが多い。私が働いていたある会社は、あまり優れたエンジニアじゃない人たちが作ったシステムで、プログラムを実行するのに日中の時間が足りなくなってた。すべてのクライアントが24時間でスケジュールされていて、プログラムを22時間実行することになって、時間がなくなる前に必死で修正しようとしてた。プログラムの売りの一つが、すべてのクライアントからデータを統合することだったから、並行して実行することはできなかった。

AIの進歩が停滞しても、現在のモデルを基にしたツールやパターンを作ることで、手作りのものを超える自信があるよ。

どこか真ん中にいる超生産的なキャンプ この生産性の向上をどうやって定量化して測るの？

カーニハンの法則、つまりデバッグは最初にコードを書くよりも2倍難しいってやつね。最近はAIが人間よりもずっと早くデバッグできるって信じる人が増えてきた（たぶん、他の賢い人たちが似たようなデバッグをすでにやってるから）。最悪の場合、AIにコードを書き直させればいいし。これとは逆の方向に進むと思ってたけど。デバッグは今や、最初にコードを書くよりも100倍難しい。 > レーマンの法則、システムの複雑さが進化するにつれて増加するってやつで、維持または削減するための作業が行われない限り。上の話と似てるけど、人々はそうじゃないと信じ始めてる。これにも反対だね。バイブを続けるためには多くの作業が必要だと思う。さもないと、複雑さがLLMの能力を超えて急速に増加しちゃうから。

その通りだね。微妙なバグやユーザーの期待を裏切る部分、古くて繰り返しのコード、無駄なテスト（実際には1つの論理フローで済む6つのテストとか、三項演算子がまだ三項演算子であることの確認とか）、ドキュメントのギャップ、その他いろいろを探すための素敵なマルチパラグラフのプロンプトを持ってるよ。オーパス、GPT5.4、ジェミニにそれをやらせて、自分たちのヒットリストを作らせる。そして、オーパスの監視インスタンスにその結果を反証させて、最終的なヒットリストを作成してもらう。最後に、新しいコンテキストインスタンスを使ってヒットリストを修正する。いつも小さな不具合や矛盾、コードの整理の改善を見つけてくれる。コードベースに必要以上の変動をもたらすけど、彼らが見つけるものは依然としてプラスだし、最終的なヒットリストの各項目を確認してる（過剰に反応してるものや、直す価値のない一万分の一のバグを見つけた場合は、しばしば削除することもある（最近は、「デバイスが無効なシリアル出力を返したらどうする？」っていうのにこだわるエージェントがいて、「うん、クラッシュする」っていうのは全然問題ない反応なんだけどね））。