Magpapatuloy ang pagpapalit ng mga empleyado hanggang matutunan natin ang paggamit ng AI
May-akda: Arnav Gupta, AI Engineer
Bao Yu, AI Analyst

Sa loob ng opisina ng mataas na pamamahala ng aming kumpanya, nasa isang lugar ang isang lista ng pagpapalit na naglalaman ng 8,000 tao. May 10% na posibilidad na ako ay nasa listahang iyon. Sa loob ng ilang araw, sa Mayo 20, malalaman ko ang aking kapalaran.

Nakita ko ang balita tungkol sa “AI layoffs” na inanunsyo ng Coinbase ngayon, kaya nagpasya akong sumulat ng artikulong ito. Sinikap kong magsimula bago ang Mayo 20, dahil gustong-gusto kong ibahagi ang mga pinakatotoong pananaw, nang walang anumang personal na emosyon tungkol sa “kakalabasan ko ba o hindi.” Ang mga ideyang ito ay hindi nauugnay sa kung ako ay mawawalan ng trabaho o hindi, at hindi lamang limitado sa kompanya kung saan ako nagtatrabaho. Mula sa mga totoong saloobin ng aking mga kaibigan na nagtatrabaho sa iba’t ibang malalaking kumpanya.

May malaking bilang ng mga artikulo na nag-uusap: ang bagong alon ng pagpapalayas (na karaniwang itinuturing na nagsimula nang palayasin ni Jack Dorsey ang 40% ng mga empleyado ng Square) — ay dahil sa AI, o simpleng nagpapakita lang ng “AI-washing” (ang paggamit ng pagtanggap sa AI bilang palaisipan upang itago ang iba pang pagkabigo sa negosyo o totoong layunin ng pagpapalayas).

Hindi ko gustong punuin ang artikulo ng mga link sa mga balita at papel para ihirap ka, maaari nang nakikita mo na ang mga ito o kaya’y kailangan mo lang i-search sa Google o tanungin ang ChatGPT.

Highly touted "AI Productivity" and Elusive Evidence

Totoo ba na ginawa ng AI ang ating paggawa nang mas epektibo? Ito ay talagang isang kontrobersyal na malaking tanong! Kung isipin natin sa kabaligtaran at ipagkakaila na “hindi nagbago ng anuman ang AI,” isipin ko na kahit ang mga pinakamalalim na nag-aalinlangan sa halaga ng AI ay hindi sasang-ayon sa ganitong pahayag.

Lalo na sa mga tech company, ang tibay na pagtaas ng paggamit ng AI ay isang katotohanang nakikita. Kahit ang mga pinakamakapag-isa, may limitadong budget para sa AI, at hindi nagbibigay ng AI tools sa kanilang mga empleyado, hindi maiiwasan na may bahagi ng trabaho na natutupad ng AI—kahit ang mga empleyado ay nagtatrabaho nang mahirap sa Google o Microsoft Office Suite, at lihim na gumagamit ng Gemini o Copilot para i-edit ang mga dokumento.

Para sa mga kumpanya na may mas malalim na pananaw at sumali sa dagat ng AI token (ang pangunahing yunit ng teksto na ginagamit ng AI model, kung saan karaniwang binabayaran ang mga kumpanya batay sa bilang ng mga token na ginamit) tulad ng Uber o Shopify (hindi ko kasama dito ang mga tulad ng Meta o Microsoft na nagtatayo ng kanilang sariling malalaking language model, o ang Vercel o Cloudflare na aktibong nagtatayo ng AI infrastructure; tanging ang mga "tagagamit" lamang ang isinasaalang-alang), ang kanilang paggamit ng AI ay naging kakaibang malala.

Nagiging karaniwan na namin ito: mula sa 90% hanggang 100% ng code na ginawa ng AI, hanggang sa pagtaas ng 2 hanggang 5 beses ang bilang ng code reviews (PRs/diffs) bawat linggo, hanggang sa pagkawala ng taunang budget para sa AI na nasa milyon-milyon dolyar sa loob ng ilang buwan.

Gayunpaman, tiyak na sasagotin ng mga tech critic at investor tulad ni Ed Zitron, Will Manidis, Gary Marcus, at Michael Bury ang tanong na direktang tumutok sa kaluluwa: Kung ganito, bakit hindi nagkaroon ng pagtaas ng 2 hanggang 5 beses sa kita ng mga kumpanyang ito? Bakit tila magkakapareho ang kanilang App sa nakaraang anim na buwan? Kung talagang napakadali ng AI, ano nga ba ang natapos nila gamit ang AI? Kung mas maraming 5 beses silang isinulat na code, ngunit walang pakiramdam ang end-user, ano ba ang kahalagahan ng mga code na ito? Ito ay isang napakalalim at makatotohanang tanong.

