Hvad databaseteams kan lære udviklere om AI-kodningsagenter

Lad os være ærlige: Hver uge bringer endnu en overskrift om, hvordan AI-agenter skriver kode hurtigere end menneskelige udviklere. Cursor genskrev SQLite på få dage. Softwarefabrikker spytter PR'er ud i volume. Det er nok til at få enhver udvikler til at undre sig over, om deres job er ved at blive overflødigt.

Men her er hvad de overskrifter overser: hastighed er den nemme del. At få agenter til at skrive kode hurtigt? Det er trivialt løst. At få dem til at skrive kode, du faktisk ville have tillid til i produktionssystemer? Det er det svære problem, ingen rigtig vil tale om.

Cockroach Labs delte for nylig deres tilgang til denne udfordring, og det er værd at dykke ned i – især hvis du er startup eller udvikler, der tænker over at integrere AI-agenter i din arbejdsgang.

De $160.000 spørgsmål

I 2024 tilføjede Cockroach Labs Oracle-databasesupport til deres migrationsværktøj, MOLT. Projektet tog ni måneder og kostede cirka $160.000 i ingeniørtid. Solidt, professionelt arbejde af erfarne ingeniører.

Så kom april. Teamet havde brug for at tilføje support til IBM Db2 – en database med en rig SQL-dialekt, komplekst typesystem og native wire-protokol. Samme tekniske omfang.

De klarede det på mindre end to dage. Den samlede pris var $4.172.

Hmm? Ingen mennesker skrev noget af koden.

Før du begynder at skrive din opsigelse i tankerne, så overvej hvad der gjorde dette muligt: Det var ikke bare smartere agenter. Det var et system designet omkring en radikal forudsætning – at flaskehalsen ikke er at skrive kode, det er at skrive pålidelig kode.

Introduktion til MOLT Sinai: Et kodehospital

Cockroach Labs smed ikke bare agenter på problemet. De byggede det, de kalder MOLT Sinai: en pipeline modelleret efter undervisningshospitaler, hvor issues bliver til "patienter", merged kode bliver til "udskrivning", og menneskelige reviewere bliver til "chefer".

Vokabularet er charmerende, men den underliggende filosofi er seriøs:

• Issues er patienter: Hver opgave kommer ind i systemet med dokumentation, bliver triageret, og følger en defineret behandlingsvej
• Dekomponering er diagnose: Store problemer bliver brudt ned i delproblemer med eksplicitte afhængighedsgrafer. Fundamental arbejde før typesystemer. Typesystemer før row iterators. Man kan ikke skynde sig helbredelse.
• Review er runder: Hvert stykke arbejde bliver undersøgt, sendt tilbage til revision (nogle gange 55 gange per parent issue), og eskalerer når det er nødvendigt
• Mennesker er chefer: Endelig autoritet forbliver hos erfarne ingeniører, som kan eskalere issues til sig selv, når noget ser forkert ud

Dette handler ikke om at erstatte læger – det handler om at bygge et system, hvor beboere, reservelæger og specialister alle har klart definerede roller.

Hvorfor throughput er den forkerte metrik

Her går de fleste AI-kodning eksperimenter galt: De optimerer for "PR'er per time" eller "linjer kode per dag". Disse metrics føles spændende i demos. De giver fantastiske overskrifter. De er næsten ubrugelige til faktisk at shippe software.

Cockroach Labs siger det direkte: De ville hellere have, at agenter tager 10x længere tid end at lande forkerte data i en kundemigration. For en virksomhed hvis hele værditilbud er datakorrekthed, er dette ikke bare filosofi – det er overlevelse.

Deres spørgsmål var ikke "hvor mange PR'er kan vi merge?" Det var "hvor mange af disse PR'er ville vi være flov over at merge?"

Det er et spørgsmål flere teams burde stille sig, uanset om de bruger AI-agenter eller ej.

Hvad der faktisk skete

Da Db2-support landede i MOLT:

• 32 sub-issues blev åbnet under parent issuet
• 27 pull requests blev merget gennem pipelinen
• 55 gange sendte reviewere arbejde tilbage til revision
• 9 issues eskalerede, med 2 der nåede menneskelig intervention
• Testdækningen matchede deres bedst testede dialekt (PostgreSQL)

Agenterne var ikke perfekte. De indsendte issues mod deres eget arbejde: fixture huller, type-mapping bugs, isolation-level rettelser. De havde brug for overblik. Men overblikket var struktureret, formålsbestemt, og skaleret til arbejdets kompleksitet.

Sammenlign dette med en softwarefabrik, der kører agenter parallelt med et merge-handling lag. Den arkitektur giver mening, når flaskehalsen er skrivehastighed. For korrekthedskritisk arbejde? Du har brug for noget mere som et hospital, ikke en fabriksgulv.

Hvad dette betyder for dit team

Lad mig være direkte: De fleste af jer bygger ikke databasemigrationsværktøjer. I bygger web apps, API'er, interne værktøjer, MVP'er til det næste store. Indatsen er anderledes.

Men lektionen gælder: AI-agenter excellerer i volume, mennesker excellerer i dømmekraft. De teams, der får reel værdi fra AI-kodning, prompt ikke bare ChatGPT og shipper outputtet. De bygger systemer, der udnytter hver for det, de er gode til.

Det kan betyde:

• Brug agenter til boilerplate, tests og scaffolding
• Byg review-pipelines, der fanger det agenter overser
• Behandl agentoutput som "første udkast" snarere end "klar til at shippe"
• Hold mennesker i loopet for alt, der rører kundedata eller kerneforretningslogik

De udviklere, der vil trives sammen med AI-agenter, er ikke dem, der lærer at skrive hurtigere. Det er dem, der lærer at arkitektere systemer, der gør AI til en kraftmultiplikator snarere end en risiko.

Konklusionen

MOLT Sinai processerede det, der svarer til ni måneders ingeniørarbejde, på to dage, til 2,5% af omkostningerne, med kvalitet der matchede menneskeskrevet kode.

Men den overskrift skjuler, hvad der faktisk skete: Et team af mennesker byggede et stringent system, definerede klare roller, etablerede meningsfulde checkpoints, og stolede derefter på, at deres agenter opererede inden for den ramme.

Agenterne erstattede ikke ingeniørerne. De amplifierede dem.

Det er ikke en historie om AI, der erstatter udviklere. Det er en historie om udviklere, der bygger systemer sofistikerede nok til at bruge AI godt.

Og ærligt talt? Det er den version af denne historie, der er værd at bide mærke i.