AIコーディングエージェントに全面移行したエンジニアが「もうコードを書かない」と宣言するエッセイが、2026年5月にHacker Newsで話題を集めた。関数1つ、バグ修正1件も自分では書かず、設計とレビューに集中するスタイルへ移行した経緯と、その先に見えた「コーディングの本質」を率直に綴った内容だ。

「編集画面を開いた瞬間、面白い部分は終わっていた」

著者は18年のキャリアを持つエンジニアで、splitキーボードとnvimにこだわり、スケーラブルな分散システムの構築にも携わってきた。現在はenum社でAIエージェントを活用した開発を推進しており、自身のブログから複雑なプロダクション実装まで、コードの生成はすべてエージェントに委ねている。

著者が気づいたのは「自分が本当に楽しんでいたのはタイピングではなかった」という事実だ。

  • このシステムは何をすべきか
  • 障害発生時にどう振る舞うべきか
  • どこに複雑さを集約すべきか
  • 正しい抽象化の境界はどこか

これらの意思決定にこそ知的な楽しさがあった。コードを書く作業は、その決定を現実に翻訳するための「繰り返し作業」であり、同じパターン、同じインポート、同じリトライループを何千回と打ち込む筋肉記憶に過ぎなかったと振り返る。

AIエージェント移行後の「本当の仕事」

著者が今やっていることは次の通りだ。

設計とアーキテクチャ: スケーラブルなリコンサイラーパターンの設計、データの置き場所の判断、次に解くべき本質的な問題の特定。

コードレビューと品質管理: エージェントが出力したコードを精査し、問題のある抽象化パターンや「偽のテストカバレッジ」を見抜く。AIへの移行後、以前よりも「読むコードの量」が増えたと著者は言う。自分でタイピングする代わりに、エージェントの出力を常に読んでいるからだ。

意思決定の明確化: 何をプリミティブとして定義し、何を合成で表現するか。この判断軸はAIには委ねられない。

著者はこう結論づける。「スキルとして重要なのはセンス（taste）だ。設計が悪いと気づけるか、崩壊寸前の前提を見抜けるか、何にこだわり何を手放すかを知っているか。これは何も変わっていない。むしろより重要になっている」。

日本のIT現場への影響

この話は海外のハイエンドエンジニアだけの話ではない。GitHub Copilot・Claude Code・Cursor等のAIコーディングエージェントは既に日本のエンジニアにも広く手が届く段階にある。

問題は「使うかどうか」ではなく、「どの仕事をAIに任せ、どこに人間の判断を集中させるか」という役割設計だ。

エンジニアリングリード・IT管理者へのポイント:

  • コードを書く時間の削減 ≠ 仕事量の削減: 設計・判断・レビューに使える時間が増えることを意味する
  • コードレビュー力が核心スキルになる: AIが生成したコードの品質を判断できるかどうかが、今後の差別化ポイントになる
  • 採用・評価基準の見直しが必要: 「何が実装できるか」より「何を設計・判断できるか」への転換
  • AIを「使わない」ことそのものがリスク: 現時点でAIコーディングエージェントを積極的に活用しないエンジニアは、生産性の面で大きなハンデを背負うことになる

筆者の見解

このエッセイが示しているのは、AIエージェントが「コードを書く量」を変えるだけでなく、「誰が何の仕事をするか」という職責の定義そのものを変えているという事実だ。

著者が言う「センス」──設計の良し悪しを判断する力、テストが実質的かを見極める力──は、今後むしろ希少で価値ある能力になる。コードを書けるエンジニアは増えても、「エージェントの出力をレビューして本質的な問題を発見できる」エンジニアは簡単には増えない。

「仕組みを設計できる少数の人間が判断し、AIがそれを回す」というモデルへの移行は、もはや議論の段階ではない。問題は、日本のIT組織がこの変化を表面的な「ツール導入」として処理するか、それとも「誰が何を判断するか」という職責の再設計として捉えるかだ。

AIエージェントを正しく使いこなすことは、単に生産性を上げるだけでなく、エンジニアが本来やりたかった「面白い部分」──設計の意思決定──に集中できる環境を作ることでもある。組織としてその環境を整備することが、今もっとも重要な技術的意思決定のひとつだと考える。

出典: この記事は Going full AI engineer, not touching code anymore の内容をもとに、筆者の見解を加えて独自に執筆したものです。