2025年はAIによってエンジニアリング仕事のやり方が大きく変わった年だった。これは自分だけでなく周りも含めて全体的な変化であり、いまさら特筆すべきことではないかもしれない
しかし技術はどんどん変わっていくものなので「2025年の段階ではこういう感じだった」ということを記録しておきたい
年初〜5月：Cline時代
年初から5月くらいまではClineを使っていた。ClineはVSCodeの拡張機能として動作するAIコーディングアシスタントでそれまでのGitHub Copilotのようなコード補完型とは異なり、対話的に開発できるため非常に新規性を感じてのめり込んで使っていた
ただ処理速度が遅かったり、細かい実装の一つ一つを確認しながら進める必要があったりして「これならまだ手で書いた方が速い！」とだいぶストレスフルだったような覚えがある
5月以降：Claude Codeへの移行
5月にClaude 4モデルと同時にClaude Codeがv1.0として正式リリースされ、移行した
Claude CodeはCLIツールとして動作し、要件を相談すれば自律的に調べて進めてくれる。Clineと比べて大きく成果が出た要因は、モデル性能の向上や各種ツールの充実にある。エージェントとして自律的に動くための機能が揃っていた
これにより課題を定めれば高速に成果を出せるようになった。これは個人的に大きな価値観のシフトだった
従来は具体的なコードの実装力が人間に問われるものだったが、文法をlintで自動fixさせたほうが正しくなるように、実装もAIを通したほうが正しいコードになると自分は捉えている。そのため実装自体よりも何が課題でどう解決するかというスコープを定めることが重要になった
つまりエンジニアとしてもう少しメタな立場、実装をマネジメントする意識になった
そもそも何が課題なのか？という問いに取り組むこと。会社組織における開発の立場として、ユーザーの声やサポートからの相談、経営課題など、さまざまな要求に対してより純粋なエンジニアリングを追求する目線になっていった
7月：LT「レビューレスな開発体制へ」
社内の開発ミートアップが7月に開催され、「担当領域 × 自分のエンジニアリングで、何を達成するか？」というテーマで各自LTを行った
自分はそこで「レビューレスな開発体制へ：個人開発のスピードを組織で実現する」というタイトルでLTをした
この話の背景として、休日の個人開発で気づけば100コミット以上していた日があった。個人開発で速度が出る理由は2つある
自分がオーナーであるので全てのドメイン知識を有していることに加え、全ての意思決定ができる
AIと対話しながら作ることでペアプロのように実装しながら課題を紐解いて合意形成ができる（レビュー工程が要らない）
しかし会社組織ではこうした速度を出すことは難しい。原因の一つとして人間によるPRレビューがボトルネックとなる。ではどうしたら個人開発のノリに近づけられるだろうか？というのが自分の考えるチーム開発での課題だった
レビュー問題の本質
実装自体は高速に大量にこなせるようになったぶん、レビューの問題はより大きくなる
AIに任せた実装の良し悪しの判断は難しい
判断できる人でも大量のレビューは捌けない
そもそも人間によるレビューは個人差が大きく、LGTMとしながらもあっさり不具合を見逃すことは多い（なので自分はLGTMという言葉は全く無価値で無責任だと捉えている）。これはAI以前から自分がPRレビューに感じていた課題だった
本質的な指摘をするにはPR内容を背景から完全に理解する必要があるが、一番理解しているのはPR実装者自身でありレビュアーがそれを行うのはコストが高い
そのため結局diffをざっと見て目についたコードの書き方について意見するようなbikesheddingな問題に関心が向きがちになる
本質的な理解のためにはペアプロが有効な手段ではあるけど、これもかなり時間や体力が要る
PRの構造的限界とAIの強み
PRは実装（diff）が主体の仕組みであり、既に実装されたコードから意図を読み取るのは難しい。理想としては実装前に意図だけでレビューする場があれば良いが、実際には実装前に完全な意図を定めることは難しい
むしろAIの強みは、従来コストのかかった実装が手早く行えることで意図の正しさを検証できるところにある。重要なのは実装コードよりも、課題・背景・解決手法の選択意図といったコンテキストにある
数学の試験であれば解答そのものよりも過程の算出式を評価するようなもの。自分はPRの概要にこれらをまとめるようにしている。これらの過程のコンテキストがあれば、間違いが起きたときもなぜそうなったかが分かるし修正もしやすい
11月：セルフマージ解禁へ
従来はレビュー必須の設定にしていたが、11月にはこれを解除しセルフマージ可能とした。当たり前だけどこれで大きく速度が出るようになった。PRのマージ数は一気に倍くらいになった
レビュー必須という設定自体は何年も前からやっており、やらないよりはやったほうがなんらかの信頼性が担保できると考えていたため解除するのはだいぶためらいはあった
ただレビューは前述の通り有効に機能させることは難しい
単に責任を分担するための儀式的なものになっているのならやる意味がない
なので出来ることとしてとにかくCI周りを整備した。以前はPRごとのデプロイプレビューが無かったりさまざまなチェックもあまりされておらず信頼性の担保が難しかったが、それらを自動化していった。AIによる自動レビューも取り入れた
それでも不具合は当然出る。けどまあ、不具合をゼロとするよりも迅速に修正するという方向でカバーできればいいのではないかと捉えている
理想としては各自のドメイン知識を属人化させずに共有し、AIに正しくドメイン知識・課題・ゴール・方針を伝えれば、実装やレビューは正しくできるものだと思っている
仕事時間はむしろ増える
AI使って作業が進むけど、自分はペアプロ的に付きっきりで指示出しするのでどっぷり時間も使っている。気づけば夜になり朝になる。一番働いていたときは30時退勤（朝6時）が週に2回あった
進捗が出るから作業を続けるモチベーションが持続する感じはする
やっぱ成果を出すには結局労働時間よな！みたいな気持ちはある
2025年末の所感
vibe codingの使い分け
AI利用に対してはvibe codingだとひどいコードが作られると批判されがちだが、しかし自分としては使い分けの問題だと捉えている。
可視化のための使い捨てGUI、検証用の試作、即興のリファクタ用ツールなど保守の必要がないものは、実装の詳細は関心事ではなく手早く要件通りに動けばいい
一方で継続的なサービスのプロダクションコードは、問題が起きないように何をどういう意図でやっているかを明確に把握し、コード編集時の影響範囲を限定する必要がある
なにを信頼するか？
例えばfizzbuzzの実装くらいは誰もが当たり前にできそうでも、意外と人間の場合は正答率は低いという話は聞く。しかしAIであれば100%間違えないと言っても差し支えない。正しくスコープを定めれば、AIは人間より確実に信頼できる、というのが自分の前提としてある
だからAI実装が管理できなくなるのは、複雑さを分解せず複雑なまま投げてしまっているからだと捉えている。人間自身が何が課題かを正しく認識して定めていくことは怠ってはいけない
人間が正しく理解し、課題を定める
1999年に描かれた遠藤浩輝の漫画「EDEN」の序盤に、主人公が戦闘ロボットの行動を補助するシーンがあり印象に残っている。近未来の自律型ロボットなのだが、人間がバイザーをつけて戦闘目標を設定する
「火力と機動性はロボットが人間をはるかに上回る。だが瞬間の判断力……つまり「条件反射」的な反応速度は人間の方がはるかに上だ」
今となってはそうした判断自体もロボットに任せたほうが速いんじゃないかと思うけど、しかし「人間が正しく目標を定める」という点については、現在のAI活用においても重要だと感じる
その他：他責志向の良さ
名取さなさんについてはニワカだけど、この切り抜き見て他責にするということに良さがあるなと思った
従来は自分で書いたコードは完全に自責なので言い逃れができない
しかし自分は問題があるコードを調べた挙げ句「このコードはあなたが書きました」とAIに言われても「これは俺じゃない。過去のお前が書いたんだクソ野郎！！お前の責任だ！！」と日々AIを怒鳴りつけている
この他責志向はメンタルに良い。自分のことでも他人のことでもとにかく棚に上げて、問題自体をとことん追及するということに向いている。何が悪かったのか、どうするべきだったのかについて問題の本質を理解するためには、ひたすらAIのせいにして客観視点を持つというのは有効なアプローチではないかと感じている
「おまえこれ実装したとき、このやり方がいいって言ったよな？？？！！！」「なんで気づかなかった？？？」みたいなやり取りは対人相手では到底できるものではないが、AI相手でなら気遣う必要はない。従来はできなかった問い詰めを行うことにより率直に振り返りを行い学びを得ることができる