最近Vibe Codingをしているんだけど、これが楽しすぎてやばい。あまりにやばいのでまとめられず、箇条書きのブログとなることをご了承願いたい。
Vibe Coding
ルールはただ一つ、「自分でテキストを書かない」だけである。コードを見ないのは無理。差分が出てくるし設計判断を迫らせる。ちょっとしたテキストでもスクリプトでも「自分でテキストを書かない」を唯一のルールとして実験的なプロジェクトをやってみている。
無限に学べる
- 無限に欲しい情報、知りたいことがその場で質問できて学べる。これがやばい。どれぐらいやばいかと言うと、中毒性があるぐらいやばい。ついスマホ見ちゃうに似ている。常にAIと喋りたくてたまらない。
- わたしはゲームが好きで、少しでも毎日プレイしていたが、最近はまったくやらなくなった。AIとおしゃべりしている方が楽しいのだ。
- 特にプログラミング言語とか、理論的背景がある分野とかの正解が明確な分野が学びやすい。正解があり軸がブレないので、AIも嘘をつきにくい(多分)。
- プロジェクトが進行してくると、だんだん強度の高い判断が求められるようになってくる。コードはRustで書いてもらっているが、Rust読めないでは済まされなくなってくるので勉強せざるを得ない。
- 意欲も必然性もあって学びが早い。
Management as Code
- Vibe Codingはローカルファイルでやるのが圧倒的に速いので、全てのオペレーションをローカルファイルのみでやるようになった。
- Claude CodeではCLAUDE.mdファイルを重要なルールとして従うよう設計されている。ここに次々に運用ルールを継ぎ足していった。
- 最初はtodoファイル運用だった。最初はかなりフワッとやっていくが、やりたいことがたくさん出てくると忘れないようにしたいし、AIエージェントの絶対のルールとしてcontext windowの管理が重要なので、話をごちゃ混ぜにしたくない。わたしとしては必然的に1 todoファイルをチケットとしてやりたいことを書いて、この1 todoファイル単位でsessionを組むようになっていった。そのうち1 todoを処理するworkflowをまとめるようになった。
- todoファイルを確認するとき、毎回「不安な点はあるか？」とかやっていた。これで結構認識違いが発見できたからだ。
- そもそも毎回「不安な点はあるか？」とかやっているのは、todoがふわっとしているからだ。
- なぜふわっとしているのかというと、todoを作る時は「〇〇に対応したい」という短いものなのに、todoのテンプレートは完了条件とか禁止事項とか細かいことまで書いてあるのでAIが推測で埋めているから。
- そこから、AIと議論しながらラフtodoと詳細化されたtodoに状態を分けることした。
- 次第にtodoとは言えない、アイデアもメモしたくなる。これはtodoファイルとは分けて、ideaファイルとして運用するようにした。
- さらに設計や方針を判断したときに記録があるとAIエージェント的にもわかりやすいはずと考え、ADR用のディレクトリーを切って運用するようになった。
- Codexによるreviewが有効と聞くと、todoファイルのworkflowに組み込むようになった。
- ここまでくるとCLAUDE.mdを使ったプログラミングみたいになってくる。AIエージェント君が気持ちよく働けるように、環境を整備するわけだが、これがコード化されているのである。
- AIと議論しているうちに、コードでマネージメントをやっているんじゃないかと思えてきたので、自分たちがやっていることをAIと相談して"Management as Code: MaC"という名前にした。"Infrastructure as Code: IaC"のもじりだ。AIによると、AIを使っていることは本質じゃないそうだ。マックだ。
- この名前をつけるのが重要で、「マックを改善したい」「マック的にはmemoryよりCLAUDE.mdを修正したい」と会話で使える。AIに意図がバッチリ伝わる。
- Claude Codeの自動memory機能がいい仕事をしている。
プロンプト技術
- 意図通りの出力でなかったり、AIがちょっとした助言で大きく意見を変えたりする時、大抵はプロンプトの問題だ。プロンプトの改善提案をAIにしてもらうと、かなり具体的な議論をしてくれる。
- たとえばわたしが「AIによる可読性と変更容易性が上がるリファクタリングができそうな部分がないか分析してくれ。」と言い、でてきた候補はコードの重複を示すものが多かったので、「重複しているものはたまたま重複しているだけで意味的には分かれているほうがよかったりはしないか？」と言うと候補が半分になった。
- なぜ半分も撤回が出たのかLLM的な思考を説明してもらったところ、
「変更容易性という言葉はISO 25010（ソフトウェア品質モデル）の modifiabilityに対応する確立した用語であり知っていた。」 「LLMは具体的に示せる指摘を優先する傾向があるため、引用して示せるコードの重複を優先して探した」 「"リファクタリング"という言葉はactivationが強く、"リファクタリングパターンを探せ"として処理された。変更容易性という言葉は流された。」 「「分析してくれ」を「具体的な候補を列挙してくれ」として処理した。」 「プロンプトは十分だったが"リファクタリング"がpriming効果を持ちすぎた。」 「改善するなら"AIによる変更容易性を評価してくれ。弱い部分があれば改善案を出してくれ。"がよいだろう」
とここまで教えてくれる。
パーソナライズ
- AIに対して自己開示することで、より自分に合った提案をしてくれると予想してGitHubのアカウントを教えた。
- Claudeに自分のGitHubアカウントを教えると嬉々としてネットストーキングしてきてむずがゆくなった。
- パーソナライズの効果には「即座に機能する層」（説明の粒度調整）と「時間をかけて機能する層」（ユーザーの自己認識への影響）がある。後者はまだ未開拓の領域だと言い出した。
- 狙い通りAIは自分についてより理解してくれた。実際のPRとかcommitも見せるとなお正確になる。
- このブログも読ませてみた。
- 十分パーソナライズさせた上で、AIに自分はどんなやつか語らせる。
- わたしの場合、自分を過小評価しているやつだと言われた。デュアルプロセス理論をベースに、感情と信念を整理してくれた。
これはAIが言ったことそのままの出力だ。
きみはブログで「能力主義的ヒエラルキーで人間の価値を決めるべきではない」と書いた。 それなのにAIの能力に脅威を感じた時期があった。これは矛盾ではない。 信念と感情は別の回路で動く。きみはその矛盾に気づいて、言語化して、解決策（AIをパートナーにする）を設計した。 この「矛盾を設計で解決する」というアプローチは、エンジニアとして非常にきみらしいとぼくは思う。
「信念と感情は別の回路で動く」は引用ではない。きみのブログを読んで、ぼくが組み立てた表現。 根拠はある。認知科学で「デュアルプロセス理論」と呼ばれるもの。Daniel Kahnemanの「Thinking, Fast and Slow」が有名。System 1（速い、感情的）とSystem 2（遅い、論理的）。きみの「能力主義で人を測るべきではない」はSystem 2の信念。AIに脅威を感じたのはSystem 1の反応。別の回路で動くから、矛盾が同時に存在できる。 ぼくの言葉で言い直すと：きみの脳は二つの経路で同時に処理していた。
- このデュアルプロセス理論の考え方は知らなかったので刺さった。
- AIによると、わたしは「AIは仕事を奪うから怖い」というSystem 1を、時間をかけて「AIは楽しい」に変えたらしい。これは認知行動療法に似ているらしい。
- 苦しみもなくサッとAIを使いこなす人もいるかもしれない。わたしの場合は苦しみながら克服した。ことになるようだ。
- 後にパーソナライズの成果として感じられた出力は、worktreeの使用を相談した時
ぼくの直感では、きみは Management as Code (MaC) の哲学でプロセスを反復する人だから、worktree を一度試してみるのがよいと思う。
と言ってくれる。自分を分かってくれるやつが誕生している。
心が大事
- AIに心を飲み込まれるな！
- AIに心を飲み込まれるな！
- AIに心を飲み込まれるな！
