半年間コードを手書きせずAIエージェントだけで開発してみた結果
Six Months of Writing Code Exclusively with Agents
2026年2月、著者はコードを手書きしないというルールを自らに課し、6ヶ月間AIエージェントのみで開発を行った。当初はエージェントの出力を毎回確認し手直しする必要があったが、モデルの進化により大きな変更も任せられるようになった。並行して複数のエージェントを動かすうちに、リソース競合や環境構築、レビューの課題が浮上。Linux VMを活用してエージェントを分離し、管理ツールbotdを自作するなどして解決した。最終的に、エージェントがテストやレビューを通過した変更でも、価値がなければマージしない判断を下す重要性を強調している。
エージェントが承認したからといってマージできるわけではない。私はその変更を理解する必要があった。マージされるコードに対しては、依然として私が責任を負っていたのだ。
HNでの議論
105- greenowl
私はしばらく完全にエージェント任せのアプローチにコミットしていた。手書きのコードは一切なし！
ツールの「能力」はさておき、数ヶ月ほどでそれが間違った方向だと分かった。特に覚えているのは、大規模な機能実装中に5時間のウィンドウのトークンを使い切ってしまい、自分では続けられなくなったことだ。主に怠惰のせいで（明日リセットされるまで待とう！）、でも同時に、スキルの腐敗・衰えが始まっているという最初の大きな兆候に気づき、それが不快に感じられた。
完全エージェント任せのアプローチが長期的にうまくいくとは思えない。究極の依存関係だ！もし何らかの理由で「電気が消された」ら——障害、コスト増加、あるいはエージェントの速度がついに複雑性の転換点に達し、システムの制御と理解を失ってエージェントが事態を悪化させている、など——本当に時計を戻して、かつて実際にコードを書いていたときと同じ生産性と出力でコードを書き始められると思っているのか？
- lostnfound8778
> より大きなコストはタイピングだった。何かを構築したいと思うたびに、コードが頭の中に見えていた。ただ、それを十分な速さでタイプアウトできなかった。
その通り。私の場合、頭の中で見えているものと、指が物理的に現実にする速度とのギャップが大きければ大きいほど、ストレスを感じ、マラソンのようなコーディングセッションは、その緊張だけで背中を痛めて終わることがあった。
- thisisauserid
そしてLLM以前なら、彼は昼休みに20行のbashスクリプトとcronジョブをでっち上げて、6ヶ月間別のことに取り組んでいただろう。
- redlewel
どうやって人々はこのAI風の文章でこういう投稿を読めるんだ？私は数文しか読めなかった。
- mrothroc
ここでのいくつかのコメントは核心的な問題に触れている。エージェントが私たちがレビューできる以上のコードを書いているということだ。シニアはこれまでレビューする時間が十分になかったし、コーディングエージェントの多作な出力がそれを悪化させている。さらに、コードはほとんど常に良い。だから、かなり良いコードの津波をレビューすることになり、レビュー疲れが生じて、全体がただの儀式になってしまう。
私にとって、これはチェックが「見た」以上のものでなければならないことを意味する。私がそれを見る前に起こることが2つある。第一に、他の人も言っているように、異なるファミリーのモデルに明確に定義された基準でレビューさせる。同じファミリーのレビュアーはバイアスを共有するので、異なるものでなければならない。第二に、決定的なゲートのコアセット（lintやユニットテストなど）を実行しなければならない。どちらの場合も、失敗はコーディングエージェントに戻される。
そして、その後に初めて私は気にする。しかし、本当にすべてを読むわけではない。それが標準的なCRUD操作なら、エージェントはかなり得意だ。特に成熟したパッケージを使っている場合は。私は重要なこと、例えば権限の強制方法などに焦点を当てる。
これは私にとってうまく機能しているが、1つの大きな問題には触れていない。それが構築する価値があるかどうかだ。エージェントは少し過剰に熱心になる傾向があるので、出力が価値を追加することを確認するために多くの事前作業をする必要がある。ゲートは成果物しかチェックできず、私の意図はチェックできない。
- iamflimflam1
LLMでコードを書くには規律が必要で、難しい。その方法と、そこから最大限を引き出す方法を学ぶ必要がある。
ソフトウェアエンジニアリングは死んだ、ソフトウェアエンジニアリング万歳！
- rich_sasha
これらの報告に対して、本当に奇妙な不協和音を感じる。私は仕事でCursor経由でトップモデルにアクセスしている。毎回、こう思う。「ここに退屈だが明確に定義されたタスクがあり、成功基準が明確で、粘り強い反復で多くのことを達成できる。これをClaudeに任せよう。」
まず、タスクを適切に説明するのに長い時間がかかる。これらすべての明確な成功基準、まあ、頭の中の明確な仕様からコードを書く代わりに、大量の散文を書き、それを曖昧さのないものにしようとしている。私はEnglish++でプログラミングしている。
しかし、5回に1回は、まあまあ動くものを生成する。完璧ではないが十分なもの。5回中2回は、まあまあ大丈夫そうに見えるが、実際には仕様の80%を無視しているか、コメントで最小限の口先だけの対応をしている。
そして時々、5回中2回より少し少ないかもしれないが、完全にひどいものに逸脱する。メインスクリプトのASTをロードしてピクルしてからbase64にシリアライズするスクリプトを書き始める。理由もなく。文字列に何かをエンコードして、文字列比較のためにord(string[i])を繰り返しチェックする。最終的にコンテキストを使い果たし、LLM相当の重度の認知症を発症する。
「ねえコンピュータ、これを書いて」と言って、それが彼らの時間の有効な使い方であると言う人々と、自分の経験を本当に調和させることができない。
- phildenhoff
それ以外は良い記事なのに、AI風の表現（「でも、ここにひねりがある：先ほど説明した検索はbotdに送信されなかった。すべての履歴はSQLiteにあったので、別のエージェントをそれに向けて、分析を取得した。ツールは死んだが、データは死ななかった。」など）で水増しされているのは残念だ。
Maisem Aliは、コードの生成をAIに委ねているにもかかわらず、エンジニアリングをやめていないと書いている。それはいくつかの理由で興味深い視点だと思うが、何よりも、私は同意しないかもしれない。
まず、それがどのように爆発するかの代表的な例が見られる。「botdは今月死んだ。それは自分の重みで崩壊した。」エージェントハーネス（または他のハーネスの上に重ねるオーバーレイ？）が、純粋な技術的複雑さで自分の重みで崩壊するとは想像しがたい。このようなツールが「崩壊」する原因は何か？適切にアーキテクチャされていれば、外部の変更はすべて適応可能であるように思える。失敗するテストは修正できる。
このAIコーディングの進化は、内部の仕組みを理解していないプロトタイプを素早く立ち上げる能力を与えてくれたが、価値のあるもの（そして、botdはMaisemにとって価値があったように思える）については、少なくとも構築しているもののアーキテクチャとエンジニアリングを理解し、影響を与えるべきだと私は信じる。もしMaisemがbotdに対してそれをしていたら、それは「自分の重みで崩壊」しなかっただろうし、_できなかった_だろう。botd内の変更を必要とする外部の影響は、管理可能だったはずだ。
第二に、この記事の生成を外部に委ねることは、私には[…]