Ang DevOps Pioneer ay nagbabala: Ang pagtatangkilik ng AI Agent ay nangangailangan ng mga pagbabago sa antas ng sistema, hindi lamang mga kasangkapan

Huwag nang ayusin ang code na nilalabas ng Agent, ayusin ang sistema na naglalabas ng code.

May-akda ng artikulo, pinagkukunan: InfoQ

Kung ang isang developer ay hindi kayang gamitin nang maayos ang Agent, ang problema ay maaaring hindi sa developer, kundi sa kumpanya na hindi pa handa ang isang gumagana sistema para sa Agent.

Ang maraming kumpanya ay nagpapahiwatig na isinasagawa nila ang pagpapalit sa AI, ngunit patuloy pa ring nasa antas ng pagbili ng mga kasangkapan tulad ng Cursor at Claude Code para sa mga developer, pagpapalabas ng ilang pagsasanay, at pagpapahintulot sa lahat na mag-eksperimento nang mag-isa. Kung sa huli ay hindi maganda ang epekto ng Agent, ang kasalanan ay babalik sa mga gumagamit.

Ngunit si Patrick Debois, ang nagtatag ng terminong DevOps, ay naniniwala: “Kailangan ng mga developer na magkaroon ng mahalagang pagbabago sa pag-iisip: kapag hindi nagawa ng Agent ang iyong inaasahan, huwag mong baguhin ang code na itinaguyod nito, kundi baguhin ang buong sistema, hindi lang ang Prompt.”

Sa pananaw ni Debois, ito ay ang pagbabagong kailangang harapin ng software engineering habang lumilipat mula sa deterministic systems patungo sa non-deterministic, probabilistic systems at workflows. Ito ay hindi lamang tumutukoy sa teknolohiya, kundi magreresulta rin sa pagbabago ng paraan ng paggawa ng mga developer, team, at buong organisasyon. Ngunit hindi ito maaaring gawin lamang ng isang engineer o limitado sa isang team lamang. Tulad ng DevOps, ito ay maaaring makamit lamang kapag ito ay isinabuhay sa iskala.

Ang core ng problema ay hindi lamang kung makakagamit ang mga developer ng Agent, kundi kung kayang i-ree-organize ng kumpanya ang kanilang mga team, platform, at paraan ng pagtutulungan sa paligid ng Agent.

Ang mga pangunahang punto ay sumusunod:

• Huwag nang ayusin ang code na nilalabas ng Agent, ayusin ang sistema na naglalabas ng code.
• Kung mayroon pa kayong kasamang gumagamit ng “YOLO” na paraan sa vibe coding, dapat mong agad na pigilan ito. Mahalaga ang mga inhenyerong pamamaraan hindi lamang para sa pagpapanatili ng iyong sistema, kundi pati na rin para sa patuloy na pagpapabuti ng Agent.
• Ang madilim na gawaan ay maaaring hindi lubos na madilim, kundi ay may kaunting liwanag (dim factory), na nangangahulugan na kailangan mong pumili kung gaano kalaki ang panganib na iyong tatanggapin para sa bawat tampok, at hindi lahat ng tampok ay angkop para sa ganap na awtonomiya.
• Ang tao na hinahanap mo ay yung makapagpapakita ng ekstrim na paggamit ng AI, may matibay na teknikal na kaalaman, at handang magbahagi at magtrabaho nang sama-sama.
• Ang iyong moat ay ang pagkuha ng mga nakapirming kaalaman, ang mga kasalukuyang iyong inilalagay sa skill, Context, at kahit sa mga pagbabawal ng Harness.

Noong 2009, marami ang sabi sa akin na ang ideya ng continuous delivery ay bulag.

Tala ng translator: Noong 2009, ang industriya ay gumagamit ng modelo ng malaking bersyon na isinasaad kada ilang buwan; ang karaniwang paniniwala ay ang mas maraming pagpapalabas, mas mataas ang panganib. Kasama pa rito ang malalaking hadlang sa pag-unlad at operasyon, at ang mga automated na imprastruktura tulad ng container at cloud ay hindi pa kumpleto, at kulang sa mga standardisadong tool para sa pipeline. Samantala, ang tradisyonal na pagsubok at proseso ng pagpapahintulot sa pagbabago ay naglalayong alisin ang lahat ng mga kamalian bago ang paglunsad, habang ang continuous delivery ay nagtataguyod ng isang bagong pananaw—madalas, incremental, at maaaring i-publish kahit kailan—na nagbabago sa mga pangkalahatang paniniwala tungkol sa panganib at pamamahala ng proseso sa paglunsad ng software, kaya sa karamihan ng mga kumpanya, ito ay tila isang kuwento na hindi makatotohanan at sobrang kamangmangan.

