Ovaj vikend, Andrej Karpathybivši direktor AI-a u Tesli i osnivač OpenAI-ja, odlučio je da želi pročitati knjigu. Ali nije ga htio čitati sam. Htio ju je pročitati u pratnji odbora umjetne inteligencije, od kojih je svaka nudila vlastitu perspektivu, kritizirala druge i na kraju sintetizirala konačni odgovor pod vodstvom "Predsjednik."
Da bi se to dogodilo, Karpathy je napisao ono što je nazvao a "projekt vibe koda" — dio softvera napisan brzo, uglavnom od strane AI pomoćnika, namijenjen zabavi, a ne funkciji. Objavio je rezultat, pozvano spremište "LLM Vijeće," na GitHub s jasnim odricanjem od odgovornosti: "Neću to podržati ni na koji način… Kod je sada efemeran i knjižnicama je kraj."
Ipak, za donositelje tehničkih odluka u cijelom poslovnom okruženju, gledajući dalje od obične izjave o odricanju od odgovornosti, otkriva se nešto daleko značajnije od igračke za vikend. U nekoliko stotina redaka Piton i JavaScriptKarpathy je skicirao referentnu arhitekturu za najkritičniji, nedefinirani sloj modernog softverskog niza: međuprogram za orkestraciju koji se nalazi između korporativnih aplikacija i nestabilnog tržišta AI modela.
Dok tvrtke dovršavaju svoja ulaganja u platforme za 2026. LLM Vijeće nudi ogoljen pogled na "izgraditi protiv kupiti" realnost AI infrastrukture. Pokazuje da dok je logika usmjeravanja i agregiranja AI modela iznenađujuće jednostavna, operativni omotač koji je potreban da bude spreman za poduzeća je ono gdje leži prava složenost.
Sadržaj objave
- 1 Kako radi Vijeće LLM-a: četiri AI modela raspravljaju, kritiziraju i sintetiziraju odgovore
- 2 FastAPI, OpenRouter i slučaj za tretiranje graničnih modela kao zamjenjivih komponenti
- 3 Što nedostaje od prototipa do proizvodnje: Autentifikacija, redigiranje PII-a i usklađenost
- 4 Zašto Karpathy vjeruje da je kod sada "efemeran" a tradicionalne softverske biblioteke su zastarjele
- 5 Kada AI modeli procjenjuju AI: Opasan jaz između preferencija strojeva i ljudskih potreba
- 6 Što timovi za poslovne platforme mogu naučiti iz vikend hakiranja prije nego izgrade svoj stack 2026
Kako radi Vijeće LLM-a: četiri AI modela raspravljaju, kritiziraju i sintetiziraju odgovore
Za slučajnog promatrača, LLM Vijeće web aplikacija izgleda gotovo identično kao ChatGPT. Korisnik upisuje upit u okvir za razgovor. Ali iza kulisa, aplikacija pokreće sofisticirani tijek rada u tri faze koji odražava način na koji rade ljudska tijela koja donose odluke.
Prvo, sustav šalje korisnikov upit panelu graničnih modela. U zadanoj konfiguraciji Karpathyja, to uključuje OpenAI GPT-5.1Googleov Gemini 3.0 ProAnthropic’s Claude Sonet 4.5i xAI Grok 4. Ovi modeli paralelno generiraju svoje početne odgovore.
U drugoj fazi, softver obavlja kolegijalnu provjeru. Svaki model dobiva anonimizirane odgovore svojih kolega i od njih se traži da ih ocijeni na temelju točnosti i uvida. Ovaj korak pretvara AI iz generatora u kritičara, namećući sloj kontrole kvalitete koji je rijedak u standardnim interakcijama chatbota.
Konačno, imenovani "Predsjednik LLM" — trenutačno konfiguriran kao Googleov Gemini 3 — prima originalni upit, pojedinačne odgovore i rangiranje od kolega. On sintetizira ovu masu konteksta u jedan, autoritativan odgovor za korisnika.
Karpathy je primijetio da su rezultati često bili iznenađujući. "Prilično često, modeli su iznenađujuće voljni odabrati odgovor drugog LLM-a kao bolji od njihovog," napisao je na X (bivši Twitter). Opisao je korištenje alata za čitanje poglavlja knjige, primijetivši da su modeli dosljedno hvalili GPT-5.1 kao najpronicljiviji, dok su Claudea ocjenjivali najnižom ocjenom. Međutim, Karpathyjeva vlastita kvalitativna procjena odudarala je od njegova digitalnog vijeća; pronašao je GPT-5.1 "previše riječi" i preferirao je "sažeti i obrađeni" izlaz Blizanaca.
FastAPI, OpenRouter i slučaj za tretiranje graničnih modela kao zamjenjivih komponenti
Za tehničke direktore i arhitekte platformi, vrijednost LLM Vijeće ne leži u njegovoj književnoj kritici, već u njegovoj konstrukciji. Repozitorij služi kao primarni dokument koji točno pokazuje kako moderni, minimalni AI stog izgleda krajem 2025. godine.
Aplikacija je izgrađena na "tanak" arhitektura. Pozadina koristi FastAPImoderna Piton framework, dok je frontend standard Reagiraj aplikacija izgrađena s Vite. Pohranom podataka ne upravlja složena baza podataka, već jednostavna JSON datoteke zapisana na lokalni disk.
Okosnica cijele operacije je OpenRouterAPI agregator koji normalizira razlike između različitih pružatelja modela. Usmjeravanjem zahtjeva preko ovog jedinog brokera, Karpathy je izbjegao pisanje zasebnog integracijskog koda za OpenAI, Googlei antropski. Aplikacija ne zna niti je briga koja tvrtka pruža obavještajne podatke; jednostavno šalje upit i čeka odgovor.
Ovaj izbor dizajna naglašava rastući trend u arhitekturi poduzeća: komoditizacija sloja modela. Tretirajući granične modele kao međusobno zamjenjive komponente koje se mogu zamijeniti uređivanjem jednog retka u konfiguracijskoj datoteci — posebno popisa COUNCIL_MODELS u pozadinskom kodu — arhitektura štiti aplikaciju od zaključavanja dobavljača. Ako novi model iz Meta ili maestral sljedeći tjedan bude na vrhu ljestvice, može se dodati vijeću za nekoliko sekundi.
Što nedostaje od prototipa do proizvodnje: Autentifikacija, redigiranje PII-a i usklađenost
Dok je temeljna logika LLM Vijeće je elegantan, također služi kao jasna ilustracija jaza između a "vikend hak" i sustav proizvodnje. Za tim koji se bavi poslovnom platformom, kloniranje Karpathyjevog repozitorija samo je prvi korak u maratonu.
Tehnička revizija koda otkriva nedostatke "dosadno" infrastrukture koju komercijalni dobavljači prodaju po vrhunskim cijenama. Sustavu nedostaje autentifikacija; bilo tko s pristupom web sučelju može tražiti modele. Ne postoji koncept korisničkih uloga, što znači da mlađi programer ima ista prava pristupa kao CIO.
Nadalje, sloj upravljanja ne postoji. U korporativnom okruženju, slanje podataka četirima različitim vanjskim pružateljima umjetne inteligencije istovremeno izaziva trenutne probleme u vezi s usklađenošću. Ovdje nema mehanizma za redigiranje osobnih podataka (PII) prije nego napuste lokalnu mrežu, niti postoji revizijski dnevnik za praćenje tko je što pitao.
Pouzdanost je još jedno otvoreno pitanje. Sustav pretpostavlja OpenRouter API je uvijek u toku i da će modeli pravovremeno reagirati. Nedostaju mu prekidači strujnog kruga, zamjenske strategije i logika ponovnog pokušaja koji drže kritične poslovne aplikacije u radu kada pružatelj usluga pretrpi prekid rada.
Ti izostanci nisu nedostaci u Karpathyjevom kodu — on je izričito izjavio da ne namjerava podržati ili poboljšati projekt — ali oni definiraju ponudu vrijednosti za tržište komercijalne AI infrastrukture.
Tvrtke poput LangChain, AWS Bedrocka razni startupi AI gatewaya u biti prodaju "otvrdnjavanje" oko temeljne logike koju je pokazao Karpathy. Oni pružaju sigurnost, vidljivost i omote usklađenosti koji sirovu orkestriranu skriptu pretvaraju u održivu poslovnu platformu.
Zašto Karpathy vjeruje da je kod sada "efemeran" a tradicionalne softverske biblioteke su zastarjele
Možda najprovokativniji aspekt projekta je filozofija prema kojoj je izgrađen. Karpathy je razvojni proces opisao kao "99% vibrirano," što implicira da se uvelike oslanjao na AI pomoćnike za generiranje koda, a ne da ga sam piše red po red.
"Kod je sada efemeran i knjižnicama je kraj, zamolite svog LLM-a da ga promijeni na koji god način želite," napisao je u dokumentaciji repozitorija.
Ova izjava označava radikalnu promjenu u sposobnosti softverskog inženjeringa. Tradicionalno, tvrtke grade interne biblioteke i apstrakcije za upravljanje složenošću, održavajući ih godinama. Karpathy predlaže budućnost u kojoj se kod tretira kao "promptable skele" — za jednokratnu upotrebu, AI ju je lako prepisati i nije zamišljeno da traje.
Za donositelje odluka u poduzećima ovo predstavlja teško strateško pitanje. Ako interni alati mogu biti "kodirana vibra" za vikend, ima li smisla kupovati skupe, krute softverske pakete za interne tijekove rada? Ili bi platformski timovi trebali osnažiti svoje inženjere da generiraju prilagođene, jednokratne alate koji odgovaraju njihovim točnim potrebama za djelić cijene?
Kada AI modeli procjenjuju AI: Opasan jaz između preferencija strojeva i ljudskih potreba
Osim arhitekture, LLM Vijeće projekt nenamjerno baca svjetlo na određeni rizik u automatiziranoj implementaciji AI: razlika između ljudske i strojne procjene.
Karpathyjevo opažanje da su njegovi modeli preferirali GPT-5.1, dok je on preferirao Gemini, sugerira da AI modeli možda imaju zajedničke predrasude. Oni mogu dati prednost opširnosti, specifičnom oblikovanju ili retoričkom samopouzdanju koje nije nužno u skladu s ljudskim poslovnim potrebama za sažetošću i točnošću.
Kako se poduzeća sve više oslanjaju na "LLM-kao-sudac" sustava za procjenu kvalitete njihovih botova koji su okrenuti klijentima, ova razlika je važna. Ako automatizirani ocjenjivač dosljedno nagrađuje "riječit i razvučen" odgovori dok ljudski klijenti žele koncizna rješenja, metrika će pokazati uspjeh dok zadovoljstvo kupaca pada. Karpathyjev eksperiment sugerira da je oslanjanje isključivo na umjetnu inteligenciju za ocjenjivanje umjetne inteligencije strategija prepuna skrivenih problema s usklađivanjem.
Što timovi za poslovne platforme mogu naučiti iz vikend hakiranja prije nego izgrade svoj stack 2026
U konačnici, LLM Vijeće djeluje kao Rorschachov test za AI industriju. Za hobiste, to je zabavan način čitanja knjiga. Za dobavljača je to prijetnja, koja dokazuje da se temeljna funkcionalnost njihovih proizvoda može replicirati u nekoliko stotina redaka koda.
Ali za lidera u tehnologiji poduzeća, to je referentna arhitektura. Demistificira sloj orkestracije, pokazujući da tehnički izazov nije u usmjeravanju upita, već u upravljanju podacima.
Kako platformski timovi budu ulazili u 2026., mnogi će se vjerojatno zateći kako bulje u Karpathyjev kod, ne da bi ga implementirali, već da bi ga razumjeli. To dokazuje da strategija s više modela nije tehnički nedostižna. Ostaje pitanje hoće li tvrtke same izgraditi sloj upravljanja ili će platiti nekome drugome da ga omota "kod vibracije" u oklopu poslovnog razreda.

