Ontdek hoe AMP, de vooruitstrevende coding agent van Sourcegraph, het AI-ontwikkellandschap hervormt door snelle iteratie, autonoom redeneren en tool-calling agents te omarmen—en waarom traditionele ontwikkelaarstools verouderd raken.
Het landschap van AI-coding agents ondergaat ongekende disruptie. Wat zes maanden geleden nog baanbrekend was, wordt nu als verouderd beschouwd. GitHub Copilot, ooit de gouden standaard voor AI-ondersteunde ontwikkeling, is ingehaald door nieuwere tools. Cursor domineerde de markt als snelst groeiende startup aller tijden, maar kreeg al snel te maken met concurrentie van nóg geavanceerdere oplossingen. In dit snel veranderende ecosysteem nam Sourcegraph een gedurfde strategische beslissing: in plaats van hun bestaande Cody-product geleidelijk te verbeteren, lanceerden ze AMP—een compleet nieuwe coding agent, vanaf de basis opgebouwd om de grenzen van AI-mogelijkheden te verkennen.
Dit artikel verkent de filosofie, technische architectuur en bedrijfsstrategie achter AMP, met inzichten uit gesprekken met het team achter deze revolutionaire tool. We bekijken waarom traditionele productontwikkelingsmethoden falen in het tijdperk van snelle AI-vooruitgang, hoe tool-calling agents fundamenteel verschillen van eerdere AI-code-assistenten, en hoe de toekomst van autonoom ontwikkelen eruitziet. Belangrijker nog, we begrijpen waarom “de keizer geen kleren heeft”—waarom gevestigde producten met ogenschijnlijk onaantastbare marktposities bijna van de ene op de andere dag irrelevant kunnen worden als de onderliggende technologie verschuift.
{{ youtubevideo videoID=“b4rOVZWLW6E” provider=“youtube” title=“AMP: De keizer heeft geen kleren - Waarom AI-coding agents ontwikkelaarstools verstoren” class=“rounded-lg shadow-md” }}
De evolutie van AI-ondersteunde ontwikkeling heeft een duidelijke lijn gevolgd, waarbij elke generatie voortbouwde op de vorige maar de interactie van ontwikkelaars met kunstmatige intelligentie fundamenteel veranderde. Om het belang van AMP te begrijpen, moeten we eerst weten wat een coding agent onderscheidt van eerdere vormen van AI-assistentie. De reis begon met GitHub Copilot, dat code-aanvulling en suggestiemogelijkheden direct in de editors van ontwikkelaars bracht. Copilot was revolutionair omdat het AI op een niet-opdringerige manier in het ontwikkelproces integreerde en suggesties bood terwijl je typte. Toch was Copilot fundamenteel beperkt—het kon code suggereren, maar geen complexe, meerstaps taken uitvoeren of met de bredere ontwikkelomgeving interacteren.
De volgende generatie bracht tools als Cursor en Windsurf, die een andere benadering kozen door IDE-forks te maken waarin AI dieper werd geïntegreerd in de ontwikkelomgeving. Deze tools toonden aan dat deels agentische mogelijkheden—waarbij AI complexere operaties binnen de IDE kon uitvoeren—de productiviteit van ontwikkelaars aanzienlijk konden verhogen. Ze lieten zien dat ontwikkelaars bereid waren hun hele ontwikkelomgeving te verruilen als de AI-capaciteiten geavanceerd genoeg waren. Maar ook deze tools werkten binnen beperkingen: ze waren interactief, vereisten bij elke stap input en goedkeuring van de ontwikkelaar, en konden niet echt autonoom opereren.
Een coding agent daarentegen heeft een fundamenteel andere architectuur. Een agent bestaat uit drie kerncomponenten: een taalmodel (meestal een vooruitstrevend model als Claude 3.5), een systeem-prompt die het gedrag en de beperkingen van de agent bepaalt, en een set tools met bijbehorende prompts die beschrijven wat elke tool kan. Het belangrijkste verschil is dat agents met expliciete rechten kunnen interacteren met externe systemen—bestandsystemen, code-editors, versiebeheersystemen en meer. Dit betekent dat een agent autonoom kan redeneren over een probleem, beslissen welke tools te gebruiken, die tools uitvoeren, de resultaten observeren en itereren tot de taak voltooid is. Dit is fundamenteel krachtiger dan eerdere benaderingen, omdat het echt autonoom gedrag mogelijk maakt in plaats van alleen verbeterde suggesties of interactieve assistentie.
Het technologielandschap bevindt zich in een fase van ongekende instabiliteit. Wat achttien maanden geleden state-of-the-art was, wordt nu als primitief gezien. GitHub Copilot, uitgebracht in 2021, was echt revolutionair—het was de eerste grootschalige toepassing van grote taalmodellen op softwareontwikkeling. Toch wordt Copilot vandaag de dag door veel ontwikkelaars niet eens meer tot de topkeuzes voor AI-coding gerekend. Niet omdat Copilot slechter werd, maar omdat de onderliggende technologie zo snel vooruitging dat de hele categorie verschoof. Dit vormt een grote uitdaging voor gevestigde bedrijven: hoe behoud je een succesvol product als de basis voortdurend verschuift?
Traditionele productontwikkeling gaat uit van een relatief stabiele basis. Je vindt product-market fit, schaalt het product op, bouwt goede ontwikkelpraktijken, voegt enterprise-features toe, en sluit langetermijncontracten met klanten. Deze aanpak werkt al decennia omdat technologie meestal geleidelijk evolueert. Maar in het huidige AI-tijdperk is deze aanpak zelfs schadelijk. Optimaliseer je voor schaal en stabiliteit, dan word je traag. Word je traag, dan mis je de volgende golf van verbeteringen. Tegen de tijd dat je enterprise-mogelijkheden en beveiligingscompliance hebt toegevoegd, is er een nieuw model uitgebracht dat je hele aanpak overbodig maakt.
Sourcegraph stond precies voor dit dilemma met Cody. Cody was een succesvol product met zakelijke klanten, langlopende contracten en aanzienlijke omzet. Maar Cody was sterk geïntegreerd met het Sourcegraph-platform en dus gebonden aan diens releasecycli. Het platform had zijn eigen infrastructuur, eigen deployment-schema en eigen beperkingen. Toen Claude 3.5 Sonnet uitkwam en het team inzag dat ze iets fundamenteel anders konden bouwen—een tool-calling agent met autonome redeneercapaciteiten—stonden ze voor de keuze: deze mogelijkheden proberen in Cody te proppen, of opnieuw beginnen met een nieuw product. Ze kozen voor dat laatste, en deze keuze onthult een cruciaal inzicht over concurreren in snel veranderende markten.
De belangrijkste realisatie was dat een abonnementsmodel van $20 niet werkt voor een tool-calling agent. De rekencapaciteit die nodig is, is fundamenteel anders. Een chatgebaseerde assistent als Cody kan efficiënt draaien op bescheiden infrastructuur. Een tool-calling agent die redeneert over code, tools uitvoert en autonoom iteraties doet, vereist veel meer compute. Dit is niet alleen een prijspunt; het is een signaal dat het product fundamenteel anders is en een ander bedrijfsmodel, andere klantverwachtingen en een andere go-to-market strategie vereist. Door AMP als apart product met een apart merk te creëren, kon Sourcegraph deze verwachtingen volledig resetten. Ze konden klanten vertellen: “Dit is geen Cody 2.0. Dit is iets compleet anders. Het kost meer omdat het meer kan. Het werkt anders omdat het op een andere architectuur is gebouwd.”
Om echt te waarderen waarom AMP een paradigmaverschuiving is, moeten we de technische architectuur van tool-calling agents in detail begrijpen. Een tool-calling agent is niet simpelweg een taalmodel met toegang tot functies. De architectuur is geavanceerder en krachtiger. Het systeem begint met een vooruitstrevend taalmodel—in het geval van AMP: Claude 3.5 Sonnet—dat getraind is om effectief met tools om te gaan. Het model krijgt een systeem-prompt die de rol, beperkingen en doelen definieert. Cruciaal is dat de systeem-prompt geen vrijblijvende instructie is; het is een zorgvuldig samengestelde prompt die bepaalt hoe het model redeneert over problemen en beslist welke tools te gebruiken.
Naast de systeem-prompt heeft elke tool een eigen prompt die beschrijft wat de tool doet, welke parameters het accepteert, wat het teruggeeft en wanneer het moet worden gebruikt. Dit is essentieel omdat het taalmodel niet alleen moet weten dat een tool bestaat, maar ook waarvoor en wanneer die geschikt is. Een agent kan bijvoorbeeld tools hebben voor bestanden lezen, schrijven, code uitvoeren, tests draaien en wijzigingen committen. Elke tool heeft een gedetailleerde beschrijving die het model helpt te redeneren welke tool in welke situatie gebruikt moet worden. Het model kan vervolgens autonoom besluiten deze tools te gebruiken, de resultaten observeren en itereren op basis van wat het leert.
De kracht van deze architectuur wordt duidelijk als je bedenkt wat een agent kan doen. Een ontwikkelaar kan een agent vragen een nieuwe feature te implementeren die gebruikersauthenticatie toevoegt aan een codebase. De agent kan dan autonoom: de bestaande codebase lezen om de architectuur te begrijpen, identificeren waar authenticatie geïntegreerd moet worden, de benodigde code schrijven, tests draaien om de implementatie te verifiëren, bij fouten de code aanpassen, en uiteindelijk de wijzigingen committen. Dit alles gebeurt zonder menselijke tussenkomst. De agent redeneert over het probleem, beslist welke tools te gebruiken en herhaalt op basis van feedback van die tools.
Dit is fundamenteel anders dan eerdere AI-coding tools. Copilot kan code suggereren, maar geen meerstaps-workflow uitvoeren. Cursor kan complexere operaties doen, maar vereist bij elke stap menselijke goedkeuring. Een agent kan autonoom opereren met expliciete rechten. Dit creëert een nieuwe categorie aan mogelijkheden die vele malen krachtiger is. Maar het brengt ook nieuwe uitdagingen met zich mee. Autonome agents kunnen op schaal fouten maken. Ze kunnen schadelijke bewerkingen uitvoeren als ze niet goed begrensd zijn. Ze vereisen zorgvuldige systeem-prompt engineering om het gewenste gedrag te waarborgen. Dit zijn de uitdagingen die de architectuur en aanpak van AMP zo belangrijk maken.
Toen het AMP-team begon met bouwen, maakten ze een fundamentele keuze: snelheid en iteratie zouden het primaire optimalisatiedoel zijn. Alles zou voortvloeien uit deze beslissing. Dit betekende het loslaten van veel praktijken die Sourcegraph met Cody succesvol hadden gemaakt. Geen formele code-reviews. Geen uitgebreide planningsrondes. Geen security- en compliancechecks die negen maanden duren. In plaats daarvan hanteerde het team een mentaliteit van een persoonlijk project: direct naar main pushen, 15 keer per dag releasen, het product continu zelf gebruiken, en itereren op basis van daadwerkelijk gebruik.
Deze aanpak klinkt chaotisch, en volgens traditionele softwarestandaarden is dat ook zo. Maar het is precies de juiste aanpak voor een product aan het front van AI-capaciteiten. De reden is simpel: het front beweegt. Elke paar maanden verschijnt er een nieuw model. Elke paar weken ontstaan nieuwe mogelijkheden. Elke paar dagen worden nieuwe technieken voor prompt engineering of tooldesign ontdekt. In deze omgeving is het vermogen om snel te itereren waardevoller dan het vermogen om betrouwbaar te schalen. Een product dat 15 keer per dag shipt, kan nieuwe modelmogelijkheden binnen enkele uren integreren. Een product met traditionele releasecycli loopt maanden achter.
De teamstructuur weerspiegelt deze filosofie. Het kernteam van AMP is klein—ongeveer acht mensen—vergeleken met grotere engineeringorganisaties. Deze kleine omvang is bewust gekozen. Het maakt snelle besluitvorming mogelijk en elimineert de communicatie-overhead die grotere teams vertraagt. Iedereen in het team is ervaren en kan daarom werken zonder uitgebreide code-reviews. Ze gebruiken het product zelf continu, waardoor ze snel problemen signaleren en gebruikersbehoeften goed begrijpen. Ze proberen niet een product te bouwen voor iedere ontwikkelaar; ze bouwen een product voor ontwikkelaars die net zo snel willen bewegen als zijzelf, die aan het front van AI-capaciteiten willen blijven, en die nieuwe ontwikkelmethodes willen omarmen.
Deze positionering is cruciaal. AMP probeert niet GitHub Copilot voor iedereen te zijn. Het probeert niet de standaard AI-coding tool voor alle ontwikkelaars te zijn. In plaats daarvan positioneert het zich als de tool voor ontwikkelaars en teams die snel willen schakelen en aan het front willen blijven. Dit is een veel kleinere markt dan “alle ontwikkelaars”, maar het is een markt die bereid is aanzienlijk meer te betalen voor superieure mogelijkheden. Het businessmodel weerspiegelt dit: in plaats van een abonnement van $20 per maand betalen AMP-klanten honderden dollars per maand. Sommige teams hebben een jaaromzet van honderdduizenden dollars. Dit is mogelijk omdat de waardepropositie voor de doelgroep zo sterk is.
De principes die AMP’s ontwikkeling sturen—snelle iteratie, frontier-positionering en autonoom redeneren—zijn direct toepasbaar op bredere workflow-automatisering. FlowHunt, als platform voor het bouwen en automatiseren van complexe workflows, staat voor soortgelijke uitdagingen en kansen. Net zoals AMP zich positioneert voor de volgende generatie AI-mogelijkheden, helpt FlowHunt organisaties workflows te bouwen die bestand zijn tegen snelle technologische veranderingen. Door de focus op flexibiliteit, snelle iteratie en de mogelijkheid om snel nieuwe tools en mogelijkheden te integreren, stelt FlowHunt teams in staat om voorop te blijven lopen.
Het belangrijkste inzicht is dat in een snel evoluerend technologisch landschap het vermogen om snel aan te passen waardevoller is dan optimaliseren voor de huidige situatie. Dit geldt of je nu een AI-coding agent bouwt of bedrijfsprocessen automatiseert. De aanpak van FlowHunt—het mogelijk maken van snelle workflowcreatie, testen en iteratie—sluit hier perfect op aan. Teams kunnen workflows bouwen die de nieuwste AI-mogelijkheden benutten, ze snel testen en itereren op basis van resultaten. Naarmate nieuwe modellen en tools opkomen, kunnen workflows snel geüpdatet worden zonder ingrijpende herbouw. Dit is de toekomst van automatisering: geen statische, geoptimaliseerde processen, maar dynamische, adaptieve workflows die mee-evolueren met de technologie.
De markt voor AI-coding agents is een fascinerende casus over hoe snel marktleiderschap kan verschuiven. Begin 2024 werd Cursor algemeen beschouwd als de koning van AI-coding tools. Het was de snelst groeiende startup ooit. Ontwikkelaars stapten massaal over van andere tools naar Cursor. De markt leek stabiel. Maar binnen een paar maanden veranderde het gesprek. Nieuwe tools verschenen. Mogelijkheden verbeterden. Ontwikkelaars stelden andere vragen. Midden 2024, als je ontwikkelaars vroeg wat zij de beste AI-coding tool vonden, noemde lang niet iedereen Cursor meer als eerste. De markt was zo snel verschoven dat de vorige leider niet langer dominant was.
Dit patroon is niet uniek voor coding agents. Het is een fundamenteel kenmerk van markten waar de onderliggende technologie snel voortschrijdt. In zulke markten is het vermogen om snel te bewegen en aan te passen belangrijker dan huidig marktaandeel. Een bedrijf met 30% marktaandeel dat snel innoveert en nieuwe mogelijkheden integreert, zal uiteindelijk een bedrijf met 50% marktaandeel dat langzaam beweegt inhalen. Daarom was Sourcegraphs keuze om AMP als apart product te lanceren strategisch zo sterk. Door AMP los te koppelen van Cody, bevrijdden ze zichzelf van de beperkingen die hen zouden vertragen. Ze konden snel bewegen, snel itereren en zich aan het front positioneren.
De bredere les is dat in snel evoluerende markten de keizer vaak geen kleren heeft. Gevestigde producten die dominant lijken, kunnen verrassend snel verouderen. Niet omdat ze slechter worden, maar omdat de technologie verschuift en ze zich niet snel genoeg kunnen aanpassen. De bedrijven die slagen, zijn degenen die deze dynamiek begrijpen en zich ernaar positioneren. Ze proberen niet te optimaliseren voor de huidige situatie, maar voor het vermogen om zich aan te passen aan toekomstige omstandigheden. Ze bedienen niet iedere klant, maar richten zich op klanten die snelheid en innovatie waarderen. Ze volgen geen traditionele productontwikkelpraktijken, maar omarmen methodes die snelle iteratie en leren mogelijk maken.
Het gesprek over AMP onthult een belangrijk inzicht over de toekomst van AI-agents: de volgende grote verschuiving zal die zijn van interactieve agents naar asynchrone agents. Op dit moment werken de meeste AI-coding agents interactief. Een ontwikkelaar start een agent in de editor of CLI, de agent voert operaties uit, en de ontwikkelaar ziet het resultaat. Meestal draait er één agent tegelijk, en deze werkt synchroon—de ontwikkelaar wacht op de uitkomst. Dit is een aanzienlijke vooruitgang ten opzichte van handmatig coderen, maar niet de ultieme vorm van agentgebaseerde ontwikkeling.
Het volgende front zijn asynchrone agents die 24/7 op de achtergrond draaien, gelijktijdig. In plaats van één agent tegelijk, heb je straks 10, 50 of 100 agents die simultaan aan verschillende taken werken. Een agent kan code refactoren in het ene deel van de codebase, terwijl een andere tests schrijft voor een andere component. Een derde analyseert performance-issues en doet optimalisatievoorstellen. Dit alles gebeurt zonder menselijke tussenkomst, en alles tegelijk. De implicaties zijn enorm: een 10x tot 100x verbetering in de hoeveelheid werk die verzet kan worden, een fundamentele verschuiving in hoe ontwikkelteams opereren, en een complete herziening van wat mogelijk is met AI-ondersteunde ontwikkeling.
Deze verschuiving zal grote gevolgen hebben voor inferentiekosten, voor de organisatie van teams, en voor wat het betekent om ontwikkelaar te zijn. Ook ontstaan er nieuwe uitdagingen rond kwaliteitsbewaking, beveiliging en het voorkomen dat autonome agents op grote schaal bugs of kwetsbaarheden introduceren. Maar de potentiële voordelen zijn enorm. Teams die asynchrone agents effectief weten in te zetten, kunnen in dagen bereiken wat nu weken duurt. Daarom is het zo cruciaal om jezelf te positioneren voor snelheid en aanpassingsvermogen. Bedrijven die als eerste effectieve async agents weten te bouwen, krijgen een enorme voorsprong.
Het fundamentele principe achter de aanpak van AMP is bouwen voor onzekerheid. Het team weet niet precies waar de technologie heen gaat, maar weet dát het zal veranderen. Ze weten niet welke mogelijkheden het belangrijkst worden, maar wél dat er nieuwe bij zullen komen. Ze weten niet hoe de markt er over zes maanden uitziet, maar weten zeker dat die anders zal zijn. Gegeven deze onzekerheid is het rationeel om te optimaliseren voor aanpasbaarheid in plaats van voor optimalisatie. Dit betekent de codebase flexibel houden, het vermogen om snel te releasen behouden, dicht bij het front van AI-mogelijkheden blijven, en bereid zijn om oude aanpakken los te laten als ze niet meer werken.
Dit principe geldt voor teamstructuur, businessmodel en klantstrategie. Het team is klein en ervaren, waardoor snelle besluitvorming mogelijk is. Het businessmodel is flexibel, zonder vaste prijs of usermodel, zodat er snel geschakeld kan worden als de markt verandert. De klantstrategie richt zich op ontwikkelaars die snel willen bewegen, waardoor er een natuurlijke aansluiting is tussen wat het bedrijf kan en wat de klant zoekt. Alles vloeit voort uit het principe van bouwen voor onzekerheid en optimaliseren voor aanpasbaarheid.
Dit is een radicaal andere benadering dan traditionele productontwikkeling, waarbij je de toekomst probeert te voorspellen, voor schaal bouwt en optimaliseert voor stabiliteit. Maar in een markt waar de onderliggende technologie snel voortschrijdt, zijn traditionele benaderingen zelfs schadelijk. Ze vertragen je, zetten je vast in keuzes die snel verouderen, en verhinderen aanpassing aan nieuwe realiteiten. De bedrijven die slagen in zulke markten zijn degenen die onzekerheid omarmen, optimaliseren voor aanpasbaarheid en snel genoeg bewegen om voorop te blijven.
{{ cta-dark-panel heading=“Boost je workflow met FlowHunt” description=“Ervaar hoe FlowHunt je AI-content- en SEO-workflows automatiseert — van onderzoek en contentgeneratie tot publicatie en analyse — allemaal op één plek.” ctaPrimaryText=“Boek een demo” ctaPrimaryURL=“https://calendly.com/liveagentsession/flowhunt-chatbot-demo" ctaSecondaryText=“Probeer FlowHunt gratis” ctaSecondaryURL=“https://app.flowhunt.io/sign-in" gradientStartColor="#123456” gradientEndColor="#654321” gradientId=“827591b1-ce8c-4110-b064-7cb85a0b1217” }}
De mogelijkheid om 15 keer per dag te releasen is geen toeval; het is het resultaat van bewuste architecturale keuzes. De eerste belangrijke beslissing was om AMP volledig los te koppelen van het Sourcegraph-platform. Cody was sterk geïntegreerd met Sourcegraph, en dus gebonden aan diens releasecycli en infrastructuurbeperkingen. AMP werd gebouwd als een zelfstandig product, met eigen infrastructuur, eigen deployment-pipeline en eigen releaseschema. Deze decoupling is cruciaal omdat het de coördinatie-overhead elimineert die grote systemen vertraagt. Wijzigingen aan AMP vereisen geen afstemming met platformwijzigingen. Deployments hoeven niet te wachten op platformreleases.
De tweede belangrijke keuze was het aannemen van een minimaal code-reviewproces. Het team pusht naar main en shipt frequent. Als er iets stuk gaat, wordt het snel opgelost. Dit klinkt risicovol, maar werkt omdat het team klein, ervaren en het product voortdurend zelf gebruikt. Ze signaleren problemen snel door eigen gebruik. Ze kunnen snel oplossen omdat de codebase vers in het geheugen zit. Ze kunnen snel itereren omdat ze niet hoeven te wachten op goedkeuringen voor code-reviews. In een grote organisatie met veel ontwikkelaars zou dit gevaarlijk zijn, maar bij een klein, ervaren team werkt het zeer effectief.
De derde belangrijke beslissing was om het product agressief zelf te gebruiken (dogfooding). Het team gebruikt AMP om AMP te bouwen. Dit creëert een snelle feedbackloop waarin het team direct eventuele problemen of beperkingen ondervindt. Ook ontdekken ze voortdurend nieuwe use-cases en mogelijkheden. Door je eigen product te gebruiken om je eigen product te bouwen, leer je snel wat werkt en wat niet. Je ontdekt edge-cases die je met traditionele tests niet zou vinden. Je ontwikkelt gevoel voor welke features het belangrijkst zijn. Daarom is dogfooding zo krachtig voor snelle iteratie.
De vierde keuze was om de codebase simpel en flexibel te houden. In plaats van een complex, sterk geoptimaliseerd systeem te bouwen, koos het team voor iets dat makkelijk aan te passen en uit te breiden is. Zo kunnen nieuwe mogelijkheden snel worden geïntegreerd. Komt er een nieuw model uit, dan kan dat snel worden ingebouwd. Verschijnt er een nieuwe techniek voor prompt engineering, dan kan die snel worden getest. Wordt er een betere aanpak gevonden, dan kan er snel worden gerefactord zonder zorgen over complexe afhankelijkheden. Deze eenvoud en flexibiliteit zijn meer waard dan optimalisatie in een snel veranderende markt.
Het prijsmodel voor AMP onthult belangrijke inzichten over waardecreatie in AI-ondersteunde ontwikkeling. Al vroeg in het ontwikkelproces realiseerde het team zich dat een abonnement van $20 per maand niet werkt voor een tool-calling agent. Dit was niet alleen een prijsprobleem; het signaleerde dat het product fundamenteel anders was en een ander businessmodel vereiste. Een chatgebaseerde assistent als Cody kan efficiënt draaien op bescheiden infrastructuur. Een tool-calling agent die redeneert over code, tools uitvoert en autonoom iteraties doet, vereist veel meer computing power. Alleen al de infrastructuurkosten rechtvaardigen hogere prijzen.
Maar het prijsmodel weerspiegelt ook de waardepropositie. Voor een ontwikkelaar of team dat AMP effectief gebruikt, zijn de productiviteitswinsten enorm. Een agent die autonoom features kan implementeren, tests kan schrijven en code kan refactoren, bespaart uren of zelfs dagen werk per week. Voor een team vertaalt dit zich naar aanzienlijke waarde. Als AMP een team 10 uur per week bespaart, en de ontwikkelaarstijd kost $100 per uur, dan levert AMP $1.000 per week aan waarde. Honderden dollars per maand vragen is dan slechts een fractie daarvan. Daarom werken sommige teams met jaaromzetten van honderdduizenden dollars—de waardepropositie is zo sterk dat de prijs eigenlijk een koopje is.
Het businessmodel weerspiegelt ook de strategische positionering. Door aanzienlijk meer te vragen dan traditionele coding tools, geeft AMP aan dat het een andere productcategorie is. Het concurreert niet op prijs, maar op capaciteiten en waarde. Dit trekt klanten aan die waarde hechten aan mogelijkheden en waarde, en stoot prijsgevoelige klanten juist af. Dit is precies de juiste klantsegmentatie voor een product aan het front van AI-capaciteiten. Je wilt klanten die de meerwaarde van frontier-mogelijkheden begrijpen en bereid zijn daarvoor te betalen. Je wilt geen klanten die vooral de goedkoopste optie zoeken, want die stappen snel over op de volgende goedkope tool.
Een van de meest interessante aspecten van de aanpak van Sourcegraph is hoe ze de spanning tussen innovatie en stabiliteit managen. Sourcegraph heeft met Cody en het bredere platform een succesvol, winstgevend bedrijf. Dit bedrijf genereert inkomsten waarmee de wilde experimenten met AMP worden gefinancierd. Maar dit creëert ook organisatorische spanning. Hoe houd je een stabiel, winstgevend bedrijf in stand terwijl je tegelijkertijd radicale innovatie nastreeft? Hoe houd je ervaren engineers gefocust op het nieuwe product als ze diepgaande expertise in het bestaande product hebben?
Het antwoord zit in een aantal beslissingen. Allereerst besloot Sourcegraph expliciet om bestaande Cody-klanten niet naar AMP te migreren. In plaats daarvan worden het vertrouwen en de omzet uit Cody gebruikt om AMP te financieren. Dit is essentieel: als ze Cody-klanten naar AMP probeerden te migreren, zouden ze op weerstand stuiten omdat AMP fundamenteel anders is en andere gebruikspatronen vereist. Door Cody en AMP gescheiden te houden, kunnen ze verschillende klantsegmenten bedienen en de disruptie vermijden die zou ontstaan bij migratie tussen fundamenteel verschillende producten.
Ten tweede stelde Sourcegraph een team samen voor AMP met mensen zonder vooropgezette ideeën over softwareontwikkeling. Sommige van de meest effectieve teamleden hebben alleen bij kleine, eenmansbedrijven gewerkt. Ze hebben geen jarenlange ervaring met traditionele softwarepraktijken. Ze hebben geen diepgewortelde gewoonten rond code reviews, planningscycli en optimalisatie. Dit gebrek aan bagage is juist een voordeel. Ze kunnen praktijken overnemen die voor iemand met traditionele software-ervaring radicaal lijken, zonder de cognitieve dissonantie van het loslaten van diepgewortelde overtuigingen.
Ten derde is Sourcegraph expliciet over de andere regels voor AMP. Het team volgt niet dezelfde processen als de rest van het bedrijf. Geen formele code-reviews. Geen security- of compliancechecks. Geen identieke planningscycli. Dit kan omdat ze klantvertrouwen hebben. Klanten begrijpen dat AMP een frontier-product is en accepteren andere afwegingen. Deze expliciete scheiding van regels en processen is cruciaal. Als AMP de processen van de rest van Sourcegraph moest volgen, zou het traag worden. Door de regels expliciet te scheiden, creëert Sourcegraph ruimte voor radicale innovatie.
Het verhaal van AMP biedt belangrijke lessen voor organisaties in snel veranderende markten. De eerste les is dat bestaand succes een handicap kan worden. Het succes met Cody en het platform had Sourcegraph kunnen vastzetten in een trage, incrementele aanpak. In plaats daarvan herkenden ze de technologische verschuiving en namen ze de moedige beslissing om opnieuw te beginnen. Dit vroeg om het lef om het eigen bedrijf te kannibaliseren, het inzicht dat de oude aanpak niet zou werken met de nieuwe technologie, en de moed om een radicaal andere strategie te volgen.
De tweede les is dat snelheid en aanpasbaarheid waardevoller zijn dan optimalisatie en schaal in snel veranderende markten. Het team probeert geen perfect geoptimaliseerd systeem te bouwen. Ze bouwen iets dat goed genoeg is en snel kan worden verbeterd. Ze proberen niet iedere klant te bedienen. Ze richten zich op klanten die snelheid en innovatie waarderen. Ze volgen geen traditionele processen. Ze adopteren processen die snelle iteratie mogelijk maken. Deze focus op aanpasbaarheid boven optimalisatie is voor veel organisaties contra-intuïtief, maar juist in snel bewegende technologie het beste.
De derde les is dat kleine, ervaren teams kunnen presteren boven grote organisaties. Het AMP-team bestaat uit ongeveer acht mensen. Allen zijn ervaren engineers. Ze werken zonder formele code-reviews of uitgebreide planningen. Ze shippen 15 keer per dag. Ze gebruiken het product continu zelf. Dit kleine team kan sneller bewegen en effectiever innoveren dan veel grotere teams elders. Dit komt doordat ze de communicatie- en proces-overhead van grotere teams hebben geëlimineerd. Ze hebben een omgeving gecreëerd waarin snelle iteratie mogelijk is.
De vierde les is dat je verwachtingen moet resetten als het product fundamenteel verandert. Cody-klanten hadden verwachtingen over prijs, functies en werkwijze. Die verwachtingen zouden niet overgezet kunnen worden naar AMP. Door AMP als apart product en merk te lanceren, kon Sourcegraph verwachtingen volledig resetten. Dit is een krachtige strategie als je product fundamenteel anders is dan wat eraan voorafging. In plaats van nieuwe mogelijkheden in een oud product te proppen, creëer je een nieuw product en reset je de verwachtingen.
De markt voor AI-coding agents wordt gekenmerkt door snelle veranderingen en verschuivend leiderschap. Op elk moment is er een “beste” tool, maar die leidende positie is instabiel. Copilot was een tijdlang duidelijk leider. Cursor werd leider. Nu zijn er meerdere sterke concurrenten en is de leiding omstreden. Deze instabiliteit wordt gedreven door snelle vooruitgang in onderliggende modellen en technieken. Toen Claude 3.5 Sonnet werd uitgebracht, maakte dat mogelijkheden mogelijk die voorheen niet bestonden. Wanneer nieuwe prompt engineering-technieken worden ontdekt, kunnen die snel in producten worden verwerkt. Als er nieuwe modellen komen, verschuift het concurrentielandschap.
In deze omgeving slagen bedrijven die snel kunnen bewegen en zich snel aanpassen. Een bedrijf dat is geoptimaliseerd voor stabiliteit en schaal, zal traag zijn in het opnemen van nieuwe mogelijkheden. Een bedrijf dat is geoptimaliseerd voor snelheid en iteratie, kan die snel integreren. Op termijn zal het snelle bedrijf voorop lopen. Daarom is AMP’s focus op snelheid en iteratie zo strategisch belangrijk. Door te optimaliseren voor snelheid, positioneert AMP zich om steeds voorop te blijven als de technologie verder evolueert.
De markt wordt ook steeds specialistischer. In plaats van te proberen de beste tool voor iedere ontwikkelaar te zijn, focussen succesvolle producten zich op specifieke segmenten. AMP richt zich op ontwikkelaars die snel willen schakelen en aan het front willen blijven. Andere producten kiezen voor enterprise-klanten die stabiliteit en support waarderen. Weer andere richten zich op beginners die begeleiding en educatie zoeken. Deze specialisatie is gezond voor de markt, omdat producten zo kunnen optimaliseren voor hun doelgroep en niet alles voor iedereen hoeven te zijn.
Het verhaal van AMP onthult fundamentele waarheden over concurreren in snel veranderende markten. Gevestigde producten met ogenschijnlijk onaantastbare marktposities kunnen verbazingwekkend snel verouderen als de onderliggende technologie verschuift. Bedrijven die optimaliseren voor stabiliteit en schaal worden traag en kwetsbaar. Bedrijven die optimaliseren voor snelheid en aanpasbaarheid kunnen snel genoeg bewegen om voorop te blijven. De keizer heeft vaak geen kleren—het dominante product van vandaag kan morgen irrelevant zijn als het zich niet aanpast aan technologische verandering. De keuze van Sourcegraph om AMP als apart product te lanceren, radicale praktijken te omarmen zoals zonder code-reviews naar main pushen, te focussen op snelheid en iteratie in plaats van optimalisatie en schaal, en het product aan het front van AI-mogelijkheden te positioneren, toont een diep begrip van hoe je in zulke markten moet concurreren. De lessen van AMP reiken verder dan coding agents. Elke organisatie in een markt waar technologie snel vooruitgaat, zou zich moeten afvragen of ze wel voor de juiste zaken optimaliseren. Optimaliseer je voor stabiliteit, terwijl je voor aanpasbaarheid zou moeten kiezen? Probeer je alle klanten te bedienen, terwijl je je op een specifiek segment zou moeten richten? Volg je traditionele processen, terwijl je eigenlijk praktijken zou moeten aannemen die snelle iteratie mogelijk maken? De antwoorden op deze vragen bepalen of jouw organisatie floreert of veroudert in het licht van technologische verandering.
AMP is een vooruitstrevende coding agent ontwikkeld door Sourcegraph die geavanceerde taalmodellen gebruikt met tool-calling mogelijkheden om autonoom te redeneren en codewijzigingen uit te voeren. In tegenstelling tot Cody, dat sterk geïntegreerd was met het Sourcegraph-platform en gebonden was aan diens releasecycli, werkt AMP onafhankelijk met een eigen infrastructuur, waardoor meer dan 15 deploys per dag mogelijk zijn en er snel op nieuwe modelmogelijkheden kan worden ingespeeld.
Sourcegraph heeft AMP als apart product ontwikkeld om bestaande enterprise-contracten en klantverwachtingen rond Cody niet te verstoren. De verschuiving van een chat-assistent naar een tool-calling agent is fundamenteel in hoe ontwikkelaars met AI omgaan. Door een nieuw merk en product te creëren, kon Sourcegraph verwachtingen resetten, sneller bewegen zonder legacy-beperkingen, en zichzelf aan het front van AI-ontwikkeling positioneren zonder bestaande klanten te vervreemden.
Tool-calling agents zijn AI-systemen die een taalmodel, systeem-prompts en externe tools combineren om autonome taken uit te voeren. In tegenstelling tot traditionele chatbots kunnen tool-calling agents met besturingssystemen, code-editors en andere externe systemen communiceren met expliciete toestemming. Dit stelt hen in staat om complexe, meerstapsworkflows zelfstandig uit te voeren, wat ze fundamenteel krachtiger maakt voor softwareontwikkelingstaken.
AMP groeit met meer dan 50% per maand, met sommige teams die een jaarlijkse omzet van honderdduizenden dollars halen. Het product heeft positieve brutomarges bereikt terwijl dit groeitempo werd behouden. Sourcegraph richt zich strategisch op ontwikkelaars die snel willen schakelen en aan het front van modellen willen blijven, in plaats van te proberen iedere ontwikkelaar binnen een organisatie te converteren.
De discussie benadrukt dat asynchrone agents die 24/7 op de achtergrond draaien het volgende tijdperk van AI-ontwikkeling zullen domineren. In plaats van interactieve agents die één voor één in een editor draaien, zullen teams 10-100 agents tegelijk autonoom inzetten, wat zorgt voor een 10-100x verbetering in output en inferentie. De sleutel tot succes is je product zo te positioneren dat je snel kunt bewegen en je kunt aanpassen naarmate er elke paar maanden nieuwe modellen en mogelijkheden verschijnen.
Arshia is een AI Workflow Engineer bij FlowHunt. Met een achtergrond in computerwetenschappen en een passie voor AI, specialiseert zij zich in het creëren van efficiënte workflows die AI-tools integreren in dagelijkse taken, waardoor productiviteit en creativiteit worden verhoogd.
Ervaar hoe FlowHunt teams helpt om AI-gedreven workflows sneller dan ooit te bouwen, testen en uitrollen.
Ontdek hoe Ona (voorheen Gitpod) de softwareontwikkeling revolutioneert met AI-coding agents die opereren in volledig geconfigureerde, gesandboxte cloudomgeving...
Ontdek de aankondigingen van OpenAI's DevDay 2025, waaronder de Apps SDK, Agent Kit en Model Context Protocol. Leer waarom prompten belangrijker is dan ooit bij...
Ontdek OpenAI's sprong naar AI-hardware via de overname van Jony Ive's io voor $6,5 miljard, waarmee het toneel wordt gezet voor innovatieve, schermloze generat...
Cookie Toestemming
We gebruiken cookies om uw browse-ervaring te verbeteren en ons verkeer te analyseren. See our privacy policy.
