Noul inginer 10x nu scrie de 10 ori mai mult cod. El construiește sistemul care îl scrie.

Inginerul 10x a fost un mit al Valley-ului Siliconic de decenii. Geniul singuratic, cu căști pe urechi, producând cod elegant la viteza superumană. Am dezbătut dacă există, am argumentat cum să îi angajăm și am resentimente față de oricine care pretinde a fi unul.

Dar ceva interesant s-a întâmplat pe drumul spre viitorul condus de IA: inginerul 10x a devenit real. El arată doar altfel decât am imaginat.

OpenAI a împărtășit recent cum o echipă de trei persoane a folosit Codex pentru a livra 1.500 de solicitări de extragere și aproximativ un milion de linii de cod, fără a scrie o singură linie manual. Trei ingineri și zero cod scris de mână. Un produs de producție utilizat de sute de utilizatori interni.

Acesta nu este 10x; este mai aproape de 100x. Și abilitatea care a făcut posibilă acest lucru nu a fost să scrieți mai repede sau să știți mai multe algoritmi. A fost construirea sistemului care face agenții productivi: fluxurile de lucru, gardurile de protecție, buclele de verificare, interfețele în care agenții se conectează și oamenii le verifică.

Cred că acesta este emergerea unei noi funcții cheie în organizațiile de inginerie. Aș numi-o Inginerie de Orchestare a IA.

Trei discipline intră într-un standup

Dacă priviți ce face un inginer de Orchestare a IA, veți recunoaște trei discipline familiare fuzionate în una.

Ingredientul cel mai evident este DevOps. DevOps a centralizat pipeline-ul de implementare. O echipă a configurat fluxurile de lucru CI/CD pe care fiecare inginer le-a utilizat atunci când a livrat cod. Ingineria de Orchestare a IA face același lucru, dar pentru fluxurile de lucru ale agenților. Definește cum sarcinile sunt atribuite agenților, cum ieșirile sunt validate, cum funcționează reîncercările și fallback-urile. Este infrastructura partajată pe care rulează agenții.

Apoi există arhitectura, care se suprapune cu DevOps mai mult decât ați crede. Arhitecții decid care interfețe sunt blocate, care modele sunt impuse, care limite nu pot fi depășite. Într-o lume condusă de agenți, acest lucru contează și mai mult. Agenții au nevoie de coduri bine documentate, cu contracte clare. Inginerul de Orchestare a IA definește aceste constrângeri, nu doar pentru citirea umană, ci și pentru înțelegerea agenților. Un depozit murdar nu este doar o datorie tehnică. Este un plafon de productivitate pentru fiecare agent care îl atinge.

Piesa cea mai puțin înțeleasă este stratul specific IA. Ingineria promptelor, gestionarea contextului, selectarea modelului, configurarea agentului. Astăzi, majoritatea inginerilor fac acest lucru într-un mod împrăștiat, de la o sarcină la alta. Fiecare persoană își găsește propriul stil de promptare, propriile setări de agent, propriile soluții. Inginerul de Orchestare a IA centralizează acest lucru. El construiește cărțile de joc partajate, configurațiile reutilizabile, cunoașterea organizațională despre ce funcționează și ce nu funcționează în diferite modele și cazuri de utilizare.

Separat, aceste trei funcții există în majoritatea organizațiilor de inginerie de astăzi. Argumentul este că combinarea lor într-un singur rol centralizat creează ceva calitativ diferit.

Metafora showrunner-ului

Un regizor de film nu operează camera, nu joacă în scene, nu editează imaginile. Dar fiecare cadru reflectă deciziile sale.

El alege compoziția cadrelor, ritmul, tonul. Decide când să se apropie și când să se îndepărteze. Setează mediul (iluminare, design de set, blocare) astfel încât fiecare persoană de pe platou să poată face cea mai bună muncă într-o viziune coerentă. Echipajul este individual talentat, dar fără acea coordonare, obțineți un haos care nu este niciodată livrat.

Ingineria de Orchestare a IA funcționează în același mod. Agenții sunt capabili. Modelele sunt puternice. Dar fără cineva care proiectează sistemul care îi coordonează, definește constrângerile, construiește buclele de feedback, structurează fluxurile de lucru, obțineți ceea ce am experimentat toți: ieșiri inconsistente, computație irosită, agenți care lucrează în direcții opuse, și ingineri care petrec mai mult timp reparând codul generat de IA decât ar fi petrecut scriindu-l singuri.

Regizorul face un film mai mare decât suma părților sale. Inginerul de Orchestare a IA face același lucru pentru flotele de agenți.

De ce majoritatea organizațiilor subinvestesc

Iată ce văd în industrie: companiile investesc masiv în instrumente de IA și nu suficient de mult în sistemele din jurul lor.

Inginerii au acces la Copilot, Claude, Codex. Ei experimentează individual. Unii devin utilizatori puternici. Majoritatea ajung la stadiul de “autocompletare fancy”. Câștigurile de productivitate de 20% pe care le raportează studiile? Acesta este simptomul adoptării la nivel de instrument fără gândire la nivel de sistem.

