2026年8月19日 SentryのSeerはtraceを読める。だからといつも根本原因を見つけるわけではない Seerはtrace tree、関連付けられたエラー、プロファイリングデータを取り込んで分散問題を診断する。実際にどう機能するか、どこで輝き、どこでまだ人間の助けを必要とするかを解説する。 statistical-debuggingsentryllmroot-cause-analysis
2026年8月15日 LLMはMetamorphic Relationsを提案できる。しかし保証はできない。 大規模言語モデルはtest oracleの発見において悪くないブレインストーミングパートナーだが、性質を幻覚し、ドメイン制約を見落とす。それらを、怪しいテストをリリースすることなく使う方法を解説する。 metamorphic-testingllmtest-oraclesai-engineering
2026年8月7日 LLMは静的解析の警告を優先順位付けできる。ただし、なぜかは説明できない 大規模言語モデルは静的解析の偽陽性の選別に役立つが、抽象解釈のようにプログラムの意味論を理解しているわけではない。両者を組み合わせる方法を解説する。 abstract-interpretationllmstatic-analysisfalse-positives
2026年7月28日 LLMはコードの正しさを証明できないが、証明のための定型作業は書ける クリーンルーム検証では、検証条件の生成と解消が必要である。ここでは、LLMがアノテーションとVC生成を自動化し、開発者が実際に難しい証明に集中できるようにする方法を説明する。 cleanroom-correctnessllmformal-proofsautomation
2026年7月21日 コードを先にLLMに説明したら、バグ率が85%減少した 30日間、LLMにコードを依頼する前に設計の説明を書き続けた。その結果は、私のrubber-duckingに対する考え方を変えた。 literate-programmingllmcode-qualityrubber-ducking
2026年7月19日 あなたのClaudeスレッドはすでにドキュメントです。ただ、12時間で消えてしまうだけ。 LLMの対話には意図、却下された代替案、そして動作するコードが含まれています。これこそがドキュメントであるべきものです。以下に、短寿命なチャットをナラティブを失うことなく、永続的で検索可能なドキュメントに変換する方法を説明します。 literate-programmingllmdocumentationai-engineering
2026年7月13日 大規模言語モデルはコードの事前査読はできる。会議を運営できない。 フェイガン査読は250行をレビューするのに4〜6人と2時間を要する。大規模言語モデルは準備作業とチェックリストの遵守を担うことでそのコストを削減できるが、最も高価な欠陥を見つける人間の役割は代替できない。 fagan-inspectionsllmcode-reviewai-engineering
2026年7月8日 LLMはRustコードを生成できる。形式的証明は全く別の問題だ。 大規模言語モデルは驚くほど質の高いRustコードを書くが、形式的証明を求めると、不変条件を幻覚で見つけ、どの検証器も受け付けない構文をでっち上げる。それらが実際に正しい部分、壊れる部分、それでも使う方法を解説する。 model-checkingllmrustformal-proofs
2026年7月2日 文法制約付きデコーディング: すべてのトークンでLLMに有効な構文を出力させる LLMはトークンを確率的にサンプリングするため、構文を幻覚させる。文法制約付きデコーディングは各ステップで語彙をフィルタリングし、構文的妥当性を保つトークンのみを出力する。 dsls-bounded-contextllmconstrained-generationgrammar
2026年7月1日 英語からテーマへの翻訳は簡単だ。決定論的にすることが本当の課題だ。 英語の平易な記述からデザイントークンを生成できるが、その記述をスキーマ契約とスナップショットテストを伴う限界付きコンテキストDSLとして扱う場合に限る。 dsls-bounded-contextdesign-systemsllmthemes
2026年6月13日 LLMの複数バリアントが異なる結果を出したら?どちらが正しい? 複数のLLMを並列実行すると、どの単一モデルも見逃すエラーを捕捉できる。実際に機能する不一致解決システムの構築方法を解説する。 n-version-programmingllmdifferential-testingdisagreement-resolution
2026年6月11日 同じLLMで関数を5通りに書ける。本当に異なる実装を引き出す方法。 LLMによるN-version programmingに複数のモデルは不要。プロンプト、ペルソナ、推論の制約を変えることで、単一モデルから多様で正しい実装を引き出せる。 n-version-programmingllmdiverse-implementationsai-engineering