Vi julstökar bäst tillsammans.

Två spår. Du väljer.

Eget hantverk: för dig som gillar att klura själv och vill hålla kunskaperna igång. Vässa problemlösningen och prova ett språk du vill bli bättre på. Du skriver lösningen, testerna och dagens Dockerfile. Generativ AI används inte för att producera lösningen i det här spåret.

Automatiserat agentsystem: du bygger och konfigurerar systemet som hämtar dagens uppgift och personliga indata, skriver kod, testar, rättar fel, lämnar svaret till AoC och publicerar lösningen. Målet är ett automatiserat flöde med så lite mänsklig inblandning som möjligt.

Du kan publicera lösningar i båda spåren. AoC registrerar däremot bara ett godkännande per konto och del. Våra spår beskriver arbetssättet; de är inte två oberoende AoC-resultat.

Du bygger systemet. Systemet driver flödet.

AI-assisterad problemlösning innebär att du själv driver arbetet och ber en modell om hjälp längs vägen. I agentspåret övar vi på att låta systemet driva det arbetet. Det ska kunna ta nästa steg, använda testresultat och försöka igen inom de gränser du har satt.

Du får gärna använda AI när du bygger agentsystemet. Välj verktyg och modeller själv; det viktiga är hur flödet fungerar efter start. Att manuellt chatta fram dagens lösning är AI-assisterad problemlösning och uppfyller inte i sig målet för agentspåret.

Börja med ett steg och bygg vidare. Försök som behöver din hjälp är också välkomna på vägen mot målet. Beskriv i README vilka steg systemet klarar, när du ingrep och vad du vill automatisera härnäst. Skilj på ett försök med mänsklig hjälp och en körning som klarade sig själv.

Ett repo som går att förstå

Agentens återanvändbara kod ligger i agent/. Dagslösningar ligger under exempelvis days/01/manual/ och days/01/agent/. I varje dagslösning finns src/, tests/, en Dockerfile och README. src/ hittas automatiskt; du behöver ingen config-fil.

Körmiljön tar in data via stdin och väljer del med --part 1 eller --part 2. Dokumentera hur din lösning byggs och körs. Egen gemensam kod ligger i shared/ och ingår i redovisningen av lösningens omfattning.

Dockerfile beskriver språk, beroenden och hur programmet startas. Den gör det lätt för andra att klona ditt repo och prova lösningen med Docker. I våra dag-1-exempel körs testerna när imagen byggs, och det finns egna små testdata att prova med. Personliga AoC-indata skickas in vid körning och ska aldrig byggas in i imagen.

Vår tjänst analyserar koden statiskt och mäter i dagsläget ingen exekveringstid. Du kan experimentera med körtid lokalt enligt exemplens README. I agentspåret kör dagens container den producerade lösningen; instruktionerna för att starta själva agentsystemet finns separat i agent/.

Skriv en README som visar installation, körkommandon och tester från en ny klon. För agenten delar du också instruktioner, modellval och hur flödet kan ändras. Berätta vad du lärde dig och var någon annan kan börja bygga vidare. Från topplistorna kan andra klicka direkt till ditt publika GitHub-repo.

För att delta ska du utgå från vårt startrepo, med färdigkonfigurerade GitHub Actions som registrerar repot och publicerar lösningarna. Skapa ditt repo från vår GitHub-mall och följ checklistan. Guiden till startrepot går igenom varje fil och hur allt hänger ihop. Använd ett separat repo för varje år; ange rätt år i advent.json. Mallen börjar med övningsåret 2025.

Tjuvstarta med 2025

Du behöver inte vänta på december. 2025 års kalender är öppen. Prova Docker, bygg på agenten och se att allt fungerar. Börja med övningsåret 2025.

Varje år har en egen topplista och egna kodversioner. Även övningslösningar behöver ett godkänt svar hos AoC innan vi analyserar dem. Första pushen registrerar ditt repo. Vi kontrollerar att ditt angivna AoC-ID finns i gruppen. Du behöver inte logga in på vår sajt.

Rätt svar först. Sedan analys.

Vi hämtar gruppens resultat från AoC. När ditt svar har godkänts för rätt dag och del kan vi analysera din kod. GitHub Actions talar om exakt vilken commit du pushade, så att analysen hör till rätt version.

AoC godkänner ditt svar. De granskar eller kör inte koden i ditt repo.

Fortsätt fila på lösningen

Förbättra koden och pusha igen. Den nya versionen kan få en ny analys, och den gamla finns kvar att jämföra med. Samma commit räknas bara en gång.

Vi sparar också vilken version av analysverktyget som användes. AoC-stjärnor räknas bara en gång. Inlämningstiden påverkar ingen placering.

Så läser du topplistorna

Fyra listor, fyra saker att prova. Inlämningstid ger inga poäng. Lika resultat ger delad placering, med namnen i bokstavsordning.

