15 posts
LLMの対話には意図、却下された代替案、そして動作するコードが含まれています。これこそがドキュメントであるべきものです。以下に、短寿命なチャットをナラティブを失うことなく、永続的で検索可能なドキュメントに変換する方法を説明します。
あなたはClaudeと45分かけてリトライ回路を設計しました。失敗モードを説明し、カスケード圧力を隠してしまうため指数関数的バックオフを却下し、jitter付きtoken-bucket rate limitingで決着し、動作する実装を生成しました。説明は明快で、推論は妥当であり、コードは実際にテストをパスしました。…
フェイガン査読は250行をレビューするのに4〜6人と2時間を要する。大規模言語モデルは準備作業とチェックリストの遵守を担うことでそのコストを削減できるが、最も高価な欠陥を見つける人間の役割は代替できない。
本格的なフェイガン査読には、進行役、読み手、2〜4人の査読者、そして著者が必要だ。チームは1時間あたり125行のペースで、おおむね250行のコードを2時間かけてレビューする。小さな変更でも、8〜12人時の工数がかかるのだ。…
N-version programmingは単純に聞こえる。複数の実装を実行して最良の答えを選ぶ。しかし実際には、「最良」を定義することは「最も一般的」を定義するよりはるかに難しい。
同じ関数の5つの実装がある。3つは同じ結果を返す。1つは少し違う。1つは例外を投げる。どれが正しい？ ほとんどのチームは多数決をデフォルトにする。出力が同一でエラーが明らかな場合はうまくいく。しかし、実装が微妙に異なる場合や、すべてのバリアントが異なる答えを返す場合、それは崩壊する。N-version…
LLMによるN-version programmingに複数のモデルは不要。プロンプト、ペルソナ、推論の制約を変えることで、単一モデルから多様で正しい実装を引き出せる。
N-version programmingでは、多様性は異なる作成者から生まれるものだと想定されている。LLMの場合、それは異なるモデル、異なるプロバイダー、あるいは異なる学習実行を意味する。だがこの前提は間違っている。同じモデルから、問う内容ではなく問い方を変えることで、意味のある多様性を得られる。…
AIコーディングは検証の勾配に従う。バックエンドはミリ秒で検証し、Webは数分、モバイルは数時間かかる。フィードバックループがAIコーディングの有効範囲を決める。
AIモデルが単独でコードを書くこと自体は、興味深い部分ではない。興味深いのは、コードを生成した後に何が起こるかだ。モデルはどれだけ速くコードの正しさを知ることができるか？生成と検証の間のフィードバックループはどれだけ緊密か？…
AIコーディングが機能するのは、どんな混乱からも立ち直れるエリートチームだけ。それ以外に残るのは恐怖とCI失敗と放棄された実験。格差の本質はモデルではない。
同じAIモデルを使う二つのチームを観察すれば、まったく異なる二つの結果を目にするだろう。…
ほとんどのチームはAIコーディングを試し、QAに不合格になるコードをリリースし、そして諦める。問題はモデルではない——AIの出力を信頼できるものにするガードレールの欠如だ。
AIコーディングを試すほとんどのチームは、同じ軌跡をたどる。 最初は興奮している。モデルが数分で機能を生成し、それをリリースする。QAがバグを見つけ、修正をリリースする。QAがさらに別のバグを見つける。今度は無関係であるはずの別のmoduleだ。修正は14ファイルに及び、QAはさらに3つの問題を発見する。…
型チェック、lint、設計ルールはある。でも deterministic スタックは複雑性、重複、命名の惨状を見抜けない。$0で解決する方法を紹介する。
今のAIコードパイプラインの実態を正直に見てみよう。 Cursor や Claude Code でコードを生成する。TypeScript の strict モードが型の不一致を捕捉するから、 を実行する。ESLint…
AIコーディングツールはバージョン1の生成に優れている。本当のエンジニアリング上の課題はバージョン4から始まる — チームが他のすべてを壊さずに何かを変更する必要が出たときだ。
すべてのAIコーディングデモは同じ流れをたどる。誰かがモデルにプロンプトする。動くアプリが現れる。聴衆は感心する。 当然そうなるべきだ。速度は本物だ。能力は本物だ。バージョン1はAIがループに入ることで確実に速く出荷される。 問題は、バージョン1は決して難しい部分ではなかったということだ。…
AI生成コードの品質を測る真の基準は、初日に動くかどうかではない。30日目に他のすべてをrewriteせずにそのコードを置換できるかどうかだ。
AI生成コードの品質に関する議論の多くは、生成時点での正確性に焦点を当てている。出力はコンパイルできるか？テストに通るか？仕様に合致するか？ これらは最低限の条件にすぎない。本当のコストについては何も教えてくれない。…
人間のレビューは一貫性がない。AIレビューはさらに悪い。AI生成codebaseに対するスケーラブルな唯一の防御は決定的enforcement — 無視される提案ではなく、ビルドを失敗させるルールだ。
AI生成コードに対する標準的なアドバイスは「注意深くレビューせよ」だ。 このアドバイスは正しいが、スケールにおいては無意味だ。 AI出力をレビューする開発者は、注意力があり、ドメインに精通し、時間的プレッシャーがないときに問題を発見する。それ以外のすべての条件 — つまり大半の条件 — では、見落としが発生する。…
AI が仕様から実装、テスト、contracts まで生成できるようになると、人間が最も大きなレバレッジを発揮する仕事は上流へ移る。最も厳しく吟味すべきものは、仕様そのものだ。
AI と一緒に数週間でもリリースを回していれば、この感覚にはもう覚えがあるはずです。 PR を開く。コードは十分きれいだ。命名も悪くない。テストもある。見た目には明らかな破綻はない。なのに、どこかがおかしい。 境界が少し曖昧なのかもしれない。contract…
AI-generated code を production で持たせたいなら、code review だけでは足りません。type constraints から mutation testing、runtime containment までの layered safety stack が必要です。
AI-generated code の危険なところは、常に間違っていることではありません。 危険なのは、merge できてしまう程度には正しく見えることです。 そこが本当のリスクです。明らかに壊れている code は止まります。もっともらしく見え、いくつかの happy-path tests を通り、しかも重要な…
Stanford CS146S を AIアーキテクチャの観点からレビューし、AI coding への評価は正しい一方で、置き換え可能性を支える設計規律が欠けている点を批評します。
Stanford CS146S は、正式には CS146S: The Modern Software Developer という授業です。担当は Mihail Eric で、2025年秋に初めて開講されたコースです。授業の公式な概要や syllabus の確認には themodernsoftware.dev…
Design by contract、property-based testing、mutation testing、model checking は悪い考え方だったわけではありません。継続運用に必要な専門知が重すぎただけです。AI はその前提を変えます。
ソフトウェアエンジニアリングには、読んだ瞬間に「これは正しい」と分かる考え方がたくさんあります。 function が受け取ってよい値と返してよい値を contracts で定義するのは当然です。tests が数個の例だけでなく properties を検証するのも当然です。coverage…