# Miks muudab AI su tarkvaratarne aeglasemaks?

> Sest AI kiirendab lokaalset tööd ehk koodi, spekkide ja ülesannete tootmist, samal ajal kui tarnet tegelikult piirav töö, see tähendab kokkulepe selle üle, mis on tõsi, käib endiselt inimkiirusel. Lahendus on ühildamine masinkiirusel, mitte targem mudel.

_Vaated · 2026-07-09_

**AI ei aeglusta su tarnet sellepärast, et mudelid on kehvad. See aeglustab tarnet sellepärast, et kiirendab lokaalset tööd ehk koodi, spekkide ja ülesannete tootmist, samal ajal kui tarnet tegelikult piirav töö, see tähendab kokkulepe selle üle, mis on inimeste ja tööriistade vahel tõsi, käib endiselt inimkiirusel või jääb üldse tegemata.** Mõju on mõõdetav. [METR-i (2025)](https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/) randomiseeritud kontrollitud uuringus kulus kogenud arendajatel AI-ga päris ülesannete lõpetamiseks 19% rohkem aega, uskudes samal ajal, et nad olid umbes 20% kiiremad. Nägin seda seestpoolt, ühe ettevõtte AI-algatuses.

## Kuidas kolmepäevane AI-refaktoreerimine tõi produktsioonis kaasa kaks nädalat koristamist

Iga AI-katastroofi samm tundub võiduna, kuni see kestab. 2026. aasta alguses saatis ühe ettevõtte, millega koos töötan, CEO sõnumi, mis kõlab tuttavalt: peame AI abil tarkvaraarendust kiirendama. Jaanuari lõpuks oli ta seda igale tehnilisele juhile korranud ja mõne nädalaga tekkisid isoleeritud algatused. Iga algatus oli lokaalne ja nägi omaette mõistlik välja.

Esimene oli Next.js-i suur versiooniuuendus. Frontend-tiim suunas ülesandele AI-koodiagendi ja lasi sel joosta peaaegu kolm päeva. Koodibaasis polnud ühikteste. Build läks läbi, käsitsi tehtud testid kontrollitud keskkonnas läksid läbi ja tiim hindas, et agent säästis vähemalt kaks nädalat tööd.

Siis jõudis see produktsiooni. Agent oli töö käigus vaikselt integratsioonid ümber kirjutanud ja välja mõelnud endpoint'e, mida polnud kunagi olemas olnud. Funktsionaalsused lakkasid märkamatult töötamast. Stabiliseerimine võttis kaks nädalat, mille jooksul seiskus ka teiste suundade plaanitud töö. Osa funktsionaalsusi oli kaks-kolm kuud katki ja see avastati alles siis, kui üksainus kasutaja nendeni lõpuks jõudis.

Endpoint'ide väljamõtlemine ei ole haruldane juhus. [USENIX Security 2025 uuring](https://arxiv.org/abs/2406.10279) genereeris 16 mudeliga 576 000 koodinäidist ja leidis, et vähemalt 5,2% kommertsmudelite ja 21,7% avatud lähtekoodiga mudelite paketiviidetest osutas pakettidele, mida ei eksisteeri. Enesekindel viitamine asjadele, mida pole olemas, on dokumenteeritud ja mõõdetud mudelikäitumine.

## Vanad põhitõed, rikutud masinkiirusel

