ハクソク

世界を動かす技術を、日本語で。

3ヶ月間手作業でコーディングする

19時間前原文(miguelconner.substack.com)

概要

  • Brooklynでのコーディング・リトリート体験記
  • AI時代にあえて「手書きコーディング」に集中した理由
  • Aily LabsでのAIエージェント開発経験
  • Recurse Centerでの学びと目標
  • 今後の課題と成長の実感

Brooklynでのコーディング・リトリート体験

  • 2026年3月、Brooklyn, New Yorkでコーディング・リトリート開始
  • 個人的な理由でアメリカに帰国、すぐに仕事復帰せず自分のための時間を確保
  • AI全盛の時代に、あえてAIなしでのコーディングに挑戦
  • 6週間経過時点での進捗と学びの振り返り

Aily LabsでのAIエージェント開発

  • BarcelonaのAily LabsでAIエージェント開発に従事
    • 2024年初頭、社内用ウェブ検索エージェントを開発
    • AnthropicやOpenAIによる類似記事発表よりも半年～1年以上早い取り組み
  • CursorやLLMを活用したナレッジグラフ構築にも初期から関与
  • 週次ジャーナルクラブを主催し、DeepSeek R1、Olmo 3、Llama 3論文などを紹介
  • オープンソースLLMの構築手法や、内部トレーニングとSOTAクローズドモデル活用のトレードオフを理解
  • LLMへの関心が高まり、仕組みや応用方法の探求が続く

コーディングエージェントとの関わりと気づき

  • 手書きコーディングでは「やりたいことの記述」と「コードベースの理解」を同時に進行
  • コーディングエージェント使用時は、プロンプト通りの出力が得られるが、学びや理解が浅くなりやすい
  • エージェントは迅速な反復やソフトウェア出荷には有効だが、深い理解には手書きが有効
  • Cal Newportの「思考と技術の関係」論に共感し、コードを書く苦労自体が成長につながると実感

Recurse Centerでの目標と進捗

  • Recurse Center (RC)：Brooklynにある自己主導型・全日制のプログラミング・リトリート
    • 入学には応募・コーディング面接が必要
    • 多様なバックグラウンドの参加者と協働的な学び
    • 無料で参加可能
  • 入学時の目標
    • LLMをゼロから訓練（前処理・後処理含む、Transformerの自作）
    • Python手書き力の向上（ドキュメントやLLMに頼らず直感的に書ける力）
    • コンピュータの仕組み理解（抽象化レイヤーの全体像把握）
  • CS336: Language Modeling from Scratchの課題に挑戦
    • LLMなしでトークナイザーやGPT-2風アーキテクチャを自作
    • Tiny Storiesデータセットでハイパーパラメータチューニング、OpenWebTextでも適用
    • 次の課題ではGPUプロファイリングやFlashAttention2実装にも着手

RCでの学びと成長実感

  • PythonやPyTorchで小さなエージェントやニューラルネットを多数作成
  • 10年以上の経験者とのペアプログラミングが最も役立つ
    • 分からない操作は即座にターミナルで試す習慣化が効率UPに直結
    • Advent of Codeなどの小プロジェクトで反復練習
  • Apple IIeでBASICのfizzbuzz実装など、レガシー環境での体験
  • CTF FridaysでUnixやセキュリティの基礎を実践的に学習
  • Vimのみでパーセプトロンを手書き実装、クラウドGPUでの運用にも役立つ
  • Clojureワークショップで関数型言語とモブプログラミングを体験
  • 週次テクニカルトークで幅広いテーマに触れ、発表経験も積む

今後の課題と展望

  • まもなくエージェントの本番投入や評価にも着手予定
  • 残り6週間で全ての目標達成は困難だが、「リストを消化すること」より「コーディングに没頭する時間」自体がRCの価値
  • AIと人間の学びのバランスを模索し続ける姿勢

注記

  • 日本語学習経験とLLMの出現に対する驚きや、LLMなしでのデバッグの苦労も言及

Hackerたちの意見

