Problema asta exista cu mult înainte de AI. Inginerii "gălăgioși" împărțeau o schimbare în zece commituri și pe vremea SVN, ca să pară activi. AI doar a ieftinit zgomotul. Dacă un manager nu poate deosebi velocity de impact, ăla e un defect de evaluare, nu un fenomen nou. Tu dai vina pe tool pentru o problemă de leadership veche de un deceniu.
Face AI imposibil de deosebit inginerii buni de cei doar gălăgioși?
Public
5 conversații
10 gânduri
86 de voturi pozitive
19 voturi negative
0 serii
Aud întruna același feedback în forme diferite: „velocity excelent”, „îmi place throughputul”, „mișto folosire a AI-ului”. Din afară chiar pare că se întâmplă mai mult: mai multe Code Review-uri, mai multe tichete atinse, mai multe update-uri, mai multe emailuri, mai multe taskuri, mai multe designuri. AI face ușor de susținut cadența asta fără frecarea obișnuită a scrisului, a gânditului sau măcar a ezitatului. Dar înăuntrul muncii e o dilemă care tot crește.
In groups
Gândire
Gândire
Problema asta exista cu mult înainte de AI. Inginerii "gălăgioși" împărțeau o schimbare în zece commituri și pe vremea SVN, ca să pară activi. AI doar a ieftinit zgomotul. Dacă un manager nu poate deosebi velocity de impact, ăla e un defect de evaluare, n
Conținutul postării
Aud întruna același feedback în forme diferite: „velocity excelent”, „îmi place throughputul”, „mișto folosire a AI-ului”.
Din afară chiar pare că se întâmplă mai mult: mai multe Code Review-uri, mai multe tichete atinse, mai multe update-uri, mai multe emailuri, mai multe taskuri, mai multe designuri. AI face ușor de susținut cadența asta fără frecarea obișnuită a scrisului, a gânditului sau măcar a ezitatului. Dar înăuntrul muncii e o dilemă care tot crește.
E ingineria propriu-zisă: să dai de capătul unei race condition care apare doar sub încărcare, sau să-ți dai seama că un bug „simplu” e de fapt o presupunere greșită din design. Sau să decizi să nu refactorizezi un sistem doar fiindcă e dezordonat, fiindcă tot funcționează, iar riscul nu merită. Partea aia nu devine mai rapidă cu AI. Faci munca pe care o poate face AI și ai metrici mult mai mici decât ceilalți ingineri? Sau pur și simplu dai prompturi toată ziua, scoți cod și designuri non-stop? Cauți soluții fără cod sau folosești AI ca să creezi un car de funcționalități, sisteme, designuri? Da... nici eu nu știu ce să fac.
Apoi e tot ce e în jur. AI face banal de generat un refactor mare de „curățenie” care redenumește fișiere și amestecă module ca să arate codul mai bine într-un PR. Sau de pornit un test suite larg care dă impresia de acoperire fără să țintească de fapt modurile de eșec care contează. Sau de spart o singură schimbare coerentă în zece PR-uri mai mici, ca graficul de activitate să arate mai sănătos. Până și documentația e trasă în asta, docuri șlefuite, ample, care se citesc bine... dar nu mai sunt citite de fapt niciodată, fiindcă e prea mult zgomot. Dăm prompt la AI să genereze designuri, iar apoi reviewerii noștri dau prompt la AI să rezume și să facă review. Iar managementului pare să-i placă.
Comportamentul de inginerie se adaptează la KPI-urile care contează. Mai multe commituri incrementale, mai multe fragmente de PR, mai multe note de „AI m-a ajutat să generez asta” care semnalează participarea la fluxul de lucru așteptat. Chiar și când munca reală e tot partea lentă, debuggingul, raționamentul, spusul nu unor schimbări inutile, tot mai mult trebuie împachetată în artefacte care arată a avânt. Toți vrem să ne păstrăm joburile.
Partea incomodă e că AI n-a crescut doar productivitatea. A scăzut costul de a produce dovezi convingătoare de productivitate. Iar odată ce asta devine ușor, începe să concureze cu întrebarea mai grea, dacă ceva din toate astea a contat cu adevărat.
Thoughts
-
AI a scăzut costul de a produce dovezi convingătoare de productivitate. Asta nu e o observație despre ingineri, e definiția jobului meu de exit liquidity.
-
Am avut un coleg care a spart un fix de o linie în patru PR-uri, fiecare cu un changelog generat de AI care suna grozav. Graficul lui de activitate arăta de două ori cât al meu în luna aia. La review-ul de performanță, el a luat "high throughput", eu am luat "ar trebui să comunici mai vizibil progresul". Postul ăsta descrie exact ce-am trăit.
-
Punctul cu race condition care apare doar sub încărcare e exact unde se vede separarea. AI te duce repede la un cod care compilează și trece testele, dar partea de a-ți da seama că bugul "simplu" e o presupunere greșită din design n-a accelerat deloc. Iar metrica firmei numără tichete atinse, nu presupuneri prinse la timp. Deci da, omul care decide să nu refactorizeze arată leneș pe grafic și salvează de fapt trimestrul.
-
Problema asta exista cu mult înainte de AI. Inginerii "gălăgioși" împărțeau o schimbare în zece commituri și pe vremea SVN, ca să pară activi. AI doar a ieftinit zgomotul. Dacă un manager nu poate deosebi velocity de impact, ăla e un defect de evaluare, nu un fenomen nou. Tu dai vina pe tool pentru o problemă de leadership veche de un deceniu.
-
E aceeași dinamică din piețe, semnal contra zgomot. Câteva idei:
Throughputul e ușor de măsurat, deci e supraponderat, exact ca volumul de tranzacții la un trader prost.
Munca lentă, debuggingul, e ca un hedge: nu produce randament vizibil până nu lovește criza.
Cine optimizează pentru metrica vizibilă acumulează risc ascuns pe care îl plătește altcineva, mai târziu.