Dit weekend, Andrej Karpathyde voormalige directeur van AI bij Tesla en een van de oprichters van OpenAI, besloot dat hij een boek wilde lezen. Maar hij wilde het niet alleen lezen. Hij wilde het lezen in gezelschap van een commissie van kunstmatige intelligenties, die elk hun eigen perspectief boden, de anderen bekritiseerden en uiteindelijk onder leiding van een ‘voorzitter’ een definitief antwoord samenbrachten.
Om dit mogelijk te maken schreef Karpathy wat hij noemde een ‘vibe code-project” – een stukje software dat snel is geschreven, grotendeels door AI-assistenten, bedoeld voor de lol in plaats van voor de functie. Hij plaatste het resultaat, een repository genaamd “LLM Raad,” tegen GitHub met een grimmige disclaimer: “Ik ga het op geen enkele manier ondersteunen… Code is nu vluchtig en bibliotheken zijn voorbij.”
Maar voor technische besluitvormers in het hele ondernemingslandschap onthult het kijken voorbij de nonchalante disclaimer iets veel belangrijkers dan een weekendspeeltje. In een paar honderd regels Python En JavaScriptheeft Karpathy een referentiearchitectuur geschetst voor de meest kritische, ongedefinieerde laag van de moderne softwarestack: de orkestratie-middleware die zich tussen bedrijfsapplicaties en de volatiele markt van AI-modellen bevindt.
Terwijl bedrijven hun platforminvesteringen voor 2026 afronden, LLM Raad biedt een uitgeklede kijk op de ‘build vs. buy’-realiteit van AI-infrastructuur. Het laat zien dat, hoewel de logica van het routeren en aggregeren van AI-modellen verrassend eenvoudig is, de werkelijke complexiteit ligt in de operationele verpakking die nodig is om het bedrijfsklaar te maken.
Hoe de LLM Council werkt: vier AI-modellen debatteren, bekritiseren en synthetiseren antwoorden
Voor de toevallige toeschouwer: de LLM Raad webapplicatie ziet er vrijwel identiek uit aan ChatGPT. Een gebruiker typt een vraag in een chatbox. Maar achter de schermen activeert de applicatie een geavanceerde, driefasige workflow die weerspiegelt hoe menselijke besluitvormingsorganen werken.
Ten eerste verzendt het systeem de vraag van de gebruiker naar een panel van grensmodellen. In de standaardconfiguratie van Karpathy omvat dit OpenAI’s GPT-5.1Google’s Tweeling 3.0 ProAntropisch Claude Sonnet 4.5en xAI’s Grok 4. Deze modellen genereren hun eerste reacties parallel.
In de tweede fase voert de software een peer review uit. Elk model krijgt de geanonimiseerde reacties van zijn tegenhangers te zien en wordt gevraagd deze te evalueren op basis van nauwkeurigheid en inzicht. Deze stap transformeert de AI van een generator in een criticus, waardoor een laag van kwaliteitscontrole wordt opgelegd die zeldzaam is bij standaard chatbot-interacties.
Ten slotte ontvangt een aangewezen “Chairman LLM” (momenteel geconfigureerd als Gemini 3 van Google) de oorspronkelijke vraag, de individuele antwoorden en de ranglijst van collega’s. Het synthetiseert deze massa aan context tot één enkel, gezaghebbend antwoord voor de gebruiker.
Karpathy merkte op dat de resultaten vaak verrassend waren. “Heel vaak zijn de modellen verrassend bereid om de reactie van een andere LLM te selecteren als superieur aan hun eigen reactie”, schreef hij op X (voorheen Twitter). Hij beschreef het gebruik van de tool om hoofdstukken uit boeken te lezen, waarbij hij opmerkte dat de modellen GPT-5.1 consequent prezen als het meest inzichtelijke, terwijl ze Claude het laagst beoordeelden. Karpathy’s eigen kwalitatieve beoordeling week echter af van die van zijn digitale raad; hij vond GPT-5.1 “te langdradig” en gaf de voorkeur aan de “gecondenseerde en verwerkte” uitvoer van Gemini.
FastAPI, OpenRouter en argumenten om frontier-modellen te behandelen als verwisselbare componenten
Voor CTO’s en platformarchitecten is de waarde van LLM Raad ligt niet in de literaire kritiek, maar in de constructie ervan. De repository dient als primair document dat precies laat zien hoe een moderne, minimale AI-stack er eind 2025 uitziet.
De applicatie is gebouwd op een “dunne” architectuur. De backend gebruikt SnelleAPIeen moderne Python raamwerk, terwijl de frontend een standaard is Reageren applicatie gebouwd met Snel. Gegevensopslag wordt niet afgehandeld door een complexe database, maar door eenvoudig JSON-bestanden naar de lokale schijf geschreven.
De spil van de hele operatie is OpenRoutereen API-aggregator die de 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 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 frontiermodellen te behandelen als uitwisselbare componenten die kunnen worden uitgewisseld door een enkele regel in een configuratiebestand te bewerken (met name de COUNCIL_MODELS-lijst in de backendcode) beschermt de architectuur de applicatie tegen leverancierlock-in. Indien een nieuw model van Meta of Mistral volgende week bovenaan de ranglijsten staat, kan het binnen enkele seconden aan de raad worden toegevoegd.
Wat ontbreekt er van prototype tot productie: authenticatie, PII-redactie en compliance
Terwijl de kernlogica van LLM Raad is elegant, maar dient ook als een duidelijke illustratie van de kloof tussen een ‘weekendhack’ en een productiesysteem. Voor een ondernemingsplatformteam is het klonen van de opslagplaats van Karpathy slechts de eerste stap van een marathon.
Een technische audit van de code onthult de ontbrekende ‘saaie’ infrastructuur die commerciële leveranciers voor 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 de bestuurslaag niet. In een bedrijfsomgeving leidt het gelijktijdig verzenden van gegevens naar vier verschillende externe AI-aanbieders tot onmiddellijke nalevingsproblemen. Er is hier geen mechanisme om persoonlijk identificeerbare informatie (PII) te redigeren 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 gaat ervan uit dat 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 met een storing te maken krijgt.
Deze tekortkomingen zijn geen tekortkomingen in de code van Karpathy – hij verklaarde expliciet 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-bodemen verschillende AI-gateway-startups verkopen in wezen de ‘verharding’ rond de kernlogica die Karpathy demonstreerde. Ze bieden de beveiligings-, waarneembaarheids- en compliance-wrappers die een onbewerkt orkestratiescript omzetten in een levensvatbaar bedrijfsplatform.
Waarom 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 waaronder het is gebouwd. Karpathy omschreef het ontwikkelingsproces als “99% vibratie-gecodeerd”, 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 er zijn geen bibliotheken meer. Vraag je LLM om deze op welke manier dan ook te veranderen”, schreef hij in de documentatie van de repository.
Deze verklaring markeert een radicale verschuiving in de mogelijkheden voor software-engineering. Traditioneel bouwen bedrijven interne bibliotheken en abstracties om de complexiteit te beheersen en deze jarenlang te onderhouden. Karpathy suggereert een toekomst waarin code wordt behandeld als ‘promptable steigers’ – wegwerpbaar, gemakkelijk te herschrijven door AI, en niet bedoeld om lang mee te gaan.
Voor besluitvormers in ondernemingen vormt dit een lastige strategische vraag. Als interne tools kunnen worden “sfeer gecodeerd“Heeft het zin om in een weekend dure, rigide softwaresuites voor interne workflows te kopen? Of moeten platformteams hun engineers in staat stellen 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 de architectuur, de LLM Raad project werpt onbedoeld licht op een specifiek risico bij de geautomatiseerde inzet van AI: 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 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“-systemen om de kwaliteit van hun klantgerichte bots te evalueren, is deze discrepantie van belang. Als de geautomatiseerde beoordelaar consequent” langdradige en uitgebreide “antwoorden beloont terwijl menselijke klanten beknopte oplossingen willen, zullen de statistieken succes laten zien terwijl de klanttevredenheid keldert. Karpathy’s experiment suggereert dat uitsluitend vertrouwen op AI om AI te beoordelen een strategie is vol verborgen afstemmingsproblemen.
Wat enterpriseplatformteams kunnen leren van een weekendhack voordat ze hun 2026-stack bouwen
Uiteindelijk, LLM Raad fungeert als een Rorschach-test voor de AI-industrie. Voor de hobbyist is het een leuke manier om boeken te lezen. Voor de leverancier is het een bedreiging, wat bewijst dat de kernfunctionaliteit van hun producten in 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 de 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. Het bewijst 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 ‘vibe code’ in een pantser van ondernemingskwaliteit te wikkelen.
