著者自身の韓国語の技術ブログに掲載された講演の書き起こしで、コーディングエージェントを使って K-DEVCON のコミュニティサイトを作り直し、リリースするまでを振り返っている。その語りの仕掛けは、著者の自己紹介にある。新しい技術を遠巻きに眺め、サブスクリプションに気軽にお金を払わない保守的な開発者を自認する人物が、月 100 ドルのプランを使うまでになったというのである。記事は冒頭で、本文は講演をもとに AI が整理したものであり、そのため実際の発言と異なる部分があるかもしれず、多くが省かれている可能性もあると断っている。
論旨
記事の出発点は、タイトルが反論している考え、つまりプロダクトはクリック一つで出来上がるものではない、という点である。記事は自らの経験を バイブコーディング ではなく エージェント型エンジニアリング に位置づけ、その名前の 2 つの部分を説明する。エージェント型とは、開発者が自らコードを書く代わりに、コードを書くエージェントを監督することを意味し、エンジニアリングとは、そのプロセスが、学び、身につけていくべき専門性を必要とすることを意味する。そして、その選択を経験から裏付ける。著者は、AI との作業はノリというよりも戦いに近いと感じたと述べ、やるなと言ったことをなぜやっているのかとエージェントに一度ならず問いただしたことを振り返っている。この見方では、技術が価値をもたらすのは、エージェントの出力を制御し検証できるようになってからである。
記事で最も掘り下げられている論点は、トークンの節約に反対するものである。著者は、無料プランから始めて骨組みを作ったものの、そこで行き詰まったと述べる。機能を追加すると意図と違う形になり、実行は完了せず、使用量の上限に阻まれた。有料プランでは、そのパターンは記事がトークン基準の生活と呼ぶものになった。トークンがある間は開発し、なくなったら洗濯をしてリセットを待つ、という生活である。そこから導かれる結論は、開発者の認知的なフローが失われることのほうが、節約したトークンよりも高くつくということである。
これが、記事が決定的とみなす転換につながる。記事はそのきっかけを、知人が著者に投げかけた問いに帰している。なぜそれを自分で直しているのか、エージェントに投げればいいのに、という問いである。著者はそれまで、エラーに対してモデルに 3〜5 回試させてから自分でコードを開いていた。ループでトークンを浪費するのを避けるためである。捉え直しの要点は、エージェントをコード生成器としてではなく、自ら推論して問題を解決する存在として扱うことにある。エラーログや失敗しているテストをまるごと渡し、開発者の役割は、適切なコンテキストを与えて最終的な判断を下すディレクターであると捉えるのである。
エージェントが書いたものを信頼することについて、記事の答えは、必須の検証としてのテストコードである。テストが通ることこそが、新しいコードが既存のものを乱していないことを示すものであり、記事はテストが守るべき対象をロジックだけでなく、アーキテクチャ（アーキテクチャテストで強制する構造上のルール）、カバレッジ（最低しきい値）、コード品質（テストパイプラインでの静的解析）にまで広げている。さらに、テストを書く 2 つ目の理由を挙げる。テストの結果は、チームが望む方向性を AI に伝える最良の方法の一つであり、ドキュメントよりも明確で、エージェントの選択肢を狭めすぎることなくガードレールとして機能するというのである。
報告された実践
記事は、サイト刷新の中で最も興味深かった部分として SEO の作業を挙げている。その理由は、著者がバックエンドの開発者でありながら、サイトの SEO スコアを劇的に改善したことにある。
- 2 系統のルーティング：サーバーサイドレンダリングを使わずに、クローラーから見えるメタデータを得るための仕組み。バックエンドは、コンテンツが作成、編集、削除されたときに静的な Open Graph の HTML を生成して共有ボリュームに保存し、Nginx は User-Agent で分岐して、通常のユーザーは React の SPA へ、クローラーのボットは事前生成した HTML へ送る。詳細については、記事は自身の以前の記事にリンクしている。
- サードパーティの SEO スキル：これをサイトに対して実行して改善点のリストを作り、それをエージェントに渡してソースに反映させる。記事は、このループをおよそ週に 1 回繰り返していると報告している。記事が述べる所見は、Agent Skills が最も役立つのは自分の専門外の領域だということである。
- JSON 形式の Lighthouse の出力：これをエージェントに与え、ソースを確認してレポートが指摘する点を修正するよう依頼する。
- 繰り返し使うプロンプトのスキルとしてのテンプレート化：挙げられている例は、コミットされていない変更を分析してそのテストを書くよう求める定型の依頼である。述べられている動機は、同じプロンプトを打ち直すのが面倒になったことであり、記事によれば、その結果できたものは単なるプロンプトではなく、エンジニアのノウハウをコーディング規約に移植したものである。
受け止めと限界
記事は、最後の 20% と呼ぶものについて述べて締めくくられる。AI は仕事の 80% をこなすとされ、残りの細部を埋めること、そして結果に責任を持つことは人間の役割として残る。膨大なトークンを消費し、何万行ものコードを追加したという話に対して、著者は、そうした事例は一人が領域全体を担当しているか、稼働中のサービスの外で作業している場合が多いと述べ、それに不安を感じる必要はないと助言している。
最終的な立場は、答えではなく方向性に関するものである。AI は多くの答えを示せるが、サービスの文脈に合う答えを選べるのは、それを経験してきた開発者だけである。知識だけでは与えられたものを受け入れるだけになるが、直接の経験によって埋められた細部は能力になる。記事は読者に、AI の答えを吟味せずに受け入れるのではなく、なぜそのように判断したのかを問うよう求め、AI は責任を取らず、責任を負い方向性を決められるのは人間だけだとはっきり述べている。
これは一人の開発者による一つのプロジェクトの記録であり、講演の書き起こしとして示されている。測定も比較も報告されておらず、生産性に関する主張は著者自身のものである。