2025年の私のGitHubグラフは、まるで別の開発者が前半と後半を担当したように見えます。前半はほとんど空白。後半だけで4,000件を超えるコミットがあります。
急に自由時間が増えたわけではありません。フルタイムの仕事をしながらサイドプロジェクトを進める状況は変わっていません。変わったのは、アイデアから「とりあえず動くもの」までに必要な摩擦でした。AIコーディングツールを本格的に使うようになったことで、その距離が明らかに短くなりました。
ただし、この数字は慎重に扱う必要があります。コミット数そのものは生産性の指標ではありません。4,000コミットあったからといって、4,000個の有益な改善をしたことにも、コード品質が高かったことにもなりません。それでも、働き方が大きく変わった証拠にはなります。以前より継続的に作り、直し、実際に動くところまで持っていく回数が増えました。
本当のボトルネックは、実験を始めるためのエネルギーだった
個人開発では同じ問題を何度も経験しました。最初の有用なバージョンに到達する前に、routing、validation、script、test、configuration、cleanupなどの定型作業が大量にあります。アイデアに価値があるか確かめる前に、そこで勢いを失うことがあります。
以前は、最初の動く状態まで数晩かかりそうな実験を後回しにしていました。AI coding toolは作業そのものを消したわけではありませんが、first passのコストを下げ、testableな状態までの距離を短くしました。
最大の変化はtyping speedではなく、activation energyが下がったことです。実際に試して証拠を得られるアイデアの数が増えました。
Node.js workflowで実際に変わったこと
開発プロセスをchat windowに置き換えたわけではありません。Node.jsのside projectでは、DeepSeekを明確に範囲を切った作業のsecond pair of handsとして使いました。最初の実装案、未知のcodeの読解、test案、stack traceの整理、大きなrefactorの分割、deployment assumptionの確認などです。
- Scaffolding: handler、validation、script、testの退屈な初版を作る。
- Code reading: edit前にrequestやvalueの流れを追う。
- Refactoring: 大きな変更をreviewしやすい小さなdiffに分ける。
- Debugging: logから複数の仮説を出す。
- Verification: happy pathの後にedge caseとregressionを探す。
input、output、constraint、既存のconventionが明確なほど、結果は検証しやすくなりました。曖昧なtaskほど、もっともらしいが間違ったabstractionを作りやすくなります。
そのためAI outputはfinal answerではなくcandidate patchとして扱いました。Type check、test、build、実際のflowが証拠であり、自信のある説明は証拠ではありません。
DeepSeekが最も役立った場面と、そうでない場面
DeepSeekは、具体的なprogramming taskに繰り返し使える点が私には便利でした。first passを出させ、一部を捨て、実際のerrorを返し、scopeを狭めて再試行する流れを速く回せました。
これはbenchmarkではありません。すべての競合modelとcontrolされた比較をしたわけではなく、model lineupもすぐ変わります。言えるのは、DeepSeekが私のworkflowに十分合っていたため、AI assistanceを使う頻度が大きく増えたということです。
function、test、実際のerrorが揃う問題では強く、暗黙のproduct contextや微妙なarchitecture trade-offが必要な問題では弱くなりました。後者では、流暢な回答が悪い仮定を完成品のように見せる危険があります。
AIが変えたのは「実験のコスト」だった
私にとって最大の変化は、「AIがコードを書くから開発が自動化された」という話ではありません。小さな要素を試すコストが下がったことです。以前ならセットアップを考えただけで後回しにしていた機能でも、アイデアへの熱が残っているうちにプロトタイプまで持っていけるようになりました。
ここは重要な違いです。AIは検証可能なバージョンまでのコストを下げましたが、アーキテクチャ、プロダクト判断、デプロイ、正しさの確認を不要にはしていません。生成された実装は間違うことがあります。ビルドが通っても実行時に壊れることがあります。デプロイできても、良いプロダクトだとは限りません。
私にとって実際に大きかったのは勢いでした。システム全体が一度動くところまで見えると、その後の改善を続ける心理的なコストが大きく下がりました。
より強いbenchmarkに必要なもの
再現可能なbenchmarkにするなら、正確なmodel version、固定したprogramming task、repository snapshot、prompt、raw output、所要時間、accepted/rejected patch、review time、test result、rework量を記録します。
commit数だけでなく、ideaからverified versionまでの時間、defect、rollback、書き直しも測るべきです。そうしたcontextなしでは、4,000件のcommitは活動量と行動変化の証拠ではあっても、software qualityの証明にはなりません。
私にとって何が変わったのか
2025年は、サイドプロジェクトを「本題に入る前に手作業で登らなければならないセットアップの山」と考えなくなった年でした。AIによって最初の動くバージョンを作るコストが下がり、プロダクトとしての判断が必要になる地点まで到達しやすくなりました。
GitHubグラフの後半が前半とまるで違うのは、そのためです。AIが一日の時間を増やしたわけでも、生成されたコードがすべて良かったわけでもありません。以前ならアイデアが形になる前に失われていた摩擦を減らしてくれました。
2026年に私が重視したいのは、その次の、少し地味な部分です。ワークフローを磨き、品質をもっと真面目に測り、開発速度の向上が単なるコミット数の増加ではなく、より良いソフトウェアにつながっているかを確認していきたいと思っています。