「AIを使えば開発が加速するはずなのに、なんかリズムに乗れない…」そんなモヤモヤを感じたことはありませんか？ 🤔
Hacker Newsに投稿されたスレッド「Ask HN: Is anyone experimenting with different ways of using LLMs for coding?」が、エンジニアたちの間で静かに共感を集めています。
🚲 「自転車」のはずが「急ブレーキ自転車」になっている？
投稿者はこう語っています。「Claude CodeやCodexを使っているけど、手でコードを書いているときのようなフロー状態に入れない。AIは”心のための自転車”のはずなのに、数分おきに急ブレーキがかかる自転車みたいだ」と。
つまり、こんなループが続くわけです。
- ⏸ プロンプトを入力して待つ
- 👀 出力をレビューする
- ✏️ 修正プロンプトをまた入力する
- 🔁 繰り返し…
これ、あなたも経験したことがありますよね。手で書いていればキーボードから指が離れずに思考が流れるのに、AIを挟んだ途端に「待ち」が発生してリズムが崩れるんですよね。
🔍 従来の「プロンプト→応答」以外のアプローチ、何がある？
このスレッドでは、LLMをコーディングに使う根本的に違うやり方を模索しているエンジニアの声が集まっています。いくつか注目のアイデアをまとめるとこんな感じです。
① テスト駆動でLLMを「審判」にする
自分でテストコードだけ書いて、LLMにその実装を通らせる役割を与える方法です。イメージとしては「仕様は自分が決め、LLMは実装マシン」という分業スタイルです。
# 自分で先にテストを書く（仕様の言語化）
def test_fizzbuzz():
assert fizzbuzz(3) == "Fizz" # 3の倍数はFizz
assert fizzbuzz(5) == "Buzz" # 5の倍数はBuzz
assert fizzbuzz(15) == "FizzBuzz" # 両方の倍数はFizzBuzz
assert fizzbuzz(1) == "1" # それ以外はそのまま文字列で返す
# → このテストをLLMに渡して「全部通る実装を書いて」と指示するポイントをまとめるとこんな感じです。
- ✅ 自分の思考は「仕様設計」に集中できる
- ✅ LLMの出力が「合格か不合格か」で機械的に評価できる
- ✅ フロー状態が崩れにくい（レビューじゃなく検証になる）
② 「差分だけ」を渡すインクリメンタルな使い方
コード全体を毎回貼るのではなく、変更したい差分・意図だけを渡すスタイルです。コンテキストが小さくなるので、応答が速くなり待ち時間ストレスが減ります。
③ 音声入力でプロンプトを「しゃべる」
キーボードを離れてプロンプトを打つ動作自体がリズムを壊しているという仮説から、音声でLLMに指示を出す実験も紹介されています。タイピングの中断がなくなるのでフロー継続に有利とのことです。
🧠 日本人エンジニアへの実践的ヒント
このスレッドの本質は「LLMをどう使うかより、自分の思考リズムをどう守るか」という問いだと思います。
今日からすぐ試せることとして、こんな工夫が効果的ですよ。
- 🎯 AIに渡すタスクを30行以内の小さな単位に分割する
- 📝 プロンプトをテンプレート化して入力コストを下げる
- ⏱ LLMの応答待ち中に次のテストや設計を考える習慣をつける
まとめ
LLMはまだ「止まらない自転車」には程遠いのが正直なところですが、使い方を工夫することでフロー状態に近づける余地は十分あります。
プロンプト→応答の単純なループから一歩踏み出して、あなたなりのLLM活用スタイルをぜひ実験してみてください 🚀 一緒にベストな使い方を探していきましょう！
こちらも読まれています
📚 関連商品・おすすめ書籍
※本記事にはアフィリエイトリンクが含まれます。
PR
