検証スペクトラム：AIコーディングがバックエンドで最も効果的な理由
AIコーディングは検証の勾配に従う。バックエンドはミリ秒で検証し、Webは数分、モバイルは数時間かかる。フィードバックループがAIコーディングの有効範囲を決める。
AIモデルが単独でコードを書くこと自体は、興味深い部分ではない。興味深いのは、コードを生成した後に何が起こるかだ。モデルはどれだけ速くコードの正しさを知ることができるか？生成と検証の間のフィードバックループはどれだけ緊密か？…
ai-engineering
11 posts
恐怖か驀進か：AIコーディングが分ける二つの現実
AIコーディングが機能するのは、どんな混乱からも立ち直れるエリートチームだけ。それ以外に残るのは恐怖とCI失敗と放棄された実験。格差の本質はモデルではない。
同じAIモデルを使う二つのチームを観察すれば、まったく異なる二つの結果を目にするだろう。…
本番環境でのAIコーディング：ほとんどのチームが挫折する理由
ほとんどのチームはAIコーディングを試し、QAに不合格になるコードをリリースし、そして諦める。問題はモデルではない——AIの出力を信頼できるものにするガードレールの欠如だ。
AIコーディングを試すほとんどのチームは、同じ軌跡をたどる。 最初は興奮している。モデルが数分で機能を生成し、それをリリースする。QAがバグを見つけ、修正をリリースする。QAがさらに別のバグを見つける。今度は無関係であるはずの別のmoduleだ。修正は14ファイルに及び、QAはさらに3つの問題を発見する。…
Fuck-u-code: AIパイプラインが見落としていた Deterministic 品質ゲート
型チェック、lint、設計ルールはある。でも deterministic スタックは複雑性、重複、命名の惨状を見抜けない。$0で解決する方法を紹介する。
今のAIコードパイプラインの実態を正直に見てみよう。 Cursor や Claude Code でコードを生成する。TypeScript の strict モードが型の不一致を捕捉するから、 を実行する。ESLint…
バージョン1は決して問題ではない：AIコーディングと長期保守
AIコーディングツールはバージョン1の生成に優れている。本当のエンジニアリング上の課題はバージョン4から始まる — チームが他のすべてを壊さずに何かを変更する必要が出たときだ。
すべてのAIコーディングデモは同じ流れをたどる。誰かがモデルにプロンプトする。動くアプリが現れる。聴衆は感心する。 当然そうなるべきだ。速度は本物だ。能力は本物だ。バージョン1はAIがループに入ることで確実に速く出荷される。 問題は、バージョン1は決して難しい部分ではなかったということだ。…
AI生成コードと置換可能性の原則
AI生成コードの品質を測る真の基準は、初日に動くかどうかではない。30日目に他のすべてをrewriteせずにそのコードを置換できるかどうかだ。
AI生成コードの品質に関する議論の多くは、生成時点での正確性に焦点を当てている。出力はコンパイルできるか？テストに通るか？仕様に合致するか？ これらは最低限の条件にすぎない。本当のコストについては何も教えてくれない。…
AI Codebaseのための決定的ガードレール
人間のレビューは一貫性がない。AIレビューはさらに悪い。AI生成codebaseに対するスケーラブルな唯一の防御は決定的enforcement — 無視される提案ではなく、ビルドを失敗させるルールだ。
AI生成コードに対する標準的なアドバイスは「注意深くレビューせよ」だ。 このアドバイスは正しいが、スケールにおいては無意味だ。 AI出力をレビューする開発者は、注意力があり、ドメインに精通し、時間的プレッシャーがないときに問題を発見する。それ以外のすべての条件 — つまり大半の条件 — では、見落としが発生する。…
AI時代、コードレビューは仕様レビューになる
AI が仕様から実装、テスト、contracts まで生成できるようになると、人間が最も大きなレバレッジを発揮する仕事は上流へ移る。最も厳しく吟味すべきものは、仕様そのものだ。
AI と一緒に数週間でもリリースを回していれば、この感覚にはもう覚えがあるはずです。 PR を開く。コードは十分きれいだ。命名も悪くない。テストもある。見た目には明らかな破綻はない。なのに、どこかがおかしい。 境界が少し曖昧なのかもしれない。contract…
AI Safety Stack: types、contracts、property tests、mutation gates
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 coding を正しく見ている。足りない科目はアーキテクチャだ
Stanford CS146S を AIアーキテクチャの観点からレビューし、AI coding への評価は正しい一方で、置き換え可能性を支える設計規律が欠けている点を批評します。
Stanford CS146S は、正式には CS146S: The Modern Software Developer という授業です。担当は Mihail Eric で、2025年秋に初めて開講されたコースです。授業の公式な概要や syllabus の確認には themodernsoftware.dev…
優れたエンジニアリングの考え方が AI で経済的になるまでニッチのままだった理由
Design by contract、property-based testing、mutation testing、model checking は悪い考え方だったわけではありません。継続運用に必要な専門知が重すぎただけです。AI はその前提を変えます。
ソフトウェアエンジニアリングには、読んだ瞬間に「これは正しい」と分かる考え方がたくさんあります。 function が受け取ってよい値と返してよい値を contracts で定義するのは当然です。tests が数個の例だけでなく properties を検証するのも当然です。coverage…