> For the complete documentation index, see [llms.txt](https://channyeintun.gitbook.io/blogs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://channyeintun.gitbook.io/blogs/ai/harness-engineering-how-to-build-software-when-humans-steer-agents-execute.md).

# Harness Engineering: How to Build Software When Humans Steer, Agents Execute

Ryan Leapo (OpenAI) ပြောကြားသွားတဲ့ "Harness Engineering: How to build software when humans steer and agents execute" ဆိုတဲ့ ခေါင်းစဉ်ကို အခြေခံပြီး၊ သူပြောသွားတဲ့ အနှစ်သာရတွေ မပျောက်ပျက်အောင် ပြည့်ပြည့်စုံစုံ ပြန်လည်တင်ဆက်ပေးလိုက်ပါတယ်။

Harness Engineering: AI Agent တွေနဲ့ Software တည်ဆောက်မယ့် ခေတ်သစ်ဗျူဟာ

Software Engineering လောကဟာ အရင်ကနဲ့မတူဘဲ အကြီးအကျယ် ပြောင်းလဲနေပါပြီ။ အထူးသဖြင့် ပြီးခဲ့တဲ့ ၂၀၂၅ နှောင်းပိုင်း GPT 5.2 ထွက်လာပြီးကတည်းက Coding Agent တွေရဲ့ စွမ်းဆောင်ရည်ဟာ လူတစ်ယောက်နီးပါး (Isomorphic) ဖြစ်လာခဲ့တယ်။ ဒီအပြောင်းအလဲမှာ ကျွန်တော်တို့ ဆော့ဖ်ဝဲလ်ရေးသားပုံ နည်းစနစ်တွေ ဘယ်လိုပြောင်းလဲသင့်သလဲဆိုတာကို OpenAI က Ryan Leapo က စိတ်ဝင်စားစရာ တင်ပြသွားပါတယ်။

၁။ Code is Free: ကုဒ်တွေက အလကားရနေတဲ့ခေတ်

Ryan ရဲ့ အဓိက Point က "Code is free" ဆိုတာပါပဲ။ အရင်က Implementation (ကုဒ်ရေးသားတာ) ဟာ အရင်းအမြစ်တစ်ခုအနေနဲ့ ရှားပါးခဲ့ပေမဲ့၊ အခုခေတ်မှာတော့ ကုဒ်ထုတ်လုပ်ဖို့၊ Refactor လုပ်ဖို့ ဒါမှမဟုတ် Delete လုပ်ဖို့ဆိုတာဟာ Token Budget နဲ့ GPU Capacity ပေါ်မှာပဲ မူတည်တော့တယ်။

ကျွန်တော်တို့ဟာ အခုဆိုရင် ကိုယ့်အောက်မှာ အလုပ်လုပ်ပေးမယ့် Engineer ပေါင်း ၅ ယောက်ကနေ ၅,၀၀၀ အထိ (Virtual Engineers/Agents) ကို ၂၄ နာရီပတ်လုံး ခိုင်းစေနိုင်တဲ့ "Token Billionaires" တွေ ဖြစ်လာကြပါပြီ။ ဒါကြောင့် Engineer တစ်ယောက်ရဲ့ Skill set ဟာ ကုဒ်ရေးတတ်ရုံတင် မဟုတ်တော့ဘဲ Systems Thinking၊ System Design နဲ့ Delegation (အလုပ်လွှဲအပ်ခြင်း) ဘက်ကို ပိုပြီး ဦးတည်လာရပါမယ်။

၂။ Harness Engineering ဆိုတာ ဘာလဲ?

Harness Engineering ဆိုတာကတော့ လူက လမ်းညွှန် (Steer) ပြီး Agent တွေက အကောင်အထည်ဖော် (Execute) တဲ့ နေရာမှာ Agent တွေ အလုပ်လုပ်နိုင်အောင် ဖန်တီးပေးထားတဲ့ ပတ်ဝန်းကျင် (Environment) နဲ့ စည်းကမ်းသတ်မှတ်ချက် (Guardrails) တွေကို တည်ဆောက်တာကို ဆိုလိုတာပါ။

၃။ ရှားပါးအရင်းအမြစ် ၃ ခု (The Scarce Resources)

အခုခေတ်မှာ ကုဒ်တွေက အလကားနီးပါး ဖြစ်လာပေမဲ့ အောက်ပါ အချက် ၃ ချက်ကတော့ အကန့်အသတ်ရှိနေဆဲဖြစ်လို့ ဒါကို သေချာ စီမံခန့်ခွဲတတ်ဖို့ လိုပါတယ် -

* Human Time: လူရဲ့ အချိန်ဟာ တန်ဖိုးအရှိဆုံး ဖြစ်လာတယ်။
* Attention (Human & Model): လူရော Model ရောရဲ့ အာရုံစိုက်နိုင်စွမ်း။
* Model Context Window: Model တစ်ခု တစ်ခါတည်းနဲ့ မှတ်သားနိုင်တဲ့ အတိုင်းအတာ။

၄။ Agent တွေအတွက် လမ်းစချန်ခဲ့ပါ (Leaving Breadcrumbs)

Agent တွေက ကျွန်တော်တို့ လိုချင်တဲ့ Quality ရအောင် ရေးပေးဖို့ဆိုရင် သူတို့အတွက် နားလည်နိုင်မယ့် System တွေ၊ Structure တွေ လိုပါတယ်။

* Documentation & ADRs: ဆုံးဖြတ်ချက်တွေ ဘာကြောင့် ချခဲ့သလဲဆိုတာကို ရေးထားတဲ့ Architecture Decision Records (ADRs) တွေဟာ Agent တွေအတွက် အရေးကြီးတဲ့ လမ်းပြမြေပုံတွေ ဖြစ်လာပါတယ်။
* Non-functional Requirements: Agent တွေဟာ ကုဒ်ရေးတဲ့နေရာမှာ သန်းပေါင်းများစွာသော ရွေးချယ်မှုတွေကို လုပ်နိုင်ပေမဲ့၊ ကျွန်တော်တို့ ကုမ္ပဏီ ဒါမှမဟုတ် Project ရဲ့ စံနှုန်းတွေ (ဥပမာ- Error Handling ဘယ်လိုလုပ်မလဲ၊ Retry mechanism ပါရမယ် စတာတွေ) ကို သေချာ ရေးသားညွှန်ကြားထားဖို့ လိုပါတယ်။
* Reviewer Agents: ကုဒ်တွေကို လူကိုယ်တိုင် လိုက်စစ်မယ့်အစား Security နဲ့ Reliability ကို စစ်ဆေးပေးမယ့် Reviewer Agent တွေကို CI/CD မှာ ထည့်သွင်းအသုံးပြုရပါမယ်။

၅။ OpenAI အဖွဲ့ရဲ့ အလုပ်လုပ်ပုံ (Practical Workflow)

Ryan ရဲ့ Team မှာ အသုံးပြုနေတဲ့ နည်းလမ်းတွေကတော့ -

1. Tickets as Entry Points: အလုပ်တစ်ခုကို Ticket တစ်ခုအနေနဲ့ စတင်ပြီး Agent ကို ပေးလိုက်တယ်။
2. Skills over Shells: Agent ကို Terminal shell ပေးလိုက်ရုံတင် မဟုတ်ဘဲ၊ App ကို ဘယ်လို Launch လုပ်ရမလဲ၊ Chrome DevTools ကို ဘယ်လိုသုံးရမလဲ ဆိုတဲ့ "Skills" တွေကို သင်ပေးထားတယ်။
3. Lints and Tests as Prompts: လင့် (Lint) အမှားတွေ ဒါမှမဟုတ် Test failure တွေဟာ Agent အတွက် Feedback ကောင်းတွေ ဖြစ်တယ်။ ဥပမာ- "File တစ်ခုဟာ Line ၃၅၀ ထက် မကျော်ရဘူး" ဆိုတဲ့ Rule မျိုးဟာ Context window ကို ချွေတာရာရောက်သလို Agent အတွက်လည်း ပိုပြီး ရှင်းလင်းစေပါတယ်။
4. No Slop: ကုဒ်တွေထဲမှာ အရည်အသွေးမမီတာတွေ (Slop) မပါလာအောင် Guardrails တွေ သေချာ ထားရှိရပါမယ်။<br>

နိဂုံးချုပ်အနေနဲ့ ပြောရရင် Software Engineer တစ်ယောက်ရဲ့ အလုပ်ဟာ အရင်လို Manual Implementation လုပ်နေတာမျိုး မဟုတ်တော့ဘဲ၊ Agent တွေ အမှားအယွင်းမရှိ အလုပ်လုပ်နိုင်မယ့် "Harness" တစ်ခုကို တည်ဆောက်ပြီး စနစ်တကျ မောင်းနှင်ရမယ့် Staff Engineer mindset မျိုး ထားရှိရတော့မှာ ဖြစ်ပါတယ်။

"Don't hesitate to remove yourselves from the loop by getting the agents to do the full job because they can." — Ryan Leapo

ဒီဆောင်းပါးက Ryan ရဲ့ ပြောကြားချက်တွေကို ပိုပြီး မျက်စိထဲ မြင်သွားစေမယ်လို့ မျှော်လင့်ပါတယ်။ ထပ်ပြီး သိချင်တဲ့ အပိုင်းတွေရှိရင် ပြောပါဦး၊ ဆွေးနွေးပေးပါ့မယ်။