AI コードが機能しても拒否する場合 – ヴィニシウスブラジル

実装が高速化するにつれて、本当のハードルは AI によって生成されるコードの量をレビューすることになります。私はあなたの同僚（とそのエージェント）のPRについて話しているのではなく、あなた自身のPRについて話しています。 git diff コーディングエージェントが作業を完了した後。

計画モードで開始する、大きなタスクをいくつかのステップに分割する、小さな変更を反映するなど、適切なプラクティスに従っている場合でも、自分自身で深く考えていないものをレビューするときに依然として認知的な過負荷を感じます。

エージェントをコーディングする前に、タスクが与えられると、コードベースを探索し、さまざまなソリューションを考え、実験してから実装します。すべてのコンテキストを統合するには数日かかる場合があります。最終的にその自己PRを提出すると、自信が高まり、同僚に自分の変更点をそれぞれ説明するのが簡単になりました。

AI を使用しても、より大きなタスクを完了するにはまだ数日かかることを認めなければなりません。多くの場合、AI によって加えられたすべての変更を拒否して、最初からやり直します。最初のセッションと 2 回目のセッションの違いは、LLM モデルではなく、画面の向こうにいる人です。解決しようとしている問題を整理するための時間が増えると、エージェントをそれに駆り立てられるのではなく、より良い解決策に導くことができます。

AI コードが機能しても拒否する場合 – ヴィニシウスブラジル — イチジク。その違いを信じられますか？

私は同じ理由で AI コードを拒否することが多くなりました。

自分の言葉でビジョンを説明できない場合、私は AI コードを拒否します。
違いが問題よりも大きい場合、AI コードを拒否します。
AI コードが必要であると証明される前に抽象化を導入する場合、私は AI コードを拒否します。
AI コードがローカルで動作する場合、私は反対する傾向がありますが、そうするとシステムについて推論することが難しくなります。
自分が理解できる以上に出力を信頼している場合、私は AI コードを拒否します。

エンジニアが AI によって生成された変更を急速に採用するのは珍しいことではありません。だからこそ、必要な人間によるレビューだけでなく AI レビューも推奨するのです。実際には、実行して CI をグリーン化するコードはまだ不十分なソリューションである可能性があり、エンジニアリングは常に、適切でスケーラブルで拡張可能なソリューションを実装することに重点を置いています。

私はここしばらくコーディングエージェントを使用してきましたが、それがどれほど素晴らしいものであっても、優れたソリューションに導く優れたエンジニアが必要です。はい、コーディングエージェントはコードを書くだけでなく、このタスクを支援できますが、それは持続可能な方法で自律的に実行できるという意味ではありません。 今のところ。