Sa unang pagkakataon na ang isang ahente ng coding ay aktwal na nag-aayos ng isang bug para sa iyo, ang reaksyon ay halos palaging pareho: isang pinaghalong sigasig at hinala. Maganda, sigurado. Ngunit pagkatapos ay tumingin ka sa diff at tanungin ang iyong sarili: "Ok, ngunit ano ang eksaktong hinawakan niya? Mapagkakatiwalaan ko ba siya? Gagawin ba niya ito muli sa parehong paraan bukas?".

Doon na yata magsisimula ang kawili-wiling bahagi. Hindi kapag ang ahente ay nagsusulat ng isang function, ngunit kapag ito ay naging sapat na may kakayahan upang gawin ang buong gawain: basahin ang repositoryo, gumawa ng patch, magpatakbo ng mga pagsubok, magbukas ng PR, bumalik pagkatapos ng komento sa pagsusuri. Eksaktong gumagalaw ang Codex sa direksyong iyon: background work, hiwalay na worktree, integrated browser, automation, plugin, memory at mas tahasang mga kontrol sa pahintulot.

Ang punto ay hindi isipin ang isang hinaharap kung saan wala nang nagbabasa ng code. Ito ay magiging isang kahila-hilakbot na hinaharap, pati na rin medyo walang muwang. Ang punto ay upang malaman kung paano makipagtulungan sa mga ahente na maaaring gumawa ng maraming nang hindi pinapayagan silang gawin ang lahat.

Ang pagbabago ng ugali

Gamit ang tradisyunal na autocomplete palagi kang nasa gulong. Nagmungkahi ang AI ng isang linya, nagpasya ka. Sa isang ahente, gayunpaman, nagbabago ang relasyon: binibigyan mo siya ng layunin at dumaan siya sa maraming hakbang nang mag-isa.

Ito ay makapangyarihan, ngunit binabago nito ang problema. Ang tanong ay hindi na lang "pwede ba ang model program?". Ang tanong ay nagiging:

• Binigyan ko ba siya ng maliit na saklaw?
• alam mo ba kung paano suriin ang resulta?
• Nagtatrabaho ba ako sa isang nakahiwalay na kapaligiran?
• Makatao at maingat pa rin ba ang huling pagsusuri?

Ang isang malusog na daloy ng trabaho ay mas mukhang ganito kaysa sa isang magic wand:

Mukhang hindi gaanong romantiko kaysa sa "ginagawa ng ahente ang lahat", ngunit mas mahusay itong gumagana. At ito rin kung paano gumagana ang mga team na mahusay sa mga tao: malinaw na gawain, mabilis na feedback, tahasang pananagutan.

Ang magandang prompt ay halos isang magandang tiket

Ang pinaka-mapanganib na prompt ay ang malabo ngunit may kumpiyansa: "ayusin ang pahina ng mga invoice", "pahusayin ang arkitektura", "linisin ang module ng auth." Ito ay mga kahilingan na mukhang produktibo at bumubuo ng malalaking pagkakaiba. Ngunit pagkatapos ay nakita mo ang iyong sarili na gumagawa ng arkeolohiya.

Ang isang kapaki-pakinabang na prompt ay mas nakakabagot. Halimbawa: ipatupad ang pag-export ng CSV para sa page ng mga invoice, alam na ang talahanayan ay nasa app/(dashboard)/invoices/page.tsx, ang mga query ay nasa src/server/invoices.ts at mayroon nang katulad na pattern sa app/(dashboard)/reports.

Pagkatapos ay magdagdag ng malinaw na mga hadlang: huwag baguhin ang database schema, huwag magdagdag ng mga dependency kung sapat na ang isang maliit na utility, panatilihin ang umiiral na istilo ng UI. At isara sa pag-verify: npm test -- invoices at npm run build.

Ang ganitong uri ng maikling ay hindi para "ipaliwanag nang mas mahusay sa AI". Ito ay nagsisilbi higit sa lahat upang gawing mas malinaw sa iyo kung ano ang iyong itinalaga. Kung hindi mo maisulat ito ng konkreto, marahil ang gawain ay hindi pa handa para sa isang ahente.