すごい！自分もRCで12週間のバッチをやったけど、めっちゃ楽しかったよ。コーディング楽しんで！好奇心を持ち続けてね。
└
RC仲間だよ、こんにちは！自分はFall 2 '23だった。
└
RCの大ファンだよ。親友がやってた。自分も何度も応募しようと思ったけど、タイミングが合わなかったんだ。
脳みそをlean、coq、haskellに使えるのが大好き。楽しいことがいっぱい！お金の仕事はほとんどエージェントに任せてる。
自分のやり方はこうだよ：AIをフル活用してたくさんのものを作るけど、AIが出すコードが自分の認知負荷基準をクリアしてるかを確認するために必要な時間も使ってる。コードを整えたり、しっかりドキュメントを書くためにトークンを使うこともあるけど、これはAGENTS.mdのおかげでほとんど手間いらず。変なことが起きたらすぐに気づくし、軌道修正する。クレジットが切れたら、いよいよショータイム！コードはきれいに整理されてるし、抽象化も意味がある。コメントも役立つから、良い古き良き人間のコーディングができる。限界に近づいたら、AIに舞台を整えてもらうように頼むようにしてる。クレジットが切れるとイライラしてたけど、今は次の「脳の時間配分」を楽しみにしてる。変に聞こえるかもしれないけど、これはチームワークの一形態だよ。もっと大きなプランにお金を払う手段はあるけど、脳をアクティブに保ちたいんだ。
└
共有してくれてありがとう。エージェントが何かをしている間に、自分にタスクを残しておくアプローチについて考えたことがある。脳を活性化させて、萎縮を防ぐためにね。もしかしたら、Claude Codeのスキルやフックを作るべきかも :)
└
> DRYを乱用するな、少しの重複は不必要な依存関係よりマシだ。これは面白いポイントだね。原則的には同意だけど、少なくともClaudeはロジックを重複させすぎてて、逆の方向に押してあげる必要があると思う。
└
> 変に聞こえるかもしれないけど、これはチームワークの一形態なんだ。俺にはできない。LLMにコードを書かせると、そのコードは手を加えられない。俺はそれをブラックボックスとして見ていて、絶対に開けたくない。動けば使うけど、信用はしてない。壊れたらイライラするし。俺にとって唯一うまくいくのは、常に運転席にいて、LLMが俺の質問に答えるアシスタントとしていることだ。何かをブレインストーミングするか、俺が知っていることを言語の構文で表現するのを手伝ってもらう。なんか、そのステップがいつも少し負担に感じてたんだよね。概念はよく理解してたけど、構文で表現するのがちょっと難しかった。
AIのオートコンプリートワークフローにもっと投資してほしいな。あれはいい中間地点だった。でも、直感的には「古いやり方」って感じがするけど、呼び方が正しいかは分からない。広い視点で見ると、「エージェント的」なワークフローと同じくらいの価値があると思う。コードベースの知識がずっと良くなるし、コーディングの概念に対する理解も深まる（アクティブリコールはパッシブリコグニションよりずっと強いからね）。
└
「手動コーディング」の論理は理解できるけど、国を横断するのと飛行機で行くのは違う感じ。飛行機に一度乗ったら、戻るのがすごく難しい…
└
エージェントのワークフローを逆転させるのがすごく楽しいんだ。手動でコードを書いて、エージェントにコードレビューをお願いする。これでコーディングスキルとコードベースの知識が鋭く保たれるし、コミットする前にバグを見つけられるからね！
└
AIのオートコンプリートは最悪だった。みんなすぐに移行しちゃったよ、役に立たないインターフェースだから。
└
ほんと、同じく、Cursorの初期の頃は衝撃的だったよね。でもそれ以来、オートコンプリートは停滞してるし、新しいCursorのバージョンも他のものと同じようにエージェント的になってきてる。もし将来的に拡散モデルがもう少し注目されるようになったら、オートコンプリート関連のワークフローに新しい息吹を吹き込んでくれるといいな。Inceptionのマーキュリーモデルのほぼ瞬時に返ってくるレスポンスは、ちょっと魔法みたいに感じるし、Cursorの洗練さや深いエディター統合が欠けてるだけなんだよね。拡散モデルについて言えば、ローカルで使うには完璧なフィットなのに、重要なオープンウェイトモデルがないのが残念だな。
Zedを半端な手段として使い始めた。AIを使って計画や提案された実装ステップを始めようと思ってる。ノンテクニカルな人たちがClaudeでアプリを作るのを見てる。Openclawや他のエージェント的なトレンドの後、AIに夢中になるのは現実的じゃないと思う。人生の他の面では、自分のスキルが細かいところに気を配る能力や新しい問題に取り組む能力で評価されてきたから、これがどう市場に適応していくのか、そして人々がこの微妙な能力をどうコミュニケートするのか興味津々だ。
3ヶ月の自己学習の旅を過ごせるなんて素晴らしいね。これらの深いスキルは長期的に価値があると思うし、この新しい抽象化はアセンブリからCに移るのとは違うと思うけど、完全には確信が持てない。最近はほとんどのコードがLLM生成で、自分が仕事の終わりに楽しさや達成感、満足感を感じることはないな。でも、実際にはコーディングの5〜10%だけを楽しんでいて、残りはその小さな面白いコアを支えるための面倒な半機械的な変更ばかりだって気づいた。人類の歴史のスケールで見ると、コンピュータと仕事をするのはほんの一瞬の出来事で、100年後には手書きのコードがどう見られるのか気になる。もしかしたら脚注として扱われるか、単に「機械が自己自動化する前のすべて」としてまとめられるかもしれないね。
└
現在のシフトは「アセンブリからコンパイル言語への移行」に似ているかもしれないと思う。昔はアセンブリ言語でコードを書いていたけど、次第にCや他のコンパイル言語に移った。アセンブリプログラミングは非常に役立つけどニッチなスキルになった。コードをコンパイルして、コンパイラを信頼する。コンパイラの出力を確認することは時には必要だけど、それをできる開発者は多くない。今も似たようなことが起こっているかもしれない。ほとんどの開発作業がLLMの抽象レベルに移行していて、必要なスキルは良いプロンプトを書くことや、コンテキストウィンドウ、エージェント、メモリーの管理など。いくつかの開発者はLLMが生成したコードを確認して問題を見つけることができるけど、大半はそのスキルを持っていない。どう感じるべきか分からない。ChatGPTが登場してから、数ヶ月前まではLLMプログラミングに対して懐疑的だった。数週間ごとに新しいモデルが出てきて、毎回同じ低品質の出力の違うバージョンだと感じていた。でも最近、モデルがある閾値を超えたようで、能力が本当に向上したように思う。今はClaudeを使っていて、まだ控えめに使っているけど、自分が必要な時間よりもずっと短い時間で機能を実装したり、ログ出力だけでバグを見つけたりしている。「コーディングは解決された」というハイプにはまだ懐疑的だけど、高水準プログラミング言語の採用以来、プログラミングにとって最大の変化を迎えているのは確かだ。
今学期、18歳の学生たちにエミュレートされたApple II Plusを使って6502アセンブリプログラミングを教えてるんだ。彼らはPythonの入門やデータ構造、オブジェクト指向プログラミングの授業を受けてきたけど、今は1983年に書かれたエディタ/アセンブラを使って70年代のチップをプログラミングしてる。クラスとラボで合計10時間、アセンブリ言語について教えたり、レジスタや命令、アドレッシングモード、Appleのメモリマップやモニタルーチンについて話したりした後、一緒にいくつかのプログラムを書いたよ。主に低解像度のグラフィックスモード（40x40）を使って、描画プログラムやバウンスボール、最後には手作りのスプライトで簡単な衝突検出を実装した。彼らの課題は、簡単なプログラムを書くこと（低解像度のゲーム、例えばスネークやテトリスを提案したけど、彼らがやりたいことなら何でもOK。ただし、事前に教えてもらって承認を得る必要がある）。プログラムをデモして、クラスにその仕組みを説明するんだ。最初はラインエディタが嫌いだったけど、面白いことが起こった。コードを書く前に考えるようになったんだ。計画を立てたり、事前に話し合ったり。前の授業でコードを書く前にやるべきこととして教えたことを、強力なエディタがあったからやらなかったのに、今はラインエディタに慣れてきたみたい。画面にコードを表示する必要はないって言ってた、頭の中にあるから。授業が終わったらもちろん現代のツールに戻るけど、こういう経験をするのはいいことだと思う。
└
大学でこういった授業をいくつか受けたよ。ベアメタルの68kアセンブリで基本的なOSを書く授業や、ブレッドボードで周辺機器を配線する授業など。74シリーズのロジックチップだけを使ってALUを作ったりもした。30年前のことだけど、70年代のチップはすでにアンティークだった。でも、その授業の教訓は時代を超えていると思う。こういうコースが今も存在していることが嬉しいし、みんなが標準のコンピュータサイエンスのカリキュラムの一部として受けられる機会があればいいのにと思う。少なくとも私にとっては、コンピュータ機械に対する視点を根本的に形作ってくれた経験だった。今はアタリのために6502/7アセンブリをプログラムして、リラックスしているけど、それが私をグラウンディングして喜びを与えてくれる。一方で、仕事では10レベル以上の抽象化が進んでいる。
└
>> Edは、自分が何をしているかを覚えている人のためのものだ。 https://www.gnu.org/fun/jokes/ed-msg.html 大学を卒業して最初の仕事で、IBM UniDataのラインエディタの使い方を教わった。ああいう風にコードを書くのに慣れるのは面白かった。でも、「プログラムテーブル」がFTPでマウントできるサーバー上のディレクトリに過ぎないことを発見した日は素晴らしかった。
└
9年前に似たような授業を受けたんだけど、正直言ってそれがCSの学位で得た中で一番役に立ったことの一つだった。低レベルで限られたツールを使うことで、書き始める前に考えることを学んだんだ。他の人からは変な目で見られることもあったけど、グリーンフィールドの仕事では、ペンとグラフ用紙から始めることが多い。擬似コードを書くわけじゃなくて、潜在的な関数やクラスをつなげた緩いグラフを図示してる。もちろん、これをやりすぎると、完全なウォーターフォール計画は別のフラストレーションの運動になるけどね。エディタを開く前に数時間計画を立てることで、実際にコーディングする時間がかなり節約できることがわかった。プロジェクトが紙の図に似ることは一度もなかったけど、事前に全体の構造を考えることで、コードを書く時にすごく生産的になれるんだ。エディタで図示したりスキャフォールディングしたりしたこともあるけど、結局大きな絵を描くんじゃなくてコードを書いちゃうんだよね。紙に書くことで、どうせ再入力しなきゃいけないってわかってるから、どのメソッドを使うかとか変数の名前をどうするかっていう気が散る要素がなくなるんだ。数回 vibe-code した時にはこれがすごく役立ったよ。具体的で集中したプロンプトを出せるからね。
└
初めての本格的なプログラムはUVEPROMコピー機だった。MC6800のマシンコードで書かれていて、RAMは256バイト（キロバイトじゃないよ）しかなかった。コードも含めてね。それが1983年のこと。今はSwiftでLLMを使って、Xcodeで結構大きなアプリを作ってる。ストレージは最低64GB、RAMは8GBのデバイス向けだ。正直、昔の良き時代が恋しいわけじゃない。今はすごく楽しいよ。
└
これ全部大好きなんだけど、少なくとも学生にはviを使わせてあげてほしいな。あの頃はあったし（近い時期でも）、現実の世界に戻っても手放さなくていいスキルだからね！
└
最近、Psion 3a（90年代初頭のポケットPC）用にワードルクローンをコーディングした時に似たような体験をした。画面には数行のコードしか表示されないし、内蔵IDEはテキストエディタに近いものだった。プロセスがすごく楽しかったよ。
└
楽しいアーキテクチャを選んでくれてありがとう！最初からx86のクルフトで人を怖がらせるのは誰にとっても良くないよね :-)
└
エンジニアとして成長する中での一番好きな体験の一つは、最初の頃に非常に経験豊富なエンジニアと一緒に働いたことだ。彼はタスクや問題があると、まず考え始めて、紙にちょっと落書きしたり、散歩に出たりしてから、やっとコンピュータの前に座ってタイピングを始めるんだ。一気にタイピングして、最後にコンパイルして、ちゃんと動くんだ。（タイプミスもほとんどなかった。）つまり、プログラムと問題空間を頭に入れておくのがすごく役立つってことだ。事前に考えることで、何を期待しているのかが明確になって、予期しないことが起こった時に気付きやすくなる。
└
ちょっと脱線するけど、動的型付けと静的型付けは同じように機能すると思う。俺はよく切り替えるんだけど、動的型付けから長いブレイクを取った後に戻ると、すごく重く感じる。「どうやってこれをやってたんだっけ？」って感じ。ほんと重い。でも数時間（または数日）経つと、何が問題だったか忘れちゃう。脳の一部が目覚めるんだ。何を渡しているのか考え始めて、文脈や名前から型を認識し始める… ただの考え方の違いなんだよね。長時間バイブコーディングして運転席に戻った後に、同じ感覚を認識した。もう二度と手放さないって決めたんだ。
└
これはデザインスクールでスケッチやクレイモデリングを学び続けるのとすごく近い感じだね。
AI、特にGenAIの大ファンなんだけど、手でコーディングする時間も結構取ってるよ。「手で書く + Copilotの補完を使う」って感じでね。もちろん、SpecKit + OpenCodeを使った仕様駆動開発や、たまに「バイブコーディング」もするけど、今のところコードを理解する責任を放棄したり、書き方の知識を捨てたりするつもりはない。最近はLISPやJavaの新しい本も何冊か買ったし、それぞれの分野を復習してる。Forthの本もその前にいくつか買ったよ。しばらくは完全にコーディングをやめるつもりはないな。
└
私の責任は、自分のコードが機能要件と非機能要件を満たしていることを確認すること。つまり、*動作*を理解することだ。自動化されたユニット、統合、負荷テストがそれを確認してくれる。ある人は、私が「バイブコーディング」で作った内部ウェブ管理サイトが、コードを一行も見ずにセキュリティ要件を満たしていると言ったら、ナイーブだと思ったみたい。でも、要件は「サイトにアクセスできる人は誰でもサイト上で何でもできる」というもので、サイトはAmazon Cognitoの資格情報で保護されていて、提供しているLambdaには最小権限のロールが付いていたから、そう言えるんだ。もしその不変条件が破られたら、Claudeは大きなAWSの脆弱性を見つけたことになる。
キャリアの最初の数年は、SPARCでSolarisを動かしながら、vi（vimじゃない）でコード（主にPerl）を書いてた。O’RileyのPerl Cookbookを買って、それが当時の唯一のガイドだった。インターネットフォーラムも少ししかなかったし、検索エンジンもまだ原始的だったから、詰まった時に助けを求めるのがすごく難しかった。でも、そのおかげで多くのことを深く学ぶことができたんだ。Perlの構文（構文ハイライトやインテリセンスなんてなかったし）、ターミナルツール、特にviのキーストローク。振り返ると、当時は気が散る要素や「ノイズ」がずっと少なかったけど、キャリアの始まりだったから期待値が低かったのかもしれない。あの頃が懐かしいな、今はすべてが信じられないくらい複雑で層が多い感じがする。
└
> あの頃が恋しいな。今はすべてが異常に層が深くて複雑に感じる。俺にとってはGW-BASICで、今のようなエディターはなかった。即時満足、迅速な開発、無駄な層もなくて、すごく純粋だった。それが俺を引き込んだんだ。ある意味、エージェント的なコーディングは、ソフトウェアを作る楽しさを取り戻してくれた。すべてのクレイジーなエンタープライズや現代の開発の考慮を直接扱わなくて済むからね。思考と結果の間にもっと近い繋がりがあって、それが俺の想像力を掴んだ魔法だったんだ。
このタイトルは、このサイトで読んだ中で一番落ち込む内容だな。
└
これがジョークかどうか確かめたくなった。おお、まじか。