Tankeledere
API-eksplosjonen er realistisk – og Vibe Coding tænder lunten
For bare noen år siden var det en høyfriksjonell innsats å sette i gang en ny API-endepunkt i en moden kodebase. Du måtte navigere eierskap av multiple kodeområder, håndtere godkjenninger fra irriterte arkitekter og gjennomføre gjennomganger som noen ganger varte i uker eller måneder. Friksjonen var smertefull, men den sikret at hver ny API medførte en viss grad av gjennomgang og institusjonell hukommelse.
Nå? AI-drevne utviklingsverktøy har ødelagt denne flaskehalsen.
GenAI-agenter kan forbruke massive mengder kontekstuell data og generere kodeendringer over hundredvis av filer på sekunder. Dette har demokratisert evnen til å opprette API-er – ikke bare for ingeniører, men også for ikke-tekniske roller (sjokk og horror) som produktledere og støtteam som nå kan føle seg beføyde til å sende eksperimenter rett til produksjon.
Det er en massiv endring i hvem som har makt i programvareutviklingsprosessen. Og det er ikke nødvendigvis et dårlig ting, spesielt i en forretningsmiljø som prioriterer hastighet og iterasjon. Men resultatet er en brann av raskt distribuerte API-er: mange lansert som “eksperimentelle” eller skjult bak funksjonsflagg, men raskt blir essensiell infrastruktur når forretningsbehov utvikler seg. Hva som starter som en rask prototyp blir en nøkkelintegrering. Og nå er det for sent å rulle tilbake.
Oppkomsten av “Vibe Coding”
Denne nye typen AI-genererte API-er ankommer ofte med lite i vei for arkitektur, dokumentasjon eller testing. Vi kaller dette fenomenet “vibe coding”– å skrive programvare basert på grov intuisjon, løs prompting og en generell følelse av hva som “burde fungere”, snarere enn en dyp forståelse av systemer eller designmønster.
Uheldigvis tenderer API-er som er opprettet på denne måten å følge ujevne konvensjoner, mangle robust validering og ofte ignorerer etablerte interne standarder. Verre, de kan introdusere alvorlige sikkerhets- eller regulatoriske risikoer, spesielt når de kobles til sensitive data eller eksterne endepunkter. AI vet ikke ditt selskaps styringsmodell – eller ditt overholdelseskrav. Med mindre det uttrykkelig blir fortalt, vil det ikke skrive med dem i mente.
Og problemene forverres raskt. AI brukes også i økende grad til å generere tester. Men når feil kode testes med AI-genererte valideringer, bekrefter testene bare feilfunksjon. Utviklere er motvillige til å skrive tester for kode de ikke har forfattet, snarere kode generert av maskiner, så AI fyller gapet. Resultatet? En rekursiv tilbakemeldingsloop av lavkvalitetskode testet og “valideret” av like usikre rammeverk.
Lappeteknikk-API-er og eierkrisen
Alt dette fører til et spredt, fragmentert API-lag innen de fleste organisasjoner. API-er dekker nå overlappende domener, utfører lignende funksjoner på litt forskjellige måter og mangler ofte klart eierskap. Mange ble skrevet uten en dyp forståelse av underliggende datamodeller, tjenestegrenser eller teamcharter. Ikke overraskende blir vedlikehold et mareritt. Hvem eier denne endepunktet? Hvem kan modifisere det? Hvem vet det overhode finnes?
AI-verktøy prioriterer nytte og hastighet. Uten kontroll vil de skape den korteste veien til levering, uansett om det stemmer overens med din arkitektoniske visjon. Over tid kan vekten av denne tekniske gjelden bremse fremgangen.
Noen praktiske skritt å gå.
1. Synlighet
Svaret er ikke å bremse alt ned eller forbud mot AI. Det er ikke realistisk, og det ville etterlate enorme verdier på bordet. I stedet må vi utvikle hvordan vi håndterer programvare i generativ utviklingsalder.
Den grunnleggende første skrittet er synlighet. Du kan ikke styre det du ikke kan se. Organisasjoner trenger kontinuerlig API-oppdagelse, ikke statisk dokumentasjon som er foreldet øyeblikket det blir publisert.
Verktøy som overvåker API-er – både under kjøring og i kode – blir essensielle. Når du kan kartlegge din virkelige API-landskap, kan du vurdere risiko, identifisere duplisering og begynne å bygge pålitelig styring på toppen.
Ironisk nok kan AI selv hjelpe med denne prosessen. Ved å bruke prompted AI-modeller til å analysere og auditere API-kart hjelper med å avdekke anomalier, risikofulle eksponeringer og konsolideringsmuligheter. Dette er AI som hjelper ikke med å bygge mer, men med å rydde opp i det vi allerede har.
2. Opprette organisasjonsomfattende standardisering av promptingeniør og verktøy
Bedre kontroll over både utgangen og inngangen til AI-verktøy går langt i å holde en viss grad av kontroll over den genererte koden. Enkle skritt som å aligne på de AI-drevne IDE-ene og modellene som er godkjent for å bruke innen en organisasjon, vil hjelpe med variasjonen. Dette har også fordelen av å gjøre det enklere å rulle ut nye modeller og gjøre det mer sannsynlig at prompter vil være reproduserbare over ingeniørarbeidsstasjoner.
Enda mer kraftfullt er å aligne på de spesifikke rules.md type filer du krever AI-kodere å levere som kontekst til deres agent. Jo mer kompleks kodebasen er, jo mer nyttig er det for alle ingeniører å arbeide med samme sett med regler, og gi kontekst til AI-agenten om hvordan å korrekt generere kode som fungerer best med eksisterende strukturer.
Vi kommer ikke til å sette den generative genien tilbake i flasken. Men vi kan guide den, begrense sprengningsradiusen og bruke den til å drive ansvarlig innovasjon. Denne arbeidet starter ikke med kode, men med klarhet.