At ngayon, ang Dark Factory ay nakakatagpo muli ng parehong pagtutol.

Translator's note: The Dark Factory refers to an AI-driven autonomous software production model where humans only input SPEC, and AI autonomously completes coding, testing, and deployment without requiring manual line-by-line code review, differing from traditional software factories that still require significant engineer involvement in the process.

Marami akong narinig na pare-parehong pahayag sa iba’t ibang pagkakataon: “Hindi ito gumagana dito.” Ngunit ang tunay na mensahe nito ay hindi ang teknolohiya ang problema, kundi “Hindi pa tayo handa.” Hindi sila ayaw i-implement ang bagay na ito, kundi ang kasalukuyang istruktura ng organisasyon ay hindi pa makakatulong sa ganitong modelo.

Marami ngayon ang nagsasalita tungkol sa paano gamitin ang loop para i-optimize ang Agent, paano itayo ang Harness—lahat ng ito ay mahusay. Ngunit gustong sabihin ko ay, sa wakas, lahat tayo ay magkakaroon ng antas ng teknolohiya na iyon, at sa isang araw ay magiging isang uri ng standard na produkto, kahit na isang pinakamodernong laboratorio ang magpapakalat nito bilang serbisyo. Noon, wala nang barrier sa teknolohiya. Ang totoong pagkakaiba-iba ay nasa paano gagawin ng iyong organisasyon ang pagbabago sa paraan ng pakikipagtulungan sa paligid nito.

Kaya isinusupos ko na lahat tayo ay naglalakad patungo sa direksyon ng dark factory. Ang nakikita ko sa Tessl at sa iba pang kumpanya ay kapag umuunlad ang mga tao sa paggamit ng mga teknolohiyang ito, ang dinamika ng pakikipagtulungan ay nagbabago nang lubos. Kung kilala ninyo ang Conway’s Law, alam ninyo na mayroong isang mutual shaping na ugnayan sa pagitan ng organisasyon at mga kasangkapan—kung paano mo isinaayos ang mga tao, ganyan ang sistema na iyong gagawa. Pero hindi ko ngayon sasabihin kung paano gawing mas mabuti ang inyong Agent; kundi kung paano ito nagbabago sa inyong dinamika ng team, inyong platform, at buong organisasyon.

Naniniwala ako na ang karamihan sa inyo ay nagtatrabaho sa isang team, hindi nag-iisa; ang pagtatrabaho bilang isang team ay lubos na iba sa pagtype lang sa isang tao sa Claude Code.

Ngayon, mahilig ang lahat mag-isip ng isang pahayag: ang mga developer ay hahantong sa pagiging isang konduktor, isang tagapag-ayos ng Agent. Sa tingin ko, walang mali sa pahayag na ito—totoo nga ito ang aming pinapalipat. Lalo tayong nagsisimula na maging mga tagapamahala ng Agent, at kailangan nating harapin at pamahalaan ang aming ugnayan sa mga Agent.

Ngunit ang problema ay, maraming developer ang sinasabi sa pribado: Hindi namin sinadyang pumasok sa larangan para gawin ito, hindi namin inaasahan na magugugol ng maraming oras para i-optimize ang Prompt o isulat ang mas mahusay na SPEC. Kami ay mga inhinyero, at aming pinag-uusapan ang teknolohiya, at ito ay nagdudulot ng isang pagkakatulad sa pagkakakilanlan, at patuloy naming itatanong sa sarili namin: Ito ba talaga ang papel na gusto kong gawin?

Matapos ay lumitaw ang konsepto na “Context engineering,” na nagbigay ng pagkakataon sa mga developer. Ito ay nagsasabi na hindi lang ito tungkol sa pagtawag ng Prompt; kailangan mo ring subukan, suriin, ibahagi, at mapabuti ang Prompt, kaya may kaunting katangian ng engineering dito. Ngunit sa totoo lang, marami pa ring mga developer ang naramdaman na malalim ang pagiging nakapag-ugnay lamang sa Prompt at SPEC, at nararamdaman nilang naging “prompt administrator” na sila mula sa isang engineer.

