Dacă IA ar fi existat de la început: Cod mai ieftin nu a făcut decizia cu privire la ceea ce să se construiască mai ușoară

Pentru cea mai mare parte a istoriei software-ului, partea scumpă a fost construirea lui. Echipele au petrecut luni transformând idei în cod funcțional, și acea raritate a modelat totul despre cum se organizează munca.

Drumurile au fost secvențiate în jurul capacității de inginerie disponibile; arhitecții și-au câștigat locul la masă pentru că au înțeles sisteme pe care nimeni altcineva nu le înțelegea; managerii de produs și-au petrecut săptămânile traducând cereri vagi de afaceri în ceva pe care un dezvoltator putea să acționeze. Scrierea software-ului a fost stenoza, și în mod natural, scrierea lui a fost unde a trăit avantajul.

Acest lucru nu mai este adevărat, și schimbarea s-a întâmplat mai repede decât majoritatea liderilor de inginerie au avut timp să o digere.

Uneltele de codare AI au colapsat costul implementării. Așa că, munca care a durat o echipă de ingineri săptămâni acum durează un agent câteva ore. Și presupunerea evidentă a fost că o construire mai rapidă se va traduce direct în valoare livrată mai rapid.

Ce s-a întâmplat, cu toate acestea, este mai complicat: echipele pot produce acum mai mult software decât știu ce să facă cu el, și lucrul care le încetinește a mutat în mod tacit undeva altundeva.

“Nu poți aplica IA la un proces defect”, a spus Pablo Gamba, șeful tehnologiei din America la startup-ul global de software și soluții IA intive. “Este ca și cum ai da o sapă mai rapidă unui muncitor. El va lucra mai repede, dar numai în direcția greșită.”

Execuție mai rapidă, aceeași veche constrângere

Fiecare inflexiune majoră în tehnologie – internetul, cloud-ul și offshoring-ul – a urmat o formă identică. Ceva care era scump a devenit ieftin aproape peste noapte, și tot ceea ce o firmă construisise pe baza acelei cheltuieli a trebuit să fie dărâmat și reconstruit.

Această dată, lucrul care devine ieftin este inteligența tehnică aplicată în sine, care se întâmplă să fie exact ceea ce firmele de servicii și echipele de inginerie au petrecut decenii încărcând pentru, susține Gamba afirmă.

Execuția mai ieftină nu face constrângerea să dispară, cu toate acestea. Ea se mută undeva mai puțin vizibil. Stenoza de codare, de exemplu, în migrarea upstream, a accelerat implementarea, dar obstacolul este acum în revizuirea codului. Automatizați revizuirea codului și se arată în testare și implementare; automatizați și acestea, și în cele din urmă se aternează pe oamenii care scriu specificațiile de la care agenții lucrează.

Deoarece un agent poate construi doar ceea ce a fost descris suficient de precis pentru a acționa fără a ghici.

Acesta este capcana în care multe echipe merg acum, adesea fără să observe. Dacă poți construi aproape orice într-o fracțiune din timpul în care se făcea anterior, costul construirii lucrului greșit crește, nu scade, pentru că vei afla mai repede și cu mai multe already expediate.

O presupunere care a apărut anterior lent, în timpul codării manuale, poate deveni acum infrastructură de încărcare înainte ca cineva să se gândească să o pună la îndoială. Prioritizarea, și nu producția brută, se dovedește a decide dacă investiția în IA se plătește cu adevărat.

În acest paradigme, Gamba crede că companiile ar trebui să urmărească nu viteza de dezvoltare, ci ciclul complet de la intenție la producție. “Dacă îmbunătățiți viteza de dezvoltare, dar QA este stenoza dvs., ați ajuns doar mai repede la QA. Apoi remediați QA și stenoza se mută la cerințe”, a spus el.

Numerele îl susțin, de asemenea. Întreprinderile Fortune 50 care utilizează dezvoltarea asistată de IA expediază commit-uri de 3-4 ori mai repede decât omologii lor, conform cercetărilor Cloud Security Alliance, dar introducând noi constatări de securitate la aproximativ zece ori rata.

Viteza fără o destinație clară, în acest sens, nu doar irosește efort; ea compune riscul mai repede decât majoritatea echipelor de securitate pot ține pasul.

Obținerea cerințelor într-un limbaj pe care IA îl poate valorifica cu adevărat

Dacă definiția este unde se află cu adevărat constrângerea, soluția nu este mai multă documentație. Este o documentație diferită, scrisă într-o formă pe care un sistem IA o poate executa fără a umple golurile de unul singur.

Acest lucru înseamnă retragerea documentului de cerințe scris pentru un om pentru a-l interpreta cu judecată și înlocuirea lui cu criterii de acceptare structurate, modele de domeniu explicite și teste de contract care spun ce ar trebui să facă o funcție și ce nu ar trebui să facă.

Agenții, după cum se știe, umplu ambiguitatea în același mod în care un inginer junior ar face, cu o presupunere încrezătoare. Diferența este că presupunerea celui din urmă vine însoțită de o anumită ezitare, un semn pentru un coleg senior, un sentiment că ceva ar putea fi în neregulă.

Presupunerea unui agent arată altfel. Ea apare sub forma unui cod curat, fluent și complet format, și nu există nicio ezitare în ea, chiar și atunci când este greșită.

