その横にエクセルシートがあって、それと照らし合わせてテストできるんだよ。何かおかしいと思ったら質問もできるし、コードの説明もしてくれる。

AIによって大きなクラッシュが一回起これば、資本家たちがビビるだろうね。そしたら、ホワイトカラーの俺たちも少しは息ができるかもしれない（少なくとも数年、もしくは10年くらいは）。

全然怖くないよ。失敗するところもあれば成功するところもあるし、全体的には私たちにとっては何も変わらないと思う。

PythonからRustを学ぼうとしてるんだけど（楽しみでね）。Python用のいろんなLLMを使ってるけど、たまに躓くことがある。AIを信じすぎると、どれだけ自分が知らないか、どれだけ多くの人がそのことを理解していないかを実感するのは美しい体験だよ。自分のレベルでAIを使ってRustプロジェクトを展開するのは、ちょっと怖いな。

いつも通りのビジネスだね。

もし彼らがExcelモデルを検証するスキルを持っているなら、AIが生成したモデルの数字にも同じアプローチを適用できるはずだよ。直接検査できなくてもね。私の経験では、多くのExcelモデルは実際にはあまりテストされていなくて、ちょっとチェックして正しいと見なされるだけなんだ。

医療に移行すると、少し怖さが減るだろうね。

俺は、かなり悪化すると思う。エクセルシートは、長年にわたってその動作を理解していた人たちによって調整されてきたし、無数のバグも直されてきたからね。Claude Codeのコピーは、同じように動くかもしれないけど、エッジケースを間違える可能性が高い。30シートのエクセルを考えると、そういう鋭い部分がたくさんあるんだ。

こういう「コードに近い」分野の一つのダーティな秘密は、テストがほとんどないってこと。データサイエンスチームがシミュレーションで何かを間違ってモデル化したら、それを誰が見つけるの？普通は誰も気づかないよ。遅すぎるまでね。「これ、信じられない」って出力に対して言える？それとも「データドリブンじゃない」って怒られるのが怖くて言えないかな。もし役員がインターンや派遣に「それをvibecodeして」って言ったら、プロセスを人間の言葉で説明したものが正しくシミュレーションに変換されたか確認するチェックポイントは絶対にないよ。でも、コーディングとは違って、誰かがクリックしたりリクエストを送ったりして確認できるユーザー向けの製品がないからね。巨大なエクセルドキュメントにテストスイートはあるのかな？多分ないと思うけど、間違ってるかもしれない。金融モデルみたいに、白黒の検証や正確性が少ない分野で働く人には、すごく難しいことになりそうだね。

お約束のxkcd: https://xkcd.com/1667/

ところが、AIを使うときは、自分でやるんじゃなくて、やってもらってる感じだよね。AIはツールじゃなくてサービスなんだ。昔、IBMが「エグゼクティブデータターミナル」を設計・構築したことがあったけど、私たちが理解するコンピュータターミナルとはちょっと違った。実際には、ビデオと双方向オーディオのフィードがあって、部下たちがいる部屋に接続されていて、エグゼクティブはビジネスデータや分析を頼むことができたんだ。それをコンピュータのディスプレイで呼び出して、エグゼクティブのオフィスにもルーティングされていた。この仕組みで、エグゼクティブは質問をして、情報に基づいた意思決定ができた。だから、エグゼクティブは何かをやってもらうのに慣れているから、AIがこの設定で「部下のチーム」を置き換えるのは理解できる。実際、もし私がそのCEOの椅子に座っていたら、LLMが言うことを信じる前に二度考えるし、その結果をダブルチェックするだろうね。たぶん、私の部下たちと一緒にね。Hackernewsで議論されているよ: https://news.ycombinator.com/item?id=42405462 IEEEの記事: https://spectrum.ieee.org/ibm-demo

「悪いエクセルシートが不況を引き起こした」から「悪い雰囲気の金融システムが不況を引き起こした」に変わってきてるね。