Ngunit sa aking pagmamasid sa praktika, nakita ko ang isang interesanteng pagbabalik-tanaw. Nang simulan naming ipakilala ang Harness, ang mga loop, at kahit paano ang buong organisasyon patungo sa mas mataas na antas ng awtonomiya, isang bagong teknikal na landas ang nabuksan. Biglaan, kailangan ng mga developer na gumawa ng mga kasangkapan para sa Agent, at biglaang na-ignite ang isang grupo ng mga tao. Ang mga developer na dati ay nagsasabi, “Hindi ito gawain ko,” ay biglaang naging mas aktibo. Sabi nila, oo, kayang gawin namin ito! May-kaalaman tayo sa ganitong kaalaman! Kayang gawin namin na mas mabuti ang sistema sa pamamagitan ng pag-program. Kaya interesante ito: habang patuloy naming sinasabi ang “abstrak, abstrak, at muli pang abstrak,” ang pakiramdam ng “kasanayan” ay bumalik sa isang ibang lugar, at nagbigay ng bagong espasyo para sa mas matitigas na inhinyeriyang gawain.

Madalas akong tanungin: Paano haharapin ang mga nagkakaroon ng pag-aalinlangan? Ang aking sagot ay palaging ito: ang mga tao na ito ay talagang iyong kayamanan. Dahil sila ay may malaking halaga ng implicit na kaalaman at pagpapasya, kailangan mong ilagay ang lahat ng ito sa Agent. Maaari mong sabihin sa kanila: “Ibaba mo ang lahat ng iyong kaalaman at kritikal na pag-iisip,” at ito ay gagawing mas mahusay ang Agent at Harness. Kung makakasalubong mo ang mga taong mas malakas ang pagtutol, at araw-araw ay nagsasalita ng “sobrang mababa ang kalidad ng code na ginawa nito,” gawin mong fuel ang mga ito—ilipat ang galit at pag-aalinlangan na ito bilang lakas para sa pagpapabuti ng sistema.

Ngayon, ibinibigay ko ang isang rekomendasyon sa mga developer ng kompanya: gawin ang isang malaking pagbabago sa pananaw—hindi na mag-ayos ng code na ginawa ng Agent, kundi ayusin ang sistema na nagpapagawa ng code. Tulad ng sinabi ng isang tao ilang taon na ang nakalipas: Huwag gawin ang bagay na iyon, kundi gawin ang bagay na nagpapagawa ng bagay na iyon. Ngayon, nasa antas na ito ng abstrakson natin, gumagawa tayo ng “bagay na nagpapagawa ng bagay” sa pamamagitan ng Context, Harness, at loop. Kailangan ng marami pa ring nasa antas ng “Human in the Loop,” auto-complete, at pagpapalit ng prompt na isipin kung paano sila maaaring umabot sa isang sistema ng pag-iisip.

Ang tunay nating gagawin ay gamitin ang mga mabuting praktis sa inhenyeriya upang minimisa ang bilang ng pag-intervensyon ng tao. Sa simula, lahat ay nagsasabing “vibe coding” ay nakakatuwa—ilagay ang Prompt, makakuha ng resulta, at ipagpatuloy na lang. Ngunit ngayon, mas malinaw na ang ating pag-unawa: hindi lang natin ibinibigay ang mga utos sa Agent sa pamamagitan ng Prompt; sa katotohanan, sinasabi natin: “Pakisulat kasama ang mga pagsubok,” “Pakiusap i-update ang dokumentasyon,” “Pakisunod ang mga pamantayan sa pagsusulat ng code.” Ang lahat ng mga bagay na sinasabi natin sa mga mabuting inhenyero, ngayon ay iniiwan natin nang buo sa Agent. Kung mayroon pa ring miyembro sa iyong tim na gumagamit ng ganitong “YOLO (gawin muna, pagkatapos ay tingnan)” na paraan sa vibe coding, dapat mong agad itigil ito. Ang mga praktis sa inhenyeriya ay hindi lamang mahalaga para sa pagpapanatili ng iyong sistema, kundi pati na rin para sa patuloy na pagpapabuti ng Agent mismo.

Sa ilang mga team na nasa unahan, nakikita ko na ang isang bagong ritwal: patuloy pa silang gumagawa ng mga pagpupulong sa plano at pagmamasid, ngunit ang paksa ng pag-uusap ay lubos na nagbago. Sa mga pagmamasid, hindi na sila nagsasabi, “Ano ang problema sa code?”, kundi, “Ano ang problema sa sistema?”

