個人開発者のAnkur Sethiは、AIエージェントに「ファイルを直接編集するな、提案はチャットに出せ」と指示し、そこから自分の手でコードを打ち直している。Hacker Newsで351pt・292コメントを集めたこの主張は、非効率を承知の上で何を守ろうとしているのか。
手で打ち直す実践の具体的な指示文言と3つの効果の仕組み、そして「どこまで速度を犠牲にできるか」を自分の作業に当てはめて判断するための材料。
以前この連載で、AIへの委任が知らないうちに「認知的降伏」——出力を検証せずそのまま受け入れる状態——へ変わっていく話を書いた（認知的オフロードと認知的降伏）。境界線は習慣の積み重ねでじわじわ動く、という指摘だった。
個人ブログを書くAnkur Sethiは、この境界線を意識ではなく行動の制約で戻そうとしている。答えは単純で、AIにファイルを直接編集させず、提案をチャットに表示させてから、自分の手で1文字ずつ打ち直す。Hacker Newsで351pt・292コメントという高い温度感で議論されたのは、この提案が「非効率で滑稽」だと著者自身が認めながらも、譲らない一線を明確に引いているからだろう。
複雑な仕組みではない。著者がAIエージェントに与えている指示は、要約すると次の2点に集約される。
提示されたコードを読み、意味を理解しながらエディタに打ち込む——この一手間を、コピー&ペーストの代わりに毎回挟む。単発の「ワンショットで一気に完成させる」使い方には向かず、著者自身「複雑な作業で自動ファイル編集が要る場面では使わない」と線引きしている。定型的だが退屈な作業（Djangoへのタグ機能追加、など）や個人プロジェクト全般が主な適用場面だ。
著者が挙げる根拠は、精神論ではなく具体的な3つのメカニズムだ。
手で入力する過程で、コード片が全体にどう適合するかを自然と考えることになる。読んで流すのと、書き写しながら追うのとでは、頭に残る解像度が違う。
コピペで一括反映すると見落としがちな不自然な処理や、存在しないAPIの参照が、1行ずつ手を動かしている最中に「あれ」という違和感として引っかかる。
その機能がプロジェクトのどこに存在するかを体で覚える。後日AIに追加の指示を出すときも、的確な場所・的確な粒度で頼めるようになる。
ここが核心。著者はこの実践で得られる速度を「10倍ではなく、せいぜい2倍程度」と見積もっている。完全自動化を諦めてでも、理解を手放さないという取引を、自覚的に選んでいる。
正直に言えば、この実践をこのブログの運用（記事の自動生成・自動投稿パイプライン）にそのまま持ち込むのは筋が悪い。1日1本のペースで記事を出す量産工程に、1文字ずつ打ち直す工程を挟めば速度が半分以下になり、そもそもの仕組みが成立しなくなる。
だが著者の線引きには持ち帰れる部分がある。「単発のワンショットでは使わない」「複雑な自動編集が要る場面では使わない」という制限は、裏を返せばそれ以外の場面——退屈だが理解しておきたい定型作業——には使うという宣言だ。全部の作業に一律で手打ちを課すのではなく、後で自分が説明責任を持ちたい部分だけ、意図的に速度を落とすという発想は、量産と検品を両立させたい個人開発者にも応用できる。
著者自身、この実践の動機を「効率」ではなく「個人プロジェクトは成果より過程が重要だから」と述べている。数百行の防御的で説明不足なコードをただレビューするだけの作業は、企業でも退屈で嫌なものだ、とも。業界全体が積み上げている"認知的負債"は、いずれ誰かが払わされる——その危機感が、非効率を承知で手を動かし続ける理由になっている。
出典: Ankur Sethi — Prevent cognitive debt by manually retyping LLM-generated code（Hacker News 351pt・292コメント）