Input, Output, at Outcome

Kailangan muna nating magbigay ng isang maikling aralin sa pagpapatakbo ng negosyo. Kapag ang isang katamtamang kumpanya na mabilis na lumalago, may sobrang pondo, at nagkakalat ng pera ay nagtatapos sa pagkawala ng pondo, pupunta ka sa isang matandang CEO para humingi ng payo. Sasabihin niya sa iyo na hingin ang tulong ng mga tagapayo mula sa McKinsey. Ang mga tagapayo ay maglalagay ng isang puting slide sa unang pahina ng kanilang presentation, na may tatlong salita na isinulat gamit ang default na Arial font: “Input, Output, Outcome.”

Sasabihin nila sa iyo ang isang pangunahing prinsipyo ng negosyo na kilala ng lahat, ngunit madalas kalimutan:

Code, only investment.

Ang tampok ay ang output.

Ang tagumpay ay ang pagiging handa ng mga user na magbayad para sa iyong produkto.

Ang AI (o kaya naman ang mga produkto tulad ng Claude Enterprise Edition) ay isang B2B SaaS na produkto. Makikita mo na ang pagtatakda ng presyo at pagmamarketing ng mga SaaS ay iba-iba. Kung ang isang produkto ay direktang nagbabago sa "mga resulta," karaniwang kumukuha sila ng bahagi mula sa "mga resulta." Isipin ang ganitong pananalita sa pagbebenta: "Ang aming tool ay nagpapabilis ng 36% sa pagpapagawa ng mga lead sa pagbebenta. Subukan agad, at magbayad lamang ng mababang bayarin na 5% ng kabuuang kita."

Ito ay talagang magpapabilis sa pagkuha ng mga kliyente. Sa parehong iba pang kondisyon, kung nakakapag-negotiate ka ng 100 deals sa nakaraang 100 araw, ngayon ay kailangan mo na lang ng 63 araw. Ang 36 araw na natipid (kung tama ang aking kalkulasyon) ay maaaring gamitin mo para makakuha ng karagdagang 57 deals! Ibig sabihin, potensyal na tumataas ang iyong kita ng 57%. Sana ay sadyang magagandang ideya para sa sinuman na magbigay ng 5% ng kanilang komisyon para makakuha ng karagdagang 57% na kita. At kung hindi mo gagamitin ang produkto na ito, hindi ka magbabayad ng anumang pera.

Maaari mong maunawaan kung ano ang sasabihin ko—ang pricing model ng Claude para sa paggamit ng Token ay ganito hindi. Kung ang iyong software engineer ay tulad ng isang addict na nakakasigurado sa paggamit ng Claude para sa programming (natuklasan ko lang na parehong 'cc' ang kanilang abbreviation), at bumubuo ng 100 milyon na Token araw-araw, magkakahalaga ito ng $100 araw-araw para sa bawat engineer.

Kahit na ang ilang bahagi ng kanilang code ay itinapon sa basurahan dahil hindi ito gumagana;

Kahit na ilang code ay na-rollback nang maagap dahil sa nakapagdulot ng seriyosong system failure (SEV) (SEV ay ang Severity, karaniwang ginagamit ng mga tech company upang tukuyin ang mga seriyosong online incident na nagdudulot ng service interruption);

Kahit mayroon pa ring ilang code, para lamang magbago ang hitsura ng mga panloob na kasangkapan, upang mas maging kaakit-akit ang mga dashboard ng data para sa mga vice president;

Kailangan mong sundin ang lahat ng order. Dahil ang code ay tanging “input.” Bagaman karaniwan, kung tama ang direksyon, mas maraming “input” ay madalas na nagdudulot ng mas maraming “output,” na nagtatapos sa mas magandang “resulta.” Ngunit kapag pinarami mo ang input nang limang beses sa isang gabi, hindi na laging sumasalamin ang batayang ito. Ang mga dagdag na “input” na iyong idinagdag ay maaaring biglaang maging parang mga insekto na walang direksyon, at lubos na maliit sa inaasahang “output” o “resulta.”

