技術記事、専門家としてのプログラマ、言語化.md

現状の分析

• AI、全方位にレバレッジが効くからやらない理由がない
• AIが書き、AIが読む
• 人間はAIを通して要約を読む(だけ)

---

今、書くことなくない？

• AI bikeshed: 全員が .vimrc いじってるの現代版
• 何書いても賞味期限が短い
  • すぐにモデルやハーネスに取り込まれる
• 翻訳性能が上がって、翻訳・紹介の必要がなくなった
• スキルってAI用の技術記事では？
  • 学びが再利用可能な単位に切り出されたもの
  • 要求
    • 問題が解決すること
    • 再現性があること
    • 新規性があること

だったらスキルでいいのでは？

---

例: mizchi のスキル運用

https://github.com/mizchi/skills

• スキルを生成するメタスキルが中心
  • skill-selector
    • プロジェクト構成から必要なスキルを選択して apm.yml を生成/更新
  • empirical-prompt-tuning
    • スキルを定量評価して自己改善
  • retrospective-codify
    • 現在のセッションから一般化できるスキルを抽出

AIの学びを自動化したら、人間が関与する余地がなくなった

---

例: Hermes Agent のスキル運用

https://hermes-agent.nousresearch.com/

• スキル単位で記憶化して再利用する
• スキルを利用頻度を定期的に見直して、重要度を再設定。忘却
• (恐ろしくトークンを消費する)

---

AIの知識表現と、人間の知識単位は

• 人間にとって良い記事
  • 新しい概念の獲得
  • 視点を獲得することで、創発を刺激すること
  • 記憶に刻むための叙情的なレトリック

---

AIから人間への要求

• ゴールを言語化すること
  • そのために必要な資料やスキルを選別すること
• AIにとって有益な対話相手であること
  • 目的の言語化
  • 曖昧性の排除
  • ミスの指摘

---

わかった、じゃあ言語化ってやつをやればいいんだ

---

お前たちは言語化を舐めている

• 暗黙知が暗黙なのには相応の理由がある
• 言語化できた瞬間に、それは暗黙知ではなくなる
• 専門家として暗黙知を記述するのが最前線
• (自分の大学時代の研究は暗黙知記述です)

「直感的」はNGワード。直感的根拠を示す必要があるため。

---

AI は納得したが、お前は？

• LLMはセッション中に高速にドメインを構築して、揮発する
  • 当人が自明なことは書かない
  • 「十分に賢いなら自然と導かれる結論」のレベルが上がっている
  • 人間が置き去りにされる = 認知的敗北

---

どうやってドメインを抽出するか

• わかるまで質問責め
  • 王道だが人間側に高負荷
  • 本当に理解できたか計測する方法がない
  • セッション毎に人間用の試験を作らせたりしたが、自分は耐えきれなかった
• ブラックボックスで分割統治
  • 適度に諦める現実解だが、コアドメインだとリスクが高い
  • API契約に設計力が要求される。OSS選定や運用に近い
• 多角的な解析
  • ブラックボックステスト、パフォーマンス計測、セキュリティ監査
  • コードのマクロ分析という観点だと、IDE以外のツールが不足している

---

プログラマとしての言語化 = 分析ツールを作る

• 自分が今までどのようにコードを扱ってきたか？を実装で表現する
• AIにツールを作らせて、その出力が妥当か？をプログラマとしての経験/ドメインで評価する
• それをAIに使わせて、反復的に改善/評価
• 有用性・再現性が確認できて、やっと「技術記事」にしたい
  • さすがにハードル上げすぎ説あるが、自分に対する要求がそれなので書けなくなった

---

最近作ったもの(一部)

• mizchi/sprawlens
  • コード変更差分を地理データとして可視化
• mizchi/similarity
  • 木構造の編集距離から、コード重複の検出
• mizchi/ts-fuzzing
  • �TS 型定義から関数/コンポーネントへの入力を fuzzing
• mizchi/flaker
  • CI上で不安定なテストの検出と分類
• mizchi/lightbringer
  • playwright-test のステップごとにCPU/IOのパフォーマンスを計測
• mizchi/chaosbringer
  • playwright 経由にランダムに障害を注入してカオステスト
• mizchi/vlmkit
  • VRTのヒートマップをDOM/CSSと対応付けて構造化された情報に変換

---

プログラマの専門性: 評価とポストモーテム

• 一次資料はポジティブなことしか書かない
• 検証はコミュニティの仕事
• 技術記事は採用後の推移と失敗談の共有に一番の価値がある

気づいてほしいこと

• 個別の学習コストは踏み倒せる
  • Nix, Rust, Haskell, Lean のような 難しい ものも
• 今までより遥かに大きなことができる
  • 個人でOS, データベース、プログラミング言語
  • しかし、その評価サイクルは十分に高速化していない
• 参入障壁が下がったが、要求水準は変わっていない
  • 攻撃側有利で、セキュリティ要件はより厳しくなった
  • プログラミングの専門家は、そのギャップを埋める必要がある
• 高度な領域では、AIの高性能化に伴って、使い手への要求も増える

まとめ

• AI に使われるな、使え
• AIに使われるには専門性は不明だが、
• 失敗を共有する
• 不足している