Hva databaseteam kan lære utviklere om AI-kodeagenter

La meg være ærlig: Hver uke dukker det opp overskrifter om AI-agenter som skriver kode raskere enn menneskelige utviklere. Cursor gjenoppbygde SQLite på noen dager. Programvarefabrikker leverer PR-er i volum. Det er nok til å få enhver utvikler til å lure på om jobben er på lånt tid.

Men her er hva disse overskriftene overser: hastighet er den enkle delen. Å få agenter til å skrive kode fort? Trivielt løst. Å få dem til å skrive kode du faktisk ville stolt på i produksjonssystemer? Det er det vanskelige problemet ingen vil snakke om.

Cockroach Labs delte nylig sin tilnærming til denne utfordringen, og det er verdt å gruble over — spesielt hvis du er en gründer eller utvikler som vurderer å integrere AI-agenter i arbeidsflyten din.

Spørsmålet som koster 160 000 dollar

I 2024 la Cockroach Labs til Oracle-database-støtte i migrationsverktøyet sitt, MOLT. Prosjektet tok ni måneder og kostet rundt 160 000 dollar i ingeniørtimer. Solid, profesjonelt arbeid fra erfarne ingeniører.

Så kom april. Teamet trengte støtte for IBM Db2 — en database med et rikt SQL-dialekt, komplekst typesystem og native wire-protokoll. Tilsvarende teknisk omfang.

De gjorde det på mindre enn to dager. Den totale kostnaden var 4 172 dollar.

Haken? Ingen mennesker skrev noen av koden.

Før du begynner å skrive oppsigelsesbrevet i hodet, tenk på hva som muliggjorde dette: Det var ikke bare smartere agenter. Det var et system designet rundt en radikal forutsetning — at flaskehalsen ikke er å skrive kode, det er å skrive pålitelig kode.

Introduksjon til MOLT Sinai: En kodehospital

Cockroach Labs kastet ikke bare agenter på problemet. De bygde det de kaller MOLT Sinai: en pipeline modellert etter undervisningssykehus der problemer blir «pasienter», mergget kode blir «utskrivning», og menneskelige reviewere blir «overleger».

Vokabularet er sjarmerende, men den underliggende filosofien er alvorlig:

• Saker er pasienter: Hver oppgave kommer inn i systemet med dokumentasjon, blir triagert, og følger en definert behandlingsvei
• Dekomponering er diagnostikk: Store problemer deles opp i delproblemer med eksplisitte avhengighetsgrafer. Fundamentalarbeid før typesystemer. Typesystemer før raditeratorer. Du kan ikke skynde healing.
• Review er runder: Hvert arbeidsstykke blir undersøkt, sendt tilbake for revideringer (noen ganger 55 ganger per hovedsak), og eskalert ved behov
• Mennesker er overleger: Endelig autoritet forblir hos erfarne ingeniører som kan eskalere saker til seg selv når noe ser galt ut

Dette handler ikke om å erstatte leger — det handler om å bygge et system der beboerne, spesialistene og overlegene alle har klart definerte roller.

Hvorfor gjennomstrømning er feil metric

Her er der de fleste AI-kodeeksperimenter tar feil: De optimaliserer for «PR-er per time» eller «linjer med kode per dag». Disse metricene føles spennende i demoer. De lager gode overskrifter. De er nesten ubrukelige for faktisk å levere programvare.

Cockroach Labs sier det rett ut: De vil heller at agentene tar 10 ganger lengre tid enn å levere feil data i en kundemigrasjon. For et selskap hvis hele verditilbud er datakorrekthet, er dette ikke bare filosofi — det er overlevelse.

Spørsmålet deres var ikke «hvor mange PR-er kan vi merge?» Det var «hvor mange av disse PR-ene ville vi skamme oss over å merge?»

Det er et spørsmål flere team burde stille seg, enten de bruker AI-agenter eller ikke.

Hva som faktisk skjedde

Da Db2-støtten landet i MOLT:

• 32 undersaker ble opprettet under hovedsaken
• 27 pull requests ble merget gjennom pipelinen
• 55 ganger sendte reviewere arbeid tilbake for revidering
• 9 saker ble eskalert, med 2 som krevde menneskelig inngripen
• Testdekningen matchet deres best testede dialekt (PostgreSQL)

Agentene var ikke perfekte. De opprettet saker mot sitt eget arbeid: fixture-hull, type-mapping-bugs, isolasjonsnivå-fikser. De trengte oppfølging. Men oppfølgingen var strukturert, formålsrettet, og skalert til arbeidets kompleksitet.

Sammenlign dette med en programvarefabrikk som kjører agenter i parallell med en merge-håndteringslayer. Den arkitekturen gir mening når flaskehalsen er skrivehastighet. For korrekthets-kritisk arbeid? Du trenger noe nærmere et sykehus, ikke en fabrikkgulv.

Hva dette betyr for teamet ditt

De fleste av dere bygger ikke databasemigrasjonsverktøy. Dere bygger webapplikasjoner, API-er, interne verktøy, MVP-er for neste store greie. Innsatsen er annerledes.

Men lærdommen gjelder: AI-agenter er gode på volum, mennesker er gode på dømmekraft. Teamene som får reell verdi fra AI-koding kobler ikke bare ChatGPT og sender ut resultatet. De bygger systemer som utnytter hver sin styrke.

Dette kan bety:

• Bruke agenter til boilerplate, tester og stillasbygging
• Bygge review-pipelines som fanger opp det agentene overser
• Behandle agentoutput som «utkast én» heller enn «klar til levering»
• Holde mennesker i loop for alt som berører kundedata eller kjerneforretningslogikk

Utviklerne som vil trives sammen med AI-agenter er ikke de som lærer å skrive raskere. Det er de som lærer å arkitektere systemer som gjør AI til en kraftmultiplikator heller enn en risiko.

Bunnlinjen

MOLT Sinai prosesserte det som tilsvarer ni måneders ingeniørarbeid på to dager, til 2,5% av kostnaden, med kvalitet som matcher menneskeskrevet kode.

Men den overskriften skjuler hva som faktisk skjedde: Et team av mennesker bygde et strengt system, definerte klare roller, etablerte meningsfulle kontrollpunkter, og stolte deretter på at agentene deres opererte innenfor den rammen.

Agentene erstattet ikke ingeniørene. De forsterket dem.

Det er ikke en historie om AI som erstatter utviklere. Det er en historie om utviklere som bygger systemer sofistikert nok til å bruke AI godt.

Og ærlig talt? Det er versjonen av denne historien det er verdt å følge med på.

Lei av infrastruktur som bremser deg? Vibe Hosting kombinerer AI-drevet distribusjon med påliteligheten du trenger for å sende fort uten frykt. Domeneregistrering, SSL-sertifikater og skytjenester — alt på ett sted.