ここ数か月、手でコードを書いています
(miguelconner.substack.com)- AIコーディングエージェントが一般化した時代に、あえてLLMを使わず手でコードを書く3か月のリトリートに参加した開発者の記録
- ブルックリンのRecurse Centerで6週目を過ごしながら、LLMをゼロから自作し、Pythonの腕を磨きつつ、コンピュータの複数の抽象化レイヤーへの理解も深めている
- コーディングエージェントは高速な反復とデプロイを可能にする一方、実際に手でコードを書くと、望むものを表現することと、コードベースを学ぶことの2つが同時に起こる
- Cal Newportが語る**「文章を書くことは運動に似ている」**という比喩のように、コードを書く精神的な努力こそが技術の中核的要素だという見方を共有
- AIツールを巧みに使うエンジニアほど深い知識を持っているという観察を踏まえ、AI時代でも基礎力がレバレッジを生むことを強調
LLMとコーディング体験
- この2年間、バルセロナのAily LabsでAIエージェントを構築してきた
- 2024年初頭に社内向けWeb検索エージェントを作成しており、これはAnthropicの「Building Effective AI Agents」の記事より約6か月、OpenAIのDeepResearchより約1年早かった
- Cursorの初期ユーザーであり、LLMを活用した知識グラフ構築にも早くから関わっていた
- 毎週のジャーナルクラブを主導し、オープンソースLLM構築に関する論文を発表
- DeepSeek R1、Ai2のOlmo 3、MetaのLlama 3の論文などを扱った
- 社内モデルの学習と、SOTAなクローズドモデルを使ったワークフロー構築のあいだにあるトレードオフを理解する助けになった
- 2023年に初めてLLMを使って以来、その仕組みと応用に継続して関心を持ってきた
技術の中核要素としての手書きコーディング
- LLMを学びながらコーディングにも活用して気づいたこと
- 「手で」コードを書くときには、作りたいものを書くことと、コードベースを学ぶことの2つを同時に行っている
- コーディングエージェントを使う場合、プロンプトで指定した内容だけを正確に得ることになり、何を望むのかが曖昧だと、エージェントが多くの**仮定（assumption）**を代わりに置いてしまう
- その場合、学習量が減り、コードベースへの理解も浅くなる
- 一方でコーディングエージェントは、高速な反復と安定したソフトウェアデプロイを可能にし、優れたチューターの役割も果たす
- Cal NewportのNYTコラムからの引用
- 「あなたの文章は、あなた自身のものであるべきだ。明快なメモや報告書を書くのに必要な緊張は、アスリートにとってのジムでのトレーニングに相当する精神的な作用であり、取り除くべき煩わしさではなく、技術の中核的要素なのだ」
- この比喩はコードを書くことにもそのまま当てはまると考えている
- Ailyで一緒に働いた優れたプログラマーたちは、おおむねAIを非常にうまく活用する人たちでもあり、深い知識がAIツールに対するレバレッジを生んでいた
コード・リトリートとは何か
- **Recurse Center（RC）**はブルックリンにある、自主性を重んじるフルタイムのプログラミングリトリート
- Retreat: 「日常から少し離れて、特定の活動に集中する期間」
- 応募書類とコーディング面接を経て参加し、6週間または12週間、プログラミングに没頭する
- 多様な専門性を持つコホート型の協業環境が特徴で、数十年の経験を持つプログラマーも多く参加している
- 無料で運営されている
- Recurse Centerでの目標
-
ゼロからLLMを学ぶ
- 事前学習と事後学習を含め、既存コードベースをforkするのではなく、自分でTransformerを書くことが目標
-
Pythonを手でより上手く書けるようになる
- 数年間Pythonで仕事をしてきたが、まだ学ぶことが多いと感じており、ドキュメント参照やLLMへの質問を最小限にして、プロジェクト構成への直感を育てたい
-
コンピュータをもっと深く理解する
- コンピュータは複数の抽象化レイヤーで動く非常に複雑な機械だという認識がある
- 正規のComputer Science教育を受けていないため、それらのレイヤーがどう連動しているかについて、より良いメンタルモデルを作りたい
- 具体的な計画は多くないが、RCはそのために適した場所だと考えている
-
進捗状況
-
1. LLMをゼロから学習させる
- StanfordのCS336: Language Modeling from Scratchコースの最初の課題を、LLMによるコーディング支援なしで完了
- 50ページにおよぶ課題を別のRecurserと一緒に取り組んだ
- Pythonで最適化したtokenizerを書き、PyTorchで改良版のGPT-2スタイルアーキテクチャを実装
- Tiny Storiesデータセットでハイパーパラメータ調整のための多数のablationを行った後、OpenWebTextの約90億トークンに適用
- 自作した1700万パラメータモデルのlearning rateスイープでは、高いlearning rateが不安定性を引き起こした。A100で約1時間の学習
- 今後の計画
- CS336の残りの課題に取り組む: 言語モデル最適化、scaling lawの推定・計算、生テキストの事前学習データへの変換、モデルのpost-training
- 2つ目の課題であるGPUプロファイリングとTritonでのFlashAttention2実装にはすでに着手している
- 最終的には自分でpost-trainingしたモデルを手に入れることが目標
- StanfordのCS336: Language Modeling from Scratchコースの最初の課題を、LLMによるコーディング支援なしで完了
-
2. Pythonの腕を上げる
- PythonとPyTorchで小さなエージェントやニューラルネットワークを多数書きながら練習している
- 最も役立ったのは、10年以上のPython経験を持つ人とのペアプログラミング
- あるペアの相手は、構文や挙動を思い出せないとき、すぐにターミナルを開いて簡単な例を入力し、1分以内に動作を確認する
- Google検索やLLMへの問い合わせなしで問題を解決するこの筋肉記憶化されたプロセスが、行き詰まりの解消に大きく役立った
- Advent of Codeのような問題をペアプログラミングで解きながら、この方向性を続ける予定
- リアルタイム協業は最初は緊張するが、そのぶん成長の速さを実感している
-
3. コンピュータ理解の深化
- 1983年のApple IIeコンピュータでBASICを使ってfizzbuzzを書いた
- 受動的なコード編集と実行のプロセスを直接体験し、昔と今のコンピュータの違いと共通点の両方を認識した
- CTF Fridaysへの参加でUnix/ターミナルのスキルを強化
- Banditなどの「war games」チャレンジをターミナルで解き、パスワードを集めてレベルアップしていった
- 今ではClaude Codeが自分のコンピュータ上で何を実行しようとしているのか把握できる
- Vimで単一層パーセプトロンを手でコーディング
- 最初はとても退屈だったが、別のRecurserのコツやショートカットを学んで改善した
- クラウドGPUで学習ジョブを回している最中に、最後のファイル修正が必要なとき非常に便利
- Clojureワークショップに参加（15年以上の経験者が進行）
- 関数型言語の経験が少ないため、テーマ自体が興味深かった
- 短い導入のあと、モブプログラミングで進行し、参加者が交代で1〜2分ずつ問題解決に貢献した
- 毎週の5分技術発表に参加
- 「Running Rust Code」「GPUs for Dummies」「Typesafe APIs for Type B Personalities」「Some Useless Agents」（本人発表）など、多様なテーマが扱われた
- 自分はこれまでに2回発表しており（単純なエージェントアーキテクチャ、MCPツールの効率的な拡張）、今週はGPU最適化の方法について発表予定
- 他の参加者たちのプロジェクトやキャリアを聞くだけでも、コンピュータで解決できる問題領域への理解が広がる
- 1983年のApple IIeコンピュータでBASICを使ってfizzbuzzを書いた
残り6週間
- リトリート後は、新しい技術とスキルを携えて、エージェントの本番デプロイとeval実行の仕事に戻る予定
- 残り6週間ですべての項目を終えるのは難しいのではないかという不安がある
- それでもRCの本当の価値は、すべてをやり切ることではなく、コーディングそのものに時間を注ぐことにある
6件のコメント
仕事用のコードはAIエージェントに任せて、できるだけループを長く回せるように全部任せてしまっていて
趣味の個人プロジェクトはAIアシスタントやAI自動補完も使わず、自分で開発しています (...)
少し前に見たジョーク投稿を思い出しました。
まず自分で手書きでコードを書いてからAIに改善してくれと頼んだら、
Phase 1: ゴミコードを削除
と出たそうです（笑）
VSCode の AI 機能をオフにして Claude Code を使っていますが、確かに快適です。
AI のために vim を捨てて vscode に乗り換えたのですが、
開発するときの喜びを失ってしまった感じがして、vim に戻りました。
AI はアシスタントとして使っていますが、確かに開発の喜びを取り戻せた気がします。
私はむしろAIエージェントを使ってから、nvimに戻りました。
ソースを見るなら、nvimで見るほうがずっと楽なので..
Hacker Newsの意見
私は今学期、18歳の学生たちに、エミュレートした Apple II Plus 上で 6502 アセンブリを教えている
学生たちはすでに現代的な環境で Python、データ構造、オブジェクト指向を学んでいた
合計10時間ほどの授業と演習で、レジスタ、命令、アドレッシング方式、メモリマップ、Apple モニタルーチンを身につけたあと、40x40 の低解像度グラフィックスでお絵描きプログラム、跳ねるボール、自作スプライト、簡単な衝突判定まで一緒に実装した
課題では Snake や Tetris のような簡単なゲームを自分で作って実演し、その動作の仕組みを発表させた
最初はラインエディタを嫌がっていたが、すぐにコードを書く前にまず計画し、議論するようになった
以前の授業でいつも強調していたのになかなか身につかなかった習慣が、強力なツールがないことでむしろ自然に定着した
後になると、画面にコードを全部表示しなくても頭の中にコードが入っていると学生たちは言っていた
いずれまた現代的なツールに戻るだろうが、こうした経験には確かに大きな意味があると感じる
最大の理由は、型を常に意識する必要があるのに、Python はむしろその部分を曖昧にしてしまうことがあるからだ
空白も、あるときは必須で、あるときはそうではなく、慣れた人には呼吸するように自然でも初心者には紛らわしいことがある
低レベル環境と限られたツールのおかげで、コードを書く前にまず考える習慣が身についた
今でもグリーンフィールドの作業では、まずペンと方眼紙を取り出して、関数やクラスの候補をゆるいグラフとして描き、矢印でつないでみる
もちろんこれをやりすぎるとウォーターフォール型の計画の別形態になってしまうので、加減が大事だ
数時間あらかじめ構造を考えるだけでも、実際のコーディング時間は大幅に減ると感じる
実際の成果物が紙の設計とまったく同じだったことはほとんどないが、大きな絵を先に考える過程そのものが生産性を高めてくれる
エディタ内でスキャフォールディングするとすぐ実装に流れてしまうが、紙に書けばどうせ打ち直す必要があるので、変数名やメソッド選びのような細かな雑念から離れられた
何度かvibe codingをするときもこの方法がとくに有用で、そのおかげでずっと具体的で集中したプロンプトを与えられた
でも、学生たちの頭の中にコードが定着したというくだりを読んで考えが変わった
Zed Shaw も似たことを言っていて、IDE なしで書いたコードのほうがなぜか良く見えると話していたのを思い出した
同じ文脈で、私は "From Nand to Tetris" のような本で学んだが、コンピュータやアセンブラ、コンパイラがどう動くのかを理解するのに本当に大いに役立った
その人は問題を受けてもすぐにタイプし始めず、まず考え、紙に少し書きつけ、散歩までしてからようやくコンピュータの前に座った
そしてほぼ一発で入力し、最後にコンパイルするだけで、実際によく動いた
タイプミスすらまれだった
この経験のおかげで、問題空間とプログラムをまず頭の中に組み立てて推論する能力がどれほど重要かを強く実感した
そうすると期待する結果がより明確になり、想定外のことが起きたときにもより早く気づける
上のほうでは、難しすぎる、もう誰も使わないと言って科目をなくしてしまうことが多かった
それでも、システムプログラミング、計算機言語、計算機アーキテクチャのような別の授業の中にこっそり少しずつねじ込んできた
私が育った時代にはアセンブリは教育課程の一部で、高級言語である C/C++ とハードウェアの間の溝を埋める役割を果たしていた
なぜ特定の言語機能が存在するのか、多くの言語要素が実際にはどう動作しているのかも理解できるようになった
何より、上のコメントのように CPU を一行ずつ追いながら考える訓練になるという点が本当に素晴らしかった
正式な科目としてはよく負けたが、少なくとも学生たちの中に種はまけていることを願っている
誰もが少なくとも一度は、何らかのアセンブリを学ぶ価値があると信じている
私はAI オートコンプリートのワークフローにもっと投資があってほしいと感じる
それがかなりちょうどよい中間地点だった
今いわゆる昔ながらのやり方と呼ばれるものも、もっと広く見ればエージェント型ワークフローと比べてなお十分に競争力があると思う
自分で打ち込むことでコードベースの知識をずっと維持しやすくなり、能動的に思い出して検証する過程のおかげで概念理解もより深まる
コードは自分で書き、エージェントにはコードレビューを任せる
そうすると自分のコーディング感覚とコードベース理解を保ちつつ、コミット前にバグもしっかり見つけてくれる
初期の Cursor は本当に驚異的だったが、その後はオートコンプリートがほとんど停滞した印象で、最新の Cursor でさえ他のツールのようにだんだんエージェント寄りになっている
いつか diffusion モデルにさらに勢いがつけば、オートコンプリート寄りのワークフローにもまた活気が戻るかもしれないと期待している
Inception Labs の Mercury モデルは応答がほぼ即時で、今でも少し魔法のように感じる
ただ、Cursor 級の洗練さや深いエディタ統合がまだ足りないのが惜しい
それに diffusion 系はローカル利用に本当に向いていそうなのに、まともなオープンウェイトモデルがほとんどないのも残念に感じる
自分で退屈なグルーコードを書くと、プロジェクトの地図が頭の中にできる
逆にエージェントが構造を作りすぎると、その場では動いても、1週間後に小さな修正をしようとするたびに、どこに何を置いたのか探すところから始まる
みんながすぐ別の方向に移ったのには理由があり、結局有用なインターフェースではなかったと思う
一度飛行機に乗ってしまうと、もう戻るのは本当に難しい
このタイトルは、ここで見た中でもっとも憂鬱なタイトルの一つに感じられた
手でコーディングすることが、もはやブログに書くほど珍しいことになってしまって憂鬱だ、という意味にも取れるし、逆に AI 最大主義者が人間のコーディングを皮肉っているとも取れる
投稿履歴を見ると、おそらく前者の解釈が正しそうだった
かつて流行語になった wild swimming みたいで、何か遠くまで来すぎた感じがする
本当にサメを飛び越えたような状況に見えた
それでも、とても印象的な貢献だったと感じた
読んでみると本当にあきれる
そのうち手コーディングの話をしただけで精神病院に送られる世の中まで冗談みたいに想像してしまう
キャリア初期の数年間、私は SPARC ベースの Solaris で vi を使い、それもvim ですらない viで主に Perl コードを書いて過ごしていた
O’Reilly の Perl Cookbook がほぼ唯一の道しるべで、インターネットフォーラムもあまりなく、検索エンジンも原始的だったので、行き詰まっても助けを得るのはずっと難しかった
その代わり、その環境のおかげで Perl の文法、ターミナルツール、とくにvi のキーストロークを非常に深く身につけられた
シンタックスハイライトも IntelliSense もなかったが、そのぶんむしろより身体に残った
今振り返ると、当時は気を散らすものやノイズがずっと少なかった
もちろんキャリア初期で期待値が低かったからそう感じる面もあるだろうが、今はあらゆるものが過剰にレイヤー化されて複雑になりすぎたと感じる
それは即時的な報酬と素早い開発、余計なレイヤーのないかなり純粋な体験で、まさにその点が私をこの道に引き込んだ
皮肉なことに、agentic codingはあの頃のワクワクを一部取り戻してくれた
複雑なエンタープライズ上の考慮事項を自分で全部格闘しなくてよくなり、思考と結果のあいだのつながりが再び近くなったからだ
業界の変化には本当に驚かされる
ほんの2年前までなら、ほとんどすべての開発者が言いそうなことだったのに、今では手でコーディングすると言う人が絶滅危惧種のように見えるほどだ
この1年で触れてきた新しい技術や言語ほど、今ではあまりにも簡単に結果を出せてしまうので、かえって自分の中に知識負債を積み上げている感じがある
次の世代のソフトウェアエンジニアが、こうしたものへの深い理解をいったいどう身につけるのか、あるいはそもそも身につけられなくなるのか、とても不安だ
さらに前の世代にたとえるなら IDE なしでコーディングするのに近く、実際そういうやり方もすでに珍しかった
私は AI 全般、とくに GenAI をかなり支持しているが、それでも今なお手でコーディングする時間を多く取っている
多くてもCopilot の補助をオンにしておく程度だ
ときには SpecKit + OpenCode のようなツールで spec-driven development をしたり、ただ vibe code したりもする
それでも、コードを理解すべき自分の責任を手放して、直接書く能力そのものを捨てるつもりはまだない
だから最近も LISP と Java の本を何冊か新たに買ったし、その前には Forth の本も買った
少なくとも当面は、もしかすると永遠に、完全にコーディングをやめるつもりはない
核心は実装ではなく振る舞いの理解だ
その検証は自動化された単体テスト、統合テスト、負荷テストが担ってくれる
誰かは、私が内部向け Web 管理サイトを vibe coded で作り、しかもコードを一行も見ずにセキュリティ要件を満たしていると言ったのを、甘いと見た
しかし要件は、そのサイトへのアクセス権を持つ人は何でもできなければならないというもので、アクセスは Amazon Cognito の認証情報で保護し、それを提供する Lambda には最小権限ロールを付けていた
もしその二つの不変条件が破れていたなら、それは Claude が巨大な AWS 脆弱性を発見したレベルの話だと思う
私は AI を最大限活用して多くを作る一方で、同時に AI が作ったコードが自分の認知負荷の基準を通るかどうかを必ず見直す時間を取っている
その過程にはコードの磨き込みや文書化も含まれていて、この AGENTS.md の例をもとに多くの部分を楽に処理している
それでも変な方向に進み始める瞬間は察知できるので、そのときはまた自分が舵を取る
そしてクレジットが尽きたら、そのときが本当の自分の番だ
すでにコードはよく整理され、抽象化も筋が通っていて、コメントも役に立つので、その上で有機的な人間のコーディングを続けやすい
今では上限に近づくほど、AI に先に舞台を整えておいてくれと頼むようになった
以前はクレジットが切れると、理解するには勉強が必要なコードを残されて苛立っていたが、今ではむしろ次のbrain time hand-outが待ち遠しいくらいだ
奇妙に聞こえるかもしれないが、私にはこれも一種のチームワークのように感じられる
もっと高いプランを使うこともできるが、私は自分の脳を動かし続けていたい
原則自体には同意するが、少なくとも Claude はロジックをあまりにも頻繁に複製するので、むしろ逆方向への誘導が必要だと感じた
LLM が私の代わりにコードを書くと、そのコードは私にとってほとんど手の入れられないブラックボックスのように見える
動けば使いはするが信用はできず、壊れるとただフラストレーションがたまる
結局、自分に合っているのは、常に自分がハンドルを握り、LLM は質問に答えたり、一緒にアイデアをブレインストーミングしたり、すでに理解している概念を特定の言語の文法で表現するのを助けたりする補佐役だ
実のところ私は、概念理解そのものより、それを文法に落とし込むことのほうが昔から少し苦手だった
私もエージェントに一部を任せつつ、ある作業は意図的に自分の担当として残して脳を使い続けるやり方について考えていた
もしかすると Claude Code 用のskill や hookを作ってみるべきかもしれない
3か月間、自主的に深く学ぶ旅を送れるというのは本当に素晴らしいことに思える
こうした深い技術は長期的にも価値がありそうだし、今回の変化がアセンブリから C への移行とまったく同種の抽象化なのかはまだ確信がない
最近の私のコードの大半は LLM が生成しているが、一日の終わりに楽しさや達成感、満足感は正直あまりない
ただ同時に、自分がもともとコーディングで本当に楽しんでいた部分は 5〜10% ほどしかなく、残りは興味深い中核を支える退屈で半機械的な作業だったのだとも気づいた
人類の歴史全体で見れば、コンピュータで仕事をしている時代そのものがごく短い瞬間であり、100年後には手コーディングの時代がどう見えるのか気になる
あるいは単なる脚注として残るか、機械が自ら自動化する以前のすべての時代として一括りにされるのかもしれない
昔は直接アセンブリで書いていたが、その後 C のようなコンパイル言語へ移り、アセンブリは有用ではあってもニッチな技術として残った
今ではコードをコンパイラに任せ、その内部出力をほとんど見ないのと同じように、今後は開発の大半が LLM という抽象化レイヤーへ移るかもしれないと感じる
中核的な能力も、よいプロンプトの作成、コンテキストウィンドウの管理、エージェントやメモリの運用といった方向へ移っていくかもしれない
一部の開発者はなお LLM が作ったコードを読んで問題を見つけられるだろうが、大半はそうできなくなるかもしれない
私も複雑な気持ちだ
ChatGPT 登場以後、数か月前までは LLM プログラミングにかなり懐疑的で、新しいモデルが出ても結局は似たような質の低い出力の変奏に思えていた
しかし最近は、モデルが何らかの閾値を超えたように見え、私も Claude をまだ慎重に使ってはいるものの、機能実装の時間を大きく短縮したり、ログだけを見てバグ箇所を特定したりするのに実際役立っている
まだコーディングは解決されたといった誇張には同意しないが、少なくとも高級言語の導入以降で最大級の変化の一つを目にしているという気はする
私は半分妥協案として Zed を使い始めた
これからは AI を実装そのものより計画や段取りの提案に使ってみようと思っている
最近は非技術職の人たちも Claude でアプリを作り始めているのが見えるし、Openclaw をはじめとするエージェント偏重の流れを見ると、AI への過度な没入をこのまま進めるのは実用的ではないと感じる
私は人生のほかの領域でも、いつも内部の細部まで気を配り、新しい問題に自分で手を汚して取り組む能力で評価されてきた
市場が今後どう適応するのか、そして人々がこうしたニュアンスを扱う能力をどう伝え、どう証明していくのかが気になる
Recurse Center のサイトで「教師や決まったカリキュラムはなく、リトリートの間フルタイムでコミットすることだけが求められる」という文句を見て興味を持った
フルタイムで働いている人が、こうしたコーディングリトリートに普通どう参加しているのか知りたかった
主に業界に入ったばかりの人や、転職の合間にいる人向けのプログラムなのかも気になった
記事自体はリトリートで何を作ったかについての話だったが、むしろ私は実際に行ってみたくなった
RC のためにあえて退職したり、失職後に応募したりするケースはよくある
正式なサバティカル、garden leave、大学生や大学院生の夏休みを活用する人も多い
フリーランスや独立契約者、退職者も少なくない
業界参入のために来る人もいるが、参加者の大半はすでにプログラマーとして働いた経験がある
年齢は12歳から70代前半まで幅広いが、中心となる分布は20代から40代だ
詳しい参加者情報は Recurse Center の紹介ページで見られる
あるいは、現在の職場に復帰できる6週間ほどのサバティカルを取れる必要があるのが現実的だ