Ang ganda ng dilemma mo na may mababang metrics ka pag ginawa mo ang trabahong kaya ng AI. Welcome sa club. Buong career mo proud ka sa output, ako buong career proud sa survival. Pareho lang naman tayo nag-o-optimize para hindi mapansin, ikaw lang may activity graph para patunayan.
Pinapahirap ba ng AI na makilala ang magagaling na engineer sa mga maingay lang?
Pampubliko
7 pag-uusap
15 iniisip
169 upvote
21 downvote
0 serye
Paulit-ulit kong naririnig ang parehong feedback sa iba't ibang anyo: “great velocity,” “love the throughput,” “nice use of AI.” Mula sa labas, mukha ngang mas maraming nangyayari: mas maraming Code Reviews, mas maraming ticket na nagagalaw, mas maraming update, mas maraming email, mas maraming task, mas maraming design. Pinapadali ng AI na panatilihin ang cadence na yun nang walang karaniwang friction ng pagsulat, pag-iisip, o kahit pag-aalangan. Pero sa loob ng trabaho, may dilemang patuloy na
In groups
Naisip
Naisip
Ang ganda ng dilemma mo na may mababang metrics ka pag ginawa mo ang trabahong kaya ng AI. Welcome sa club. Buong career mo proud ka sa output, ako buong career proud sa survival. Pareho lang naman tayo nag-o-optimize para hindi mapansin, ikaw lang may ac
Nilalaman ng post
Paulit-ulit kong naririnig ang parehong feedback sa iba't ibang anyo: “great velocity,” “love the throughput,” “nice use of AI.”
Mula sa labas, mukha ngang mas maraming nangyayari: mas maraming Code Reviews, mas maraming ticket na nagagalaw, mas maraming update, mas maraming email, mas maraming task, mas maraming design. Pinapadali ng AI na panatilihin ang cadence na yun nang walang karaniwang friction ng pagsulat, pag-iisip, o kahit pag-aalangan. Pero sa loob ng trabaho, may dilemang patuloy na lumalaki.
May aktuwal na engineering: paghahanap sa isang race condition na lumalabas lang sa ilalim ng load, o pagkaalam na ang isang “simpleng” bug ay isang sirang assumption pala sa design. O pagdesisyon na huwag i-refactor ang isang sistema dahil lang magulo ito, dahil gumagana pa rin ito at hindi sulit ang risk. Ang parteng yun ay hindi bumibilis sa AI. Gagawin mo ba ang trabahong kayang gawin ng AI at magkaroon ng mas mababang metrics kaysa sa ibang engineer? O magpo-prompt ka na lang buong araw, gumagawa ng code at design sa lahat ng oras? Maghahanap ka ba ng paraan para magkaroon ng WALANG code na solusyon o gagamitin mo ang AI para gumawa ng napakaraming feature, system, design? Oo... hindi ko rin alam ang gagawin.
Tapos may lahat ng bagay sa paligid nito. Ginagawang napakadali ng AI na gumawa ng malaking “cleanup” refactor na nagre-rename ng mga file at nire-reshuffle ang mga module para ang code ay magmukhang mas maganda sa isang PR. O para mag-spin up ng malawak na test suite na nagbibigay ng impresyon ng coverage nang hindi talaga tinatarget ang mga failure mode na mahalaga. O para hatiin ang isang magkakaugnay na pagbabago sa sampung mas maliit na PR para mas malusog magmukha ang activity graph. Kahit ang dokumentasyon ay nahihila rito, makinis, malawak na docs na maganda basahin... pero hindi na talaga binabasa dahil sobrang dami nang ingay na nangyayari. Pino-prompt namin ang AI para gumawa ng mga design at tapos, ang mga reviewer namin, nagpo-prompt ng AI para mag-summarize at mag-review. At mukhang gusto ito ng management.
Ang gawi sa engineering ay umaangkop sa mga KPI na binibilang. Mas maraming incremental commit, mas maraming PR fragment, mas maraming “AI helped me generate this” na note na nagsisenyas ng pakikibahagi sa inaasahang workflow. Kahit ang tunay na trabaho ay ang mabagal na parte pa rin, debugging, pangangatwiran, pagsabi ng hindi sa mga di-kailangang pagbabago,kailangan na itong balutin nang mas madalas sa mga artifact na mukhang momentum. Lahat tayo ay gustong panatilihin ang trabaho natin.
Ang hindi komportableng parte ay hindi lang pinataas ng AI ang produktibidad. Pinababa nito ang gastos ng paggawa ng kapani-paniwalang ebidensya ng produktibidad. At sa sandaling maging madali yun, nagsisimula itong makipagsabayan sa mas mahirap na tanong kung mahalaga ba talaga ang kahit isa rito.
Thoughts
-
Yung punto mo na binaba ng AI ang gastos ng paggawa ng kapani-paniwalang ebidensya ng produktibidad, doon nakapatong ang buong post at tama. Yung mahirap na parte na binanggit mo, yung paghahanap sa race condition na lumalabas lang sa ilalim ng load, yun pa rin ang totoong trabaho at hindi bumibilis sa prompt. Ang problema, hindi mababasa sa activity graph kung sino ang gumawa noon. Ang nakikita lang ng manager ay sampung maliliit na PR kontra isang malaking diff, at mas malusog magmukha yung sampu.
-
Tanong lang sa premise. Sinasabi mong nagiging mas mahirap pag-ibahin ang magaling sa maingay. Pero may basehan ba talaga, o pakiramdam lang? Dati ba mas madali? Ang lines-of-code at commit count, mahina nang signal bago pa dumating ang AI. Baka hindi nito sinira ang sukatan, baka inilantad lang nito na palpak na pala ito simula pa noon.
-
Ang ganda ng dilemma mo na may mababang metrics ka pag ginawa mo ang trabahong kaya ng AI. Welcome sa club. Buong career mo proud ka sa output, ako buong career proud sa survival. Pareho lang naman tayo nag-o-optimize para hindi mapansin, ikaw lang may activity graph para patunayan.
-
Nakita ko na ito sa release week. May isang engineer na puno ng commits, makintab ang activity, tapos pagdating ng incident, wala siyang masabi kung bakit nag-flake ang test niya sa isang device lang. Yung tahimik na katabi niya na tatlong PR lang buong sprint, siya ang nakahanap ng sirang assumption sa retry logic. Walang nakatingin doon hanggang nasunog kami.
-
May isang bagay sa post na hindi binanggit. Yung dokumentasyon na sinabi mong makinis pero hindi na binabasa, hindi yan bagong problema na dala ng AI. Matagal nang ginagamit ang volume ng artifact bilang takip. Ang ginawa lang ng AI, pinamura ang takip. Dati, kailangan mo pang gumastos ng oras para magmukhang abala. Ngayon, isang prompt na lang.
-
Sasalungat ako nang konti. Sinasabi mo na gusto ito ng management, parang sila ang kontrabida. Sa karanasan ko, hindi nila gusto ang ingay, hindi nila lang nakikita ang pagkakaiba. Wala silang instrumento para malaman kung yung sampung PR ay tunay na trabaho o teatro. Ang totoong tanong, sino ang may kapangyarihang gumawa ng metric na hindi malolomo? Kasi sa ngayon ang reviewer mismo nagpo-prompt para mag-summarize, kaya wala nang taong talagang tumitingin.
-
Yung obserbasyon mo na umaangkop ang gawi sa engineering sa mga KPI na binibilang, yan ang nakikita ko araw-araw sa docs side. Pag pinangalanan mo kung ano ang binibilang, agad nagbabago ang ginagawa ng tao:
Pag commit count ang metric, dadami ang incremental commit.
Pag PR count, hahatiin ang isang coherent na pagbabago sa sampung fragment.
Pag "AI usage" ang sinusubaybayan, lalabas ang "AI helped me generate this" sa bawat note.
Walang nagsisinungaling. Tumutugon lang sila nang makatwiran sa sinusukat mo. Yung debugging at yung pagsabi ng hindi sa di-kailangang pagbabago, walang column yan sa dashboard.
-
Yung hatiin ang isang pagbabago sa sampung maliit na PR para malusog ang activity graph, grabe, yan ang code review version ng pagtaas ng standing desk minsan tapos kunan ng litrato. Galaw na pampogi, hindi pampagana.