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 naar voren brachten, de anderen bekritiseerden en uiteindelijk een definitief antwoord samenvatten onder leiding van een ‘voorzitter’.
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 “De LLM-raad”, tegen GitHub met een scherpe disclaimer: “Ik zal het op geen enkele manier ondersteunen… De code is nu vluchtig en de bibliotheken zijn verdwenen.”
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 JavaScriptKarpathy heeft een referentiearchitectuur geschetst voor de meest kritische, ongedefinieerde laag van de moderne softwarestack: de orkestratie-middleware die zich bevindt tussen bedrijfsapplicaties en de volatiele markt voor AI-modellen.
Terwijl bedrijven hun platforminvesteringen voor 2026 afronden, De LLM-raad biedt een onthullende blik 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 echte 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 De LLM-raad webapplicatie ziet er vrijwel identiek uit aan ChatGPT. Een gebruiker voert een vraag in een chatbox in. Maar achter de schermen activeert de applicatie een geavanceerde workflow in drie stappen die weerspiegelt hoe menselijke besluitvormingsorganen werken.
Eerst stuurt het systeem de vraag van de gebruiker naar een panel van grensmodellen. In de standaardconfiguratie van Karpathy omvat dit OpenAI’s GPT-5.1Die van Google 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 verandert de AI van een generator in een criticus, waardoor een laag 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 in één enkel, gezaghebbend antwoord aan de gebruiker.
Karpathy merkte op dat de resultaten vaak verrassend waren. “Heel vaak zijn de modellen verrassend bereid om het antwoord van een andere LLM te kiezen 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 de modellen GPT-5.1 consequent als het meest inzichtelijke prezen, terwijl Claude als de laagste werd beoordeeld. Karpathy’s eigen kwalitatieve beoordeling verschilde echter van zijn digitale advies; hij vond de GPT-5.1 “te omslachtig” en gaf de voorkeur aan de “gecomprimeerde en verwerkte” uitvoer van de Gemini.
FastAPI, OpenRouter en de argumenten om frontier-modellen als vervangbare componenten te behandelen
Voor CTO’s en platformarchitecten is de waarde van De 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 uit zal zien.
De applicatie is gebouwd op een “dunne” architectuur. Backend-gebruiker SnelleAPIeen moderne Python frame, terwijl de voorkant een standaard is Antwoorden applicatie gebouwd met Snel. Gegevensopslag wordt niet afgehandeld door een complexe database, maar door eenvoudige databases JSON-bestanden naar de lokale schijf geschreven.
Het centrale punt in de hele operatie is Router openeneen API-aggregator die de verschillen tussen verschillende modelaanbieders normaliseert. Door verzoeken via deze ene makelaar te routeren, vermeed Karpathy het schrijven van afzonderlijke integratiecodes 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 (in het bijzonder de COUNCIL_MODELS-lijst in de backendcode) beschermt de architectuur de applicatie tegen leverancierlock-in. Indien een nieuw model van Meta of Mistral staat volgende week bovenaan de ranglijsten en kan binnen enkele seconden aan het bord worden toegevoegd.
Wat ontbreekt er van prototype tot productie: authenticatie, PII-redactie en compliance
Terwijl de kernlogica van De 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 één stap in een marathon.
Een technische audit 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 de managementlaag 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 bewerken 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 OpenRouter-API altijd beschikbaar is en dat de modellen tijdig zullen reageren. Er ontbreken 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 gebreken in de code van Karpathy – hij zei expliciet dat hij niet van plan is het project te ondersteunen of te verbeteren – maar ze definiëren de waarde ervan voor de commerciële AI-infrastructuurmarkt.
Bedrijven vinden het leuk Lange ketting, AWS-basisen verschillende AI-gateway-startups verkopen in wezen de ‘verharding’ rond de kernlogica die Karpathy demonstreerde. Ze bieden beveiligings-, waarneembaarheids- en compliance-wrappers die een onbewerkt orkestratiescript omzetten in een levensvatbaar bedrijfsplatform.
Waarom Karpathy gelooft dat code nu ‘vluchtig’ 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 de bibliotheken zijn verdwenen. Vraag uw LLM om deze op elke gewenste manier aan te passen”, schreef hij in de documentatie van de repository.
Deze verklaring markeert een radicale verschuiving in de mogelijkheden van softwaretechnologie. Traditioneel bouwen bedrijven interne bibliotheken en abstracties om met complexiteit om te gaan en deze jarenlang te onderhouden. Karpathy stelt een toekomst voor waarin code wordt behandeld als ‘promptable steigers’: wegwerpbaar, gemakkelijk te herschrijven door AI en niet bedoeld om lang mee te gaan.
Voor zakelijke besluitvormers roept dit een moeilijke strategische vraag op. Als interne tools kunnen worden “sfeer gecodeerdHeeft het zin om een weekend lang dure, rigide softwarepakketten voor interne workflows te kopen? Of moeten platformteams hun technici toestaan om op maat gemaakte, eenmalige tools te genereren die precies aan hun behoeften voldoen, tegen een fractie van de kosten?
Wanneer AI-modellen AI beoordelen: de gevaarlijke kloof tussen machinevoorkeuren en menselijke behoeften
Voorbij de architectuur De LLM-raad Het project werpt onbedoeld licht op een specifiek risico van 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 AI-modellen mogelijk gedeelde vooroordelen hebben. Ze geven misschien de voorkeur aan bewoordingen, 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 evaluator consequent” langdradige en uitgebreide “reacties beloont, terwijl menselijke klanten beknopte oplossingen willen, zal de metriek succes tonen terwijl de klanttevredenheid afneemt. Karpathy’s experiment suggereert dat het volledig afhankelijk is van de aanpassing van AI-kwaliteitsproblemen aan AI-kwaliteitsproblemen.
Wat enterpriseplatformteams kunnen leren van een weekendhack voordat ze hun 2026-stack bouwen
Op het einde, De LLM-raad dient als Rorschach-test voor de kunstmatige intelligentie-industrie. Voor de hobbyist is het een leuke manier om boeken te lezen. Voor de leverancier is het een bedreiging die bewijst dat de kernfunctionaliteit van hun producten kan worden gerepliceerd in een paar honderd regels code.
Maar voor de technologiemanager van het bedrijf is het een referentiearchitectuur. Het demystificeert de orkestratielaag en laat zien dat de technische uitdaging niet ligt in het aansturen van de aanwijzingen, maar in het beheren van de gegevens.
Nu platformteams 2026 ingaan, 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 de managementlaag zelf zullen bouwen of iemand anders zullen betalen om de ‘vibe code’ in een pantser van ondernemingskwaliteit te wikkelen.
