Trabaho Na ang Harness Engineering — Ito ang Laman ng Job Description

Sa nakaraang dalawang taon, karamihan sa payo tungkol sa karera hinggil sa mga AI agent ay nakasentro sa pag-aaral kung paano sila i-prompt nang maayos. Hindi na iyon ang bihirang kasanayan sa ngayon. Ang bihirang kasanayan ay ang pagbuo ng balangkas na kinaroroonan ng isang agent — ang bagay na lalong tinatawag na harness — at ito ay sapat na tiyak, at sapat na mahirap, kaya't nagiging sarili na nitong job description sa halip na karagdagang tungkulin lamang ng "AI person" sa isang koponan.

Ang pinakamalinaw na publikong paglalarawan kung ano talaga ang kinapapalooban nito ay mula sa Lenny's Newsletter, na nagdodokumento kung paano ginawa ng product-management tool na ChatPRD ang isang harness upang awtomatikong i-debug ang mga bug sa Sentry. Sulit basahin nang buo ang artikulong ito kung nagtitimbang ka kung magse-specialize dito, dahil may punto ito na madaling hindi mapansin: hindi kailanman naging bottleneck ang modelo. Ginamit ng team ang Claude Agent SDK bilang pundasyon, pagkatapos ay ginugol nila ang mas malaking bahagi ng kanilang pagsisikap sa engineering sa isang custom na terminal UI at isang set ng mga adapter na nag-uugnay sa agent sa Sentry, Linear, GitHub, at Vercel. Iyan ang trabaho, sa maliit na sukat. Apat na sistema, apat na magkakaibang auth scheme, apat na magkakaibang hugis ng data, at isang UI na nagpapahintulot sa isang tao na manood at mangialam nang hindi kinakailangang bantayan ang bawat hakbang.

Ano talaga ang bumubuo sa "harness"

Kung sinusubukan mong alamin kung ito ba ay isang set ng kasanayan na sulit buuin, makakatulong na hatiin ito sa mga bahaging hiwalay na inuupahan, o kahit man lang hiwalay na sinusuri sa isang panayam:

