2026年8月15日 LLMはMetamorphic Relationsを提案できる。しかし保証はできない。 大規模言語モデルはtest oracleの発見において悪くないブレインストーミングパートナーだが、性質を幻覚し、ドメイン制約を見落とす。それらを、怪しいテストをリリースすることなく使う方法を解説する。 metamorphic-testingllmtest-oraclesai-engineering
2026年7月19日 あなたのClaudeスレッドはすでにドキュメントです。ただ、12時間で消えてしまうだけ。 LLMの対話には意図、却下された代替案、そして動作するコードが含まれています。これこそがドキュメントであるべきものです。以下に、短寿命なチャットをナラティブを失うことなく、永続的で検索可能なドキュメントに変換する方法を説明します。 literate-programmingllmdocumentationai-engineering
2026年7月13日 大規模言語モデルはコードの事前査読はできる。会議を運営できない。 フェイガン査読は250行をレビューするのに4〜6人と2時間を要する。大規模言語モデルは準備作業とチェックリストの遵守を担うことでそのコストを削減できるが、最も高価な欠陥を見つける人間の役割は代替できない。 fagan-inspectionsllmcode-reviewai-engineering
2026年6月12日 5つの実装と多数派なし：実際に最良のものを選ぶ方法 N-version programmingは単純に聞こえる。複数の実装を実行して最良の答えを選ぶ。しかし実際には、「最良」を定義することは「最も一般的」を定義するよりはるかに難しい。 n-version-programmingimplementation-selectiondifferential-testingai-engineering
2026年6月11日 同じLLMで関数を5通りに書ける。本当に異なる実装を引き出す方法。 LLMによるN-version programmingに複数のモデルは不要。プロンプト、ペルソナ、推論の制約を変えることで、単一モデルから多様で正しい実装を引き出せる。 n-version-programmingllmdiverse-implementationsai-engineering
2026年5月27日 検証スペクトラム：AIコーディングがバックエンドで最も効果的な理由 AIコーディングは検証の勾配に従う。バックエンドはミリ秒で検証し、Webは数分、モバイルは数時間かかる。フィードバックループがAIコーディングの有効範囲を決める。 ai-engineeringbackendwebmobilevalidationai-codebase
2026年5月26日 恐怖か驀進か：AIコーディングが分ける二つの現実 AIコーディングが機能するのは、どんな混乱からも立ち直れるエリートチームだけ。それ以外に残るのは恐怖とCI失敗と放棄された実験。格差の本質はモデルではない。 ai-engineeringsoftware-architectureproductionai-codebaseteam-dynamics
2026年5月24日 本番環境でのAIコーディング：ほとんどのチームが挫折する理由 ほとんどのチームはAIコーディングを試し、QAに不合格になるコードをリリースし、そして諦める。問題はモデルではない——AIの出力を信頼できるものにするガードレールの欠如だ。 ai-engineeringsoftware-architectureproductionautotomyai-codebasebest-practices
2026年5月23日 Fuck-u-code: AIパイプラインが見落としていた Deterministic 品質ゲート 型チェック、lint、設計ルールはある。でも deterministic スタックは複雑性、重複、命名の惨状を見抜けない。$0で解決する方法を紹介する。 ai-engineeringdeterministicguardrailscode-qualitystatic-analysisci
2026年5月22日 バージョン1は決して問題ではない：AIコーディングと長期保守 AIコーディングツールはバージョン1の生成に優れている。本当のエンジニアリング上の課題はバージョン4から始まる — チームが他のすべてを壊さずに何かを変更する必要が出たときだ。 ai-engineeringsoftware-architecturerefactoringai-codebaselong-term-maintenance
2026年5月22日 AI生成コードと置換可能性の原則 AI生成コードの品質を測る真の基準は、初日に動くかどうかではない。30日目に他のすべてをrewriteせずにそのコードを置換できるかどうかだ。 ai-engineeringsoftware-architecturereplaceabilityai-generated-codemaintainability
2026年5月22日 AI Codebaseのための決定的ガードレール 人間のレビューは一貫性がない。AIレビューはさらに悪い。AI生成codebaseに対するスケーラブルな唯一の防御は決定的enforcement — 無視される提案ではなく、ビルドを失敗させるルールだ。 ai-engineeringsoftware-architectureguardrailssemgrepci-cdcode-review-automation
2026年5月17日 AI時代、コードレビューは仕様レビューになる AI が仕様から実装、テスト、contracts まで生成できるようになると、人間が最も大きなレバレッジを発揮する仕事は上流へ移る。最も厳しく吟味すべきものは、仕様そのものだ。 ai-engineeringcode-reviewspecificationsliving-specificationsci
2026年5月16日 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-engineeringsafety-stacktypesdesign-by-contractproperty-based-testingmutation-testing
2026年5月16日 Stanford CS146S は AI coding を正しく見ている。足りない科目はアーキテクチャだ Stanford CS146S を AIアーキテクチャの観点からレビューし、AI coding への評価は正しい一方で、置き換え可能性を支える設計規律が欠けている点を批評します。 ai-engineeringsoftware-architecturestanfordcs146sguardrailsagentic-development
2026年5月15日 優れたエンジニアリングの考え方が AI で経済的になるまでニッチのままだった理由 Design by contract、property-based testing、mutation testing、model checking は悪い考え方だったわけではありません。継続運用に必要な専門知が重すぎただけです。AI はその前提を変えます。 ai-engineeringsoftware-reliabilitydesign-by-contractproperty-based-testingmutation-testing
