Dit was zo leuk, Mario. Bedankt dat je me in de show hebt gehad om over alles wat er in de markt gebeurt te praten!

OpenAI ontvangt gemiddeld 1 zoekopdracht per Amerikaan per dag. Google ontvangt ongeveer 4 zoekopdrachten per Amerikaan per dag. Aangezien 50% van de Google-zoekopdrachten AI-overzichten heeft, betekent dit dat minstens 60% van de Amerikaanse zoekopdrachten nu AI is. Het heeft iets langer geduurd dan ik had verwacht voordat dit gebeurde. In 2024 voorspelde ik dat 50% van de consumentenzoekopdrachten AI-ondersteund zou zijn. ( Maar AI is aangekomen in de zoekresultaten. Als de zoekpatronen van Google enige indicatie zijn, is er een machtswet in zoekgedrag. De analyse van SparkToro van het zoekgedrag op Google toont aan dat de bovenste derde van de Amerikanen die zoeken, goed voor meer dan 80% van alle zoekopdrachten is - wat betekent dat het gebruik van AI waarschijnlijk niet gelijkmatig verdeeld is - zoals de toekomst. Websites en bedrijven beginnen de gevolgen hiervan te voelen. Het stuk van The Economist "AI doodt het web. Kan iets het redden?" vangt de geest van deze tijd in een kop. ( Een supermeerderheid van de Amerikanen zoekt nu met AI. De tweede orde effecten van veranderende zoekpatronen komen in de tweede helft van dit jaar en meer mensen zullen zich afvragen: "Wat is er met mijn verkeer gebeurd?" ( AI is een nieuw distributiekanaal en degenen die het grijpen, zullen marktaandeel winnen. - William Gibson keek veel verder de toekomst in! - Dit is gebaseerd op een middelpuntanalyse van de SparkToro-grafiek, is een zeer eenvoudige analyse en heeft daardoor enige foutmarge.

Bij het werken met AI stop ik voordat ik iets in het vak typ om mezelf een vraag te stellen: wat verwacht ik van de AI? 2x2 om te helpen! In welk vak ben ik? Op de ene as, hoeveel context ik geef: niet veel tot behoorlijk wat. Op de andere, of ik de AI moet observeren of het gewoon moet laten draaien. Als ik heel weinig informatie geef en het systeem laat draaien: ‘onderzoek trends van Forward Deployed Engineers,’ krijg ik oppervlakkige resultaten: brede overzichten zonder relevante details. Het uitvoeren van hetzelfde project met een reeks korte vragen produceert een iteratief gesprek dat succesvol is - een Verkenning. “Welke bedrijven hebben Forward Deployed Engineers (FDEs) geïmplementeerd? Wat zijn de typische achtergronden van FDEs? Welke soorten contractstructuren en bedrijven lenen zich voor dit werk?” Wanneer ik een zeer lage tolerantie voor fouten heb, geef ik uitgebreide context en werk ik iteratief met de AI. Voor blogposts of financiële analyses deel ik alles (huidige concepten, eerdere schrijfsels, gedetailleerde vereisten) en ga dan zin voor zin verder. Een agent vrij laten draaien vereist dat alles van tevoren wordt gedefinieerd. Ik slaag hier zelden in omdat het voorbereidende werk enorme duidelijkheid vereist - exacte doelen, uitgebreide informatie en gedetailleerde takenlijsten met validatiecriteria - een schets. Deze prompts lijken op de productvereisten documenten die ik schreef als productmanager. Het antwoord op ‘wat verwacht ik?’ zal gemakkelijker worden naarmate AI-systemen meer van mijn informatie kunnen benaderen en beter worden in het selecteren van relevante gegevens. Naarmate ik beter word in het verwoorden van wat ik eigenlijk wil, verbetert de samenwerking. Ik streef ernaar om veel meer van mijn vragen uit de linkerbovenhoek - hoe ik getraind ben met Google-zoekopdrachten - naar de andere drie kwadranten te verplaatsen. Ik verwacht ook dat deze gewoonte me zal helpen beter met mensen samen te werken.

Die kleine zwarte doos in het midden is machine learning code. Ik herinner me dat ik het paper van Google uit 2015 over Hidden Technical Debt in ML las en dacht hoe weinig van een machine learning toepassing daadwerkelijk machine learning was. De overgrote meerderheid was infrastructuur, databeheer en operationele complexiteit. Met de opkomst van AI leek het erop dat grote taalmodellen deze dozen zouden overnemen. De belofte was eenvoud: plaats een LLM en kijk hoe het alles van klantenservice tot codegeneratie afhandelt. Geen complexe pijplijnen of kwetsbare integraties meer. Maar bij het bouwen van interne applicaties hebben we een vergelijkbare dynamiek met AI waargenomen. Agenten hebben veel context nodig, zoals een mens: hoe is de CRM gestructureerd, wat vullen we in elk veld in - maar input is duur voor het Hongerige, Hongerige AI-model. Kosten verlagen betekent deterministische software schrijven om het redeneren van AI te vervangen. Bijvoorbeeld, het automatiseren van e-mailbeheer betekent tools schrijven om Asana-taken te creëren en de CRM bij te werken. Naarmate het aantal tools boven de tien of vijftien tools uitkomt, werkt het aanroepen van tools niet meer. Tijd om een klassiek machine learning model op te zetten om tools te selecteren. Dan is er het observeren van het systeem met observability, evalueren of het performant is, en routeren naar het juiste model. Daarnaast is er een hele categorie software die ervoor zorgt dat de AI doet wat het moet doen. Guardrails voorkomen ongepaste reacties. Rate limiting voorkomt dat kosten uit de hand lopen wanneer een systeem ontspoort. Informatieophaling (RAG - retrieval augmented generation) is essentieel voor elk productiesysteem. In mijn e-mailapp gebruik ik een LanceDB vector database om alle e-mails van een bepaalde afzender te vinden en hun toon te matchen. Er zijn andere technieken voor kennisbeheer rond graf RAG en gespecialiseerde vector databases. Meer recent is geheugen veel belangrijker geworden. De command line interfaces voor AI-tools slaan gespreksgeschiedenis op als markdown-bestanden. Wanneer ik grafieken publiceer, wil ik dat de Theory Ventures onderschrift rechtsonder staat, een bepaald lettertype, kleuren en stijlen. Die worden nu allemaal opgeslagen binnen .gemini of .claude bestanden in een reeks van cascaderende mappen. De oorspronkelijke eenvoud van grote taalmodellen is ondergesneeuwd door de complexiteit van enterprise-grade productie. Dit is niet identiek aan de vorige generatie machine learning systemen, maar het volgt een duidelijke parallel. Wat leek op een eenvoudige "AI-magische doos" blijkt een ijsberg te zijn, met het grootste deel van het engineeringwerk verborgen onder het oppervlak.

Als 2025 het jaar van de agenten is, dan zal 2026 zeker toebehoren aan agentmanagers. Agentmanagers zijn mensen die teams van AI-agenten kunnen beheren. Hoeveel kan één persoon succesvol beheren? Ik kan nauwelijks 4 AI-agenten tegelijk beheren. Ze vragen om verduidelijking, vragen om toestemming, doen webzoekopdrachten - allemaal vereisen ze mijn aandacht. Soms duurt een taak 30 seconden. Andere keren, 30 minuten. Ik verlies het overzicht over welke agent wat doet en de helft van het werk wordt weggegooid omdat ze instructies verkeerd interpreteren. Dit is geen vaardigheidsprobleem. Het is een gereedschapsprobleem. Fysieke robots bieden aanwijzingen over de productiviteit van robotmanagers. MIT publiceerde in 2020 een analyse die suggereerde dat de gemiddelde robot 3,3 menselijke banen verving. In 2024 meldde Amazon dat pickpack- en verzendrobots 24 werknemers vervingen. Maar er is een cruciaal verschil: AI is niet-deterministisch. AI-agenten interpreteren instructies. Ze improviseren. Ze negeren af en toe volledig de richtlijnen. Een Roomba kan alleen dromen van de creatieve vrijheid om je woonkamer te negeren en in plaats daarvan te besluiten dat de garage aandacht nodig heeft. Managementtheorie leidt teams vaak naar een controlebereik van 7 mensen. Door te spreken met enkele betere agentmanagers, heb ik geleerd dat ze een agentinbox gebruiken, een projectmanagementtool voor het aanvragen van AI-werk en het evalueren ervan. In software-engineering dienen Github's pull requests of Linear-tickets dit doel. Zeer productieve AI-software-engineers beheren 10-15 agenten door 10-15 taken in detail te specificeren, deze naar een AI te sturen, te wachten tot de voltooiing en vervolgens het werk te beoordelen. De helft van het werk wordt weggegooid en opnieuw gestart met een verbeterde prompt. De agentinbox is nog niet populair - nog niet. Het is niet breed beschikbaar. Maar ik vermoed dat het een essentieel onderdeel zal worden van de productiviteitsstack voor toekomstige agentmanagers, omdat het de enige manier is om het werk bij te houden dat op elk moment kan binnenkomen. Als ARR per werknemer de nieuwe vanity-metric voor startups is, dan kan het aantal agenten dat per persoon wordt beheerd de vanity-productiviteitsmetric van een werknemer worden. Hoeveel agenten denk je dat je in 12 maanden zou kunnen beheren? 10? 50? 100? Zou je een agent kunnen beheren die andere agenten beheert?

"Oh, je kantoor is in het Ferry gebouw, dat is zo geweldig, hoe is het daar" "Non-stop straatmuzikanten. Vergaderingen onderbroken door doedelzakspelers buiten. Voorste rij voor de volgende Santana op straat."

In het afgelopen decennium was het grootste kostenpost in het R&D-budget van elke startup voorspelbaar talent. Maar AI dringt zich op in de winst- en verliesrekening. Hoeveel zou een startup aan AI moeten besteden als percentage van zijn uitgaven voor onderzoek en ontwikkeling? 10%? 30%? 60%? Er zijn drie factoren om te overwegen. Ten eerste, het gemiddelde salaris voor een software-engineer in Silicon Valley. Ten tweede is de totale kosten van AI die door die engineer wordt gebruikt. Cursor kost nu $200 per maand voor hun Ultra Plan en beoordelingen van Devin suggereren $500 per maand. Ten derde, het aantal agents dat een engineer kan beheren. Een eerste schatting: (eerste afbeelding) Maar de abonnements kosten zijn waarschijnlijk laag. In de afgelopen dagen heb ik uitgebreid gespeeld met AI-coding agents en ik heb binnen vijf dagen een rekening van $1.000 opgebouwd! 😳😅 Laten we de tabel bijwerken en aannemen dat er nog eens $1000 per maand per engineer bijkomt. Dus voor een typische startup zou een schatting van 10 tot 15% van de totale R&D-uitgaven vandaag de dag mogelijk voor AI kunnen worden gebruikt. De varianten zullen in de praktijk veel breder zijn naarmate we allemaal beter leren omgaan met AI en het meer doordringt in de organisatie. Kleinere bedrijven die vanaf het begin AI-native zijn, zullen waarschijnlijk aanzienlijk hogere verhoudingen hebben. Als je geïnteresseerd bent om deel te nemen aan een anonieme enquête, zal ik de resultaten publiceren als de steekproefgrootte voldoende groot is om een statistisch significante uitkomst te hebben. Enquête is hier: Dit is een grof vereenvoudigd model waarbij we alleen salarissen bekijken, zonder voordelen, hardware, ontwikkelings- en testinfrastructuur, enz. Dit is een schatting op basis van persoonlijke ervaring met vibe coding.

In het afgelopen decennium was het grootste kostenpost in het R&D-budget van elke startup voorspelbaar talent. Maar AI dringt zich op in de winst- en verliesrekening. Hoeveel zou een startup aan AI moeten besteden als percentage van zijn uitgaven voor onderzoek en ontwikkeling? 10%? 30%? 60%? Er zijn drie factoren om te overwegen. Ten eerste, het gemiddelde salaris voor een software-engineer in Silicon Valley. Ten tweede is de totale kosten van AI die door die engineer wordt gebruikt. Cursor kost nu $200 per maand voor hun Ultra Plan en beoordelingen van Devin suggereren $500 per maand. Ten derde, het aantal agents dat een engineer kan beheren. Een eerste schatting: (eerste afbeelding) Maar de abonnements kosten zijn waarschijnlijk laag. In de afgelopen dagen heb ik uitgebreid gespeeld met AI-coding agents en ik heb binnen vijf dagen een rekening van $1.000 opgebouwd! 😳😅 Laten we de tabel bijwerken en aannemen dat er nog eens $1000 per maand per engineer bijkomt. Dus voor een typische startup zou een schatting van 10 tot 15% van de totale R&D-uitgaven vandaag de dag mogelijk voor AI kunnen worden gebruikt. De varianten zullen in de praktijk veel breder zijn naarmate we allemaal beter leren omgaan met AI en het meer doordringt in de organisatie. Kleinere bedrijven die vanaf het begin AI-native zijn, zullen waarschijnlijk aanzienlijk hogere verhoudingen hebben. Als je geïnteresseerd bent om deel te nemen aan een anonieme enquête, zal ik de resultaten publiceren als de steekproefgrootte voldoende groot is om een statistisch significante uitkomst te hebben. Enquête is hier: Dit is een grof vereenvoudigd model waarbij we alleen salarissen bekijken, zonder voordelen, hardware, ontwikkelings- en testinfrastructuur, enz. Dit is een schatting op basis van persoonlijke ervaring met vibe coding.

Wanneer je AI ondervraagt, verzamelt het relevante informatie om je te antwoorden. Maar, hoeveel informatie heeft het model nodig? Gesprekken met praktijkmensen onthulden hun intuïtie: de invoer was ~20x groter dan de uitvoer. Maar mijn experimenten met de Gemini-tool commandoregelinterface, die gedetailleerde tokenstatistieken weergeeft, toonden aan dat het veel hoger is. Gemiddeld 300x en tot 4000x. Hier is waarom deze hoge invoer-naar-uitvoer verhouding belangrijk is voor iedereen die met AI bouwt: Kostenbeheer draait helemaal om de invoer. Met API-aanroepen die per token worden geprijsd, betekent een verhouding van 300:1 dat de kosten worden bepaald door de context, niet door het antwoord. Deze prijsdynamiek geldt voor alle grote modellen. Op de prijs pagina van OpenAI zijn uitvoertokens voor GPT-4.1 4x zo duur als invoertokens. Maar wanneer de invoer 300x volumineuzer is, zijn de invoerkosten nog steeds 98% van de totale rekening. Latentie is een functie van de contextgrootte. Een belangrijke factor die bepaalt hoe lang een gebruiker wacht op een antwoord, is de tijd die het model nodig heeft om de invoer te verwerken. Het herdefinieert de technische uitdaging. Deze observatie bewijst dat de kernuitdaging van bouwen met LLM's niet alleen het aansteken is. Het is contextengineering. De kritieke taak is het bouwen van efficiënte gegevensophaling en context - het creëren van pijplijnen die de beste informatie kunnen vinden en deze kunnen destilleren tot de kleinste mogelijke tokenvoetafdruk. Caching wordt cruciaal. Als 99% van de tokens in de invoer zitten, verschuift het bouwen van een robuuste cachinglaag voor vaak opgehaalde documenten of veelvoorkomende querycontexten van een "mooi om te hebben" naar een kernarchitectuurvereiste voor het bouwen van een kosteneffectief en schaalbaar product. Voor ontwikkelaars betekent dit dat de focus op invoeroptimalisatie een kritieke hefboom is voor het beheersen van kosten, het verminderen van latentie en uiteindelijk het bouwen van een succesvol AI-gestuurd product.

Gisteren heeft Figma zijn prachtig ontworpen S-1 ingediend. Het onthult een productgedreven groeimodel (PLG) met een opmerkelijke traject. Figma’s samenwerkingsplatform voor ontwerp heeft de ontwerpmarkt verstoord die lange tijd door Adobe werd gedomineerd. Hier is hoe de twee bedrijven zich verhouden op belangrijke metrics voor hun meest recente boekjaar [zie bijgevoegde afbeelding]: Figma is ongeveer 3% van de grootte van Adobe, maar groeit 4x sneller. De brutomarges zijn identiek. Figma’s 132% Netto Dollar Retentie is top deciel. De gegevens tonen ook aan dat de uitgaven voor Onderzoek & Ontwikkeling van Figma bijna gelijk zijn aan de uitgaven voor Verkoop & Marketing. Dit is het PLG-model op zijn best. Figma’s product is de primaire marketingmotor. De samenwerkingsnatuur bevordert virale, bottom-up adoptie, wat leidt tot een verkoopsefficiëntie van 1.0. Voor elke dollar die in 2023 aan verkoop & marketing werd uitgegeven, genereerde Figma een dollar aan nieuwe brutowinst in 2024. Adobe’s gecombineerde bottom-up & verkoopgedreven model levert een meer typische 0.39 op. De S-1 benadrukt ook risico's. Het meest significante is de concurrentie van AI-producten. Terwijl Figma zwaar investeert in AI, verlaagt de technologie de drempel voor nieuwe toetreders. Figma’s verdediging is zijn uitbreidende platform - met producten zoals FigJam, Dev Mode, & nu Slides, Sites, & Make. Deze nieuwe productcategorieën hebben veel PLG AI-softwarebedrijven in recordtijd naar tientallen en honderden miljoenen in ARR gedreven. Gezien de hoge groei & het unieke bedrijfsmodel, hoe zou de markt Figma moeten waarderen? We kunnen een lineaire regressie gebruiken op basis van openbare SaaS-bedrijven om de toekomstige omzetmultiple te voorspellen. Het model toont een bescheiden correlatie tussen omzetgroei & waarderingsmultiples (R² = 0.23). Figma, met zijn 48% groei, zou het snelstgroeiende softwarebedrijf in deze groep zijn, afgezien van NVIDIA. Er kan een overtuigend argument worden gemaakt dat Figma een hogere dan voorspelde waardering zou moeten hebben. De combinatie van hyper-groei, best-in-class verkoopsefficiëntie, & een gepassioneerde, zelf-propagaterende gebruikersbasis is zeldzaam. Door de voorspelde 19.9x multiple van ons model toe te passen om de toekomstige omzet te schatten, komt een geschatte IPO-waardering van ongeveer $21B naar voren - een premie op de $20B die Adobe in 2022 voor het bedrijf bood. De S-1 vertelt het verhaal van een categorie-definiërend bedrijf dat een samenwerkingsproduct voor ontwerp heeft gebouwd, een fenomenale PLG-beweging heeft ontwikkeld, & actief in AI duwt. De beëindigingsvergoeding van $1,0 miljard van Adobe werd in december 2023 ontvangen en geregistreerd als "Overige inkomsten, netto" in het boekjaar 2024 (eindigend op 31 januari 2024). De grote kosten voor aandelencompensatie van bijna $900 miljoen zijn gerelateerd aan een werknemersaanbieding in mei 2024. Beide worden verwijderd in de niet-GAAP-gegevens die hierboven zijn genoemd. Door Figma’s 48,3% groei over de afgelopen twaalf maanden te nemen & deze met 15% te verdisconteren (om rekening te houden met een natuurlijke groeivertraging), produceert het model een schatting van de toekomstige groei van 41,1%. Dit zou impliceren dat de toekomstige omzet ongeveer $1,1 miljard bedraagt.