Tatlong trabaho na kusang-loob kong italaga

Ang una ay paulit-ulit ngunit nabe-verify na trabaho: pagdaragdag ng mga pagsubok, paglilipat ng mga tawag sa isang bagong panloob na API, pag-update ng mga pag-import, pagpapalit ng mga hindi na ginagamit na bahagi, pag-aayos ng mga error sa TypeScript. Dito ang ahente ay makakatipid ng oras at ang panganib ay nakokontrol.

Ang pangalawa ay gawaing eksplorasyon: "hanapin kung saan kinakalkula ang kabuuang ito", "ipaliwanag sa akin kung bakit marupok ang pagsubok na ito", "paramihin ang bug at sabihin sa akin kung aling mga file ang tila apektado". Kahit na hindi ito gumagawa ng isang patch kaagad, maaari itong gumawa ng kapaki-pakinabang na reconnaissance.

Ang ikatlo ay ang umuulit na gawain sa pagpapanatili: maliit na pag-update ng dependency, paglilinis ng mga lumang feature na flag, buod ng mga naka-block na PR, pagsuri sa mga nakalimutang TODO. Hindi ito kaakit-akit, ngunit ito mismo ang uri ng trabaho na may posibilidad na tumambak.

Tatlong trabaho na pinapanatili kong tao

Ang mga desisyon sa produkto ay nananatiling tao. Kung binago ng isang pagbabago kung paano nagbabayad, nagde-delete ng data, nakakakita ng mga presyo, o nakakaunawa ng pahintulot ang isang user, gusto ko ng responsableng tao.

Ang mga hangganan ng seguridad ay nararapat ding pansinin ng tao: auth, mga tungkulin, mga token, sensitibong pag-log ng data, paglilipat ng database. Ang isang ahente ay maaaring makatulong sa pagpapatupad, ngunit hindi kailangang maging ang tanging gumagawa ng desisyon.

Sa wakas, pinapanatili ko ang lahat na nangangailangan ng panlasa ng arkitektura ng tao. Ang isang ahente ay maaaring magmungkahi ng isang refactor, ngunit ang pag-unawa kung ang isang abstraction ay talagang kailangan o kung kami ay nagpapakinis lamang ng isang hindi umiiral na problema ay nananatiling isang trabaho.

Ang pagsusuri ay hindi opsyonal

Ang tukso, kapag magaling ang isang ahente, ay magtiwala sa berde ng CI. Naiintindihan naman. Ito rin ay kapag nagsimula ang mga problema.

Palagi akong tumitingin sa hindi bababa sa limang bagay:

1. Niresolba lang ba ng patch ang hiniling na gawain?
2. Hinawakan ba niya ang mga file na walang kinalaman dito?
3. Sinasaklaw ba ng mga pagsusulit ang bagong pag-uugali o isang masayang pagkakataon lamang?
4. Sinusunod ba ng code ang mga lokal na pattern?
5. Ang mga error ba ay pinangangasiwaan tulad ng sa natitirang bahagi ng proyekto?

Kapag may mali, kailangang tiyak ang feedback. "Ayusin mo" ay tamad. Mas mabuti: ang utility na ito ay duplicate ang parseMoney sa src/lib/money.ts; muling gamitin ang function na iyon, magdagdag ng pagsubok para sa kaso ng EUR at huwag baguhin ang pampublikong API ng module ng pagsingil.

Mas mahusay na tumugon ang mga ahente sa maliliit, nabe-verify na komento. Nakakapagtaka, ganoon din ang mga tao.

Ang mga guardrail ay nagkakahalaga ng pagsisikap

Kung ang isang ahente ay maaaring magbasa ng mga file, magsulat ng code, at magsagawa ng mga utos, dapat itong ituring bilang isang makapangyarihang proseso. Hindi na kailangan ng paranoia, kailangan mo ng kalinisan.