Sa pagpupulong tungkol sa plano, nakita ko rin ang isang natural na paghahati. Ang mga gawain na malinaw na natukoy at may sapat na saklaw ay direktang ibinibigay sa Agent, dahil mas nagiging mahusay ang Harness at kayang masunod ang mga malinaw na gawain. Samantala, ang mga gawain na may ambigong hangganan at kailangan ng pag-uusap ay nananatili sa mga tao. Kaya nangyari ang isang natural na paghahati sa pagpupulong: ang mga kard na ito ay papasok sa pipeline ng Agent, habang ang mga kard na iyon ay pag-uusapan namin.

Karaniwang dinadanas ng mga developer ang isang siklo ng pagkatuto: una ay natututo ng Prompt, pagkatapos ay mas mahusay na SPEC, sunod ang Context, Harness, at loop, at ang buong industriya ay umuunlad sa loob ng siklo na ito. Ngunit ang maaaring gawin ng team Lead ay magtakda ng ritmo at mga limitasyon sa proseso, tulad ng pagsasabi sa kanila: “Huwag na mag-adjust ng Prompt, gawin ninyong reusable ang Context.” “Sige, natapos na ang hakbang na ito, lumipat tayo sa susunod.” Ang halaga ng team Lead ay nasa pagtatakda ng ganitong ritmo; kung ikaw ay nag-iwan lang ng isang pahayag na “Mag-isip kayo ng sarili ninyo,” hindi ito gagana.

Mayroon ding isang epekto sa kaisipan: kapag umabot ang produksyon ng inyong tim ay isang malaking pagtaas, ang mga nasa ibaba tulad ng mga nasa GTM (Go to Market) ay maaaring hindi makasabay, kahit na ang mga user ay maaaring hindi makasabay din. Kaya kailangan mong gamitin ang automation upang tulungan sila; ang inyong framework ay hindi dapat tumigil sa pag-code lamang, kundi kailangan itong ma-extend patungo sa kanila. Parehong prinsipyo ang umiiral sa mga input ng pangangailangan sa itaas: kung ang mga pangangailangan ay hindi sapat na mabilis, ang tim ay maaaring mabigatan, at ang mga bahaging ito ay kailangang isama rin sa bagong workflow.

Mayroon ng maraming indikador sa merkado ngayon, tulad ng Token spending at iba pa. Ngunit unti-unting naniniwala ako sa dalawang tunay na indikador na makakatukoy sa produktibidad. Ang una: bilangin mo kung ilang beses pa kailangan ng tao na mag-intervene upang mabuo nang tama ng isang Agent ang isang gawain. Dapat itong patuloy na bumababa. Mas mabuti ang iyong Harness, mas magandang Context, mas malinaw ang gabay, mas mababa ang bilang na ito. Ang pangalawang indikador ay ang multiplier effect na nangyayari kapag lumilipas ka mula sa pagtatrabaho nang mag-isa patungo sa isang shared system. Kapag nagayos mo ang isang bagay sa isang lugar, lahat ng tao ay nakikinabang. Hindi ito nangangahulugan na isang tao ay naging sampung beses na mas epektibo, kundi isang pagpapabuti sa Agent system ay nagdudulot ng multiplier effect sa lahat.

Maaari mong simulan ito sa isang repository o loob ng isang maliit na team, i-share ang Context at magkaisa upang mapabuti ang Harness. Ngunit ang tunay mong nais gawin ay palawakin ang epekto na ito sa buong organisasyon. Sa puntong ito, kailangan nating pag-usapan ang platform team.

Ang tim ng platform ay isang tipikal na shared organization, at ngayon ay maaaring nagtatrabaho sila sa infrastraktura, cloud services, MCP gateway, at iba pang bagay, at hindi gaanong nakafokus sa Agent. Ngunit may maraming bagong bagay na lumalabas na kailangan nilang tanggapin, tulad ng skill registry (hindi dapat pagsamahin ng bawat isa ang parehong set ng skill sa kanilang sariling sulok), system ng pag-evaluate ng Context (gagamitin ba talaga ang Context na ito? Maaari bang masukat ito?), at espesyal na mga safety at identity management para sa coding agent (sa anong identidad ang ipinapasa ng Agent ang code? Saan ang hangganan ng pagsasakop?) Kaya kailangan ng platform team ng isang tao na magtutulak sa kanila upang lumago sa kanilang bagong sentral na papel.