それでも、30シートのExcelファイナンシャルモデルをPythonに変換するClaude Codeは、元のものより大幅に悪くなることはないだろうね。笑わせてもらったよ。 :)

エクセルがどれだけ簡単にテストできるかによるね。ClaudeがエクセルとPythonを異なる入力で実行して、出力をチェックできるなら、ほぼ一発でできる可能性が高いよ。

401kがLLMを使って金融モデリングツールをいじってるアナリストに管理されてるって考えると、夜も眠れないって感じじゃない？

公平に言うと、彼はほぼワンショットと言ったんだ。まるで、ほぼ100%信頼できるCPUみたいで… それは、100万クロックサイクルごとに一度だけ失敗するってこと。

そうだね、私の普段の仕事では、多分20%くらいの生産性向上があるかな、正直言うと10%に近いかも。チーム全体の生産性には何も影響してない気がする。上司たちは小さな生産性向上を使ってPRの問題を直したり（何か見逃したときは本番でね）。でも先週は、実際の仕事がない日が二日あったから、組織を助けるCLIツールを作ったり、整理整頓をしたりしたんだ。AIのおかげで生産性が少なくとも200%、下手したら500%は上がったと思う。

企業ITの化石みたいなもんだけど、この視点と著者の意見に賛成だね。Hashicorp Packerのビルドファイルを急いで作る必要があったとき、VaultやTerraformのちょっとした経験しかなかったけど、ローカルAIがあれば一瞬で80%まで進められた。読んだり、編集したり、テストしたりできて、Packerの薄っぺらい「はじめに」ガイドよりもずっと早く進めたよ。結果的に、全くの前知識から1週間以内に堅牢なOSイメージと再現可能なパイプラインを作れた。逆に、チャットボットにGPOについて聞いたり、ネットワークファイアウォールやセグメンテーションルールを変更させたりするのは絶対に無理だね。企業の基盤である脆弱なシステムの中で自由に動かすなんて、絶対にダメだ。何かが存在すればするほど、チャットボットがそれを壊す可能性が高くなる。彼らはパターンマッチングと予測で訓練されているから、インフラが老朽化するのとは真逆なんだ。LLMがあってもそれは変わらないと思う。LLMは中小企業のITにおける私の一人軍団のセールスポイントには本当に革命的だね。

AIは、問題を考えすぎているときや、やらなきゃいけないことに着手するのが面倒なときに、すごく役立つと思う。解決策が、私の自然な過剰設計の傾向を抑えるのにも助けてくれるしね。ChatGPTにクイズを出してもらうのも楽しいよ。

約5000行のコードまでは素晴らしいけど、それを超えるともっと多くのガイダンスや注意深い監視、懐疑心、積極的なコンテキスト管理が必要になるね。気をつけて使えば、完全に脱線するのはたまにだけど、そのダメージは1時間か2時間のロスだけだよ。全体的には、まだ4倍の生産性向上があるから、月20ドルで文句はないかな。特に複雑なCの部分を管理するのが得意だから、シンボルのもつれよりも大きな視点に集中できるのがいいね。

これはどんなグリーンフィールドプロジェクトにも当てはまるんじゃない？生成モデルの有無に関わらず。最初の数日は驚くほど生産的だけど、その後は機能や修正がどんどん遅くなっていく。最初のアーキテクチャが現実の要件の変化に耐えられるかどうかで、自分がどれだけ優れたエンジニアかがわかるよね。そして、何かを出荷するまでに持ちこたえてくれることを願う。「それは週末に作れるよ」「プロジェクトの最初の80%は80%の時間がかかり、残りの20%は他の80%の時間がかかる」

