20件の記事が見つかりました
seekseep氏は「エージェントが読む前提でGit履歴を書く」パターンを紹介する。だがgit logが記録できるのは選んだ道だけで、選ばなかった道は書き手が意識して残さない限り消える。この非対称性を自社のコミット履歴で確かめる。
jodycraft氏は「グラフの配線より、各エッジの判定関数の精度が本質」と指摘し、過去の誤判定を記録して次の判定基準へ反映する仕組みを提案する。ParryのSweep・rejectedAlternativesは、この仕組みとして本当に機能しているか。
LayerXのuphy氏は個人タスク管理を「判断は人間・更新はエージェント・計算はスクリプト」の三分法で再設計した。Parryはこの三分法のどこを担っているのか、担っていない部分で何が起きるのかを、自社の事故から検証する。
ナレッジセンス社の「地図は現地ではない」という整理は、AIへの指示の不確実性を4象限に分ける。だが4象限のうち「未知の未知」だけは、フォームを用意しても書けない。それを書けるように変えるのは何か。
Claude Codeを6セッション並列で走らせるターミナルを自作したIsamu氏は、1日500コミットを達成した。だがボトルネックは消えず、手を動かす速度からGitHubへの取り込み速度へ移っただけだった。
gingerBill氏の「良いツールは見えなくなる」という主張は、コードレビューにも当てはまる。丁寧に書き込むレビューがくれる達成感と、レビューが実際に機能しているかどうかは、別の軸である。
化学論文の査読で、AIを使ったとみられる査読者が存在しないデータを批判した事例がある。書く側にAIを置くのと、確認する側にAIを置くのとでは、事故の起き方が違う。
文章で決めただけの約束は、破られてもエラーにならない。kamo78氏のガード設計論から、PRの説明欄を散文のままにしておくことの脆さと、人間が最後に全部確認する設計の限界を考える。
DDDのユビキタス言語が組織で定着しないのは、辞書として固定しようとするからだ。ドメインが発見し続けるものであるように、PRのWhyもテンプレートに固定した瞬間から形骸化が始まる。
MIXIの松谷峰生氏が指摘する「AIにテストケースを作らせると、なぜ必要かを追えなくなる」問題は、PRレビューでコードの意図が消える問題と同じ構造を持つ。
ログラスCTOの「動くだけのその先へ」は、仕様の正しさをハーネスと三層構造で担保する。だが仕様が正しくても、複数ある実装のどれを選んだかという理由は、その三層のどこにも残らない。
「透明性を高めよう」という抽象目標がなぜ施策を際限なく増やし、止められなくなるのか。しんざき氏の報告とParryのWhy/Risk軸から検証する。
まつもとゆきひろ氏が語る「コード生成のコモディティ化」は、Parryが要求するWhy欄の世界観を先取りしていた。自分のブログ執筆を一次データに、上流シフトの実像を検証する。
DMM.comの可観測性成熟度モデルは評価基準をCSVでGit管理している。実際のコミットを見ると、変わった箇所は残っても、その基準を選んだ理由は残っていなかった。
士業がAIを使う場面で必要なのは答えの速さではなく「誰が何を確認したか」の記録だ。窓の杜の実録記事とblog-prod-postsのfrontmatter設計を並べて検証する。
GitHub公式のStacked PRs公開プレビューが認めたPRレビューのボトルネックを起点に、構造の分解と意図の記録は別問題だと検証する。
Anthropicの新機能「Advisor tool」は判断と実行を分離し、コスト63%で性能92%を保った。数字の不釣り合いさから、Parry自身のdraft/directモード設計にも同じ構造があることに気づいた話。
意図負債という言葉は、1985年のNaurの論文まで遡れる。t-wadaの資料と、blog-prod-posts自身の一次データから、その系譜と実在を検証する。
AGPLを選べば守れると思っていた。でも、LLMがコードを読んで「意味的に等価な別実装」を生成できる時代に、コピーレフトは何を守っているのか。
PRテンプレートに「なぜ」欄を追加する運用は、多くのチームが一度は試して失敗している。実際に公開されている失敗事例2件から、崩壊のパターンを分解し、なぜ善意の運用が構造的に続かないのかを整理する。