「AIとの往復がしんどい」——HNで集まった”別のコーディング”12の型

要点（30秒で）: Hacker Newsで「AIとの往復がフロー状態を壊す、手で書くより疲れる」という嘆きが180点を集めた。集まった回答は”もっと任せる”か”もっと絞る”かの二極に割れている。自分の疲れがどちらタイプか、まず見極めてから道具を選ぶといい。

Claude CodeもCodexも使っている。なのに、なぜか手で書いていた頃より消耗する——そんな正直な告白から始まったスレッドが、いま静かに読まれている。

投稿者 yehiaabdelm が「Ask HN」に立てた問いは短い。チャット越しにプロンプトを投げ、返事を待ち、また投げる。その往復が集中を断ち切る。誰か、この構造そのものを変える使い方を試していないか、と。

何が問われたか

面白いのは、彼が不満をぶつけるだけで終わらなかった点だ。「tab（タブ）モデル」的な発想に興味がある、とヒントを添えている。

ここでいうタブモデルとは、Cursorが磨いてきた次の一手を予測する方式のこと。文字だけでなく、次にどこを直すか・どのファイルへ飛ぶかまで先読みし、開発者はTabキーで受けるか流すかだけを決める。27万トークンの文脈を読むMoEモデルが背後で走り、チャットのような明示的な往復が要らない。

つまり投稿者が欲しいのは、「指示して待つ」構造そのものを消した道具だ。180点・184コメントという反応が、この違和感が一人のものではないことを示していた。

回答は"二極"に割れた——「もっと任せる」派と「もっと絞る」派の対比（両極とも狙いは"待つ往復"を消すこと）
回答は”二極”に割れた——「もっと任せる」派と「もっと絞る」派の対比（両極とも狙いは”待つ往復”を消すこと）

回答は”二極”に割れた

集まった実践を眺めると、方向は大きく二つに分かれる。

ひとつは、もっと任せる派。仕様を厚く書き込み、エージェントを何時間も無人で走らせ、結果だけを後から検分する。chris_fullcycle は事前計画を徹底したうえで自動承認をオンにし、夜通しClaude Codeを回す。朝起きると、動かせるアプリが出来ている、という運用だ。

もうひとつは、もっと絞る派。avilay は最初のコードを自分で書き、難所の設計だけClaudeに相談し、「全部書きましょうか」という申し出は断る。DanielHB は「ファイルXでYをやれ」と範囲を絞ったプロンプトに割り、毎回文脈をリセットする。狭いほどモデルは速く正確、という経験則だ。

速度と理解が、ここで綱引きしている。全部渡せば速いが分からなくなる。手元に残せば分かるが遅い。フロー状態は、全委任か最小干渉かの両極でしか保てない——スレッド全体が、そう囁いているように読める。

疲れの正体は"非対称"——並列に働くAIと、逐次でしか動けない人間の注意（研究の数字つき仕組み図）
疲れの正体は”非対称”——並列に働くAIと、逐次でしか動けない人間の注意（研究の数字つき仕組み図）

「見せない」ことで賢くする

二極の内側には、もっと尖った工夫が並んでいた。

seanmcdirmid は、コードを書くエージェントとテストを書くエージェントに互いの成果を見せない。人間のチームがそうであるように、確証バイアスを構造で殺すためだ。その代わり、前提となる仕様は最初に細かく書き切る。

vitally3643 は逆に群れで攻める。llama3.2:3b級からQwen3の27bクラスまで、性能の違うモデルを並列に走らせ、意見を出させ、結論を議論させる。個々のコード力は弱くても、合議による統合は驚くほど効いた、という。

aard は生成物にコードだけでなく大量の散文を並走させる。なぜこう設計したかという文脈を、コードの外に文章として残す「文芸的プログラミング」の再来だ。決定の理由が失われる、という生成AIの持病への処方箋である。

自分の疲れで選ぶ——「任せ足りない」なら全委任系、「任せすぎた」なら最小干渉系（迷ったら文脈リセットから）

人間を”閉じられないノード”にする

構造そのものを設計し直す人もいる。