誰でも何かの小さなバージョンを作れる そうだね。ソフトウェアを設計する時の一番の問題は、システムアーキテクチャやインフラの設計だね。AWSに全部押し込んで終わりっていうのには反対だよ。そこからは何も学べないし、クラウドのパフォーマンスは多くのことに対してイマイチだし、何かのインスタンスをうっかり動かしっぱなしにして、30万円の請求書が来るのは避けたいからね。AIは、怠け者の開発者のための解決策としてクラウドがあるから、シナリオXに最適なインフラを判断するのが苦手だよ。自己ホスティングの方法を勧めさせようとしたけど、それは一般的にセキュリティの危険があるだけだね。

私はこれを「day50問題」と呼んでいて、約1年前に名付けたんだ。それに対処するためのツールを作ってきた。7ヶ月前に日常の仕事を辞めて、フルタイムでやってるよ。https://github.com/day50-dev/ ブログを立ち上げようと思ってたんだけど… 本質的には、人間がやることとコンピュータが生み出すものの間にギャップがあるんだ。クラシックなコンパイラの設定では、これは開発ライフサイクル全体を通じて知られている安定した量なんだけど、AIコーディングの世界ではこの距離が増えていく。いろんな障壁があって、「コードデット」みたいなラベルがついてるところでラインが交差することがある。今は三つの緩和策がある。ラインを近づけて始める（PRDが今の流行の方法）、誰かがどれだけ気にするかのフロンティアを押し出す（これがTDDエージェントの方法）、曲線を曲げてあまり飛び出さないようにする（これが同僚の方法）。残念ながら、私は一人でやってるから、私が先に進んでいて、これを説明するためのモデルがあることには報酬がないんだ。だって、良いソフトウェアを作るのは難しいから… SFのイベントでこれを説明したことがあって（たぶん40〜50回くらい）、これを読んでる人の中には私から聞いたことがある人もいるかも… もしそうなら、こんにちは、もう一度ここにあるよ。

このスピードランは、コンテキストウィンドウで壁にぶつかる。プロジェクトが20万トークンに収まる限りは順調だけど、それを超えると生産性は20%下がるどころか、ゼロになる。エージェントに他のファイルで何を変えたかを説明するのに何時間もかかるようになる。大規模な組織が長期的に勝つのは、単一の脳、たとえ電子のものであっても、その記憶に依存しないプロセスに頼っているからだ。

ちょっとした反論だけど、新しいモデルやエージェントフレームワークを試すときは、古いオープンソースのGitリポジトリをコピーして、昔のプロジェクトや実験をやってる。で、新しいインフラが古いコードのリファクタリングやクリーンアップにどれだけ効果的かを見てるんだ。テストの後は古いプロジェクトを更新して、家の春掃除をしたときみたいな温かい気持ちになるよ。ゼロからグリーンフィールドのコードベースを作るのも好きだな。

ここでエンジニアリングのプラクティスが役立つんだ。私のチームの1.5年のデータに基づくと、成熟したシステム（約9年のコードベース）で約30%のパフォーマンス向上が見られるよ。面白いのは、LLMはレバレッジで、エンジニアが優れれば優れるほどLLMからの恩恵が大きくなるってこと。

力は尾にある。

それに加えて、いつスピードを落とすべきかも大事だよね。大企業で働いた経験から言うと、「セキュリティやコンプライアンスを損なわずにどうやって早くなるか」っていう質問にシフトすると思う。

これは一般的なスタートアップのアドバイスだね（真実じゃないってわけじゃないけど）。遅い方が早いっていう例を見つけると、少しレベルアップするよね（例：Teams vs Slack）。

同じ人がトピックや時間帯によって、両方のタイプのユーザーになることもあるよね。

会社が考えるエンジニアを求めていない、またはそれを負担できないってはっきり言ったから、仕事で考えることをアウトソーシングし始めたんだ。考えるには時間がかかるし、彼らは早く届けたいからね。だから、PMが設定した現実的な締切に合わせて動いてるんだよね。面白いことに、顧客によると機能はすぐに実装しなきゃいけないけど、顧客のフィードバックは、納品から6ヶ月後に新機能を使い始めるから、6ヶ月もかかる。もう気にしなくなったよ。学ぶ部分は休みの時にやるけど、業界全体に疲れてきたから、最低限の努力で請求書を払うだけ。だから、仕事で考えることをアウトソーシングしてるって感じだね。

