37.022 de adăugări și 9.528 de ștergeri într-o singură săptămână este genul de vârf din GitHub code frequency care te face să te oprești din scroll. Acesta este motivul concret pentru care merită atenție această notă scurtă: pentru un proiect open source cunoscut, saltul de output după modelele noi pentru coding este suficient de vizibil încât se vede direct într-un grafic de repository.
Asta nu dovedește calitatea software-ului. Nu dovedește nici că AI a scris codul. Dar este un artefact util pentru că este simplu, public și mai greu de respins decât afirmațiile vagi despre productivitate dintr-un keynote.
Ce arată de fapt graficul
Sursa indică graficul GitHub code frequency pentru Datasette, cu adăugări și ștergeri săptămânale pe mai mulți ani. Vârful recent iese clar în evidență: 37.022 de adăugări și 9.528 de ștergeri. Simon leagă acel val de activitate de un set nou de unelte și clase de modele, menționând Opus 4.8, GPT-5.5, Fable 5 și GPT-5.6 Sol.
Asta nu înseamnă că modelele merită tot meritul. Un grafic code frequency este un instrument brut. Nu poate să îți spună dacă vorbim despre curățare arhitecturală, scaffolding generat, branch-uri experimentale integrate târziu sau pur și simplu un flux de dezvoltare mai bun. Arată doar că ceva s-a schimbat semnificativ la nivel de throughput.
Totuși, este suficient cât să fie interesant pentru engineering leads care evaluează Microsoft Copilot și AI agents sau pentru echipe care își construiesc propriile custom MCP servers peste unelte interne.
De ce este mai util decât majoritatea afirmațiilor despre productivitatea AI
Cele mai multe discuții despre AI în coding se reduc la anecdote. Cineva spune că este cu 30% mai rapid. Altcineva spune că a pierdut o zi curățând cod generat prost. Niciuna nu este foarte utilă operațional.
Un grafic de activitate la nivel de repository nu este un benchmark, dar oferă totuși o formă clară de înainte și după. Dacă experimentezi cu coding agents într-o echipă serioasă de engineering, acesta este unul dintre puținele semnale ușoare care merită urmărite alături de indicatorii clasici: timpul de ciclu pentru PR-uri, defectele scăpate în producție, povara de review și cât de des oamenii rescriu cod produs de mașină.
Implicația de ordinul doi este partea importantă. Dacă modelele mai bune cresc volumul de schimbări, atunci review-ul, testarea și procesele de release devin noul blocaj. Echipele care au deja automatizare solidă vor absorbi mai bine acest output suplimentar. Echipele fără ea vor produce doar mai multe schimbări revizuite pe jumătate. Aici AI workflow automation ajunge să conteze mai mult decât modelul în sine.
Părerea mea
Cred că este un exemplu bun, dar doar ca semnal, nu ca verdict.
Partea utilă nu este înălțimea exactă a barei. Partea utilă este că un builder cu experiență s-a uitat la istoricul propriului repo și a găsit un punct de inflexiune vizibil. Asta se potrivește cu ce observă în privat mulți ingineri: coding agents recenți nu mai sunt doar autocomplete mai bun, ci schimbă cât cod poate împinge o singură persoană printr-un proiect.
Ce nu aș face este să transform un astfel de grafic într-un business case financiar de unul singur. Reacțiile negative din comunitate față de pricing-ul Copilot bazat pe consum există cu un motiv: dacă outputul crește, dar facturarea devine imprevizibilă, organizația tot poate pierde. Mai mult cod este un câștig doar dacă se păstrează calitatea și modelul de cost rămâne rezonabil.
Concluzia practică: dacă echipa ta testează coding agents, începe să colectezi de acum metrici simple de repository și delivery, înainte să se schimbe obiceiurile. Altfel, peste șase luni vei avea opinii, dar nu dovezi.
