TL から EM へ：AI に依存せずコードを書く姿勢の変化

今年、コーディングエージェントの利用において大きな変化がありました。それはテックリード（TL）の役割からエンジニアリングマネージャー（EM）の役割へと移行したことです。

この二つの役割の違いは、技術への関与の深さにあります。

以前：AI が書くコードを細部までチェックしていた TL の頃

当時はどちらかといえば TL でした。すべてを自分でやるわけではありませんが、システム設計やコードレビューには必ず携わっていました。結局のところ、AI が生成したコードに対してまだ不安があったからです。

このやり方は品質の担保には役立ちましたが、人がエージェントのボトルネックになるという問題がありました。多くの意思決定や細部の管理を人間が行う必要があるのです。

転換点：Fable 5 の登場で「結果」を信頼するようになった

転機となったのは Fable 5 の前後です。AI が生成するコードの品質が相当高いことに気づき、わずかな検証を行えば大きなズレは生じないと確信しました。そこで私は AI によるコーディングへの介入を減らし、プロジェクト全体を俯瞰して見るようになりました。

「どのように作るか」を決め、「結果」を検証する。

これによりエージェントの生産性が劇的に向上しました。多くの場合、まず機能の実装方針を Agent と一緒に検討し、問題ないことが確認できれば /goal コマンドに方針を組み込んで実行させます。コードの記述や自動化テストはすべて Agent に任せ、完成後に機能を検証するだけで、コード自体を細かくチェックすることはほとんどなくなりました。

バグが見つかった場合は、その内容を Agent に伝えて再現させ、解決させます。そして関連するテストケースの追加も Agent に任せておき、修正後に人間が再度検証します。

技術選定も、自分の得意分野に縛られなくなった

このやり方のもう一つの利点は、技術選定において自分の好みや得意分野に囚われなくなることです。

TL の立場では、どうしても技術の実装方法や自分が得意とする技術に目が向きがちで、結果として「自分にとって使いやすい」技術を選定しがちでした。しかし EM として技術選定を行うようになると、「自分が何ができるか」ではなく「プロジェクトに最適な技術は何か」を重視するようになります。

私は元々フロントエンドが得意だったため、字幕翻訳アプリの開発初期には Electron を採用しました。自分で問題解決ができ、コードも書けるからです。

しかしその後、Electron の性能に満足できなくなったため、Swift と AppKit を使ったネイティブ技術スタックへ移行しました。本来 Swift は私があまり知らない言語でしたが、AI の支援があればプロセス全体にストレスを感じることはありませんでした。

現在、BaoCut の次期メジャーバージョンの設計ではクロスプラットフォーム対応を検討しています。首选は Rust です。私はこれまで Rust で一行もコードを書いたことがありませんが、これが優れたクロスプラットフォームの選択肢であることを知っています。

すでに Rust を使った最初のバージョンの開発は完了しており、言語自体の壁を感じることはほとんどありませんでした。

本当のボトルネックは「書くこと」から「考えること」へ

この開発モデルのおかげで、BaoCut の開発ではほぼ毎日小さなバージョンをリリースできるようになりました。https://baocut.app/releases/

最近ペースが落ちているのは、新機能の大きなバージョン構想に時間を割いているからです。ここで再び人間がボトルネックになります。もし人間が「何をすべきか」を明確に考えきれていなければ、どんなに優秀な Agent であっても力を発揮できないのです。