• Stjärnor: antal godkända delar enligt AoC. Stjärnorna hör till kontot och är gemensamma för båda spåren.
• Kodrader: jämför samma år, dag och del. Alla visar både hantverk och agent, med en märkt rad per deltagare och spår. Du kan också filtrera på ett spår. Vi räknar icke-tomma fysiska rader inklusive kommentarer i src/ (eller valda källkodsmappar) och deklarerad egen kod i shared/. Färre rader hamnar högre. Senaste färdiganalyserade kodversionen används; en förbättring kan alltså ändra listan. Tester, Docker/infrastruktur och agentramverk visas separat. Kod för båda delarna i samma mapp räknas som en hel lösning, även om bara en del är vald.
• Språk: antal olika identifierade språk i årets analyserade lösningar, inklusive tidigare versioner. Vi använder Linguists språkdefinitioner för att identifiera språk i lösningens källfiler. Tester, ramverk och språk som bara nämns i README räknas inte. Läs mer om identifieringen nedan.
• AI-modeller: antal unika par av leverantör och modell-ID i analyserade agentlösningars run.json. Samma modell i flera dagar räknas en gång. Rapporten är självrapporterad och länkas från listan till exakt analyserad commit. Olika alias kan avse samma underliggande modell; detta är en utforskningslista, ingen verifierad modellbenchmark.

Agentverktyg och modeller är olika saker. Exempelvis kan samma verktyg byta modell mellan anrop. Låt agentens adapter skriva modell-ID från API-svaret till run.json, tillsammans med leverantör, verktyg och eventuell tokenstatistik. Om exakt modell-ID saknas lämnar du modellistan tom. Okända mätvärden är null.

GitHub bekräftar repot och kodversionen. Varken GitHub eller AoC bevisar vilken modell som användes. Därför märker vi modelluppgifterna som självrapporterade. Rapportera aldrig API-nycklar, uppgiftstext, indata eller råa konversationer.

Nästa år finns det kvar

2026 drar vi igång. Med 2025 års pussel kan vi värma upp redan nu. När nästa december kommer finns tidigare stjärnor, kodversioner och analyser kvar under Historik.

En push räcker

Pushflödet registrerar dina ändrade dagslösningar, utan inputfiler. Vi kontrollerar vilket repo de kommer från. Första gången läser vi ditt AoC-ID från repot och kontrollerar medlemskapet i gruppen vid nästa synk. Därefter räcker en push för att registrera ny kod. Analysen väntar tills rätt svar är godkänt hos AoC.

Vi läser koden för statisk analys. Deltagarnas program körs inte på vår server.

Synken hämtar AoC högst en gång per 15 minuter och kan behöva vänta längre om AoC ber om det. Resultatsidan läser lagrade data och gör inga egna anrop till AoC. Senare pushar skapar nya kodversioner. Återkörning med samma commit skapar inga dubbletter.

Prova våra exempel

I startrepot finns två exempel för 2025 dag 1, med tester, Dockerfile och körinstruktioner. Båda är framtagna med AI-stöd. Agentexemplet visar hur en producerad dagslösning kan se ut; det är inget färdigt automatiserat agentsystem. Exemplen ligger utanför days/ och räknas inte som dina egna lösningar. Prova gärna uppgiften själv innan du öppnar dem, eftersom de innehåller spoilers.

Så identifierar vi språken

Workern använder GitHub Linguists språkdefinitioner, via det versionslåsta paketet linguist-languages. Den jämför filnamn, filändelser och eventuell shebang: första raden i ett skript, till exempel #!/usr/bin/env python3. För .rs används även Linguist-baserade innehållsregler för att skilja Rust från RenderScript.

Det är en lättare identifiering med Linguists data, inte hela GitHubs Linguist-motor. Vi kör ingen kod och använder inte GitHubs språkfördelning för hela repot, eftersom den även kan innehålla tester, exempel och agentramverk. Tvetydiga eller motstridiga träffar lämnas okända. Exempelvis kan .h höra till flera språk. Okända språk ger inga språkpoäng, men deras källfiler räknas fortfarande i kodraderna.

Endast icke-tomma filer i lösningens källkodsmappar ger språkpoäng. Ett språk räknas en gång per deltagare och år, även om det förekommer i många filer, dagar eller förbättrade versioner. Tester, delad hjälpkod och själva agentramverket ger inga extra språkpoäng. Identifieringen bevisar inte att koden faktiskt körts.

På Topplistor → Språk finns ett ordmoln. Varje ords storlek visar hur många deltagare som har använt språket under valt år och spår, bland AoC-godkända, färdiganalyserade lösningar. Tidigare analyserade versioner ingår, men samma person räknas bara en gång per språk. Antalet står också i klartext.

Se ordmolnet och språklistan · Vad krävs för färdig analys?