あなたは手動でGitコマンドを入力するからといって、より優れたエンジニアではありません

2026年7月10日 あなたは手動でGitコマンドを入力するからといって、より優れたエンジニアではありません コードを書き始めて27年、私は小さくも苦痛なエンジニアリングタスクの長いリストに費やす時間をやめました。AIエージェントは今、コミットメッセージ、プルリクエストの説明、コードコメント、命名規則、Gitの衛生管理、課題追跡、リリースワークフローを、ほとんどのチームが手動で管理していたよりも一貫して処理しています。 私がAIについて最も気に入っていることの一つは、これほど高く評価するとは思ってもみなかったことです。それは、開発者がめったにやりたがらないタスクにおいて驚くほど優れており、それらを適切に行うと、ばかばかしいほどの時間を消費します。まず、みんなが忘れている友であるコミットメッセージから始めましょう。良いコミットメッセージ、有用なPRの説明、そして変更を他者にとって理解可能にするためのすべての周辺コンテキストを書くのに、どれだけの時間を費やしたか思い出せません。私が一緒に仕事をしたほとんどのエンジニアは、意味のあるコミットメッセージをほとんど書いていませんでした。そして、レビューやマージの時期になると、コミットやPRが何をしようとしていたのかを理解するために、コードを掘り下げるのにさらに多くの時間を費やしました。今、私はその作業をAIに委任しています。それは私が望む方法でコミットメッセージやPRの説明を書き、最初は私を少し怖がらせたが、今では絶対に気に入っているレベルの精度で書き上げます。私はアプリケーションに集中でき、開発者がコーヒーを飲みながら一度だけスキャンするであろう短い本を書く必要がなくなります。 コメントはついに安価になりました これはコミットやPRだけではありません。コード内のコメントにも適用されます。この件については明確な二極化があります。良いコードコメントを愛するエンジニア（例えば私）もいれば、リポジトリからすべてのコメントを削除したいと喜んで言うエンジニアもいます。正直に言って、両方の立場を理解できます。長年、私はバランスを見つけました。コードがすでに言っていることを繰り返すためだけに、コードベース全体を人間が読める英語で書き直したくはありません。しかし、コメントには特定のルールがあります：絵文字なし、装飾的なナンセンスなし、作業中の言語に適したコメント、一貫したフォーマット、適切なファイルヘッダー、LLMのコンテキストに役立つ場合は完全なファイルパス、一行の事実説明、ファイルが属するアーキテクチャレイヤーに関する情報などです。これらの詳細を手動で維持するのに何百時間も費やしたことを覚えています。そして、ああ、何か変更があるたびに、ヘッダーとコメントも変更する必要がありました。今、そのほとんどが自動化されています。リポジトリは適切に説明されたままになり、有用だが痛みを伴う繰り返し作業の詳細を維持するために脳細胞を注ぎ込む必要がなくなりました。そして私を責めないでください。長年、コードベースにこのレベルの注意を払うことがプロフェッショナルな仕事の一部だと考えていました。現実はその考えに冷水を浴びせ続けました：ほとんど誰も気にしませんでした、そのような仕事をする数人を除いて。皮肉なことに、その構造を最も高く評価する読者は今やLLMです。彼らはこのコンテキストを愛しています。彼らは私が以前書いたルール、コメント、パス、意図、アーキテクチャの説明を使用できます。これにより、エージェントとの作業がより快適になります。次のようなやり取りが得られます。「あなたはこのルールを書きましたが、今、私に反対のことをするように求めています。どのように調和させればよいでしょうか？」そのようなやり取りは、AI支援エンジニアリングプロセスをより流動的にします。リポジトリはソースファイルの山ではなくなり、エージェントが矛盾に異議を唱えるのに十分な明示的な意図を持つようになります。 名前を付けることは依然として難しいので、私はすべてを手動で行うのをやめました 私がかつて途方もない時間を費やしたもう一つのタスクは、ファイル、クラス、関数、モジュール、そしてそれらを取り巻くすべてのものに名前を付けることでした。私は一緒に仕事をしたチームのために数十の開発者ガイドを書きました。命名規則、ディレクトリ構造、接尾辞、接頭辞、抽象化、規則への例外、そして最終的には例外への例外。AIはこの仕事をより良くこなします。プロジェクトが1年経っても、30または40もの異なるファイル命名スタイルはもうありません。命名の競合も少なくなります。6ヶ月前に責任があったファイルの名称を思い出すのに10分費やすこともなくなります。名前は一貫して付けられます。考えを変えることさえ、ほとんど無関係になります。次のように言うことができます。「クラス PostgreSQLClient {} を使用しないでください。クラス DatabaseClient {} のような汎用的な名前を使用してください。」するとエージェントはリファクタリングを実行し、参照を更新し、テストを実行し、不足している部分を修正し、チケットの関連チェックボックスをマークできます。考えを変えることはかつて高価でした。今では、多くの変更に対して、それはほとんど指示です。 私はGitのベビーシッターもやめました Gitも、エージェントに退屈な仕事を任せることを嬉しく思う分野です。私はもう、百回目と同じ愚かな間違いを犯すことはありません。dev、main、または無関係なフィーチャーブランチで作業を開始してしまうことです。それは常に起こりました。PRをマージし、後でローカル環境に戻り、コードの変更を開始し、その時になって初めて、マージされてリモートで削除されたばかりのブランチにまだいることに気づきました。今、エージェントがこれをチェックしてくれます。「あなたはdevブランチにいます。適切なブランチを作成して、そこで作業を続行します。」良い。そうしてください。そして、ブランチの作成にとどまりません。私のワークフローでは、エージェントは[WIP]付きのPRを準備し、適切なラベルを適用し、PRを割り当て、意味のある説明を書き、チェックボックスを追加し、タスクが完了して変更がプッシュされるにつれてそれらのチェックボックスを更新できます。彼らはGitHub Issueを作成し、それを適切なプロジェクト列に移動し、IssueをPRにリンクし、ラベルを適用し、説明を書くことができます。私はそのほとんどをもう考える必要がありません。実際の問題に対する良い解決策を見つけることに注意を集中できます。 デリバリーは儀式ではなく、一連のチェックになりつつあります デリバリーの時期になっても同じことが起こります。まず、/definition-of-doneスキルを呼び出します。これは、実装がPRと計画で述べられたことをカバーしているかを確認します。テストと私が気にかけている他の検証をチェックします。異常、破損、または欠落しているものがあると通知してくれます。すべてが良好に見える場合、別のスキル、/pr-check-releaseを呼び出します。これはリモートPRをチェックし、ラベルを更新し、[WIP]を削除し、[RFC]を追加し、説明を更新し、レビューのために変更を準備します。もし1日経ってもチームの誰もPRをレビューしない場合、私たちはそれをマージします。エージェントはまた、その条件を追跡してくれるので、/pr-merge-devを実行でき、プロセスを処理します。PRをマージし、リモートブランチを削除し、ローカルブランチを削除し、devをクリーンな状態にプルバックします。これらのステップのどれも特に難しいものではありません。それがまさにポイントです。小さなタスクは、何千もあるため高価です この膨大な数の小さく苦痛なタスクを実行する必要がなくなったことによる安堵は、多くのお金に値します。たくさんのお金です。Gitコマンドを手で入力すること、すべてのPRの説明を手動で書くこと、またはコミットメッセージを作成するために指で注意深くキーボードを叩くことが、自分を他の誰よりも高める一種の技術だとまだ信じているエンジニアがいます。彼らはこれらの儀式にどれだけのお金が消えていくか全く分かっていないと思います。数分ではありません。数時間です。すべてのエンジニア、すべてのプルリクエスト、すべてのリリース、すべてのブランチの間違い、忘れられたチェックボックス、古い説明、命名に関する議論、正しくリンクされなかった課題、時代遅れになったコメント、誰かが覚えていなければならなかったリポジトリのハウスキーピングのすべてのビットに繰り返し適用されます。私はまだそれらすべてを気にしています。おそらくほとんどの人よりも。違いは、結果がプロフェッショナルな仕事と見なされるために、すべての機械的なステップを自分で実行する必要があるとはもう信じていないことです。2026年、あなたがこの種のエンジニアリングオーバーヘッドをAIに委任していないなら、あなたは金を燃やしています。そして、さらに重要なことには、あなたはあなたの人生を燃やしています。