考えることやスキル全体をアウトソーシングしている人 - 彼らはそのトピックについてほとんど理解していなくて、結果だけに興味があって、トピックについてもっと知りたいとかスキルを磨きたいとは思っていない それが特定のケースでは問題ないこともあるよね。僕はドイツ語を学んでいて、リスニングの理解力は微妙なんだ。練習テストを受けたら、15〜30秒の音声を聞いてから質問に答えるっていうのがあった。ひどい結果だったけど、練習には良さそうだった。Claude Codeを使って、短い音声（ElevenLabs経由）ダイアログと質問のセットを生成する小さなアプリを作ったんだ。結果をドイツ語の先生に見せたら、彼は感心してた。限界は理解してるよ：音声がイマイチなこともあるし（電話番号を間違えることが多い）、ドイツ語を学ぶための作業の一部にしかならないとかね。重要なのは、僕がコーディングできたけど、もっと重要なプロジェクトがあるってこと。コードについて学べなかったことは気にしてない。気にしてるのは、ドイツ語が上達してることなんだ。

第二のグループは、チャットボットと話すことでシニア開発者が置き換わると思ってるんだよね。一方、最初のグループは、これらのツールが開発者チーム全体を置き換えることができると考えてる。

まあ、あなたの分類の中で第二のグループはあまり真剣じゃないよね。AIツールを使って楽しむのは全然いいと思うし、その周りには数十億ドル規模のエンタメ産業ができるだろうね。私の経験から言うと、このグループに属していて、真剣なビジネスの決定をこういう方法でやろうとしてた人たちは、現実を見始めてる。私の視点では、違いは供給側にあって、AIツールには二つの世代がある。最初の世代は、ウェブUIでチャットボットと話すだけで、今でも使い道はある。チャットしながら文脈を作っていく感じで、トレーニングデータにかなり依存してる。多分、一つのファイルを読んでるだけ。第二の世代はRAGやエージェント機能に寄ってる（もし検索ができるなら、おめでとう、あなたはRAG戦略のv1を持ってる）。ここでGeminiは、私たちのGoogle Workspace内のドキュメントをスキャンして、以前書いた提案書に似たものを作成する。もうドキュメントテンプレートは必要ないのかな？新しいプログラミングプロジェクトを始めると、Claudeがすべてのボイラープレートを書いて、数分でベアボーンのテストスイートをセットアップしてくれる。こういうツールは新しい能力を与えてくれるし、場合によってはchatgpt.comにただおしゃべりするよりもずっと時間を節約できる。これが、まともなユーザーによる生産性の報告に大きな違いをもたらしてると思う。私は「第2世代」のアプリケーションを発見する前は、AIの生産性向上にはあまり熱心じゃなかった。

他の「ただのツール」じゃない代替案: * 検索エンジンの代わりに使う人たち。 * 医者やセラピスト、信頼できる相手として使う人たち。リサーチのためじゃなくて、実践者として。 他にも: * マンページやドキュメントの代わりに使う人たち。 * よく理解していないけど「なんとなく」短いスクリプトを書くために使う人たち。

第二のグループは、予算を持ち、5年計画を立てるような経営の意思決定者が多い。彼らを過小評価したり、嘲笑したりしないで。結局、私たち全員にとって不利益になるから。

一つ見落としてると思うよ。開発者が全体のシステムを作り上げて、出力についても理解しているっていうユーザーがいるんだ。開発者はアーキテクチャやコードの質、機能の質なんかをコントロールしてる。こういう人たちはまだまだ珍しいけど、実際に見たことがあるよ。彼らは新しい10倍の開発者だね。