AI-koodiagendid ei leiutanud uut läbikukkumisviisi; need muutsid odavaks aastakümnete vanuse vea: testideta koodibaasi big-bang-ümberkirjutuse. Martin Fowler pani reeglid kirja teoses [Refactoring](https://martinfowler.com/books/refactoring.html), mis ilmus esmakordselt 1999. aastal: refaktoreeritakse väikeste sammudega, mis jätavad koodi alati töökorda, ja seda tehakse [end ise testiva koodi](https://martinfowler.com/bliki/SelfTestingCode.html) peal. Kolmepäevane ümberkirjutus ilma testideta rikub mõlemat reeglit korraga. Agent lihtsalt muutis rikkumise odavaks.

See on kogu tööstuse muster, mitte ühe tiimi viga. [GitClear](https://www.gitclear.com/ai_assistant_code_quality_2025_research) analüüsis 211 miljonit muudetud koodirida aastatest 2020 kuni 2024 ja leidis, et olemasolevat koodi refaktoreerivate või liigutavate muudatuste osakaal kukkus 25%-lt 2021. aastal alla 10% 2024. aastal, samal ajal kui kopeeritud ridade osakaal kasvas 8,3%-lt 12,3%-le kõigist muudatustest. AI toodab tänases kasutuses rohkem koodi, mitte rohkem taaskasutust.

## Siis sai iga roll omaenda AI ja sõnad lakkasid klappimast

Kui ettevõttes saab iga roll omaenda AI, tulevad vastuolud tööriistade summast, mitte ühestki üksikust. Pärast refaktoreerimist jätkus algatus: disainer hakkas AI-ga genereerima kujundusi ja disainispekke, PM kirjutas AI-ga ülesandeid Asanasse, tooteinimesed kirjutasid AI-ga spekke Notionisse, arendajad kirjutasid AI-ga koodi. Iga suund tootis muljetavaldava koguse artefakte. Ja tootis ka kõige lihtsama võimaliku vastuolu: tootemääratlustes kasutatud nimed lakkasid klappimast koodis kasutatud nimedega.

Eric Evans andis kaotatule nime. Domain-Driven Design (2003) nimetab seda [ühtseks keeleks (ubiquitous language)](https://martinfowler.com/bliki/UbiquitousLanguage.html): üks range sõnavara, mida jagavad toote määratlejad ja kood, mis selle teostab. See keel oli tiimi mitteametlik konsensusprotokoll, mis püsis iseenesest töös, kuni inimesed kirjutasid kõike käsitsi ja lugesid üksteise tööd. AI-tootmine kustutas selle ühe kvartaliga.

Bugid, mida see tekitab, on vaiksed. Ülesanne „töötab“, aga väikeste erinevustega spekist, nii et esimesel päeval ei plahvata miski. Ja kuna tervikut ei mõistnud enam ükski inimene, tuli iga viga välja alles siis, kui keegi ehitas eelduse peale ja põrkas reaalsusega kokku.

## AI nihutas pudelikaela koodi kirjutamiselt kokkuleppele, et seda on ohutu liita

Tarkvaratarne pudelikael polnud kunagi trükkimine. See oli kokkulepe. Gene Amdahl formaliseeris üldise seaduse [1967. aastal](https://en.wikipedia.org/wiki/Amdahl%27s_law): kiirenda süsteemi ühte osa ja koguvõit jääb piiratuks osadega, mida sa ei kiirendanud. AI kiirendas tootmist. See ei kiirendanud ülevaatust, QA-d, integreerimist ega ühildamist ehk tarne järjestikust osa. Ja see on hullem kui lagi, sest kiirem tootmine valab rohkem tööd just sinna ossa, mis ei skaleeru.

[Faros AI telemeetria](https://www.faros.ai/blog/ai-software-engineering) enam kui 10 000 arendaja ja 1 255 tiimi pealt näitab täpselt seda mustrit: kõrge AI-kasutusega tiimid liitsid 98% rohkem pull requeste, samal ajal kui ülevaatuse aeg kasvas 91%. Sama andmestiku järgi seostus AI kasutuselevõtt 154% suuremate PR-idega ja 9% rohkemate bugidega arendaja kohta. Ettevõtte tasandil ei leidnud Faros märkimisväärset paranemist üheski mõõdikus, kaasa arvatud DORA. Pudelikael nihkus koodi kirjutamiselt otsusele, kas koodi on ohutu liita.

Kedagi, kes on lugenud [DORA uuringuid](https://dora.dev/capabilities/working-in-small-batches/), ei tohiks miski sellest üllatada: väikestes partiides töötamine on tarnevõimekuse tugevamaid ennustajaid ja rõhk on väikestel muudatustel kiire tagasisidega, mitte toodetud koodi mahul. Ettevõte kiirendas täpselt seda ainsat asja, mida DORA pole kunagi kitsaskohaks nimetanud.

## Su AI-stack on hajussüsteem ilma konsensusprotokollita

Ettevõte, kus AI töötab iga tööriista sees, on hajussüsteem ja peaaegu mitte keegi ei tarni seda koos konsensusprotokolliga. Sellel, mida ma nägin, on hajusarvutuses oma nimi: [split-brain](https://en.wikipedia.org/wiki/Split-brain_(computing)). Partitsioneeri klaster ja kui mõlemad pooled võtavad kirjutusi edasi vastu, ehitab kumbki omaenda tõeversiooni. Disainitööriist, ülesannete haldur, spekk ja koodibaas võtsid kõik kirjutusi vastu kiiremini, kui ükski inimene jõudis lugeda. Miski ei ühildanud neid.

Melvin Conway nägi selle taga olevat seadust [1968. aastal](https://www.melconway.com/Home/Conways_Law.html). Tema sõnastuses: „Iga organisatsioon, mis projekteerib süsteemi (laias tähenduses), toodab disaini, mille struktuur on koopia selle organisatsiooni suhtlusstruktuurist.“ Anna igale silole omaenda AI ja sa ei paranda killustatust, sa automatiseerid selle.

Klassikalise stsenaariumiga võrreldes on üks erinevus, ja see teeb asja hullemaks. Partitsioneeritud klastril oli kunagi konsensus ja see kaotas selle. Sinu ettevõtte AI-stackil pole seda kunagi olnud. See sündis split-brain'ina.

## Läbikukkumine, mida keegi ei mõõda: lokaalselt õige, globaalselt vale

Ohtlik läbikukkumine on vastus, mis on lokaalselt õige ja globaalselt vale: väljamõeldud vastused auditeeritakse, sidusetud libisevad läbi. Kõik mõõdavad hallutsinatsioone ja tööstusel on selleks benchmark'id. Aga sügavam läbikukkumine selles ettevõttes oli teistsugune: iga tööriist tegi oma tööd õigesti selle viilu peal, mida ta nägi, ja õigete vastuste summa moodustas sidusetu süsteemi.

Ükski standardne hindamine seda kinni ei püüa. Benchmark'id nagu MMLU ja HELM testivad ühte mudelit ühe ülesande peal. Pole olemas hindamist, mis kontrolliks, kas su viis AI-puutepunkti on sama funktsionaalsuse osas omavahel ühel nõul. Praktikud juba tunnevad seda lõhet: [Stack Overflow 2025. aasta küsitluses](https://survey.stackoverflow.co/2025/ai/) enam kui 49 000 arendaja seas kasutab või plaanib AI-tööriistu kasutada 84%, ent selle täpsust umbusaldab rohkem arendajaid (46%) kui usaldab (33%). Frustratsioon number üks, mida nimetas 66%, on kood, mis on „peaaegu õige, aga mitte päris“, ja 45% ütleb, et AI genereeritud koodi silumine võtab rohkem aega. Peaaegu õige ongi täpselt see, kuidas lokaalselt korrektne ja globaalselt sidusetu seestpoolt välja näeb.

## Mis AI tõttu takerdunud tarne lahti päästab: ühildamine masinkiirusel

Kui tootmine käib masinkiirusel, peab ühildamine käima masinkiirusel, muidu nullib kiirendus iseenda. Lahendus ei ole vähem AI-d, targem mudel ega paremad promptid. Puuduv tükk on funktsioon, mida inimesed täitsid märkamatult, kuni kõik oli aeglane: disaini, speki, ülesannete ja koodi eraldiseisvate väidete kokkuviimine üheks kehtivaks tõeks. See funktsioon peab nüüd olema infrastruktuur: [kontekstikiht](/en/blog/guides/context-layer-for-ai-agents) (inglise keeles), mida iga tööriist enne tegutsemist loeb ja mille kaudu tagasi kirjutab. Ühtne keel ja konsensusprotokoll, ehitatud harjumuse asemel süsteemiks.

Ka see lahendus on mõõdetud, ühe reservatsiooniga, mis tuleb enne. 2026. aasta preprintis testisid [Dillon ja Varanasi](https://arxiv.org/abs/2605.08112) koodiagenti 41 tiimiotsuse vastu ühes koodihoidlas ja tõstsid vastavuse 46%-lt 95%-le. Reservatsioon: nad ise ehitavad kontekstitööriista, mida nad testisid, ja võit tuli tervikpaketist, kuhu kuulusid talletatud otsused, genereeritud spetsifikatsioon ja konsultatsioon ehitamise ajal, nii et ükski koostisosa eraldi au ei teeni. See, mis reservatsiooni üle elab, on üks juhtum nende otsustepõhises tabelis. Koodihoidlas oli kaks auditifunktsiooni ja SOC-2 reegel tegi neist täpselt ühe ekspordi puhul kohustuslikuks. Reegel ise ei olnud kirjas üheski kohas, kuhu agent ligi pääses. Kui tal kästi tagada, et toiming logitakse, otsis ta, leidis auditifunktsiooni ja kasutas valet, ning autorite sõnul nõuab see vahetegemine teadmist, miks õige funktsioon üldse olemas on. Mõlemat funktsiooni suutis ta lugeda. Kokkulepet, kumma tiim oli valinud, ta lugeda ei suutnud. Otsing üksi seda lõhet ei sulge, sest [otsing leiab sarnast teksti, aga ei halda tõde](/en/blog/comparisons/mcp-vs-rag-for-agent-context) (inglise keeles).

## Mida kontekstikihilt nõuda

Enne järgmise AI-tööriista ostmist esita tiimile üks küsimus: kust loevad kõik meie AI-d seda, mis on tõsi? Kontekstikiht väärib seda rolli ainult siis, kui ta teeb nelja asja. Viib ühe ja sama asja eri nimed kokku üheks entiteediks. Jälgib päritolu, nii et iga fakt viib tagasi allikani. Paneb vaidlustatud faktid ootele või märgistab need, selle asemel et segada need üheks enesekindlaks vastuseks. Ja asub tööriistade all, mida sa juba kasutad, nii et agendid loevad seda esimesena, standardse liidese (näiteks MCP) kaudu.

Enamik selle kategooria tooteid töötab pilvetellimusena võõral infrastruktuuril. [LoomSignal](/et#pricing) on meie vastus just tarnetsükli jaoks: lokaalne kontekstikiht, mida su AI-tööriistad jagavad, mis töötab su enda serverites ja mille eest maksad ühe korra. See rafineerib toorsignaale läbi [Bronze'i, Silveri ja Goldi tasemete](/et/docs/architecture), nii et agent tegutseb ainult konteksti alusel, mis on läbinud governance-värava.

Kiirenduse saavad päriselt kätte mitte ettevõtted, millel on kõige targem mudel, vaid need, mille tööriistad on ühel nõul selles, mis on tõsi.

---
Source: https://loomsignal.io/et/blog/vaated/miks-ai-muudab-tarkvaratarne-aeglasemaks