AI時代、開発はどう変わるのか

Prompt EngineeringからHarness Engineeringまで、そして私の考え

はじめに

こんにちは。NHN ADのプラットフォームサービスラボの李昇宰です。本稿では、従来の開発からHarness Engineeringに至るまでの変化と、それに対する私の考えを共有したいと思います。

手でレンガを積む

私の最初のコーディングは2018年、大学で始まりました。ソフトウェア融合大学に所属していたため、C言語とPythonを必修で学ばなければならず、二重for文の星描きとポインタに出会う前までは「自分はコーディングの天才なのでは?」という錯覚さえ抱いていました。あの頃のコーディングとは、ググったり先輩から少しずつ教わったりしながら、レンガを一枚一枚積んでプログラムを組み上げていく作業でした。

しかし今はどうでしょうか? 開発者はもうググりませんし、コードを一行ずつ書くこともありません。すべての仕事の始まりと終わりにAIがあり、開発者の役割も「コードを書く人」から「問題を定義し解決する人」へと変わりました。実際、私はNHN AD入社以降、コードを一行も自分で書いたことがありません。

コードを自分で書かないなら、開発者は何をすべきなのでしょうか?

レンガをもっとうまく積む方法

私のAI利用は2023年、NHN Academyで学んでいた頃に始まりました。YouTubeやInstagramを開くだけで、履歴書プロンプト、文章プロンプト、開発プロンプトがあふれていた時期です。私もその流れに乗って、いつもこんな指示文から書き始めていました。

こうした方法論をPrompt Engineeringと呼びます。主な関心事はただ一つ、「モデルにどんな言葉をかけるか」でした。役割を与え、状況と望むことをできる限り詳しく説明する方式です。直感的で効果も高く、NHN ADのサービスにもFew-ShotとReActプロンプティングが適用されています。

私は長い間この方式にとどまっていました。ほとんどのコードは手で書き、行き詰まったり難しい概念が出てきたりしたときに、そこで初めてAIに尋ねるというやり方でした。

レンガを積む時代の終わり

そんな2025年、私を変えた出来事があります。それがClaude Codeです。GUIからCLIへ、そしてPrompt EngineeringからContext Engineeringへの転換でした。

かつては必要なコードやファイルを自分で埋め込み、プロンプトでモデルを制御していました。しかしClaude Code以降は、AIがファイルシステムとツールに直接アクセスし、自らファイルを読み、コードを直し、テストを回します。関心事も「どんな言葉をかけるか」から「どんな情報を入れるか」へと移りました。

要点と制約、メモリをファイルに分けて書いておき、MCPでツールを接続して、必要なときに必要な分だけ取り込ませました。その頃、私の頭の中には「開発者は要らなくなりそうだけど、就職どうしよう?」と「これで本当に速く作れそうだぞ?」が同時に渦巻いていました。この頃から自分でコードを叩く頻度が減り、面接でもClaude Code、エージェントとスキル、コンテキストウィンドウを問われ始めた、Context Engineeringの時代でした。

死んだレンガ、生きた設計

2026年の現在はHarness Engineeringの時代だと見ています。骨格はContext Engineeringと似ていますが、より洗練された方式でシステムそのものを設計します。システムプロンプトを定義し、サブエージェントを使い、決定論的な部分と非決定論的な部分を分けて管理します。エージェントが逸れないようRuleで統制し、ガイドを無視したとしてもlint·型チェック·コンパイルが機械的に捕まえるよう強制します。

以下は、私が業務で使っている構造です。作業を役割別のエージェントに分けて任せ、検証で出てきたミスはその場で直すだけにとどまらず、スキル·メモリ·Ruleに還元して二度と起きないようにします。

repo/
├─ .claude/
│   ├─ commands/   new-feature · new-bugfix · new-hotfix …
│   ├─ agents/     pm · バックエンド · フロント · インフラ · qa · レビュアー · git · 整理
│   └─ skills/     繰り返し作業·ノウハウを保存
├─ ai/          エージェント · ラムダ · バッチ
├─ app/
├─ domains/     ドメインロジック
├─ modules/     api-client · db-client · storage-client
├─ infra/       IaC · デプロイ
├─ docs/        spec · 設計記録
├─ scripts/
└─ .legacy/     古い成果物の移管

今や私はコードを一行ずつ書くことも、毎回長いプロンプトを新たに書くこともありません。やるべきことを定義しておけば、エージェントが自ら必要なファイルを読み、コードを直し、テストを回して結果を確認します。私の役割は何を作るかを定義し、その結果を検証する仕事へと狭まりました。

これからの旅

私は今、あるコンテストを自動で進める実験を回しています。毎日決まった時刻になると、私のノートPCのLaunchAgentがヘッドレスのClaudeを起こし、その日やるべきことを自ら整理して作業を遂行したのち、自分の結果を再び見直し、一日分のレポートを残して眠ります。私が手を加えなくても、翌日また同じことが繰り返されます。

その結果、私が直接コミットしなかった日でも、リポジトリには日付ごとの作業記録が着々と積み上がっています。

これからはこの構造を磨き上げ、韓国電子政府標準フレームワーク（eGovFrame）に貢献するシステムを構築してみようと思います。よく設計されたシステムであれば、他人が作った実際のコードベースに自ら貢献を残すところまで行けるはずだと考えています。電子政府フレームワーク オープンコミュニティで、その旅を続けてみようと思います。

ありがとうございました。