Ano nga ba ang nagpapahinto sa atin!

Noong nakaraan, tuwing gustong gawin ng CEO o product manager (PM) ang 10 bagay, ang team ng pag-unlad ay laging sinasabing kaya lang nila gawin ang dalawang pinakamahalaga, at wala silang oras para sa ang 8 na natitira. Ano ang dahilan? Sapagkat ang pagsusulat ng code ay hindi laruan—ang pagbuo ng isang kumplikadong at gumagana na software ay nangangailangan ng malaking dami ng oras.

Hmm... ngayon ay halos libre na ang code. Bakit pa rin natin hindi ginawa ang natitirang 8 bagay?

May dalawang sagot: isa ay hindi pinapakinabangan ng CEO at product manager; ang isa pa ay hindi pinapakinabangan ng middle management at mga karanasan na empleyado.

Hindi ibig sabihin na dahil sa 10 ideya na lumabas sa isip ng CEO o product manager, masasagawa nila ang mga ito bilang tunay na mga resulta sa negosyo. Kahit gawin mo ang 10 bagong feature (output), hindi pa rin garantisado na susundan ng mga user ang mga ito at mas maraming magagamit ang iyong App (resulta).

Sa totoo lang, dahil sa limitadong mga yaman sa pag-unlad noong nakaraan, ang “sukat na pagsisikap” na ito ay pilit na nagpapakilala ng mas malalim na pag-uusap, upang maalis ang mga masamang ideya bago sila magkonsyumo ng masyadong maraming yaman, at piliin ang dalawang pinakamahusay. Ngayon, ang pagsulat ng code ay mabilis at mura na, kaya ang pag-uusap tungkol sa kalidad ng mga ideya ay tila walang kwenta. Kahit subukan mong ipagtanggol ang iyong pananaw, naniniwala ka bang makakapigil ka sa CEO o PM na humingi ng sarili nilang kahilingan kay Claude? Huwag nang subukan.

Alam nating lahat kung gaano kahirap ito. Una, kailangan magkaisa ang lahat ng may-akda tungkol sa “bakit” gagawin ito; pagkatapos, kailangan pang magkaroon ng iba’t ibang pagpupulong upang talakayin kung “ano ang gagawin”; at huli, kailangan pa ng iba pang pag-uusap tungkol sa “paano” ito gawin.

Mas maraming proyekto ang nakakapit sa "hell ng alignment" habang mas marami ang mga team. Noong una, tinatago ang problema dahil mabagal ang pag-code. Ngayon, agad na nagkakaroon ng minimum viable product (MVP) (isang produkto na pinakamababang gastos na nagpapakita ng pangunahing ideya para sa mabilis na pagsubok) kapag matukoy ang "gawin," at agad na isinasaklaw ang susunod na pagpupulong sa susunod na araw.

Sa meeting, nagulat ka na may iba pang team na nagawa rin ang kanilang sariling MVP! Mas masama pa, dahil sa iba’t ibang aksiyoma, ang lohika ng dalawang produkto ay lubos na magkaibang direksyon.

Of course, you can sit down and take your time to discuss whose assumptions are correct.

Pero sadyang totoo. Ang iyong team na may walang hanggang Claude Token, hindi kayo gagawa nito. Hindi rin gagawa ang ibang team. Agad kayong lalapit sa Claude at hihingi niyo na gawin nito muli ang trabaho ng kalaban na paraan na inisip niyo bilang pinakamahusay. At sasagot lang ng maayos si Claude: “Tama po kayo!” at agad na magsisimula mag-code.

Ano ang mga problema na maaaring lutasin ng pagpapabaya?

Sige, salamat sa pagiging mabuting tagapakinig habang ipinagkwentok ko ang mga simpleng aral na ito. Alam kong naghahanap kayo ng pinakamahalagang impormasyon.

Ano ang tunay na layunin ng pagpapababa ng puwede? Ayon sa aking hipotesis, kung ang AI ay hindi talaga nakakapalit nang isang-isa sa 30% ng mga empleyado (ito ay dapat nating pagkakasunduan, di ba? Bagaman sa maraming gawain, mas mahusay ito kaysa sa mga junior white-collar, sa iba pang gawain naman ay mas mababa ito kaysa sa tao—hindi ito isang bahagi na maaaring diretso na i-plug o i-unplug, at mas hindi maaaring palitan nang diretso ang 10%, 20%, o kahit 30% ng mga tao sa isang kumpanya).

