Dit weekend, Andrej Karpathyvoormalig directeur kunstmatige intelligentie bij Tesla en oprichter van OpenAI, besloot dat hij een boek wilde lezen. Maar hij wilde het zelf niet lezen. Hij wilde het lezen in het gezelschap van een commissie van kunstmatige intelligenties, die ieder hun eigen perspectief naar voren brachten, de anderen bekritiseerden en uiteindelijk onder leiding van een ‘president’ een definitief antwoord samenbrachten.
Om dit mogelijk te maken schreef Karpathy wat hij noemde: “trillingscode project” – een stukje software dat snel is geschreven, grotendeels door AI-assistenten, bedoeld voor de lol in plaats van voor de functie. Hij publiceerde het resultaat, een repository genaamd “Ik raad LLM aan”, tegen GitHub met een grimmige disclaimer: “Ik zal het op geen enkele manier ondersteunen… De code is nu vluchtig en de bibliotheken zijn eindig.”
Voor technische besluitvormers in het hele ondernemingslandschap onthult het kijken verder dan de terloopse disclaimer echter iets dat veel belangrijker is dan een weekendspeeltje. In een paar honderd regels Python EN JavaScriptKarpathy schetste een referentiearchitectuur voor de meest kritische en ongedefinieerde laag van de moderne softwarestack: de orkestratie-middleware die zich tussen bedrijfsapplicaties en de volatiele markt voor AI-modellen bevindt.
Terwijl bedrijven hun platforminvesteringen voor 2026 afronden, Ik raad LLM aan biedt een kleine blik op de ‘build vs. buy’-realiteit van AI-infrastructuur. Het laat zien dat, hoewel de routerings- en aggregatielogica van AI-modellen verrassend eenvoudig is, de echte complexiteit ligt in de operationele verpakking die nodig is om het bedrijfsklaar te maken.
Hoe de LLM Council werkt: Vier AI-modellen bespreken, bekritiseren en vatten antwoorden samen
Voor de toevallige toeschouwer: de Ik raad LLM aan de webapplicatie ziet er vrijwel identiek uit aan ChatGPT. Een gebruiker typt een vraag in een chatvenster. Maar achter de schermen activeert de applicatie een geavanceerde driestapsworkflow die de manier weerspiegelt waarop menselijke besluitvormingsorganen werken.
Eerst stuurt het systeem de vraag van de gebruiker naar een grensmodelpaneel. In de standaardconfiguratie van Karpathy omvat dit OpenAI GPT-5.1door Google Tweeling 3.0 ProAntropisch Claude Sonnet 4.5en xAI Grok 4. Deze modellen genereren hun eerste reacties parallel.
In de tweede fase voert de software een peer review uit. Elk model krijgt de anonieme reacties van zijn tegenhangers en wordt gevraagd deze te beoordelen op nauwkeurigheid en inzicht. Deze stap transformeert de AI van generator naar criticus, waardoor een niveau van kwaliteitscontrole wordt opgelegd dat zeldzaam is bij standaard chatbot-interacties.
Ten slotte ontvangt een aangewezen “LLM-voorzitter”, momenteel geconfigureerd als Google’s Gemini 3, de oorspronkelijke vraag, individuele antwoorden en peer-ranglijsten. Het synthetiseert deze massa aan context in één gezaghebbend antwoord voor de gebruiker.
Karpathy merkte op dat de resultaten vaak verrassend waren. “Heel vaak zijn modellen verrassend bereid om het antwoord van een andere LLM te selecteren als superieur aan hun eigen antwoord”, schreef hij op X (voorheen Twitter). Hij beschreef het gebruik van de tool om hoofdstukken uit boeken te lezen, waarbij hij opmerkte dat modellen GPT-5.1 consequent als de meest diepgaande prezen, terwijl ze Claude het laagst beoordeelden. De kwalitatieve beoordeling van Karpathy week echter af van zijn digitale advies; hij vond GPT-5.1 “te uitgebreid” en gaf de voorkeur aan Gemini’s “gecondenseerde en verwerkte” uitvoer.
FastAPI, OpenRouter en de mogelijkheid om frontier-modellen als uitwisselbare componenten te behandelen
Voor CTO’s en platformarchitecten is de waarde van Ik raad LLM aan het ligt niet in de literaire kritiek, maar in de constructie ervan. De repository dient als hoofddocument dat precies laat zien hoe een moderne, minimale AI-stack er eind 2025 uit zal zien.
De applicatie is gebouwd op een “dunne” architectuur. De backend gebruikt Snelle APIeen moderne Python raamwerk, terwijl de frontend een standaard is Reageren applicatie gemaakt met Snel. Gegevensopslag wordt niet afgehandeld door een complexe database, maar door een eenvoudige database JSON-bestanden naar de lokale schijf geschreven.
De crux van de hele operatie is OpenRoutereen API-aggregator die verschillen tussen verschillende modelaanbieders normaliseert. Door verzoeken via deze ene makelaar te routeren, vermeed Karpathy het schrijven van aparte integratiecode OpenAI, GooglenEN Antropisch. De applicatie weet niet en maakt zich ook niet druk over welk bedrijf de informatie levert; het verzendt eenvoudigweg een prompt en wacht op een antwoord.
Deze ontwerpkeuze benadrukt een groeiende trend in de enterprise-architectuur: de commoditisering van de modellaag. Door frontier-modellen te behandelen als uitwisselbare componenten die kunnen worden uitgewisseld door een enkele regel in een configuratiebestand te wijzigen (met name de COUNCIL_MODELS-lijst in de backend-code), beschermt de architectuur de applicatie tegen leverancierlock-in. Indien een nieuw model van Half OF Mistral volgende week bovenaan de hitlijsten staat, kan binnen enkele seconden aan het bord worden toegevoegd.
Wat ontbreekt er van prototype tot productie: authenticatie, PII-schrijven en compliance
Terwijl de fundamentele logica van Ik raad LLM aan Het is elegant en dient ook als een duidelijk voorbeeld van de kloof tussen een “weekendhack” en een productiesysteem. Voor een ondernemingsplatformteam is het klonen van de Karpathy-repository eenvoudigweg de eerste stap van een marathon.
Een technische controle van de code onthult het gebrek aan ‘saaie’ infrastructuur die commerciële verkopers tegen hogere prijzen verkopen. Het systeem mist authenticatie; iedereen met toegang tot de webinterface kan de modellen opvragen. Er is geen concept van gebruikersrollen, wat betekent dat een junior ontwikkelaar dezelfde toegangsrechten heeft als de CIO.
Bovendien bestaat er geen bestuursniveau. In een bedrijfsomgeving leidt het tegelijkertijd verzenden van gegevens naar vier verschillende externe AI-leveranciers tot onmiddellijke nalevingsproblemen. Er is hier geen mechanisme om persoonlijk identificeerbare informatie (PII) te verbergen voordat deze het lokale netwerk verlaat, noch is er een auditlogboek om bij te houden wie wat heeft gevraagd.
Betrouwbaarheid is een andere open vraag. Het systeem veronderstelt de OpenRouter-API altijd actief is en dat de modellen tijdig zullen reageren. Het mist de stroomonderbrekers, terugvalstrategieën en logica voor opnieuw proberen die bedrijfskritische applicaties draaiende houden wanneer een provider een storing ervaart.
Deze afwezigheden zijn geen tekortkomingen in de code van Karpathy – hij heeft expliciet verklaard dat hij niet van plan is het project te ondersteunen of te verbeteren – maar ze definiëren de waardepropositie voor de commerciële AI-infrastructuurmarkt.
Bedrijven vinden het leuk LangChain, AWS-basisen verschillende AI-gateway-startups verkopen in wezen de ‘verharding’ rond de kernlogica die door Karpathy wordt gedemonstreerd. Ze bieden de beveiligings-, waarneembaarheids- en compliance-wrappers die een ruw orkestratiescript transformeren in een levensvatbaar bedrijfsplatform.
Omdat Karpathy gelooft dat code nu ‘vergankelijk’ is en dat traditionele softwarebibliotheken verouderd zijn
Misschien wel het meest provocerende aspect van het project is de filosofie waarmee het is gebouwd. Karpathy omschreef het ontwikkelingsproces als “99% trillingsgecodeerd”, wat impliceert dat hij sterk afhankelijk was van AI-assistenten om de code te genereren in plaats van deze zelf regel voor regel te schrijven.
“De code is nu vluchtig en de bibliotheken zijn eindig, vraag je LLM om deze naar eigen wens te veranderen”, schreef hij in de repositorydocumentatie.
Deze verklaring markeert een radicale verschuiving in de mogelijkheden voor software-engineering. Traditioneel bouwen bedrijven interne bibliotheken en abstracties om met de complexiteit om te gaan, en onderhouden ze deze jarenlang. Karpathy suggereert een toekomst waarin code zal worden behandeld als ‘kant-en-klare steigers’: wegwerpbaar, gemakkelijk herschrijfbaar door AI, en niet bedoeld om lang mee te gaan.
Voor zakelijke besluitvormers vormt dit een moeilijke strategische vraag. Als de interne tools kunnen worden “gecodeerde trillingen“Heeft het zin om in een weekend dure, rigide softwaresuites aan te schaffen voor interne workflows? Of moeten platformteams hun engineers toestaan om aangepaste, wegwerpbare tools te genereren die exact aan hun behoeften voldoen, tegen een fractie van de kosten?
Wanneer AI-modellen AI beoordelen: de gevaarlijke kloof tussen machinevoorkeuren en menselijke behoeften
Naast architectuur, de Ik raad LLM aan Het project werpt onbedoeld licht op een specifiek risico bij de geautomatiseerde AI-implementatie: het verschil tussen menselijk en machinaal oordeel.
Karpathy’s observatie dat zijn modellen de voorkeur gaven aan GPT-5.1, terwijl hij de voorkeur gaf aan Gemini, suggereert dat de AI-modellen mogelijk gedeelde vooroordelen hebben. Ze geven misschien de voorkeur aan breedsprakigheid, specifieke opmaak of retorisch vertrouwen dat niet noodzakelijkerwijs aansluit bij de menselijke bedrijfsbehoeften aan beknoptheid en nauwkeurigheid.
Nu bedrijven steeds meer afhankelijk zijn van ‘LLM als rechter“Als de geautomatiseerde evaluator consistent” langdradige en verspreide “antwoorden beloont terwijl menselijke klanten beknopte oplossingen willen, zullen de statistieken succes laten zien als de klanttevredenheid keldert. Karpathy’s experiment suggereert dat het uitsluitend vertrouwen op AI om AI te classificeren een strategie is vol verborgen afstemmingsproblemen.
Wat enterpriseplatformteams kunnen leren van een weekendhack voordat ze hun 2026-stack bouwen
Uiteindelijk, Ik raad LLM aan dient als Rorschach-test voor de AI-industrie. Voor de hobbyist is het een leuke manier om boeken te lezen. Voor de leverancier is dit een bedreiging, die aantoont dat de kernfunctionaliteit van zijn producten in slechts een paar honderd regels code kan worden gerepliceerd.
Maar voor de leider op het gebied van bedrijfstechnologie is het een referentiearchitectuur. Het demystificeert de orkestratielaag en laat zien dat de technische uitdaging niet ligt in het routeren van aanwijzingen, maar in het beheren van de gegevens.
Terwijl platformteams 2026 tegemoet gaan, zullen velen waarschijnlijk naar de code van Karpathy staren, niet om deze te implementeren, maar om deze te begrijpen. Dit laat zien dat een multi-modellenstrategie technisch gezien niet buiten bereik is. De vraag blijft of bedrijven zelf de bestuurslaag zullen bouwen of iemand anders zullen betalen om de ‘vibratiecode’ in een pantser van bedrijfsniveau te wikkelen.