Mahirap ito, kailangan mo ng isang malinaw na owner na magpapagalaw. Pero sino ito? Ang tim ng platform? Ang tim ng developer experience? Karaniwan, hindi nagtatrabaho ang una sa mga bagay na developer level, habang ang huli ay hindi gaanong nagtatrabaho sa infrastructure, kaya kailangan ng isang pagkakaisa, ngunit hindi ito mangyayari nang sarili nito. Kailangan mong siguraduhing may isang tagapagpaganap na magpapagalaw sa sentralisadong gawain, kung hindi, ang iyong tim ay magiging nakapaloob lamang sa kanilang sariling sakop at hindi magkakaroon ng “Paved Road”.

Bakit kailangan ng bawat team na mag-develop ng sariling paraan ng pagkonekta sa authentication system? Ito ay isang shared component, dapat ilagay sa registry. Bakit kailangan ng bawat isa na magtatayo ng sarili nilang harness? Kung gagamitin natin ang parehong linter at parehong set ng security scanning tools, ito ay isang reusable component. Naniniwala ako na ito ay magiging parang pagpapalawak ng cloud infrastructure noong unang panahon, at maaaring ma-concentrate sa platform registry.

Ngunit ang problema ay, kung sinuman ang maaaring magdagdag ng anumang bagay sa gitnang repository, mabilis itong magiging isang sprawl. Halimbawa, kung isang skill ay itinapon doon, sino ang nagmamaintain nito? At kung ang isang iba pang tao ay gumawa ng fork ng isang katulad na skill, alin sa dalawa ang pipiliin ko? Kaya kailangan mayroong isang tao na may malinaw na pagmamay-ari sa isang partikular na larangan, at siya ang dapat siguraduhing ang bagay na iyon ay testable at modular, upang makapag-extend ang iba sa Context o sa security scanning section ng Harness. Kailangan mong gawin ito sa isang sentralisadong paraan, hindi sa pamamagitan ng arbitraryong pagpapasa sa loob ng organisasyon.

Mahirap makapag-achieve ng konsenso. Hindi ito ganito ka-kilala tulad ng digmaan sa pagitan ng tabs at spaces, ngunit minsan, parang ganoon din. Kung pipilitin mong pagsundan ng dalawang koponan ng developer ang isang paraan ng paggawa, kailangan ng malaking dami ng komunikasyon at pagtutuwid. Kaya sa huli, mas malamang na mayroon kang hindi isang pagsasaligan, kundi tatlo o apat, kung saan sila maaaring pumili. Kung gusto nilang gumawa ng sarili nilang sistema, pwede rin—pero gamit ang kanilang sariling budget. Ang “madaling daan” ay ang isang sentralisadong sistema na ginagamit upang hikayatin ang lahat na sumunod dito.

Kung gagamitin nang walang pag-iisip ng mga users ang mga shared capability na ito, kailangan mong ipakita sa kanila ang gastos. Habang ikaw ay nagpapakita ng mga gastos, natural na isasagawa nila ang pag-optimize. Ito ang responsibilidad ng platform team: gawing transparent ang gastos: Magkano ang ginastos? Gaano kahalaga ang epekto? Kung maaari kong bawasan ang bilang ng mga iteration ng Agent, iyon ang pag-optimize. Pero kung hindi ko makikita ang indikator na ito, at tanging ang final result lang ang makikita ko, hindi ko kayang gumawa ng anumang aksyon. Ang visualization ay ang batayan ng lahat ng pag-optimize.

Kaya ang aking pangunahang pananaw ay: kailangan nating lumipat mula sa mga developer na nagtatrabaho nang mag-isa, patungo sa team-level na pagbabahagi ng Context at mga komponente, at sa huli, patungo sa “multiplayer system” sa loob ng buong organisasyon. Ang multiplier effect ay magiging malakas doon, dahil mayroon kang flywheel kung saan ang mga pagpapabuti ay maaaring magpalabas nang sabay-sabay sa maraming direksyon.

Sa mas mataas na antas, paano isipin ng VP ng Engineering ang bagay na ito? Kaya kong hulaan ang kuwento na mangyayari sa inyong organisasyon: hackathon o lunch sharing, pagbabahagi ng mga tagumpay na kaso, pagbuo ng isang shared Slack channel, at pagpapatupad ng isang champions program. Ang lahat ng ito ay karaniwang mga paraan sa pagbabago. Ganito rin ginawa noong Agile transformation, at ganito rin ginawa ng DevOps—wala naman itong bago.