Kung gayon, saan ang lohika ng pagpapabaya? Dahil ito ay agad na lutasin ang dalawang pansamantalang problema na nakikita sa ibabaw.

Ito ay simpleng aritmetika ng cash flow. Malinaw na malinaw na kung ang iyong mga inhinyero na nakalulutang sa Claude ay naglalabas ng $100 araw-araw (o $2,500 buwan-buwan, $30,000 taon-taon), ang halagang ito ay katumbas ng buong sahod ng isang software development engineer (SDE) sa India; kalahati ng SDE sa Europe; at kalahati ng SDE sa Estados Unidos.

Kung gagawin ang pinakasimpleng at pinakadirektang kalkulasyon: ipagpalagay na sa isang flat na kumpanya, lahat ng empleyado ay SDE. Upang panatilihin ang kabuuang gastos sa sahod (kabilang ang gastusin sa pagbili ng Token), kailangan mong pabagsakin ang 50% (India), 33% (Europe), o 20% (America) ng mga empleyado.

Sa totoo lang, dahil sa patuloy na pagsabog ng paggamit ng AI na walang pagtaas sa kita ng kumpanya, ang pagpapabaya sa mga empleyado ay naging hindi maiiwasan. Kung hindi, lalabas ang balanse sheet ng kumpanya. Kung tumataas ang iyong gastos ng 50% ngunit ang iyong pangkalahatang resulta sa negosyo ay walang pagbabago o nananatiling pareho, masira na ang iyong unit economics sa buong software development lifecycle.

Kung talagang natutunan natin kung paano gamitin ang AI—naiintindihan natin kung paano isalin ang 50% na pagtaas sa gastos bilang 50% na pagtaas sa kita—hindi na namin kailangang gawin ang hakbang na ito. Ngunit dahil hindi pa mo natutunan, kailangan ng ilan sa inyo na umalis upang makalikha ng pondo para sa pagbabayad sa Anthropic.

Walang alinlangan, ang laki ng anumang malaking kumpanya ay lubos na lumipas sa kanyang kinakailangang sukat para sa「pagkakaroon ng buhay」lamang. Ito ang katangian ng mga malalaking kumpanya—ang mga malalaking organisasyon ay nakapagdadala ng「organisasyong taba」bilang natural na resulta ng disenyo ng organisasyon.

Sa mga kumpanyang ito, kahit na umalis ang isang tao, patuloy pa ring gumagana ang sistema dahil mayroon palang iba na alam kung ano ang dating ginagawa nito. Sa maraming malalaking kumpanya, maaari ka pa ring magpahinga nang kalahating taon para sa maternity leave, at patuloy pa ring ligtas ang iyong proyekto. Ito ay mga magandang bagay! Ngunit isang malakas na patunay din ito: kung iiwanan ng ilang tao ang kumpanya, hindi ito agad magkakaroon ng pagkabigo. Sa kabila nito, pagkatapos ng ilang linggo ng sistematisadong pagkakaroon ng kahirapan, mas mabilis pa ang paggalaw nito sa mga susunod na buwan!

Tandaan mo pa ba ang dalawang koponan na nagkakalaban tungkol sa teknikal na solusyon? Sobrang simple, kung iwan mo ang isang koponan at pagsisikapan ng natitirang koponan na magtrabaho nang ilang gabi—hindi na sila kailangang “magkasundo” kahit kino man.

Hindi natin maipapahalagahan kung ano ang mangyayari sa mahabang panahon (o gamitin ang mga salita ng ekonomista na Keynes—“Sa mahabang panahon, patay na tayo lahat”), ngunit sa maikling panahon, ang pagpapalit ng 10-20% ng mga empleyado sa mga malalaking kumpanya ay magdudulot lamang ng mas mabilis na ritmo ng trabaho.

Sa paglipas ng panahon, ang mga malalaking kumpanya ay hindi maiiwasang makalap ng mga pang-ibang-gawain at pagkakaroon ng sobrang tao, tulad ng pagkakalap ng malaking "organizational debt" tulad ng technical debt. Ito ang karaniwang sakit ng mga malalaking kumpanya. Kahit na magpapababa ka ng 10% ng mga empleyado ngayon, hindi ito makakatigil sa pagbabalik ng lumang problema sa loob ng dalawang taon. Ngunit kapag nakikita mo na ang lahat ay nagpapahayag na limang beses na higit ang kanilang code commits kaysa dati, ngunit hindi pa nakakapag-deploy dahil hinaharang sila ng ibang team, ang pinakadirektang, pinakamadaling solusyon ay: pababain ang ilang tao, upang wala nang magkakasalungat sa isa't isa.