Organizațiile care depășesc, cele care raportează o productivitate de 2 ori sau mai mare, au ceva în comun. Ei au centralizat munca de orchestrare. Cineva (sau o echipă) deține fluxurile de lucru ale agenților, pregătirea depozitului, infrastructura de verificare, contextul partajat pe care fiecare agent îl poate accesa.

Ce arată de fapt rolul

O zi obișnuită a unui inginer de Orchestare a IA poate include:

• Proiectarea fluxurilor de lucru ale agenților: definirea modului în care o solicitare de funcționalitate devine o specificație, devine un plan, devine sarcini paralele ale agenților, devine cod revizuit și fuzionat.
• Construirea infrastructurii de verificare: teste automate, reguli de corectură, scanări de securitate și cadre de evaluare pe care agenții trebuie să le treacă înainte de a fi fuzionați.
• Menținerea sănătății depozitului pentru consumul agenților: documentație, interfețe clare, gestionarea dependențelor și simplificarea codului, toate optimizate pentru înțelegerea agenților, nu doar pentru citirea umană.
• Centralizarea strategiilor de prompt și context: sisteme de promptare partajate, conducte de recuperare, decizii de rutare a modelului și șabloane de configurare pe care întreaga echipă le utilizează.
• Monitorizarea și îmbunătățirea performanței agenților: urmărirea ratelor de succes, a modurilor de eșec, a costului pe sarcină și a timpului până la fuziune pe întreaga flotă de agenți, apoi reglarea sistemului pe baza datelor.

Această persoană se află la intersecția ingineriei platformei, arhitecturii software și expertizei IA. El nu scrie funcționalități. El construiește sistemul care face livrarea funcționalităților rapidă, fiabilă și escalabilă.

Modelul istoric

În zilele de început ale calculului în cloud, implementarea era o misiune secundară pentru fiecare inginer. Fiecare echipă avea propriile scripturi, propriile configurații de server, propriul mod de a pune codul în producție. DevOps a apărut pentru a centraliza această muncă, iar Ingineria Platformei a evoluat pentru a o construi în infrastructură partajată și auto-deservită.

IA urmează același arc. Acum, utilizarea agenților este o misiune secundară pentru fiecare inginer. Fiecare persoană are propriul stil de promptare, propriile preferințe de instrumente, propriul model mental pentru când IA ajută și când nu. Organizațiile care centralizează acest lucru, care îl tratează ca infrastructură și nu ca experimentare individuală, vor depăși în același mod în care organizațiile cu practici mature de DevOps au depășit pe cele fără.

Diferența este viteza. Tranzitarea DevOps a durat un deceniu. Aceasta ar putea dura doar câteva trimestre, deși voi admite că această predicție presupune că organizațiile recunosc modelul mai repede decât de obicei.

Drumul înainte

Dacă sunteți un lider de inginerie, iată ce v-aș sugera, deși experiența dvs. poate varia în funcție de cât de departe este echipa dvs. deja.

1. Identificați cine face deja această muncă în mod informal. Fiecare organizație are pe cineva care a descoperit fluxurile de lucru ale agenților, pe care alți ingineri îl solicită pentru sfaturi despre configurarea instrumentelor sau promptarea. Acea persoană este proto-inginerul dvs. de Orchestare a IA.
2. Faceți-o explicită. Dați funcției un nume, un mandat și resurse. Nu lăsați-o să rămână un proiect lateral atașat de “slujba reală” a cuiva.
3. Începeți cu pregătirea depozitului. Înainte de a investi în fluxuri de lucru ale agenților sofisticați, asigurați-vă că baza dvs. de cod este ceva pe care agenții îl pot naviga într-adevăr. Interfețe clare, documentație bună, teste cuprinzătoare, arhitectură simplificată.
4. Centralizați ceea ce funcționează. Când cineva descoperă o strategie de promptare sau un model de flux de lucru care îmbunătățește dramatic ieșirile agenților, capturați-l. Faceți-l implicit pentru întreaga echipă, nu cunoașterea tribală blocată în capul cuiva.
5. Măsurați la nivel de sistem. Nu urmăriți doar utilizarea individuală a instrumentelor. Urmăriți câte sarcini completează agenții de la capăt, ce arată ratele de revizuire și re lucru, unde sunt blocajele.

Noul 10x

Mitul inginerului 10x a fost întotdeauna despre fapte individuale. O persoană, depășindu-i pe toți prin talent și cafea.

Realitatea inginerului 10x în era IA este despre gândirea sistemică. Persoana care face ca fiecare alt inginer (și fiecare agent) să fie mai productiv prin construirea infrastructurii potrivite, a fluxurilor de lucru potrivite, a constrângerilor potrivite.

El nu scrie de 10 ori mai mult cod. El construiește sistemul care îl scrie.

Nu sunt sigur că acest rol se va cristaliza exact așa cum l-am descris aici. Dar sunt destul de sigur că organizațiile care vor descoperi stratul de orchestrare (oricum îl vor numi) vor fi cele care vor realiza într-adevăr câștigurile de productivitate pe care toată lumea le discută.