Sa kabilang panig, alam natin na ang estratehiyang “magbigay ng lisensya, mag-organisa ng pagsasanay, bigyan ng kalayaan ang lahat, at hayaang umanib ang libo-libong bulaklak” ay hindi kailanman nagtagumpay. Ang resulta ng libo-libong bulaklak ay karaniwang libo-libong damo—maraming bulaklak na nagbubukas ngunit walang isang nagbubunga. Kaya aking ipinopoposal na sa aspeto ng organisasyon, dapat malinaw na bigyan ng awtoridad ang mga Team Lead at platform team upang gawin ito. Hindi ito maaaring maisagawa ng isang super indibidwal lamang; kailangan mayroong isang tao na opisyal na awtorisado upang itaguyod ito.

Ang paghingi ng tulong mula sa iba ay nakakapagod din. Ang mga pamagat ng posisyon ngayon ay isang kalituhan—AI Product Engineer, forward deployed engineer, agentic engineer, AI engineer… ang mga salitang ito ay walang tunay na kahulugan. Hindi mo maaaring matukoy ang kasiguraduhan ng isang tao batay sa kanyang pamagat, dahil ang buong industriya ay hindi pa nakakamit ang kasiguraduhan. Gayunpaman, kapag naglalabas ka ng pangangailangan sa paghahanap ng trabaho, ang mga salitang ito ay nagdadala ng ilang signal at nakakatulong upang tarikan ang mga may layunin, ngunit hindi ito nangangahulugan na mayroon sila ang kaugnay na kasanayan. Narinig ko rin ang ilang mas kakaibang kuwento—may mga kandidato na gumagamit ng AI sa kanilang mga tainga upang magbigay ng mga sagot sa real-time habang nag-iinterview; kapag tanong ng interviewer, dumating ang payo ng AI sa kanilang AirPods.

Kaya narinig ko ang mas maraming kumpanya ang gumagamit ng ganitong paraan ng pagsusuri. Unang hakbang, ibigay ang isang gawain at hilingin sa kanila na gamitin nang buong husay ang AI. Kung makatutulong ang AI sa kanila na malutas ito, iyon ay patotoo na sila ay mahusay sa paggamit ng AI. Ikalawang yugto, hilingin sa kanila na suriin ang kanilang solusyon at ipaliwanag, “Bakit mo pinili ang solusyong ito? Paano mo pinatotohanan na tama ito?” Sa puntong ito, sinusubok mo ang kanilang kakayahan sa pagsubok at inhinyeriyang pagpapasya. Ang unang bahagi ay sinusubok ang kakayahan sa paggamit ng AI, habang ang ikalawang bahagi ay sinusubok ang kanilang inhinyeriyang kaalaman. Ikatlo, tingnan din kung paano sila nagkakasama, kung handa silang magbahagi, o kung sila ay open-type o solo-type. May mga tao na may malakas na teknikal na kasanayan ngunit ayaw magbahagi ng anumang bagay—ang mga taong ganito ay maaaring maging hadlang sa panahon ng Agent.

Ang tao na hinahanap mo ay ang nagkakaisa ng tatlong bagay: kakayahang gamitin ang AI nang lubos, matibay na teknikal na pundasyon, at pagkakaroon ng pagkakataon na ibahagi at makipagtulungan. Hindi ito tao na nag-aral lang ng ML o AI, o isang eksperto sa pag-decode—kundi isang hybrid. Mahirap makahanap ng tao na puno sa lahat ng tatlo, pero walang problema kung ang isang kandidato ay sobrang malakas sa isang aspeto ngunit kailangan ng gabay sa iba. Samantala, huwag ihalo ang mga kasanayang ito at ilagay ang label na “junior” o “senior”—ibat-ibang dimensyon ito ng kasanayan, at maaaring “senior” ang isang tao sa paggamit ng AI, ngunit “junior” sa pagkakaroon ng pagkakataon na makipagtulungan.