Scrierea unei specificații suficient de precise pentru a supraviețui acestei lacune începe să se simtă mai mult ca scrierea unui contract decât a unui brief de produs. Numești fiecare actor, hărțuiești fiecare tranziție de stare pe care sistemul o poate face și iei în considerare cazurile limită în loc să le lași în mod tacit pe calea fericită, așa cum fac majoritatea documentelor de cerințe.

Echipele care tratează acest lucru ca pe o corvoadă de documentare învață în mod dur că intenția vagă produce software vag la viteza mașinii.

Echipele care capturează cu adevărat câștigurile de productivitate sunt cele care tratează scrierea de specificații ca pe o disciplină de inginerie în sine, cu același control al versiunii, cicluri de revizuire și rigurozitate a testării care au fost rezervate anterior pentru codul însuși.

În cuvintele lui Gamba, nativul IA nu este permisiunea de a sări peste proces, ci o cerință de a redesena de la zero. “Multe organizații încearcă să aplice IA la procese vechi. Acesta nu este transformarea. Organizațiile native IA încep cu o întrebare diferită: dacă IA ar fi existat de la început, cum am fi proiectat acest proces astăzi?”

Managerii de backlog, curatorii intenției

Produsul, arhitectura și ingineria au funcționat anterior ca trei funcții separate cu predări curate între ele: produsul decide ce să se construiască, arhitectura decide cum, ingineria livrează.

Odată ce implementarea devine ieftină și rapidă, aceste predări se transformă în partea cea mai lentă a lanțului. Ceea ce contează aici este cineva care poate ține imaginea de ansamblu, traduce intenția în ceva pe care un agent îl poate executa și prinde o presupunere greșită înainte de a deveni cod expediat pe care nimeni nu l-a dorit.

Această redesenare modelează în mod tacit cine face definirea și ce este munca în sine.

“Gândiți-vă la ceea ce se întâmplă cu rolul inginerului de software. Ei nu mai scriu doar cod. Ei supraveghează output-ul agenților, definesc specificații, pregătesc teste, validează rezultate. Acesta este un mod de a combina cele trei roluri separate într-unul”, a spus Gamba.

În alte cuvinte, ceea ce este valoros acum nu este știința cum să scrii un bilet sau să rulezi un sprint. Este știința ce înseamnă “minunat” înainte de a începe munca, a fi capabil să faci diferența între ceea ce este intelectual interesant și ceea ce au nevoie cu adevărat clienții și a avea curajul de a ucide o idee rapid atunci când este evident că nu trece testul.

Acestea sunt apeluri de judecată care au fost distribuite anterior pe un manager de produs, un arhitect și un lider tehnologic care compară note. Din ce în ce mai mult, ele ajung pe cineva care este cel mai aproape de a defini munca din primul rând.

Și merită, de asemenea, să ne amintim: niciunul dintre acestea nu face ca titlurile să dispară. Dar liniile dintre ele devin din ce în ce mai greu de apărat, în timp ce oamenii care prosperă în acea ceață sunt cei care acționează ca curatorii intenției.

Execuție rapidă fără garduri nu este o victorie

Există un risc care este ușor de pierdut din vedere odată ce intenția este clară și pipeline-ul IA funcționează cu adevărat: execuția rapidă și bine definită poate introduce încă eșecuri pe care un proces mai lent, mai mediat de om, le-ar fi prins aproape din întâmplare.

Numerele de aici nu sunt nici măcar aproape. Testarea de primăvară 2026 a lui Veracode across modelele de top a găsit că doar 55% din sarcinile de generare de cod au produs output securizat atunci când nu s-a furnizat nicio îndrumare de securitate explicită, o cifră care abia s-a schimbat în doi ani, chiar și pe măsură ce acuratețea funcțională a sărit considerabil.

Este clar că obținerea sintaxei corecte a încetat să mai fie partea grea de mult timp. Apelurile de judecată pe care un inginer uman le făcea instinctiv în timp ce scria, în jurul securității, conformității și a ceea ce ar trebui și nu ar trebui să atingă sistemul, sunt părțile care sunt greu de înlocuit.

Acest lucru înseamnă că aceeași rigurozitate aplicată definirii a ceea ce să se construiască trebuie să se extindă și la definirea a ceea ce este interzis, cum ar fi limitele de conformitate, regulile de manipulare a datelor și constrângerile etice formulate cu aceeași grijă ca și cerințele funcționale.

Lăsarea lor implicite și speranța că un agent le va infera corect este aceeași greșeală ca și lăsarea cerințelor de produs vagi și traversarea degetelor pentru ca construcția să iasă cumva bine.

Ce înseamnă conducerea

Nimic din toate acestea nu argumentează împotriva dezvoltării accelerate de IA; construirea nu a fost niciodată mai rapidă sau mai ieftină, și nu există modalitate de a pune asta înapoi în sticlă.

Dar ceea ce nu a devenit mai ușor, și probabil a devenit mai greu, este decizia cu adevărat precisă a ceea ce merită să se construiască, descrierea lui suficient de bine pentru ca o mașină să execute cu fidelitate și trasarea liniilor pe care nu are voie să le traverseze în timp ce o face.

La nivelul întreprinderii, echipele care se desprind nu sunt cele cu agenții de codare cei mai rapizi, acea parte este clară. Sunt cele care au lucrat mai devreme decât competitorii lor că definiția a fost întotdeauna problema mai grea – și au început să o trateze astfel.