fractorial はワークフローをDAG（有向グラフ）として組み、その中に「人間ノード」を置く。エージェントには構造上どうしても閉じられないノードで、そこで進行が止まり、人間の注意を強制的に呼ぶ。放置による暴走を、設計で封じる発想だ。

jarodrh は役割ごとにモデルを固定する。調べ物には安いモデル、実装には中位、レビューには最強、と設定ファイルで役割ごとに固定しておき、動的なルーティングをやめてトークンの無駄を削る。

philbo の opair は「運転手」と「案内人」の二役を素早く切り替える相棒方式で、自律エージェントの自律性をあえて拒む。anthonyfrisby に至っては、ハーネスをTelegramに繋ぎ、ハイキングしながらスマホでコードを書く。もっとも、それは熟考を壊すという反論もすぐ付いた。

こうした「自分の足場を自分で設計する」志向は、自分のハーネスを書いて磨くコーディングAI、Godcoder公開や自分の足場を自分で書くコーディングAI、Ornith-1.0公開のようなプロダクトの潮流とも地続きだ。個人が手元でやっている工夫が、そのままツールの設計思想になっていく。

研究も「疲れ」を裏づける

この体感には、数字の裏づけが出始めている。

ある系統的レビューは、LLM支援が不要な提案・冗長な出力・画面の切り替えを通じて頻繁な割り込みを生み、認知負荷を押し上げると指摘する。別の分析では、開発者はコーディング時間の約51%を、提案の検証やプロンプト作りといったLLMとのやり取りに費やしていた。

エージェントは並列に働けても、人間の注意は逐次でしか動かない。複数のAIを回すほど文脈の切り替えが増え、フローから引き剥がされる——この非対称が、投稿者の消耗の正体なのだろう。半面、深い集中を保てた開発者は生産性の体感が3〜5割高いという報告もある。だから問題は「AIを使うか」ではなく、「割り込みをどう設計で消すか」に移っている。

日本・個人開発の視点

日本の個人開発者にとって、このスレッドの価値は”正解”ではなく”棚”にある。12の型は、どれかが優れているのではなく、疲れの種類ごとの引き出しだ。

夜間バッチで一気に作りたいのか、難所だけ相談したいのか、群れの合議で設計を固めたいのか。自分の案件と気質に合う一つを選び、残りは捨てる。全部を真似ると、それこそ管理コストでフローが死ぬ。まずは「範囲を絞って文脈をリセット」する軽い型から試すのが、コストも学習曲線も一番なだらかだと言える。

要点まとめ

HN投稿者は「AIとの往復がフロー状態を壊し、手書きより疲れる」と問題提起し180点を集めた。
回答は”仕様を厚くして無人で走らせる”自律化派と、”範囲を絞り手元に残す”最小干渉派の二極に割れた。
見せ合わないエージェント、多モデル合議、文芸的プログラミング、人間ノード付きDAGなど尖った工夫も多数。
研究側も、開発者がコーディング時間の約51%をLLMとのやり取りに費やし割り込みが認知負荷を上げると裏づける。
求められているのは万能ツールではなく、疲れの種類に合った”型”の選択だ。

🐦‍⬛ 編集部の視点

このスレッドが刺さるのは、答えではなく問いが正直だからだ。「AIで速くなったはずなのに、なぜか疲れる」——この感覚を、多くの開発者が言語化できずに抱えていた。

私たちが注目したいのは、二極のどちらにも「待つ構造をやめたい」という一点が共通していること。任せきるのも、絞りきるのも、要は”指示して待つ往復”を消すための逃げ方だ。Cursorのタブモデルが評価されるのも同じ理由だろう。次のコーディング体験の勝負どころは、モデルの賢さより「人間の注意をいつ・どこで呼ぶか」の設計にある。

あなたの疲れは、任せ足りない疲れか、任せすぎた疲れか。まずそこを見極めてほしい。

コメントを残すコメントをキャンセル

2026年、AIは「使うもの」から「任せるもの」へ。海外最新動向で読むAIエージェント時代の本番化