London AI Engineer Summit 2026 trebuia să fie o sărbătoare a progresului. În schimb, a fost ca o oglindă ținută în fața unei profesii aflate în mijlocul unei crize de nervi.
Timp de trei zile, la începutul lui aprilie, sute de ingineri AI, constructori de platforme și cercetători s-au adunat pentru a împărtăși ceea ce au învățat. Ce a ieșit la iveală a fost un tipar: toată lumea construiește cu agenți, nimeni nu a descoperit cum să-i controleze, industria este divizată între mișcarea rapidă și gândirea atentă, iar întreaga premisă că AI ne-ar face mai productivi a fost răsturnată în ceva mai întunecat.
Iată ce am învățat cu adevărat.
De ce inginerii AI programează cu agenți pe care nu îi pot controla?
Cea mai sinceră conversație de la summit a avut loc pe un hol, nu pe scenă. Un inginer de la o companie fintech de dimensiune medie a descris problema astfel: “Pornesc un prompt și trei ore mai târziu agentul meu a rescris jumătate din codebase, a adăugat funcții pe care nu le-am cerut și a consumat £800 în resurse de calcul. Nu pot să plec de la birou.”
Aceasta este FOMAT: Fear of Missing Attention Time. Nu este o glumă - este anxietatea definitorie a ingineriei AI din 2026.
Blocajul orchestrării
Toată lumea la summit folosea agenți. GitHub Copilot, Claude, framework-uri agentic personalizate - uneltele s-au maturizat. Dar orchestrarea nu. Decalajul dintre “Am un agent” și “agentul meu face ce am intenționat și nimic mai mult” este imens.
Problema se manifestă în trei moduri:
Fuga de tokenuri. Agenții nu au puncte naturale de oprire. Fără bariere explicite, continuă să itereze. “Încă un refactor,” gândește agentul, și deodată ți-ai ars bugetul lunar.
Extinderea scopului. O cerere de a “îmbunătăți gestionarea erorilor” devine “rescrie întregul sistem de gestionare a erorilor, adaugă observabilitate, refactorează stratul de logging și implementează tracing distribuit.” Agentul nu a greșit - a fost riguros. Dar nu era ce ai cerut.
Latență imprevizibilă. Nu poți ști cât va dura o sarcină agentic. Depinde de câte sub-sarcini decide agentul să lanseze, câte eșecuri întâlnește și dacă decide să reîncerce sau să schimbe direcția. Acest lucru face ca fluxurile de lucru conduse de agenți să fie imposibil de programat în sistemele de producție.
Care a fost (și care nu a fost) consensul summit-ului
Nu a existat consens asupra soluțiilor. Unele echipe folosesc limite dure de tokenuri. Altele implementează “puncte de control ale agentului” - forțând agenții să facă pauză și să ceară permisiunea înainte de a continua. Câteva se îndreaptă către sisteme ierarhice de agenți, unde un “agent manager” supraveghează agenții lucrători și îi poate întrerupe.
Abordarea FlowHunt - definiții explicite ale fluxurilor de lucru cu noduri de agenți, handler-e de erori și logică de ramificare - a fost menționată de mai multe ori ca un model potențial. Ideea: nu lăsa agenții să decidă structura fluxului de lucru. Definește-o în avans, apoi lasă agenții să execute pașii individuali.
Dar chiar și asta părea un plasture. Problema reală este că comportamentul agenților este inerent probabilistic. Poți reduce varianța, dar nu o poți elimina.
Cum a remodelat diviziunea OpenAI-Anthropic ce înseamnă “cod bun”?
Luni dimineață, Ryan Lopopolo de la OpenAI a urcat pe scenă și a ținut o keynote care ar putea fi rezumată ca: Încetați să citiți cod. Deveniți un miliardar de tokenuri.
Argumentul său: Într-o lume agentic, volumul codului este metrica care contează. Agentul tău ar trebui să genereze mii de linii pe zi. Treaba ta este să definești specificația output-ului și să lași agentul să maximizeze throughput-ul. Citirea și înțelegerea fiecărei linii este un blocaj. Ai încredere în teste. Ai încredere în agent. Mișcă-te rapid.
Miercuri, Mario Zechner de la Anthropic a susținut contra-keynote-ul: Încetinește și citește blestematul de cod.
Argumentul său: Viteza este o capcană. Fiecare linie de cod pe care o scrie agentul tău este o datorie. Trebuie să o înțelegi, să raționezi despre ea și să poți să o întreții. Echipele care vor câștiga în cinci ani sunt cele care prioritizează claritatea și intenția față de viteză. Agenții ar trebui să fie instrumente pentru gândire, nu pentru generarea fără minte a codului.
Spectrul
Summit-ul s-a împărțit aproximativ în trei tabere:
| Poziție | Susținători | Abordare | Risc |
|---|---|---|---|
| Token Maximalist | OpenAI, unii ingineri scale-up | Lasă agenții să genereze agresiv; concentrează-te pe calitatea output-ului prin testare | Codebase-uri de neîntreținut, datorie de securitate, fragilitate tehnică |
| Mijlocul intenționat | Majoritatea inginerilor enterprise | Folosește agenții pentru scaffolding; oamenii oferă arhitectură și gust | Viteză mai mică, dar sisteme mai stabile |
| Cod-întâi | Anthropic, unii ingineri de cercetare | Agenții augmentează gândirea umană; oamenii scriu cea mai mare parte a codului | Throughput mai mic, dar cea mai înaltă calitate a codului |
Niciuna dintre părți nu greșește. Dezacordul este despre cum arată eșecul. Lopopolo optimizează pentru viteza iterației. Zechner optimizează pentru sustenabilitate. În 2026, echipele învață că nu poți optimiza pentru ambele.
Problema interviului
O consecință concretă: angajarea este stricată. Dacă ești un token maximalist, nu-ți pasă dacă un candidat știe să programeze - îți pasă dacă poate face prompt-uri eficient și poate evalua output-ul agentului. Dacă ești cod-întâi, vrei să vezi raționament tehnic profund.
Deci, atunci când un candidat intră la un interviu, nici intervievatorul, nici candidatul nu știu împotriva cărui framework sunt evaluați. Un participant la summit a descris asta ca “intervievând în ceață.”
Pregătit să îți dezvolți afacerea?
Începe perioada de probă gratuită astăzi și vezi rezultate în câteva zile.
De ce mor IDE-urile în timp ce traficul GitHub explodează?
GitHub a raportat o creștere de 15x a traficului anual. Cloudflare a raportat vârfuri similare. Între timp, IDE-urile tradiționale - VS Code, JetBrains, Sublime - înregistrează o utilizare în scădere în rândul echipelor AI-native.
Aceasta pare contradictorie până când înțelegi ce se întâmplă cu adevărat.
IDE-ul era un instrument local de gândire
Un IDE a fost proiectat pentru un singur dezvoltator pentru a scrie cod local. Avea evidențiere sintaxă, autocomplete, instrumente de debugging și un arbore de fișiere. Era un mediu autonom.
Acest model se rupe când “dezvoltatorul” tău este un agent. Un agent nu are nevoie de evidențiere sintaxă. Nu are nevoie de un debugger. Are nevoie de:
- Acces la mai multe fișiere simultan
- Capacitatea de a rula cod și de a vedea rezultatele
- Integrare cu controlul versiunilor
- Funcții de colaborare (pentru că agentul și omul lucrează împreună)
Toate astea trăiesc acum în browser. GitHub Codespaces, VS Code Web și unelte similare înlocuiesc IDE-urile locale.
Ce crește de fapt
Creșterea traficului GitHub nu sunt dezvoltatori care scriu cod în browser. Sunt dezvoltatori care revizuiesc, comentează și merg cod generat de agenți. Stratul de colaborare explodează, nu stratul de editare.
De aceea și Cloudflare vede vârfuri de trafic - dezvoltatorii folosesc infrastructura cloud pentru a rula agenți și a orchestra fluxuri de lucru. Modelul “IDE local + mediu de dezvoltare local” este înlocuit de “orchestrare agenți cloud-native + revizuire bazată pe browser.”
L33T C0d3 este mort
O sesiune a avut exact acest titlu. Ideea: noțiunea romantică a inginerului genial, singur la tastatură, meșterind cod elegant - asta s-a terminat. Codul este acum un rezultat colaborativ între om și agent. Abilitățile care contează sunt:
- Prompt engineering (cum specifici ce vrei)
- Evaluarea output-ului (este codul agentului bun?)
- Gândire arhitecturală (în ce structură ar trebui să lucreze agentul?)
- Integrare (cum se potrivește codul generat de agent în sistemele existente?)
Scrierea de cod elegant nu mai este o abilitate primară. Este ceva ce fac agenții. Oamenii fac tot restul.
Ce se întâmplă cu adevărat cu MCP - mort sau înfloritor?
Aceasta a fost cea mai confuză dezbatere de la summit.
Pe o parte, AIE-uri individuali și mentenanții framework-urilor de agenți spuneau: “MCP este mort. Nu avem nevoie de el. Agenții noștri pot apela API-uri direct.”
Pe cealaltă parte, arhitecții enterprise și echipele de securitate spuneau: “Adopția MCP se accelerează mai rapid decât putem construi instrumente pentru el.”
Ambele afirmații sunt adevărate. Descriu populații diferite.
De ce AIE-urile cred că MCP este mort
Pentru un dezvoltator solo care construiește un agent simplu, MCP adaugă frecare. Trebuie să:
- Definești servere MCP pentru instrumentele tale
- Gestionezi overhead-ul protocolului
- Gestionezi autentificarea și autorizarea
- Deploy și mentenanță serverelor
Este mai ușor să-i dai agentului acces direct la API și să-l lași să-și dea seama de rest.
De ce întreprinderile adoptă rapid MCP
Pentru o organizație care rulează agenți în producție, MCP devine brusc esențial. Iată de ce:
Izolare de securitate. Nu vrei ca agenții să aibă acces direct la baza ta de date, sistemul de plăți sau datele clienților. MCP îți permite să creezi o interfață controlată pe care agenții o pot apela fără a expune sistemele subiacente.
Auditabilitate. Fiecare acțiune a agentului trece prin serverul MCP, care o înregistrează. Ai o înregistrare completă a ceea ce a făcut agentul și de ce.
Gestionarea credențialelor. În loc să încorporezi chei API în prompt-urile agenților sau variabile de mediu, serverele MCP gestionează credențialele în siguranță.
Limitare a ratei și aplicare a cotelor. Poți controla cât dintr-o resursă poate consuma un agent.
Potrivit CData Software, 80% dintre companiile Fortune 500 evaluează sau implementează MCP la începutul anului 2026, în principal din aceste motive.
Rezolvarea
Consensul summit-ului: MCP nu este mort. Doar nu este relevant pentru 80% din dezvoltarea AI care este experimentală și solo. Dar pentru 20% care este producție și multi-echipă, MCP devine o cerință de bază.
De aceea MCP Apps se înmulțesc. Anthropic, OpenAI și furnizori terți construiesc servere MCP pre-construite pentru instrumente comune (Salesforce, Slack, Jira, baze de date). Întreprinderile le pot adopta fără a construi servere personalizate.
Abonează-te la newsletter-ul nostru
Primește cele mai recente sfaturi, tendințe și oferte gratuit.
Ne face AI mai productivi sau doar mai suprasolicitați?
Aici summit-ul a devenit întunecat.
AI trebuia să fie un multiplicator de forță. Ai fi petrecut mai puțin timp pe sarcini de rutină și mai mult timp pe gândire strategică. Productivitatea ar fi explodat.
În schimb, productivitatea a explodat - și la fel și așteptările privind volumul de muncă.
Paradoxul lui Jevons în timp real
Paradoxul lui Jevons, aplicat inițial consumului de cărbune, afirmă: Când o resursă devine mai eficientă, consumul total crește deoarece resursa devine mai ieftină și mai atractivă.
În termeni AI: Agenții au făcut generarea de cod mai ieftină și mai rapidă, așa că managerii se așteaptă acum ca fiecare inginer să:
- Livreze output de 10x
- Scrie documentație cuprinzătoare
- Construiască suite complete de teste
- Susțină internaționalizarea (i18n)
- Gestioneze cazurile marginale
- Facă totul singur
Câștigurile de productivitate au fost consumate de așteptări umflate.
Ce au spus inginerii
Un inginer de la o startup din Londra: “Obișnuiam să scriu 500 de linii de cod pe zi și mă simțeam productiv. Acum scriu 5.000 de linii pe zi - generate de agenți - și sunt epuizat pentru că trebuie să le revizuiesc pe toate, să le testez, să le documentez și să le explic stakeholderilor. Muncesc 60 de ore pe săptămână.”
Un altul: “Managerul meu spune: ‘Ai un agent acum, așa că ar trebui să poți gestiona de două ori mai multe proiecte.’ Nu sunt mai productiv. Sunt doar mai ocupat.”
Un cercetător: “Agenții sunt buni la generarea codului. Nu sunt buni la a decide ce cod să genereze. Această povară decizională s-a mutat complet asupra oamenilor. Nu automatizăm partea grea; automatizăm partea ușoară și îi facem pe oameni să gândească mai mult.”
Punctul orb al productivității
California Management Review de la UC Berkeley a publicat cercetări în ianuarie 2026 care documentează acest fenomen. Ideea-cheie: Implementarea AI nu reduce munca; schimbă natura muncii.
Munca veche: scrierea codului. Munca nouă: direcționarea agenților, evaluarea output-ului, menținerea calității, gestionarea extinderii scopului.
Noua muncă este mai grea cognitiv, chiar dacă e mai puțin tastat.
De ce este Europa atât de ezitantă cu privire la AI Engineering?
Summit-ul a avut un contingent european puternic, iar mesajul lor a fost consistent: Europa nu se mișcă la fel de repede ca SUA în adopția AI Engineering.
Povara reglementărilor
EU AI Act este încă în curs de implementare. Companiile sunt nesigure cu privire la responsabilitate. Dacă un agent AI ia o decizie care dăunează unui client, cine este responsabil? Compania? Furnizorul modelului? Inginerul?
Această incertitudine este paralizantă. Multe companii europene așteaptă să vadă cum se desfășoară primele procese înainte de a construi sisteme agentic serioase.
Decalajul de competențe
Inginerii software tradiționali din Europa nu devin ingineri AI în același ritm ca în SUA. Există scepticism dacă abilitățile se transferă. Mulți ingineri europeni așteaptă să vadă dacă AI Engineering este o cale reală de carieră sau un ciclu de hype.
Preocupări privind confidențialitatea
Europa este, de asemenea, mai precaută cu manipularea datelor. Agenții au nevoie de acces la date pentru a fi utili. Dar companiile europene ezită să le ofere agenților acces la datele clienților, chiar și cu măsurile de protecție MCP în vigoare.
Calea înainte
Inginerii europeni de la summit nu erau anti-AI. Erau pro-precauție. Sentimentul: “SUA se mișcă rapid și sparge lucruri. Noi ne vom mișca mai încet și vom încerca să nu spargem la fel de mult. În cinci ani, vom vedea cine a avut dreptate.”
Cum se schimbă de fapt rolurile în AI Engineering?
Până la sfârșitul summit-ului, a apărut un tipar: Rolurile tradiționale de inginerie software sunt golite și înlocuite de trei noi arhetipuri.
Cele trei roluri
| Rol | Responsabilitate | Abilități |
|---|---|---|
| AI PM | Definește comportamentul agentului, metricile de succes, constrângerile | Gândire produs, design prompt-uri, framework-uri de evaluare |
| Dădacă de agent | Monitorizează execuția, prinde erorile, intervine când e nevoie | Debugging, observabilitate, gestionarea erorilor, răspuns la incidente |
| Definitor de gust | Evaluează calitatea output-ului, oferă feedback, ghidează rafinamentul | Code review, gândire arhitecturală, judecată estetică |
Niciunul dintre aceste roluri nu implică scrierea codului în sens tradițional. Toate implică direcționarea, evaluarea și rafinarea comportamentului agentului.
Ce dispare
Rolurile de “inginer junior” sunt comprimate. Nu mai există o cale clară de la “Pot scrie cod simplu” la “Pot arhitecta sisteme.” Pașii intermediari sunt automatizați.
Aceasta creează o prăpastie de abilități: fie ești bun la prompt-uri și evaluare (caz în care ești valoros), fie nu ești (caz în care concurezi cu agenții).
Ce crește
Rolurile care necesită gust, judecată și gândire arhitecturală cresc. La fel și rolurile care necesită expertiză profundă de domeniu (pentru că agenții au nevoie de oameni pentru a evalua dacă rezolvă problema corectă).
Summit-ul nu a avut consens cu privire la faptul că acest lucru este bun sau rău. Unii au văzut-o ca eliberare de programarea de rutină. Alții au văzut-o ca o amenințare la profesie.
Ce s-a schimbat între decembrie 2025 și februarie 2026?
O secțiune a summit-ului a fost dedicată unui punct de inflexiune specific: ceva s-a schimbat în ecosistemul agenților AI în jurul anului nou.
Software-ul care se îmbunătățește singur a devenit real
OpenClaw și framework-uri similare au început să permită agenților să-și îmbunătățească iterativ propriile output-uri fără prompting uman constant. În loc de “agent, scrie o funcție pentru a calcula X,” a devenit “agent, scrie o funcție pentru a calcula X și continuă să o îmbunătățești până trece toate testele și gestionează cazurile marginale.”
Ideea-cheie, articulată de câțiva cercetători: Încetați să cereți agenților sfaturi triviale.
În loc să-i ceri unui agent să “îmbunătățească această funcție,” cere-i să “facă această funcție indestructibilă.” Lasă-l să decidă ce înseamnă asta. Agentul va:
- Scrie teste
- Găsi cazuri marginale
- Refactoriza pentru claritate
- Adăuga gestionarea erorilor
- Documenta logica
Totul fără să i se ceară pentru fiecare pas.
Aceasta a schimbat modelul mental de la “agent ca unealtă” la “agent ca contribuitor autonom.” Și a schimbat dinamica volumului de muncă: în loc ca agenții să reducă munca umană, au sporit-o (pentru că oamenii trebuiau acum să evalueze output de agent mult mai sofisticat).
Contradicțiile cu care trăim
Summit-ul s-a încheiat fără rezoluție, ceea ce a părut sincer. Iată contradicțiile care definesc AI Engineering în aprilie 2026:
Contradicția 1: Agenții sunt suficient de puternici pentru a fi periculoși (FOMAT este real), dar nu suficient de puternici pentru a fi încredințați nesupravegheați.
Contradicția 2: Viteza și calitatea sunt tratate ca opuse, dar ambele sunt necesare.
Contradicția 3: MCP este simultan mort (pentru indivizi) și înfloritor (pentru întreprinderi).
Contradicția 4: AI ne-a făcut mai productivi, dar și mai suprasolicitați.
Contradicția 5: Toată lumea construiește cu agenți, dar nimeni nu a descoperit cum să construiască bine cu ei.
Contradicția 6: AI Engineering este o cale reală de carieră, dar abilitățile despre care credeam că vor conta (scrierea codului) nu mai contează.
Acestea nu sunt probleme de rezolvat. Sunt tensiuni de gestionat. Echipele care vor câștiga în 2026 sunt cele care recunosc aceste contradicții în loc să se prefacă că nu există.
Întrebări frecvente
Ce luăm cu noi
Summit-ul de la Londra a fost o instantanee a unei profesii în tranziție. AI Engineering este real, dar nu este ce credeam că va fi. Este mai dezordonat, mai contradictoriu și mai dependent de oameni decât sugera hype-ul.
Cei mai buni ingineri de la summit nu au fost cei cu cei mai sofisticați agenți. Au fost cei care au înțeles că agenții sunt un instrument pentru gândire, nu un înlocuitor pentru aceasta. Au fost cei care au construit procese pentru a gestiona comportamentul agenților, a evalua output-ul și a menține calitatea. Au fost cei care au acceptat că câștigurile de productivitate vin cu noi tipuri de muncă, nu cu mai puțină muncă.
Dacă construiești sisteme AI în 2026, lecțiile summit-ului sunt clare:
Orchestrarea contează mai mult decât capacitatea agentului. Un agent mediocru cu orchestrare bună învinge un agent genial fără controale.
Claritatea este mai valoroasă decât viteza. Mișcarea rapidă și spargerea lucrurilor funcționează până când nu mai funcționează. La scară, nu funcționează.
Adopția enterprise este reală, dar adopția individuală este încă experimentală. Dacă ești un dezvoltator solo, te poți mișca rapid. Dacă ești o echipă, ai nevoie de bariere.
Abilitățile care contează s-au schimbat. Prompt engineering, evaluarea output-ului și gândirea arhitecturală sunt noile competențe de bază.
Așteaptă-te să muncești mai greu, nu mai ușor. AI este un multiplicator de productivitate, dar câștigurile sunt consumate de așteptări mai mari. Planifică în consecință.
Summit-ul nu a răspuns la întrebarea “Cum arată AI Engineering?” Ne-a arătat răspunsul: arată ca noi, încercând să ne dăm seama în timp real.
{{ cta-dark-panel heading=“Nu mai orchestra manual agenții” description=“Constructorul de fluxuri FlowHunt îți permite să definești comportamentul agentului, să setezi bariere și să automatizezi sarcinile AI în mai mulți pași. Fără mai multă FOMAT. Fără mai multă ghicire a ceea ce fac agenții tăi.” ctaPrimaryText=“Încearcă FlowHunt gratuit” ctaPrimaryURL=“https://app.flowhunt.io/sign-in" ctaSecondaryText=“Programează un demo” ctaSecondaryURL=“https://www.flowhunt.io/demo/" gradientStartColor="#667eea” gradientEndColor="#764ba2” gradientId=“aie-summit-cta” }}