Ito ang pagpapabaya sa AI, kahit hindi direktang palitan ng AI ang iyong posisyon

Nalitan ba ng isang bagong instance ng Claude na tumatakbo sa isang virtual machine ang iyong employee ID? Alam nating lahat na hindi ganito ang sitwasyon.

Gayunpaman, mayroon ba maraming proseso sa kumpanya na dati ay nangangailangan ng iyong pagpindot sa keyboard at mouse sa VS Code, Figma, Canva, o Google Docs, ngayon ay naging simpleng paghinga ng prompt sa isang malaking modelo ng wika ng iba (ang mga taong dating kailangan ng iyong mga output) at wala nang gustong humingi ng tulong sa iyo? Ito ay totoo rin.

Kung titingnan, ang mga pagpapalit na ito ay isang uri ng “AI washing”? Ibig sabihin—mayroon ba talagang mga pangunahing problema ang kumpanya na walang kinalaman sa AI (tulad ng sobrang paghingga, pagbaba ng kita, presyong mula sa kompetisyon, masamang desisyon sa negosyo), at ngayon ay ginagamit lang nila ang AI bilang “dahilan” para sa mga pagpapalit? Oo, sa ilang paraan ay may katotohanan ito.

Maaari mong makita rin na kung ikokolekta mo ang lahat ng “email ng pagpapalit ng empleyado” na isinulat ng mga CEO sa panahong ito, maaari mong isipin na sila ay nagtatayo ng isang chat group at nag-uusap sa isa’t isa habang sumusulat ng mga email na ito. “AI-native team,” “managers na nagsusulat ng code,” “pagpapalawak ng management span,” “flat structure,” “pagpapamahala sa mga AI agent team”… makikita mong ang mga bagong salitang ito ay pare-pareho na lumalabas sa bawat email. Parang binigyan nila ang GPT ng iisang prompt.

Ngunit ang katotohanan ay, kahit hindi direktang inalis ng AI ang iyong trabaho, kahit mayroong bahaging “AI washing,” ang mga pagkakawala ng trabaho na ito ay dahil sa AI. At ang alon ng pagkakawala ng trabaho na ito ay magpapatuloy hanggang sa matututo tayong gamitin nang tama ang AI.

Hanggang matutunan natin kung paano i-convert ang malaking dami ng AI Token sa tunay na mga negosyong resulta, hindi lamang sa pagpapakilala ng code; hanggang matutunan natin na i-sync ang bilis ng “alignment” sa pagitan ng mga organisasyon sa bilis ng pag-code ng bagong henerasyon; hanggang maintindihan natin kung paano gamitin ang dagdag na produktibidad para masunod ang 10 pang bagong ideyang may potensyal, maliban sa orihinal na 2 mabubuting ideya at 8 masamang ideya.

Bago natin talagang maintindihan kung paano tinutulungan ng AI ang pagtaas ng global GDP, upang makapagbayad ng taunang gastusin na humigit-kumulang sa $7 bilyon (kabuuang enterprise revenue ng OpenAI at Anthropic), ang mga kumpanya ay kailangang mag-iyak ng mga sahod ng mga empleyado upang “magsalansan.”

Sa bawat pagkakataon bago tayong matututo kung paano mas epektibong lutasin ang mga pagkakabagot sa pagitan ng mga team, ang solusyon ay palaging isa lamang—alisin natin ang ating sarili mula sa organizational chart.

May 15 pa araw, at malalaman ko ang aking kapalaran. Ngunit anuman ang resulta, naniniwala na ako na alam ko na ang dahilan. Kahit na ako ang nagsagawa ng desisyon sa malawak na opisina ng CEO sa sulok noong panahong iyon, hindi ko alam kung kaya kong gawin ito nang mas mabuti, baka naman ako rin ay gagawa ng parehong desisyon tulad ng iba pang mga CEO na nagtatayo ng grupo.

Original link

Klik upang malaman ang mga posisyon na hinahanap ng BlockBeats

Maligayang pagdating sa opisyal na komunidad ng律动 BlockBeats:

Telegram subscription group: https://t.me/theblockbeats

Telegram group: https://t.me/BlockBeats_App

Twitter official account: https://twitter.com/BlockBeatsAsia