あなたは今も、自分の手でコードを書いていますか？
先日、Redditのr/javaにあるスレッドが立ちました。
タイトルは「Do you still handcraft your java projects?」です。
そして、大きな議論を呼びました。
AIがコードの大半を書く時代になりました。
では、Java開発者たちは実際どう働いているのか。
現場の生々しい声が集まっていたので、論点ごとに紹介します。
発端となった問い
投稿者の悩みはシンプルでした。
LLMにコードを書かせる人が増えています。
しかし、自分は主にプランニングにAIを使い、コード自体は手で書きたい。
なぜなら、読むだけの開発を続けたら、スキルが衰えてしまう気がするからです。
そのうえで、投稿者はこう問いかけました。
「あなたの職場では、Spring Bootプロジェクトをどんなワークフローで開発していますか？」と。
この素朴な質問に、100件近いコメントが寄せられました。
手書き派の実体験：AIが2日間を無駄にした話
最も支持を集めたのは、完全手書き派のコメントでした。
ドキュメントを読んで、ひたすらタイプする。
それだけだと言います。
興味深いのは、その人がAIを試した実体験です。
Spring Securityのバージョンアップで、問題が発生しました。
そこでAIに解決を頼ったところ、もっともらしい解決策を次々と提示されます。
しかし、どれも的外れでした。
結果として、丸2日を浪費したそうです。
真の原因を突き止めたのは、AIではなくデバッガでした。
JDBでサービスの起動処理を追いかけます。
すると、原因が判明しました。
CGLIBプロキシを期待するメソッドに、Javaプロキシが渡されていたのです。
修正自体はたった1行でした。
ただし、コードベースは約20万行あります。
その中から1行を特定する作業こそが、仕事の本体だったわけです。
この人の結論は示唆に富んでいます。
デバッガの環境を整え、ライブラリの内部も理解しました。
だから、同種の問題は今なら数十分で解決できる。
つまり、AIへの依存よりも自分の調査能力への投資が効いたのです。
なお、この人はAI否定派ではありません。
数ヶ月に一度は真剣に試していると明言しています。
個人の作業で有効性を確認できるまで、業務では使わない。
それだけの話だと述べていました。
「AIなら20倍速い」という主張と、その反応
対照的に、強烈なAI推進派のコメントもありました。
その主張はこうです。
コードを書く前に、AIへ徹底的な分析をさせる。
次に、複数の解決案を比較する。
さらに、仕様書とTDDベースの計画を作らせる。
そうすれば数時間でPRまで到達でき、手書き派の20倍の成果を出せる、と。
しかし、このコメントは150以上のマイナス評価を受けました。
スレッド内で最も批判されたコメントです。
反論の中身も具体的でした。
CIパイプラインや要件の検討など、コーディング以外の工程は消えません。
また、トークンコストもゼロではありません。
ある大手企業の開発者は、こう証言していました。
端から端まで見た生産性向上はせいぜい25%程度で、しかも1人あたりのコスト増を伴う、と。
どちらの極端にも与しない。
それがこのスレッド全体の空気でした。
中間派の使い分けが面白い
実は、コメントの大半は「場合による」派です。
そして、その使い分けの基準がそれぞれ具体的で、参考になります。
ある開発者は、自分のやり方を「レイヤーケーキ」と表現していました。
人間とAIの層を、交互に重ねる方式です。
例えば、手でコードを書いたらAIにユニットテストを任せる。
逆にTDDで自分がテストを書き、実装をAIに直させてもいい。
ただし、コードとテストの両方をAIに書かせると破綻するそうです。
なぜなら、ロジックの微妙な誤りに気づけなくなるからです。
タスクの性質で線を引く人もいます。
よく挙がっていた判断基準はこうです。
- 仕様が明確で、探索の余地がないタスクはAIに任せてレビューする
- 未知の領域や設計判断が必要なタスクは、学びのために自分で書く
- 何百回も書いてきたREST APIのような定型作業は、迷わずAIへ
3つ目の基準を挙げたのは、あるOSSメンテナーでした。
その言葉が印象的です。
人は自分で手を動かして初めて、知識を長期記憶に定着させられる。
だからこそ、初めて挑む難しいタスクは自分で書くべきだ、と。
挑戦的な仕事は、そう頻繁には巡ってきません。
その貴重な学習機会をAIに渡すな、という指摘です。
比喩も豊富でした。
LLMとの開発を「熱心なジュニアとのペアプロ」と呼ぶ人がいます。
一方で、「極めて博識で疲れ知らずのシニアパートナー」と評する人もいました。
さらに、コンパイラ黎明期との比較も出ています。
数年後には、LLMを使わない開発は奇異に見えるだろう。
ちょうど、1980年代に手書きアセンブリへ固執するのと同じように。
そんな予測です。
見落とされがちな著作権の問題
技術論とは別の角度から、法的リスクを指摘するコメントもありました。
まず、欧州の観点です。
LLMが生成したコードは、著作権保護の要件を満たさない可能性があります。
つまり、生成コードにライセンスを付与できません。
すると、企業環境では雇用主への利用許諾の扱いが曖昧になります。
一方で、逆方向のリスクもあります。
そのコードが、学習元の他者コードを侵害している危険です。
しかも、事前に知る手段がありません。
これに対して、反論も出ていました。
米国の判例では、LLM生成テキストへの人間による著作権が認められている、と。
要するに、法域によって扱いが割れており、決着していないのです。
生成コードを業務に取り込むなら、この不確実性は頭に入れておくべきでしょう。
スキルは本当に錆びるのか
投稿者の元々の不安、つまり「スキル喪失」についても議論がありました。
楽観派の意見はこうです。
使わないスキルが衰えるのは、AI以前から人生でずっと起きてきたこと。
だから、必要になったら学び直せばいい。
対して「そんなに簡単な話ではない」と切り返す声もありました。
あるベテランは、率直に恐怖を語っています。
30年以上、エンタープライズ開発を続けてきた人です。
積み上げてきた知識が、一瞬で処理される様子を目にする。
そして、自分のキャリアの存在意義を自問していると。
それでも、この人は前向きに結んでいました。
恐怖に未来を決めさせてはいけない。
なぜなら、開発者は言語もフレームワークも設計手法も、何度も学び直してきた職業だからです。
一方で、こうした「適応せよ」論への冷静なツッコミもありました。
エージェントに任せきりにすると、どうなるか。
20コミット後には、テストは通るが理解不能なコードの山ができあがる。
そんな現場報告です。
人間のレビューなしのマージは「ゲームオーバー」だと。
まとめ
スレッドを通読して、見えてきたことがあります。
完全手書き派も完全AI派も、実は少数だという事実です。
大多数は使い分けています。
定型作業とテストはAIへ。
設計判断と学びのあるコードは自分の手で。
そして、生成物には必ず人間のレビューを通す。
この中間地帯に、現時点での現実解があるようです。
もうひとつ、重要な教訓があります。
AIが解けない問題に直面したとき、最後に頼れるのは何か。
それは、デバッガを扱う力であり、システムを理解する力でした。
検証できない者は、AIの出力を評価できません。
あなたのチームでは、どこに線を引きますか？
この議論は、自分のワークフローを見直すいいきっかけになるはずです。
