Det går snabbare att bygga programvara nu än för två år sedan. Det är inte ett påstående, det är något vi märker i varenda leverans. Men farten har flyttat flaskhalsen, inte tagit bort den, och de problem vi rycker ut till nu är inte desamma som förr.
1. Prototypen kastades aldrig
Någon byggde något på en eftermiddag för att visa en idé. Det fungerade. Sedan började folk använda det. Nu ligger det i produktion utan tester, utan miljöer, utan att någon vet vem som äger det.
Det här är det vanligaste, och det är inte ett AI-problem, AI gjorde bara vägen dit billigare. Lösningen är att bestämma i förväg vad en prototyp är: något man tittar på och sedan fattar ett beslut om, inte något som glider in i drift för att ingen sa stopp.
2. Ingen kan förklara varför koden ser ut så
Kod som skrivits snabbt och godkänts ytligt blir dyr i samma stund något måste ändras. Frågan är inte om en människa skrev varje rad. Det är om någon förstod den tillräckligt väl för att svara för den.
Det är därför vi granskar allt som ska i produktion, oavsett vem eller vad som skrev det. En agent som skriver kod snabbt är en fördel. En agent som skriver kod ingen läser är en skuld.
3. Behörigheterna städades aldrig
Det här biter hårdast när AI kommer in i en miljö som vuxit i tio år. Copilot och agenter visar fram det användaren har åtkomst till, och plötsligt upptäcker folk vad det faktiskt är. Verktyget orsakar inte problemet, det avslöjar det.
Städa behörigheterna innan ni rullar ut, inte efter.
4. Ingen äger lösningen
Fart gör det lätt att bygga många saker. Det gör dem inte lättare att drifta. Fem applikationer utan namngiven ägare blir fem överraskningar om arton månader, när något slutar fungera och ingen vet var källkoden ligger.
5. Kostnaden per körning mättes aldrig
Något som körs i produktion och anropar en modell har en löpande kostnad. Mäter ni den inte innan ni går live upptäcker ni den på fakturan. Det är ett lösbart problem, vi sätter tak per körning och per månad, men bara om någon tänker på det först.
Det som inte har ändrats
Fart flyttar var arbetet ligger. Den tar inte bort behovet av miljöer, granskning, ägarskap och drift. De fyra är precis lika nödvändiga nu som förr, skillnaden är att man hinner bygga mycket mer innan man märker att de saknas.
Var Breathe AI Launchpad passar in
Launchpad är vårt svar på just den här ordningen. Vi bygger med AI-kodagenter, men runt dem ligger det som gör att resultatet håller: miljöer som hålls isär, granskning innan något når produktion, dokumentation ni äger, och drift som följer med.
Ni beskriver behovet, vi bygger en fungerande prototyp snabbt, och ni tittar på den innan någon binder budget. Det som godkänns sätts i produktion i er egen miljö. Det som inte godkänns kastas, och det är billigare att säga nej till en prototyp än till ett halvfärdigt projekt.
Prismodellen följer samma logik: en fast del för utvecklingsmiljön och styrningen, en flat avgift per applikation vi driftar i produktion. Kostnaden följer antalet applikationer ni kör, inte antalet människor som använder dem.
Passar det er? Det beror på om ni behöver något eget eller något standard. Vi har skrivit hur vi skiljer dem åt, och vi säger till när svaret är Dynamics 365. Mer om Launchpad.
Vanliga frågor
Är kod skriven med AI sämre?
Inte i sig. Problemet uppstår när den inte läses. Vi granskar allt som ska i produktion oavsett vem eller vad som skrev det, frågan är om någon förstod koden tillräckligt väl för att svara för den.
Vilket är det vanligaste problemet ni ser nu?
Prototyper som hamnade i produktion utan att någon bestämde att de skulle det. AI gjorde det billigare att bygga något snabbt, och därmed lättare att glida in i drift utan miljöer, tester eller ägarskap.
Varför kostar AI-lösningar mer att drifta än folk tror?
För att något som anropar en modell har en löpande kostnad som följer användningen. Mäts den inte innan produktionssättning upptäcks den på fakturan. Vi sätter tak per körning och per månad innan något går live.
Vad är skillnaden på Launchpad och ett vanligt utvecklingsprojekt?
Prismodellen och ordningen. Ni ser en fungerande prototyp innan ni binder budget, och kostnaden följer antalet applikationer vi driftar, inte antalet användare.