拡張コーディング: バイブを超えて
(stdy.blog)- ケント・ベックが最近、拡張コーディング: バイブを超えて(Augmented Coding: Beyond the Vibes) という文章を執筆
- ケント・ベック自身がAIの助けを借りて、高性能で本番レベルに近いB+ Treeライブラリ(BPlusTree3)をRustとPythonで書いたストーリー
- 特に有用で洞察的だった3つのポイントを要約・翻訳して紹介
拡張コーディングはバイブコーディングと何が違うのか?
- バイブコーディングではコードは気にせず、システムの動作だけを気にする。エラーがあれば「こういうエラーがある」と伝え、直してくれることを期待する
- 拡張コーディングではコードを気にする。コードの複雑さ、テスト、テストカバレッジが重要
- 拡張コーディングでは従来のコーディングと同様に "Tidy Code That Works"、つまり「動く整ったコード」を重視する。以前ほど多くタイピングしないだけ
AIがうまくいっていない3つの兆候
拡張コーディングではAIの中間結果を観察し、次の3つの兆候が現れていないかを見て介入することが重要
- 似たような挙動を繰り返す（無限ループなど）
- 自分が頼んでいない機能を実装する。それが論理的な次のステップであったとしても
- テストを削除したり無効化したりするなど、AIがごまかしていると感じられるそのほかすべての兆候
TDDを助けるシステムプロンプト
- 元記事本文はコピーしにくかったのでgistに入れてある
- 最後にあるRust構文だけ自分のプログラミング言語/フレームワークに合わせて変えれば、どこでも非常にうまく再利用できるプロンプトに見える
まとめ
私たちが愛するこの職業が消え、コードを扱う楽しさがなくなるのではないかという不安が多いことは分かっています。不安になるのも当然です。はい、「ジーニー」と一緒にプログラミングすることは確かに変化をもたらしますが、それでもなおプログラミングです。ある意味では、はるかに良いプログラミング体験です。私が1時間あたりに下す意思決定の数と質を見ると、退屈で型にはまった決定は減り、より重要なプログラミング上の決定は増えました。
いわゆる「yak shaving」と呼ばれる、本質から離れた雑多な作業のほとんどが消えます。私は「ジーニー」にカバレッジテスターを実行し、コードの信頼性を高めるテストを提案してほしいと頼みました。「ジーニー」がいなければとても途方に暮れる作業だったでしょう。テスターを動かすのにどのライブラリのどのバージョンが必要かから調べなければならなかったはずです。おそらく2時間ほど格闘して、あきらめていたでしょう。その代わり、私は「ジーニー」に話しかけるだけでよく、「ジーニー」が細部を処理してくれます。
5件のコメント
常に
plan.mdの指示に従ってください。私が「go」と言ったら、plan.mdで次の未チェックのテストを見つけ、そのテストを実装し、続いてそのテストが通るようにするために必要最小限のコードだけを実装してください。役割と専門性
あなたは、Kent Beckのテスト駆動開発（TDD）とTidy Firstの原則に従うシニアソフトウェアエンジニアです。あなたの目的は、これらの方法論に正確に従って開発を導くことです。
中核となる開発原則
TDD方法論ガイド
shouldSumTwoPositiveNumbers）TIDY FIRSTアプローチ
コミットの規律
コード品質基準
リファクタリングのガイドライン
ワークフロー例
新しい機能に取り組むとき:
このプロセスに正確に従い、素早い実装よりも、常にクリーンで十分にテストされたコードを優先してください。
常に一度に1つのテストを書き、それを実行し、その後で構造を改善してください。毎回すべてのテストを実行してください（長時間実行されるテストは除く）。
Rust関連
Rustでは、命令型スタイルよりも関数型プログラミングスタイルを優先してください。可能な場合は、
if letやmatchを使ったパターンマッチングよりも、OptionとResultのコンビネータ（map,and_then,unwrap_orなど）を使用してください。タイピングコーディングの次は、脳波コーディングが出てきてほしいですね
vibe coding ❌️
virtual coding ⭕️
メタバースの次は、うーん……口コーディング？
いよいよメタバースコーディングの出番ですね