Udforsk hvordan AMP, Sourcegraphs banebrydende kodeagent, omformer AI-udviklingslandskabet ved at omfavne hurtig iteration, autonom ræsonnement og værktøjskaldende agenter – og hvorfor traditionelle kodningsværktøjer bliver forældede.
Landskabet for AI-kodeagenter oplever en hidtil uset forstyrrelse. Det, der var banebrydende for seks måneder siden, betragtes nu som forældet. GitHub Copilot, der engang var guldstandarden for AI-assisteret udvikling, er blevet overhalet af nyere værktøjer. Cursor dominerede markedet som den hurtigst voksende startup nogensinde, blot for at møde konkurrence fra endnu mere avancerede løsninger. I dette hurtigt udviklende økosystem traf Sourcegraph en dristig strategisk beslutning: I stedet for gradvist at forbedre deres eksisterende Cody-produkt lancerede de AMP – en helt ny kodeagent bygget fra bunden til at omfavne AI-frontens muligheder.
Denne artikel udforsker filosofien, den tekniske arkitektur og forretningsstrategien bag AMP med indsigter fra samtaler med teamet bag dette revolutionerende værktøj. Vi undersøger, hvorfor traditionelle tilgange til produktudvikling fejler i en tid med hurtig AI-udvikling, hvordan værktøjskaldende agenter grundlæggende adskiller sig fra tidligere AI-kodeassistenter, og hvordan fremtiden for autonom udvikling ser ud. Vigtigst af alt forstår vi, hvorfor “kejseren ikke har noget tøj på” – hvorfor etablerede produkter med tilsyneladende urokkelige markedspositioner kan blive irrelevante nærmest natten over, når den underliggende teknologi ændrer sig.
{{ youtubevideo videoID=“b4rOVZWLW6E” provider=“youtube” title=“AMP: Kejseren har ingen tøj på - Hvorfor AI-kodeagenter forstyrrer udviklerværktøjer” class=“rounded-lg shadow-md” }}
Udviklingen af AI-assisteret udvikling har fulgt en tydelig kurs, hvor hver generation bygger videre på den forrige, men fundamentalt ændrer, hvordan udviklere interagerer med kunstig intelligens. For at forstå betydningen af AMP må vi først forstå, hvad der adskiller en kodeagent fra tidligere former for AI-assistance. Rejsen startede med GitHub Copilot, som introducerede kodefuldførelse og forslag direkte i udviklernes editorer. Copilot var banebrydende, fordi det bragte AI ind i udviklingsarbejdet på en ikke-påtrængende måde ved at komme med forslag, mens udviklerne skrev. Men Copilot var grundlæggende begrænset – det kunne foreslå kode, men ikke udføre komplekse, flertrinsopgaver eller interagere med det bredere udviklingsmiljø.
Næste generation bragte værktøjer som Cursor og Windsurf, der greb sagen an ved at skabe IDE-forke med dybere AI-integration i udviklingsmiljøet. Disse værktøjer viste, at delvist agentiske egenskaber – hvor AI kunne udføre mere komplekse operationer i IDE’en – kunne forbedre udviklernes produktivitet markant. De viste, at udviklere var villige til at skifte hele deres udviklingsmiljø, hvis AI-egenskaberne var tilstrækkeligt avancerede. Men også disse værktøjer arbejdede inden for begrænsninger: de var interaktive og krævede input og godkendelse fra udvikleren ved hvert skridt, og de kunne ikke arbejde helt autonomt.
En kodeagent er derimod en grundlæggende anderledes arkitektur. En agent består af tre kernekomponenter: en sprogmodel (typisk en frontmodellen som Claude 3.5), en systemprompt, der definerer agentens adfærd og begrænsninger, samt et sæt værktøjer med tilhørende prompts, der beskriver, hvad hvert værktøj kan. Den afgørende forskel er, at agenter kan operere med eksplicitte tilladelser til at interagere med eksterne systemer – filsystemer, kodeeditorer, versionsstyringssystemer med mere. Det betyder, at en agent autonomt kan ræsonnere om et problem, beslutte hvilke værktøjer der skal bruges, eksekvere dem, observere resultaterne og iterere, indtil opgaven er løst. Dette er grundlæggende mere kraftfuldt end nogen tidligere tilgang, fordi det muliggør reel autonom adfærd frem for blot forbedrede forslag eller interaktiv assistance.
Teknologilandskabet befinder sig i en fase med hidtil uset ustabilitet. Det, der var state-of-the-art for atten måneder siden, er nu primitivt. GitHub Copilot, lanceret i 2021, var ægte banebrydende – det repræsenterede den første mainstream-anvendelse af store sprogmodeller i softwareudvikling. Men i dag regner mange udviklere det ikke engang blandt de bedste valg for AI-assisteret kodning. Det skyldes ikke, at Copilot er blevet dårligere; det skyldes, at den underliggende teknologi har udviklet sig så hurtigt, at hele kategorien har ændret sig. Det skaber en stor udfordring for etablerede virksomheder: hvordan kan du opretholde et succesfuldt produkt, når grundlaget konstant skifter?
Traditionel produktudvikling forudsætter et forholdsvist stabilt fundament. Du finder product-market fit, skalerer produktet, bygger ordentlige engineering-praksisser, tilføjer enterprise-funktioner, etablerer langtidskontrakter med kunder. Denne manual har fungeret i årtier, fordi teknologi typisk udvikler sig gradvist. Men i den nuværende AI-æra er denne tilgang direkte skadelig. Hvis du optimerer dit produkt til skalering og stabilitet, bliver du langsom. Hvis du bliver langsom, misser du næste bølge af muligheder. Når du har tilføjet enterprise-funktioner og sikkerhedscertificering, er der udkommet en ny model, der gør din tilgang forældet.
Sourcegraph stod præcis overfor dette dilemma med Cody. Cody var et succesfuldt produkt med enterprise-kunder, langvarige kontrakter og betydelige indtægter. Men Cody var tæt integreret med Sourcegraph-platformen, hvilket betød, at det var bundet af platformens udgivelsescyklusser. Platformen havde sin egen infrastruktur, egne implementeringsplaner og egne begrænsninger. Da Claude 3.5 Sonnet blev lanceret, og teamet indså, at de kunne bygge noget grundlæggende anderledes – en værktøjskaldende agent med autonom ræsonnement – stod de overfor et valg: forsøge at eftermontere disse egenskaber i Cody, eller starte forfra med et nyt produkt. De valgte at starte forfra, og denne beslutning afslører en vigtig indsigt om at konkurrere i hurtigt udviklende markeder.
Den væsentligste erkendelse var, at man ikke kan få et $20-abonnementsprodukt til at fungere for en værktøjskaldende agent. De beregningsmæssige omkostninger er grundlæggende anderledes. En chatbaseret assistent som Cody kan køre effektivt på beskeden infrastruktur. En værktøjskaldende agent, der ræsonnerer omkring kode, udfører værktøjer og itererer autonomt, kræver markant større regnekraft. Dette er ikke bare et prisproblem; det er et signal om, at produktet er grundlæggende anderledes og kræver en anden forretningsmodel, andre kunde-forventninger og en anden go-to-market-strategi. Ved at skabe AMP som et separat produkt med et separat brand kunne Sourcegraph nulstille disse forventninger fuldstændigt. De kunne sige til kunderne: “Dette er ikke Cody 2.0. Det er noget helt andet. Det koster mere, fordi det kan mere. Det fungerer anderledes, fordi det er bygget på en anden arkitektur.”
For virkelig at værdsætte, hvorfor AMP repræsenterer et paradigmeskift, skal vi forstå den tekniske arkitektur for værktøjskaldende agenter i detaljer. En værktøjskaldende agent er ikke blot en sprogmodel med adgang til funktioner. Arkitekturen er mere sofistikeret og mere kraftfuld. Systemet starter med en frontmodellen – i AMPs tilfælde Claude 3.5 Sonnet – der er trænet til effektivt at forstå og bruge værktøjer. Modellen får en systemprompt, der definerer dens rolle, begrænsninger og mål. Afgørende er, at systemprompten ikke bare er en løs instruktion; det er en nøje udformet prompt, der former, hvordan modellen ræsonnerer om problemer og vælger, hvilke værktøjer der skal bruges.
Sideløbende med systemprompten har hvert værktøj sin egen prompt, der beskriver, hvad værktøjet gør, hvilke parametre det accepterer, hvad det returnerer, og hvornår det skal bruges. Dette er kritisk, fordi sprogmodellen ikke kun skal vide, at et værktøj findes, men også hvad det skal bruges til, og hvornår det er passende at bruge det. For eksempel kan en agent have værktøjer til at læse filer, skrive filer, eksekvere kode, køre tests og committe ændringer. Hvert værktøj har en detaljeret beskrivelse, der hjælper modellen med at ræsonnere om, hvilket værktøj der skal bruges hvornår. Modellen kan så autonomt vælge at bruge disse værktøjer, observere resultaterne og iterere baseret på, hvad den lærer.
Styrken i denne arkitektur bliver tydelig, når man overvejer, hvad en agent kan gøre. En udvikler kan bede en agent om at “implementere en ny funktion, der tilføjer brugerautentificering til denne kodebase.” Agenten kan da autonomt: læse kodebasen for at forstå arkitekturen, identificere hvor autentificering skal integreres, skrive den nødvendige kode, køre tests for at verificere implementeringen, håndtere fejl ved at ændre koden og til sidst committe ændringerne. Alt dette sker uden menneskelig indgriben. Agenten ræsonnerer om problemet, beslutter hvilke værktøjer der skal bruges, og itererer baseret på feedback.
Dette er grundlæggende forskelligt fra tidligere AI-kodeværktøjer. Copilot kan foreslå kode, men ikke udføre flertrins-workflows. Cursor kan udføre mere komplekse operationer, men kræver menneskelig godkendelse ved hvert skridt. En agent kan operere autonomt med eksplicitte tilladelser. Det skaber en ny kategori af muligheder, der er langt mere kraftfuld. Det giver dog også nye udfordringer. Autonome agenter kan begå fejl i stor skala. De kan udføre skadelige operationer, hvis de ikke er korrekt begrænset. De kræver omhyggelig systemprompt-engineering for at sikre, at de opfører sig som ønsket. Disse udfordringer er grunden til, at AMPs arkitektur og tilgang er så vigtige.
Da AMP-teamet begyndte at bygge, traf de en grundlæggende beslutning: hastighed og iteration skulle være den primære optimeringsparameter. Alt andet skulle flyde derfra. Det betød at opgive mange af de praksisser, der havde gjort Sourcegraph succesfuld med Cody. Ingen formelle kodegennemgange. Ingen omfattende planlægningscyklusser. Ingen sikkerheds- og compliance-afkrydsninger, der tager ni måneder at gennemføre. I stedet adopterede teamet en personlig projektmentalitet: push til main, udgiv 15 gange om dagen, brug produktet selv hele tiden og iterer baseret på reel brug.
Denne tilgang lyder kaotisk, og målt med traditionelle softwareudviklingsstandarder er den det også. Men det er præcis den rigtige tilgang for et produkt, der arbejder på AI-fronten. Grunden er simpel: fronten flytter sig. Hver få måneder lanceres en ny model. Hver få uger opstår nye muligheder. Hver få dage opdages nye teknikker til prompt-engineering eller værktøjsdesign. I dette miljø er evnen til at iterere hurtigt mere værdifuld end evnen til at skalere pålideligt. Et produkt, der udgiver 15 gange dagligt, kan inkorporere nye modelmuligheder inden for timer efter deres lancering. Et produkt med traditionelle udgivelsescyklusser vil være måneder bagefter.
Teamstrukturen afspejler denne filosofi. Det centrale AMP-team er lille – omkring otte personer – sammenlignet med større engineering-organisationer. Denne lille størrelse er bevidst. Den muliggør hurtige beslutninger og eliminerer den kommunikationsbyrde, der sinker større teams. Alle på teamet er erfarne, så de kan arbejde uden omfattende kodegennemgange. De bruger produktet konstant, hvilket betyder, at de hurtigt fanger problemer og forstår brugerbehov indgående. De forsøger ikke at bygge et produkt til alle udviklere; de bygger til udviklere, der vil bevæge sig lige så hurtigt som dem selv, som vil være i fronten af AI-mulighederne og som er villige til at omfavne nye udviklingsmetoder.
Denne positionering er afgørende. AMP forsøger ikke at være GitHub Copilot for alle. Det prøver ikke at være standardværktøjet for alle udviklere. I stedet positionerer det sig som værktøjet for udviklere og teams, der vil bevæge sig hurtigt og blive ved fronten. Det er et meget mindre marked end “alle udviklere”, men det er et marked, der er villigt til at betale betydeligt mere for overlegne muligheder. Forretningsmodellen afspejler dette: i stedet for et $20-abonnement per måned betaler AMP-kunder hundredvis af dollars om måneden. Nogle teams har årlige omsætninger på flere hundrede tusinde dollars. Det er muligt, fordi værdiskabelsen er så stærk for målgruppen.
De principper, der styrer AMPs udvikling – hurtig iteration, positionering i fronten og autonom ræsonnement – gælder direkte for bredere workflow-automatisering. FlowHunt, som en platform til at bygge og automatisere komplekse workflows, står over for lignende udfordringer og muligheder. Ligesom AMP positionerer sig til at håndtere næste generations AI-muligheder, kan FlowHunt hjælpe organisationer med at bygge workflows, der er robuste over for hurtige teknologiske ændringer. Ved at fokusere på fleksibilitet, hurtig iteration og evnen til hurtigt at inkorporere nye værktøjer og muligheder gør FlowHunt det muligt for teams at holde sig foran.
Den væsentligste indsigt er, at i et hurtigt udviklende teknologilandskab er evnen til at tilpasse sig hurtigt mere værdifuld end evnen til at optimere for nuværende forhold. Dette gælder, uanset om du bygger en AI-kodeagent eller automatiserer forretningsprocesser. FlowHunts tilgang med hurtig workflow-oprettelse, test og iteration passer perfekt til denne filosofi. Teams kan bygge workflows, der inddrager de nyeste AI-muligheder, teste dem hurtigt og iterere baseret på resultaterne. Når nye modeller og værktøjer opstår, kan workflows opdateres hurtigt uden omfattende genengineering. Det er fremtiden for automatisering: ikke statiske, optimerede processer, men dynamiske, adaptive workflows, der udvikler sig med teknologien.
Markedet for AI-kodeagenter giver et fascinerende casestudie i, hvor hurtigt markedslederskab kan skifte. I starten af 2024 blev Cursor bredt betragtet som kongen af AI-kodeværktøjer. Det var den hurtigst voksende startup nogensinde. Udviklere skiftede fra andre værktøjer til Cursor i stor stil. Markedet virkede afgjort. Så, inden for få måneder, ændrede samtalen sig. Nye værktøjer opstod. Mulighederne blev forbedret. Udviklere begyndte at stille andre spørgsmål. Midt i 2024, hvis man spurgte udviklere om det bedste AI-kodeværktøj, ville mange ikke længere nævne Cursor først. Markedet havde flyttet sig så hurtigt, at den tidligere leder ikke længere var klart dominerende.
Dette mønster er ikke unikt for kodeagenter. Det er en grundlæggende egenskab ved markeder, hvor den underliggende teknologi udvikler sig hurtigt. I sådanne markeder er evnen til at bevæge sig hurtigt og tilpasse sig vigtigere end nuværende markedsandel. En virksomhed med 30 % markedsandel, der kan iterere hurtigt og inkorporere nye muligheder, vil til sidst overhale en virksomhed med 50 % markedsandel, der bevæger sig langsomt. Det er derfor, Sourcegraphs beslutning om at skabe AMP som et separat produkt var så strategisk fornuftig. Ved at adskille AMP fra Cody frigjorde de sig fra de begrænsninger, der ellers ville have bremset dem. De kunne bevæge sig hurtigt, iterere hurtigt og positionere sig i fronten.
Den bredere lektie er, at i hurtigt udviklende markeder har kejseren ofte intet tøj på. Etablerede produkter, der virker dominerende, kan blive forældede overraskende hurtigt. Det skyldes ikke, at de bliver dårligere; det skyldes, at teknologien skifter, og de ikke kan tilpasse sig hurtigt nok. De virksomheder, der lykkes, er dem, der forstår denne dynamik og positionerer sig derefter. De forsøger ikke at optimere for aktuelle forhold; de optimerer for evnen til at tilpasse sig fremtidige forhold. De forsøger ikke at betjene alle kunder; de fokuserer på kunder, der værdsætter hastighed og innovation. De følger ikke traditionelle produktudviklingspraksisser; de vælger metoder, der muliggør hurtig iteration og læring.
Samtalen om AMP afslører en vigtig indsigt om fremtiden for AI-agenter: det næste store skift bliver fra interaktive agenter til asynkrone agenter. I dag fungerer de fleste AI-kodeagenter interaktivt. En udvikler kører en agent i sin editor eller CLI, agenten udfører nogle operationer, og udvikleren ser resultaterne. Typisk kører én agent ad gangen, og det sker synkront – udvikleren venter på, at den bliver færdig. Det er en betydelig forbedring i forhold til manuel kodning, men det er ikke den endelige form for agentbaseret udvikling.
Den næste front er asynkrone agenter, der kører døgnet rundt i baggrunden, parallelt. I stedet for én agent ad gangen kan du have 10, 50 eller 100 agenter, der arbejder samtidigt på forskellige opgaver. En agent kan arbejde på refaktorering af kode ét sted, mens en anden skriver tests et andet sted. En tredje agent analyserer performance og foreslår optimeringer. Alt dette sker uden menneskelig indblanding og sker samtidigt. Implikationerne er enorme: en 10 til 100 gange forbedring i mængden af arbejde, der kan udføres, et fundamentalt skift i, hvordan udviklingsteams arbejder, og en fuldstændig nytænkning af, hvad der er muligt med AI-assisteret udvikling.
Dette skift vil få store konsekvenser for inferensomkostninger, for hvordan teams organiserer arbejdet, og for, hvad det vil sige at være udvikler. Det vil også skabe nye udfordringer omkring kvalitetssikring, sikkerhed og sikring af, at autonome agenter ikke introducerer fejl eller sikkerhedsproblemer i stor skala. Men potentialet er enormt. Teams, der effektivt kan udnytte asynkrone agenter, vil kunne opnå på dage, hvad der i dag tager uger. Derfor er det så afgørende at positionere sig til at bevæge sig hurtigt og tilpasse sig. De virksomheder, der først knækker koden til effektive asynkrone agenter, får et massivt konkurrenceforspring.
Det grundlæggende princip bag AMPs tilgang er at bygge til usikkerhed. Teamet ved ikke præcist, hvor teknologien går hen, men de ved, at den vil ændre sig. De ved ikke, hvilke muligheder der bliver vigtigst, men de ved, at nye muligheder vil opstå. De ved ikke, hvordan markedet ser ud om seks måneder, men de ved, at det vil være anderledes. Givet denne usikkerhed er det rationelle at optimere for tilpasningsevne snarere end optimering. Det betyder at holde kodebasen fleksibel, bevare evnen til at udgive hurtigt, holde sig tæt på AI-fronten og være villig til at droppe tilgange, der ikke længere virker.
Dette princip gælder også teamstruktur, forretningsmodel og kundestrategi. Teamet er lille og erfarent, hvilket muliggør hurtige beslutninger. Forretningsmodellen er fleksibel, uden fast pris eller brugermodel, hvilket gør det muligt hurtigt at tilpasse sig markedsudviklingen. Kundestrategien fokuserer på udviklere, der vil bevæge sig hurtigt, hvilket skaber en naturlig alignment mellem virksomhedens muligheder og kundernes behov. Alt udspringer af princippet om at bygge til usikkerhed og optimere for tilpasningsevne.
Dette er en radikalt anderledes tilgang end traditionel produktudvikling, hvor man forsøger at forudsige fremtiden, bygge til skalering og optimere for stabilitet. Men i et marked, hvor teknologien rykker hurtigt, er traditionelle tilgange direkte skadelige. De gør dig langsom, låser dig fast i beslutninger, der hurtigt bliver forældede, og forhindrer dig i at tilpasse dig nye realiteter. Virksomheder, der lykkes i sådanne markeder, er dem, der omfavner usikkerhed, optimerer for tilpasningsevne og bevæger sig hurtigt nok til at holde sig foran.
{{ cta-dark-panel heading=“Boost dit workflow med FlowHunt” description=“Oplev hvordan FlowHunt automatiserer dine AI-indholds- og SEO-workflows — fra research og indholdsgenerering til publicering og analyse — alt samlet ét sted.” ctaPrimaryText=“Book en demo” ctaPrimaryURL=“https://calendly.com/liveagentsession/flowhunt-chatbot-demo" ctaSecondaryText=“Prøv FlowHunt gratis” ctaSecondaryURL=“https://app.flowhunt.io/sign-in" gradientStartColor="#123456” gradientEndColor="#654321” gradientId=“827591b1-ce8c-4110-b064-7cb85a0b1217” }}
Evnen til at udgive 15 gange dagligt er ikke tilfældig; det er resultatet af bevidste arkitektoniske valg. Den første nøglebeslutning var at afkoble AMP fuldstændigt fra Sourcegraph-platformen. Cody var tæt integreret med Sourcegraph, hvilket bandt det til platformens udgivelsescyklusser og infrastrukturelle begrænsninger. AMP blev bygget som et selvstændigt produkt med egen infrastruktur, egen deployments-pipeline og egen udgivelsesplan. Denne afkobling er afgørende, fordi den eliminerer den koordinationsbyrde, der sinker større systemer. Ændringer i AMP kræver ikke koordinering med platformens ændringer. Udrulninger kræver ikke at vente på platformudgivelser.
Den anden nøglebeslutning var at vedtage en minimal kodegennemgangsproces. Teamet pusher til main og udgiver ofte. Hvis noget går i stykker, løser de det hurtigt. Det lyder risikabelt, men det virker, fordi teamet er lille, erfarent og bruger produktet selv hele tiden. De opdager problemer hurtigt, fordi de selv bruger produktet. De kan løse problemer hurtigt, fordi kodebasen er frisk i deres erindring. De kan iterere hurtigt, fordi de ikke venter på godkendelse af kodegennemgange. Denne tilgang ville være farlig i en stor organisation med mange udviklere, men i et lille, erfarent team er det utroligt effektivt.
Den tredje nøglebeslutning var at bruge produktet intensivt selv. Teamet bruger AMP til at bygge AMP. Det skaber et tæt feedback-loop, hvor teamet straks oplever eventuelle problemer eller begrænsninger i produktet. Det betyder også, at teamet hele tiden opdager nye anvendelsesmuligheder og egenskaber. Når du bruger dit eget produkt til at bygge dit eget produkt, lærer du hurtigt, hvad der virker og ikke virker. Du opdager edge cases, som du ikke ville finde gennem traditionel test. Du opbygger intuition om, hvilke funktioner der betyder mest. Det er derfor, dogfooding er så stærkt for hurtig iteration.
Den fjerde nøglebeslutning var at holde kodebasen enkel og fleksibel. I stedet for at forsøge at bygge et komplekst, stærkt optimeret system, byggede teamet noget, der er let at ændre og udvide. Det betyder, at de hurtigt kan indarbejde nye muligheder. Når en ny model lanceres, kan de integrere den hurtigt. Når en ny teknik til prompt-engineering opstår, kan de eksperimentere hurtigt. Når de finder en bedre tilgang til et problem, kan de refaktorere hurtigt uden at bekymre sig om at bryde komplekse afhængigheder. Denne enkelhed og fleksibilitet er mere værd end optimering i et hurtigt udviklende marked.
Prisstrukturen for AMP afslører vigtige indsigter om værdiskabelse i AI-assisteret udvikling. Tidligt i udviklingsprocessen indså teamet, at de ikke kunne få et $20-abonnement til at fungere for en værktøjskaldende agent. Det var ikke bare et prisproblem; det var et signal om, at produktet var grundlæggende anderledes og krævede en anden forretningsmodel. En chatbaseret assistent som Cody kan køre effektivt på beskeden infrastruktur. En værktøjskaldende agent, der ræsonnerer om kode, eksekverer værktøjer og itererer autonomt, kræver markant mere regnekraft. Infrastrukturomkostningerne alene retfærdiggør højere priser.
Men prisstrukturen afspejler også værdiskabelsen. For en udvikler eller et team, der kan bruge AMP effektivt, er produktivitetsgevinsterne enorme. En agent, der autonomt kan implementere funktioner, skrive tests og refaktorere kode, kan spare time- eller dagsarbejde hver uge. For et team af udviklere er det betydelig værdi. Hvis AMP kan spare et team 10 timer om ugen, og udviklertid koster 100 dollars i timen, skaber AMP 1.000 dollars værdiskabelse om ugen. At opkræve hundredvis af dollars om måneden er en lille brøkdel af den værdi. Derfor har nogle teams årlige omsætninger på flere hundrede tusinde dollars – værdiskabelsen er så stærk, at prisen faktisk er et kup.
Forretningsmodellen afspejler også den strategiske positionering. Ved at opkræve betydeligt mere end traditionelle kodningsværktøjer signalerer AMP, at det er en anden produktkategori. Det konkurrerer ikke på pris, men på muligheder og værdi. Det tiltrækker kunder, der går op i muligheder og værdi, og frastøder kunder, der primært er prisfølsomme. Det er præcis den rette kundesegmentering for et produkt på AI-fronten. Du vil have kunder, der værdsætter frontmuligheder og er villige til at betale for dem. Du vil ikke have kunder, der primært leder efter det billigste, for de skifter til det næste billige alternativ, der dukker op.
En af de mest interessante aspekter ved Sourcegraphs tilgang er, hvordan de har håndteret spændingen mellem innovation og stabilitet. Sourcegraph har en succesfuld, profitabel forretning med Cody og den bredere Sourcegraph-platform. Denne forretning genererer omsætning, der finansierer de vilde eksperimenter med AMP. Men det skaber også organisatorisk spænding. Hvordan opretholder du en stabil, profitabel forretning og forfølger samtidig radikal innovation? Hvordan får du erfarne ingeniører til at fokusere på det nye produkt, når de har stor ekspertise i det eksisterende?
Svaret indebærer flere nøglebeslutninger. Først besluttede Sourcegraph eksplicit ikke at forsøge at konvertere eksisterende Cody-kunder til AMP. I stedet bruger de tilliden og indtægterne fra Cody til at finansiere AMP-udvikling. Det er en vigtig forskel. Hvis de forsøgte at migrere Cody-kunder til AMP, ville de møde modstand, fordi AMP er grundlæggende anderledes og kræver andre brugsmetoder. Ved at holde Cody og AMP adskilt kan de betjene forskellige kundesegmenter og undgå forstyrrelser, der ville opstå ved at migrere kunder mellem fundamentalt forskellige produkter.
For det andet har Sourcegraph samlet et team til AMP, der inkluderer folk uden forudfattede meninger om, hvordan man bygger software. Nogle af de mest effektive teammedlemmer er folk, der kun har arbejdet i små, enmandsfirmaer. De har ikke mange års erfaring med traditionelle softwareudviklingspraksisser. De har ikke indgroede vaner om kodegennemgange, planlægning og optimering. Denne mangel på bagage er faktisk en fordel. De kan adoptere praksisser, der ville virke radikale for en med traditionel erfaring, uden den kognitive dissonans, der følger med at opgive dybt forankrede overbevisninger.
For det tredje har Sourcegraph gjort reglerne for AMP eksplicit anderledes. Teamet følger ikke de samme processer som resten af virksomheden. De laver ikke formelle kodegennemgange. De tjekker ikke sikkerheds- og compliancebokse af. De følger ikke de samme planlægningscyklusser. Det er muligt, fordi de har kundernes tillid. Kunderne forstår, at AMP er et frontprodukt, og de er villige til at acceptere andre trade-offs. Denne eksplicitte adskillelse af regler og processer er afgørende. Hvis AMP skulle
AMP er en banebrydende kodeagent udviklet af Sourcegraph, der bruger avancerede sprogmodeller med værktøjskaldende evner til autonomt at ræsonnere og udføre kodeændringer. I modsætning til Cody, som var tæt integreret med Sourcegraph-platformen og bundet af dens udgivelsescyklusser, fungerer AMP uafhængigt med egen infrastruktur, hvilket muliggør over 15 udrulninger om dagen og hurtig iteration på nye modelmuligheder.
Sourcegraph skabte AMP som et separat produkt for at undgå at forstyrre eksisterende enterprise-kontrakter og kunders forventninger til Cody. Skiftet fra en chatbaseret assistent til en værktøjskaldende agent repræsenterer en grundlæggende ændring i, hvordan udviklere interagerer med AI. Ved at skabe et nyt brand og produkt kunne Sourcegraph nulstille forventninger, bevæge sig hurtigere uden arvemæssige begrænsninger og positionere sig i fronten af AI-udvikling uden at fremmedgøre eksisterende kunder.
Værktøjskaldende agenter er AI-systemer, der kombinerer en sprogmodel, systemprompter og eksterne værktøjer til at udføre autonome opgaver. I modsætning til traditionelle chatbots kan værktøjskaldende agenter interagere med filsystemer, kodeeditorer og andre eksterne systemer med eksplicitte tilladelser. Det gør dem i stand til at udføre komplekse, flertrins-workflows autonomt, hvilket gør dem grundlæggende mere kraftfulde til softwareudviklingsopgaver.
AMP vokser med over 50 % måned for måned, og nogle teams har en årlig omsætning på flere hundrede tusinde dollars. Produktet har opnået positive bruttomarginer, mens denne vækst opretholdes. Sourcegraph har strategisk fokuseret på udviklere, der ønsker at bevæge sig hurtigt og blive ved AI-fronten, frem for at forsøge at konvertere enhver udvikler i en virksomhed.
Diskussionen understreger, at asynkrone agenter, der kører døgnet rundt i baggrunden, vil dominere den næste fase af AI-udvikling. I stedet for interaktive agenter, der kører én ad gangen i en editor, vil teams køre 10-100 samtidige agenter autonomt, hvilket skaber en 10-100 gange forbedring i output og inferens. Nøglen til succes er at positionere sit produkt til at bevæge sig hurtigt og tilpasse sig, efterhånden som nye modeller og muligheder opstår hver få måneder.
Arshia er AI Workflow Engineer hos FlowHunt. Med en baggrund inden for datalogi og en passion for AI, specialiserer han sig i at skabe effektive workflows, der integrerer AI-værktøjer i daglige opgaver og øger produktivitet og kreativitet.
Oplev hvordan FlowHunt hjælper teams med at bygge, teste og implementere AI-drevne workflows hurtigere end nogensinde før.
Udforsk OpenAI's DevDay 2025-annonceringer, inklusiv Apps SDK, Agent Kit og Model Context Protocol. Lær hvorfor promptning er vigtigere end nogensinde for at by...
FlowHunt muliggør ubesværet AI-automatisering med en no-code platform, der giver brugerne mulighed for at skabe tilpassede værktøjer. Grundlagt af QualityUnit, ...
Opdag hvordan Ona (tidligere Gitpod) revolutionerer softwareudvikling med AI-kodeagenter, der opererer i fuldt konfigurerede, isolerede cloud-miljøer. Læs om ar...
Cookie Samtykke
Vi bruger cookies til at forbedre din browsingoplevelse og analysere vores trafik. See our privacy policy.
