AIコーディングをあえて遅くする——兼業でGo OSSを書く自分の場合

今朝の研究ログに、nolanlawson の「Using AI to write better code more slowly」が入っていました。AI コーディングはほぼ常に「速く出すための道具」として語られます。この記事はその前提を引っくり返して、AI をあえて遅く使うことでコードの品質を上げる、という主張を立てています。読みながら、これは時間がいちばん足りない兼業の個人開発者にこそ刺さる話だと感じました。速さを求める動機が、誰よりも強い立場だからです。

「速さの道具」という前提が、いちばん危ういところ

記事の中心にあるのは、良いソフトウェアのボトルネックはタイピング速度ではなく理解の速度だ、という指摘です。AI にコードを生成させてそのまま受け入れると、確かに速くはなります。ただその速さは、裏返せば「自分が理解していないコードが増える速さ」でもあります。著者が提案するのは、AI を生成器としてではなくレビュアーや説明役として使い、自分の理解を補強する方向に倒すことでした。コードを書く時間にではなく、コードを理解する時間に AI を投資する、という発想です。

自分にとって耳が痛いのは、速さの誘惑が構造的に強いことです。平日は受託開発の本業があり、OSS に割けるのは夜と週末の限られた時間でした。その制約のもとでは「AI に書かせて、動いたら次へ」という回し方が最短に見えます。けれど gpdf のように他人が import して使う OSS では、動いて見えるコードと本当に正しいコードの差が、そのまま issue になって返ってくるのでした。

兼業で OSS を出すと、品質のツケは必ず後から来る

gpdf は Pure Go・zero-dependency の PDF ライブラリで、2026 年 3 月に v1.0.0 を出しました。たとえば CJK フォントのサブセット化のような部分を AI に一気に書かせて「テストが通ったから OK」とすると、後でほぼ確実に詰まります。フォントの仕様は例外の塊で、通ったテストが仕様のごく一部しか踏んでいない、ということが珍しくないからです。ここで AI を速さのためだけに使うと、理解しないまま動くコードが積み上がり、半年後に自分自身がそのコードを読めなくなるのでした。

だから最近は、実装を頼む前に AI へ「このコードはなぜこう動くのか」「この実装で踏んでいない仕様はどれか」を先に聞くようにしています。生成より先に説明をさせる、という順序です。記事の言う「遅く使う」は、自分の文脈ではこの順序の入れ替えとして効きました。タイピングそのものは速くなりませんが、後から効いてくる理解の速度のほうが上がる、という気がしています。

「遅く使う」をルールにしないと、結局は速さに引っ張られる

意志の力だけで遅く使おうとしても、時間が無ければ結局は速い方へ流れます。だから自分は、AI の使い方そのものを工程に埋め込むことにしました。具体的には、リリース前の検証を AI のレビューだけで済ませない、というルールです。AI に一度説明させたあとで、自分の手でベンチマークと例外ケースを通す。この二段構えは リリース前検証の戦略 として前に書いた工程と地続きで、AI を入れても骨格は変えていません。

逆に言えば、時間設計を変えずに AI だけ足すと、浮いた時間はそのまま「もっと速く出す」に吸われます。AI で浮かせた時間をどこへ置くかは、兼業 OSS 開発者の一日の時間設計 の問題そのものでした。速く書けるようになったぶんを理解に回せるかどうかは、ツールの性能ではなく時間の置き場所で決まると思っています。

質問への応答

兼業だと、結局は速い方が正解では?

締め切りのある本業のコードなら、速さが正解になる場面は多いです。けれど自分が一人で保守する OSS は事情が違います。速く出した不明なコードの保守コストを払うのも、結局は自分一人だからです。チームなら誰かが理解を肩代わりできますが、一人だと理解の借金は全部自分に返ってきます。だから OSS に限っては、遅く使って理解を残すほうが、長い目で見れば速いと考えています。

今朝の他に読むべき記事

• Language Models Need Sleep (arXiv / Hacker News) 睡眠のような統合フェーズを挟んで、LLM の短期コンテキストを永続的な重みに変換する仕組みを提案した論文です。AI のメモリ管理が「記憶の固定化」に向かうという視点が面白いと感じました。
• Does anybody actually like React? (Hacker News) React を長年使った開発者が「使わない理由は多いが使う理由は無い」と論じ、ネットワーク効果で技術選定が歪む構図を批判しています。nadai.dev を Vue で組んだ自分には、他人事ではない話でした。
• The User Is Visibly Frustrated (Hacker News) AI エージェントが「人間らしく振る舞う」ことで逆に苛立ちを生む、という逆説を論じ、あえてロボット的な UI に振り切る設計を提案しています。
• Ferrari Luce (Hacker News) Jony Ive と Marc Newson が手がけた Ferrari 初の EV で、タッチ至上主義を排して物理コントロールに回帰したインテリアが話題になりました。物理 UI の価値を問い直す事例として読めます。
• Uber COO says AI spending is getting 'harder to justify' (Fortune / Hacker News) Uber の COO が「AI の年間予算が 4 月に枯渇したが、消費者向け機能の増加との因果が見えない」と述べ、AI 投資の費用対効果に疑問を呈しました。今朝の本題とも地続きのテーマです。
• Netherlands blocks US takeover of vital digital supplier (Politico EU / Hacker News) オランダ政府が DigiD を支えるクラウド Solvinity の米企業による買収を初めて阻止しました。CLOUD 法に基づくデータ要求リスクが、公共インフラ M&A の壁になり始めています。

次に gpdf のフォント周りを触るときは、AI に書かせる前に、まず仕様を説明させるところから始めるつもりです。速さは本業のほうに置いておいて、OSS には理解を残しておきたいと思っています。