Kailangan pa ng VP ng Engineering na magbigay ng ulat. Binebili namin ang maraming lisensya—maaari nating patunayan ang return on investment? Mas mabilis na ang pagdedeliver? Maaaring may pangako, ngunit mahirap patunayan. Mas mataas na ang kalidad? Parehong mahirap sabihin. Pero bumalik tayo sa dalawang indikador na sinabi ko kanina: maaari mong ipakita kung gaano karami ang pagbawas sa bilang ng interbensyon, gaano karami ang pagpapabuti, at gaano karami ang pagtaas sa rate ng paggamit muli. Mas madali at mas nakakapanghikayat ito kaysa paghahambing sa “productividad sa pag-code may Agent o walang Agent.”

Kaya, kapag may nagreklamo na sobrang gastos ng Agent at naisipang i-limit ang budget, ang iyong natural na reaksyon ay hindi dapat “bawasan natin lahat ng gastos,” kundi “paano natin mapapabuti ang gastos.” Ang pinakasimpleng paraan ay piliin ang tamang model—hindi lahat ng gawain ay nangangailangan ng pinakamalakas na model; ang ilang gawain ay sapat na may mas mura. I-educate ang mga developer kung anong sitwasyon ang dapat gamitin ang anumang model, at mas malalim pa, bigyan sila ng mas mahusay na Context at Harness, upang mas mabawasan ang mga pagkakamali ng Agent at mas mabawasan ang gastos.

Mayroon pa pong isang paksa tungkol sa laki ng team. Ang pangarap na katapusan ay ang isang multi-skilled na tao na gumagawa ng lahat. Ngunit kung susuriin mo nang mabuti: karaniwang kailangan niya ng mga kagalingang komplemento, tulad ng product manager o designer. Dapat ding isama mo ang mga backup, kung sakaling mag-vacation ang isang tao? Iyon ay bumabalik sa tatlo. Maaaring kailanganin pa ng isang tao na obserbahan ang produksyon at mga work order, at kung talagang sobrang epektibo ka, maaaring gawin ng parehong grupo na兼职. Ngunit kapag nag-aayos ka ng bug, bumababa ang bilis ng paggawa ng mga feature. At mayroon pa ring mga baguhan—kailangan mong maghanda para sa kanila upang malaman nila kung ano ang “mabuti.” Kaya nananatili akong naniniwala na sa isang organisasyon, hindi natin talaga maaaring gawing dalawa o isang tao ang bawat team.

Sa huli, ang dark factory ay maaaring hindi lubos na madilim, kundi mananatili ang kaunting liwanag (dim factory), na nangangahulugan na kailangan mong pumili kung gaano karaming panganib ang iyong tatanggapin para sa bawat tampok—hindi lahat ng tampok ay angkop para sa ganap na awtonomiya. Maaari mong i-invest ang mas maraming sa pag-audit, tulad ng pagtatrace: sino ang nagbago ng code? Tao ba o Agent? Magdagdag ng validator upang suriin kung totoo bang useful ang code, at mag-invest sa pagkakaroon ng pagka-sitwasyonal kapag nagkakaroon ng pagkabigo ang awtomatikong proseso. Mula sa ganap na mikro-manipulasyon (kailangan ng tao na tingnan ang bawat linya ng code) hanggang sa ganap na awtonomikong pag-apruba (na nagpapalagay na lahat ng output ng Agent ay tama), ito ay isang buong spectrum. Ang gagawin mo ay pumili ng iba’t ibang antas ng awtomatikong proseso batay sa antas ng panganib para sa iba’t ibang uri ng pagbabago.

At sa tingin ko, ang iyong malalim na kahon ay ang pagkuha ng mga nakapirming kaalaman, ang mga bagay na iyong ipinapaloob sa skill, Context, at kahit sa Harness constraints na business context. Para sa akin, ito ay nagdadala ng continuous delivery patungo sa continuous learning. Tanungin mo ang sarili mo: Gaano kabilis natin maipapalit ang isang bagong bagay sa sistema at maalis ang isang lumang bagay? Ito ang iyong kakayahang tumugon. Kung kayang mong patuloy na mapabuti ang kakayahang ito, ang pangunahing tanong ay hindi na “Gusto kong gawing mas maaasahan ang buong sistema,” kundi “Kayang ko bang panatilihin ang kapanatagan ng sistema habang binabago ko ang mas maraming bahagi nito?”

Kung tatatayuan mo lang ng isang pangungusap, ito ang dapat: Ang mga mananalo ay hindi ang mga super player na nagtatrabaho nang mag-isa, kundi ang mga nagkakaroon ng kakayahang paunlarin ang organisasyon sa maraming antas.