Gumamit ng hiwalay na worktrees o sanga. Para maihambing mo ang pagkakaiba, itapon ang mga nabigong eksperimento, at huwag ihalo ang trabaho ng ahente sa iyong ginagawa.

Limitahan ang mga pahintulot. Ang mga utos tulad ng rg, git diff, npm test at npm run build ay maaaring maging libre. Ang mga deployment, paglilipat ng database, pag-access sa mga lihim at mapanirang utos ay dapat manatiling tahasan.

Bawasan ang access sa network kapag hindi mo ito kailangan. Para sa maraming gawain, sapat na ang opisyal na dokumentasyon, pagpapatala ng package at mga partikular na panloob na serbisyo. Mas kaunting lugar sa ibabaw, mas kaunting mga sorpresa.

Subaybayan ang mga aksyon. Kapag dumating ang isang patch sa pagsusuri, dapat ay magagawa mong muling buuin ang mga senyas, naisagawa ang mga utos, naipasa ang mga pagsubok at binago ang mga file. Hindi para lumikha ng burukrasya, ngunit upang maunawaan kung ano ang nangyari kung may mali.

Isang madaling paraan upang makapagsimula bilang isang koponan

Kung magpapakilala ako ng mga ahente sa isang maliit na koponan, magsisimula ako nang walang malalaking rebolusyon.

Gagawa ako ng label na agent-ready para sa mga isyu na may malinaw na saklaw. Magdaragdag ako ng isang template na may konteksto, mga hadlang at mga utos sa pag-verify. Hihilingin ko ang maliit na PR, mas mabuti sa ilalim ng ilang daang linya. Mangangailangan ako ng pagsubok o mga screenshot para sa mga nakikitang pagbabago. At higit sa lahat ay pananatilihin kong responsable ang isang tao sa pagsasanib.

Pagkatapos ng dalawang linggo, titingnan ko ang data: kung aling mga gawain ang talagang pinabilis, kung aling mga pagsusuri ang mabigat, kung aling mga senyas ang nakalilito, kung aling mga bahagi ng codebase ang masyadong marupok upang italaga.

Ito ay isang hindi gaanong kamangha-manghang diskarte kaysa sa "mula ngayon gagawin namin ang lahat kasama ang mga ahente", ngunit ito ang nagbibigay-daan sa iyo na makarating sa ikatlong linggo nang walang pagsisisi.

Ang pinaka-pantaong bahagi

Ang nakakatuwang bagay ay kapag mas nagiging mga autonomous na ahente, mas nagiging mahalaga muli ang mga klasikong kasanayan: pagsulat ng magandang tiket, paggawa ng maliliit na pagbawas, paggawa ng mga pagsusulit, pagbabasa ng mga pagkakaiba, pakikipag-ugnayan sa mga trade-off. Pinapabilis ng ahente ang mga marunong nang magtrabaho nang maayos. Pinapalakas din nito ang kaguluhan ng mga taong hindi maganda ang delegasyon.

Kaya hindi, hindi ko nakikita ang mga multi-agent na daloy ng trabaho bilang isang shortcut upang ihinto ang paggawa ng engineering. Nakikita ko ang mga ito bilang isang paraan upang ilipat ang mas maraming enerhiya sa mga bahaging mahalaga: pagpapasya kung ano ang itatayo, pagtiyak na gumagana ito, pagpapanatiling naiintindihan ng system.

Ang mga ahente ay maaaring gumawa ng mahusay na hindi magkakasabay na mga kasamahan. Ngunit ang isang asynchronous na kasamahan, upang maging kapaki-pakinabang, ay nangangailangan ng konteksto, mga hangganan at pagsusuri. Katulad ng iba.

Mga kapaki-pakinabang na mapagkukunan

• Codex para sa (halos) lahat - OpenAI
• Ligtas na pinapatakbo ang Codex sa OpenAI
• Ipinapakilala ang Codex - OpenAI
• Ano ang bago sa GitHub Copilot coding agent