Kun tekoäly ehdotti tuotantoon koodia, joka rikkoi kaiken

Oli keskiviikkoilta, kun huomasin viettäneeni neljä tuntia korjaamassa ongelmaa, jonka AI-agentti oli "korjannut" edellisenä yönä.

Agentti oli ollut yhtä tyytyväinen itseensä kuin tuore yliopisto-opiskelija ensimmäisessä harjoittelussaan. Se oli pushannut muutokset, ilmoittanut tehtävän valmistuneen, ja lähtenyt kuin tyttö, jonka pomo ei kiittänyt. Vain pieni yksityiskohta meni pieleen: toiminnallisuus, jonka piti korjata, ei toiminut ollenkaan. Ei buginen—täysin väärinymmärretty.

Se hetki muutti jotain päässäni.

Miksi metafora vaihtui

Olin ajatellut AI-agentteja innokkaina harjoittelijoina, jotka tarvitsevat ohjausta. Mutta harjoittelijat eivät pushaa testaamatonta koodia tuotantoon keskellä yötä. He eivät edes tiedä, missä tuotantopalvelin sijaitsee.

Sitten ymmärsin: minun pitää ajatella näitä agentteja aliurakoitsijoina.

Aliurakoitsija ei saa avaimia rakennukseesi. He eivät tule sovittamatta. He tekevät sovitun työn ja lähettävät laskun—jonka sinä tarkistat ennen maksua. Jos työn laatu on heikko, se menee takaisin.

Tämä ei ole epäluottamusta. Kyse on kannustimista. Kun aliurakoitsija ymmärtää, että tehtävä on toimittaa valmis työ sinun tarkistettavaksi—ei tehdä päätöksiä puolestasi—he keskittyy. Rajat tekevät hänet tehokkaaksi.

Tekninen puoli

Tämä ajattelumalli tarvitsee puremaa.

Tokenit ovat fyysinen este.

Omat agenttini toimivat erillisillä tunnuksilla, jotka eivät yksinkertaisesti pysty muuttamaan tuotantokoodia. Heillä on lukuoikeus pääkoodikantaan ja kirjoitusoikeus erilliseen staging-repositoryyn. Tämä ei ole sääntö—se on kryptografinen rajoite. Vaikka agentti menisi sekaisin tai keksisi väärennetyt git-komennot, se ei pysty muuttamaan tuotantoa. Tokenit eivät yksinkertaisesti salli sitä.

Staging-repositorio on postilaatikko.

Stagingistä ei koskaan mergata automaattisesti. Repositorion oletushaara on nimetty kuvaavasti: "no-main". Se sisältää vain README-tiedoston, jossa lukee: "Käytä alkuperäisen repositorion päähaaraa."

Agentit työntävät valmiit työnsä tänne. He ilmoittavat minulle, kun haarat ovat valmiita. Sitten minä tarkistan, poimin toimivat osat ja yhdistän ne manuaalisesti. Tämä kuulostaa kömpelöltä—kunnes tajuat, että näin Linux-ydin on toiminut kaksikymmentä vuotta. Kontribuuttorit lähettävät patchit. Ylläpitäjät soveltavat ne.

Tarkistus ei ole neuvoteltavissa.

Yksikään agentti ei koskaan mergaa omaa koodiaan. Koskaan. Haara ei poisteta, ennen kuin olen varmistanut—ohjelmallisesti, riippumattomasti—että sen commitit ovat turvallisesti tuotannossa. "Luota mutta varmista" ei riitä, kun varmistaminen on ilmaista.

Yksin kehittäjän etu

Tässä piilee jotain tärkeää: kun työskentelet yksin tai pienessä tiimissä, et vain rakenna softwarea. Ylläpidät kontekstia, jota ei ole missään koodissa. Tuntemustasi historiasta. Niistä edge caseista, jotka eivät koskaan päädy dokumentteihin. Asiakkaasta, jolla on omituinen konfiguraatio. Kolmesta asiasta, jotka kokeilit eikä toiminut.

Agenteilla ei ole pääsyä tähän kontekstiin. He lukevat tiedostoja, mutta eivät ymmärrä maailmaasi.

Eli tavoite ei ole antaa heille enemmän autonomiaa—se on maksimoida työ, jonka he voivat tehdä turvallisesti tarkistuskapasiteettisi sisällä.

Tässä "vibe coding" saa huonon maineen. Väärin tehtynä se tarkoittaa, että agentit tekevät mitä haluavat ja toivotaan parasta. Oikein tehtynä se tarkoittaa tekoälyn käyttämistä oman harkintakyvyn vahvistimena, ei korvaajana.

Käytännön hyödyt

Kun hyväksyt aliurakoitsija-suhteen, tapahtuu jotain odottamatonta: uskallat ottaa enemmän riskejä.

Olet valmis rakentamaan sen kokeellisen ominaisuuden, koska haitta on rajattu. Agentti ei pysty rikkomaan tuotantoa. Se voi toimittaa jotain yllättävän väärin tai yllättävän hyvin—mutta joka tapauksessa huomaat sen ennen kuin se on ongelma.

Olen aloittanut enemmän sivuprojekteja viimeisen kuuden kuukauden aikana kuin edellisen kahden vuoden aikana. En koska työskentelisin kovemmin—koska delegoin aggressiivisesti turvallisten rajojen sisällä.

Rakenna tämä työnkulkuusi

Jos käytät AI-agenteja kehityksessä, kysy itseltäsi:

1. Mihin agenttini pääsee tällä hetkellä? Jos vastaus on "tuotanto", siinä on ongelma.
2. Onko teknisessä rakenteessa estetty väärät toiminnot, vai vain poliittinen sääntö?
3. Kuka mergaa koodin? Jos vastaus ei ole ihminen, miksi ei?

Työkalut ovat olemassa. Token-scoping, erilliset staging-repositoriot, haarojen suojaus—nämä eivät ole eksoottisia Git-työnkulkuja. Ne ovat ero AI-avusteisen kehityksen ja AI-vahinkojen välillä.

NameOceanilla mietimme tätä paljon, kun rakennamme vibe coding -tukea hosting-ympäristöömme. Tavoite ei ole automatisoida kaikkea—se on luoda tiloja, joissa tekoäly voi olla aidosti hyödyllinen ilman, että se luo uuden kategorian riskejä.

Sinun harkintakykyysi on edelleen pullonkaula. Se ei ole rajoitus—se on pointti. Agentit ovat olemassa vahvistaakseen sitä, mitä voit tehdä, eivät korvaamaan sitä harkintakykyä, joka tekee softasta toimivan oikeille käyttäjille.

Rakenna sen mukaan.