Det er raskere å bygge programvare nå enn det var for to år siden. Det er ikke en påstand, det er noe vi merker i hver eneste leveranse. Men farten har flyttet flaskehalsen, ikke fjernet den, og de problemene vi rykker ut til nå er ikke de samme som før.
1. Prototypen ble aldri kastet
Noen bygget noe på en ettermiddag for å vise en idé. Det virket. Så begynte folk å bruke det. Nå ligger det i produksjon uten tester, uten miljøer, uten at noen vet hvem som eier det.
Dette er det vanligste, og det er ikke et AI-problem, AI gjorde det bare billigere å komme dit. Løsningen er å bestemme på forhånd hva en prototype er: noe man ser på og deretter tar en beslutning om, ikke noe som glir inn i drift fordi ingen sa stopp.
2. Ingen kan forklare hvorfor koden ser slik ut
Kode som er skrevet raskt og godkjent overfladisk blir dyr det øyeblikket noe må endres. Spørsmålet er ikke om et menneske skrev hver linje. Det er om noen forsto den godt nok til å svare for den.
Det er derfor vi gjennomgår alt som skal i produksjon, uansett hvem eller hva som skrev det. En agent som skriver kode raskt er en fordel. En agent som skriver kode ingen leser er en gjeld.
3. Tilgangene ble aldri ryddet
Dette rammer hardest når AI kommer inn i et miljø som har vokst i ti år. Copilot og agenter viser fram det brukeren har tilgang til, og plutselig oppdager folk hva det faktisk er. Verktøyet forårsaker ikke problemet, det avdekker det.
Rydd i tilganger før dere ruller ut, ikke etter.
4. Det er ingen som eier løsningen
Fart gjør det lett å bygge mange ting. Det gjør det ikke lettere å drifte dem. Fem applikasjoner uten navngitt eier blir fem overraskelser om atten måneder, når noe slutter å virke og ingen vet hvor kildekoden ligger.
5. Kostnaden per kjøring ble aldri målt
Noe som kjører i produksjon og kaller en modell har en løpende kostnad. Måler dere den ikke før dere går live, oppdager dere den på fakturaen. Det er et løsbart problem, vi setter tak per kjøring og per måned, men bare hvis noen tenker på det først.
Det som ikke har endret seg
Fart flytter hvor arbeidet ligger. Den fjerner ikke behovet for miljøer, gjennomgang, eierskap og drift. De fire tingene er akkurat like nødvendige nå som før, forskjellen er at man rekker å bygge mye mer før man merker at de mangler.
Hvor Breathe AI Launchpad passer inn
Launchpad er svaret vårt på nettopp denne rekkefølgen. Vi bygger med AI-kodeagenter, men rundt dem ligger det som gjør at resultatet holder: miljøer som er skilt fra hverandre, gjennomgang før noe settes i produksjon, dokumentasjon dere eier, og drift som følger med.
Dere beskriver behovet, vi bygger en fungerende prototype raskt, og dere ser på den før noen binder budsjett. Det som godkjennes settes i produksjon i deres eget miljø. Det som ikke godkjennes kastes, og det er billigere å si nei til en prototype enn til et halvferdig prosjekt.
Prismodellen følger samme logikk: en fast del for utviklingsmiljøet og styringen, en flat avgift per applikasjon vi drifter i produksjon. Kostnaden følger antall applikasjoner dere kjører, ikke antall mennesker som bruker dem.
Passer det for dere? Det avhenger av om dere trenger noe eget eller noe standard. Vi har skrevet hvordan vi skiller, og vi sier fra når svaret er Dynamics 365. Mer om Launchpad.
Vanlige spørsmål
Er kode skrevet med AI dårligere?
Ikke i seg selv. Problemet oppstår når den ikke blir lest. Vi gjennomgår alt som skal i produksjon uansett hvem eller hva som skrev det, spørsmålet er om noen forsto koden godt nok til å svare for den.
Hva er det vanligste problemet dere ser nå?
Prototyper som havnet i produksjon uten at noen bestemte at de skulle det. AI gjorde det billigere å bygge noe raskt, og dermed lettere å gli inn i drift uten miljøer, tester eller eierskap.
Hvorfor koster AI-løsninger mer å drifte enn folk tror?
Fordi noe som kaller en modell har en løpende kostnad som følger bruken. Måles den ikke før produksjonssetting, oppdages den på fakturaen. Vi setter tak per kjøring og per måned før noe går live.
Hva er forskjellen på Launchpad og et vanlig utviklingsprosjekt?
Prismodellen og rekkefølgen. Dere ser en fungerende prototype før dere binder budsjett, og kostnaden følger antall applikasjoner vi drifter, ikke antall brukere.