• Disenyo ng permissions. Ang pagpapasya kung ano ang pinapayagang gawin ng isang agent nang walang pagbabantay (magbasa ng ticket, gumawa ng draft na PR) kumpara sa kung ano ang nangangailangan ng tao sa loob ng proseso (mag-merge, mag-deploy, magbura, gumastos ng pera) — at pag-encode nito bilang aktwal na patakaran sa code, hindi bilang isang prompt instruction na maaaring balewalain ng modelo kapag nasa ilalim ng pressure. Mas malapit ito sa access-control engineering kaysa sa pagsulat ng prompt.
• Mga tool adapter. Manipis, mahusay na nasubukang mga wrapper sa paligid ng bawat external system (Sentry, Linear, GitHub, Vercel, o kung ano man ang stack ng iyong kumpanya) na nagsasalin sa intensyon ng agent tungo sa isang ligtas at validated na API call, at nagsasalin ng tugon pabalik tungo sa isang bagay na kayang pagbatayan ng pangangatwiran ng modelo. Ito'y ordinaryong software engineering — error handling, retries, schema validation — na inilapat sa isang bagong consumer.
• Terminal o console UI. Isang paraan para makita ng tao kung ano ang ginagawa ng agent, aprubahan o tanggihan ang mga aksyon, at humimasok kapag ito ay natigil. Gumawa ang ChatPRD ng sarili nilang custom na bersyon; marami namang koponan ang gagamit na lang ng mga handa nang agent console, ngunit may kailangan pa ring magpasya kung ano ang ipapakita, kung ano ang itatago, at kung ano ang nangangailangan ng pag-click bago ito mangyari.
• Pagpili ng tool sa malaking sukat. May binabanggit na isang write-up mula sa Machine Learning Mastery na dapat malaman kung gumagawa ka ng anumang bagay na lampas sa isang demo: ang kawastuhan ng agent sa mga tool call ay may hilig bumaba kapag lumampas na sa mga labindalawang opsyon ang catalog ng tool — nagsisimulang magkamali ang modelo sa pagtawag ng mga tool, mag-hallucinate ng mga parameter, o matigil sa mga maling tawag. Ang mga hakbang na inirerekomenda nito para mapagaan ito (pagre-restrict kung aling mga tool ang nakikita sa isang partikular na konteksto, retrieval-based na paghahanap ng tool, pag-route sa mga specialized na sub-agent, tahasang mga hakbang sa pagpaplano, fallback logic, at mga benchmark harness upang mahuli ang mga regression) ay isa mismong checklist ng mga bagay na kailangang malaman ng isang harness engineer kung paano ipatupad, hindi lamang malaman.
• Context at memory engineering. Ang parehong source ay gumagawa ng distinksyon na dapat isapuso: ang context engineering (kung ano ang isasama sa isang solong inference call, at kung saan) at ang memory engineering (kung ano ang nagpapatuloy sa iba't ibang session, paano ito iniimbak, paano ito kinukuha) ay magkaibang disiplina na may magkaibang paraan ng pagkabigo. Ang paggigiit nito ay karamihan sa mga pagkasira ng mga agent na tumatakbo nang matagal at may maraming session ay nagmumula sa paghahalo ng dalawang ito — ang pagtrato sa memory ng session na parang karagdagang context lamang, o kabaligtaran — lalo na sa punto kung saan nagpapasya ang sistema kung ano ang kukunin.

Ang ebidensya na ito ay tunay at maaaring pondohang tungkulin — hindi lamang isang hobbyist na niche

Makatwiran lang na itanong ng mga skeptiko kung ang "harness engineer" ay isang trabaho o isa lamang gawain sa loob ng trabaho ng iba. May dalawang datos mula sa digest na nagmumungkahi na papunta na ito sa naunang direksyon. Una, ginamit ng Aspire team ng Microsoft — isang grupong binubuo ng 10 katao — ang Agentic Workflows ng GitHub upang i-automate ang cross-repo na mga documentation PR, at sa loob ng dalawang release ay na-merge nila ang 82 PR sa median na 44.8 oras matapos i-ship ang kaukulang product PR, nang walang bagong headcount at walang muling pagsasanay sa proseso. Iyan ay isang maliit na team na nakakakuha ng napakalaking leverage dahil partikular na may namuhunan sa balangkas (ang mga workflow definition, ang review routing, ang trigger logic) sa halip na hayaan ang mga engineer na sumulat ng docs PR nang de-kamay. Ikalawa, tinitingnan ng proyektong SkillOpt ng Microsoft Research ang mga "skill" file ng agent — ang mga instruksyon at limitasyon na humuhubog kung paano kumilos ang isang agent sa loob ng harness nito — bilang isang bagay na dapat sistematikong i-optimize sa halip na i-edit nang de-kamay, at iniuulat nito na ito ay pinakamahusay o kapantay ng pinakamahusay sa lahat ng 52 cell ng isang benchmark grid (anim na benchmark, pitong modelo, tatlong execution mode), kung saan ang mga na-optimize na skill ay maililipat sa iba't ibang modelo at iba't ibang harness. Maging naging pamantayan man o hindi ang partikular na tool na ito, nagpapahiwatig ito na ang industriya ay nagsisimula nang tratuhin ang configuration ng harness bilang isang engineering artifact na may sariling tooling at benchmark — ang parehong direksyon na naghubog sa "DevOps" mula sa isang set ng ad hoc na script tungo sa isang disiplina.

May infrastraktura rin ngayon na sinasadyang binubuo para sa layer na ito. Ang bagong ianunsyo na mga kapabilidad na "Managed Agents" ng Google sa Gemini API — background at async execution, remote MCP server integration, custom function calling, pag-refresh ng credential sa iba't ibang interaksyon — ay epektibong pre-built na plumbing para sa mismong mga problemang nilutas nang de-kamay ng team ng ChatPRD. Iyan ay isang normal na pattern: kung ano ang binubuo ng isang team nang bespoke ngayong taon, gagawing produkto ng isang platform vendor sa susunod na taon. Hindi nito inaalis ang tungkulin ng harness engineering; itinataas nito ang pinakababang antas at inililipat ang trabaho tungo sa pag-integrate at pag-configure ng mga managed primitive sa halip na sumulat ng bawat adapter mula sa simula, katulad ng kung paanong hindi inalis ng cloud infrastructure ang mga ops engineer, binago lamang nito kung saan sila gumugugol ng oras.

Ano ang ibig sabihin nito kung ito ang tinatarget mong tungkulin

Ilang konkreto at masusuring bagay na maaaring ilagay sa portfolio o resume kung gusto mong maging kredible para sa trabahong ito: bumuo ng isang adapter mula simula hanggang katapusan laban sa isang tunay na API na hindi mo kontrolado (kasama ang auth, error handling, rate limits, hindi lamang isang happy-path na demo); magdisenyo at magdokumento ng isang permissions model para sa isang agent na naghihiwalay ng mga aksyong read/propose/act at nagpapakita kung bakit nasa ganoong lugar ang bawat hangganan; at bumuo o mag-configure ng isang review interface kung saan inaaprubahan ng isang tao ang mga aksyon ng agent bago ito isagawa, dahil iyan ang bahaging iinsistihan ng karamihan sa mga kumpanya bago nila pahintulutan ang isang agent na humipo sa production. Kung sinusuri mo ang isang alok na trabaho bilang harness engineer o sinusukat ang sarili mong mga responsibilidad, itanong nang tiyak kung sino ang may-ari ng permissions model, sino ang may-ari ng mga adapter, at sino ang may-ari ng human-review surface — sa maraming team ngayon, walang malinaw na may-ari ang tatlong bagay na ito, na siya mismong puwang na sinusubukang punan ng tungkuling ito.

Isang paalala na dapat sabihing tuwiran: wala sa mga sources sa itaas ang nagtatatag ng numero sa hiring market para sa partikular na titulong ito, at ang "harness engineer" ay hindi pa isang job title na makikita mo sa mga job posting — lumalabas ito sa loob ng mga titulo tulad ng "AI infrastructure engineer," "agent platform engineer," o kaya't simpleng "senior backend engineer, AI systems." Ituring ito bilang isang set ng kasanayan na dapat buuin at ilarawan nang wasto, hindi isang titulong hahanapin sa LinkedIn.