Hackday i AI-eran

På jobbet kör vi två hackdays per år. En inför sommaren, en inför julen. Det är en dag där vi får bygga vad vi vill, testa nya tekniker, eller fixa den där grejen som aldrig får prioritet i sprintplaneringen.

Tidigare har tankarna inför en hackday sett ungefär likadana ut. Man har en idé, kanske lite väl ambitiös, och frågar sig: Hinner jag verkligen koda klart det här på en dag? Hinner jag researcha dokumentationen tillräckligt? Blir det bara ett halvfärdigt proof of concept?

Hur det brukade vara

Jag minns en tidigare hackday där jag ville migrera en av våra frontend-tjänster från vanilla Redux till Redux Toolkit. Jag valde medvetet en av de mindre tjänsterna, mindre kod att ändra. Ändå gick halva dagen åt till att läsa dokumentation. Hade jag gjort samma sak idag hade jag bett Claude ansluta till context7 MCP-servern för att läsa up-to-date dokumentation om Redux Toolkit, titta på befintlig implementation, och sedan sköta migreringen åt mig.

Men något hände på vår senaste hackday, den innan julledigheten. Något hade skiftat.

Hela teamet gick all-in

I princip alla utvecklare i vårt team hade samma approach: vibe-coding med AI. Inte som ett experiment eller en gimmick, utan som det primära sättet att få saker gjorda.

Mitt projekt: Ett CLI i React

Inför hackdayen frågade jag Claude om inspiration. Vi har ett CLI vi använder dagligen för att snurra igång vår lokala utvecklingsmiljö - Docker-containers för frontend, backend, och alla tjänster i vårt monorepo. Det gamla CLI:et hade tjänat oss väl, men det hade samlat på sig en del legacy. Gamla beroenden, föråldrad TypeScript-konfiguration, och kod jag ärligt talat inte hade så bra koll på.

Claudes förslag? Skriv om hela CLI:et med Ink - ett bibliotek för att bygga CLI-gränssnitt med React. Rendera komponenter direkt i terminalen. Det lät kul.

Men att skriva om ett helt CLI på en dag? Med en kodbas jag inte hade full koll på, och Docker-hantering som inte direkt är min starkaste sida? Det lät inte realistiskt. Men också utmanande och roligt.

Förberedelserna gjorde skillnaden

Istället för att hoppa in huvudstupa bad jag Claude skapa en utförlig migreringsguide några dagar innan hackdayen. Inte vag eller övergripande, utan konkret och fasindelad. Resultatet blev en markdown-fil på cirka 4 000 rader.

Planen innehöll:

• Tydliga faser med specifika mål
• En markerad brytpunkt för MVP
• Vilka features som måste fungera för att det skulle vara värt att mergea
• Vilka features som var nice-to-have

Jag committade planen till en branch och lät den vänta.

Hackday: Exekvering fas för fas

När hackdayen började checkade jag ut branchen med migreringsplanen och bad Claude jobba utifrån den. Fas efter fas betade vi av planen, med mindre justeringar längs vägen. Ibland bad jag Claude ta ett steg tillbaka och granska koden vi redan hade, leta efter saker att refaktorera eller förenkla.

I slutet av dagen hade vi ett nytt CLI byggt med Ink. Modernare arkitektur, några nya features, och en hel del kod jag inte granskat tillräckligt noga. Det sista visade sig vara ett problem.

Vem skrev koden?

Jag hade inte skrivit en enda rad kod själv. Men jag hade guidat Claude att följa samma patterns och struktur som vi använder i resten av repot.

Det nya normalläget

En tanke slog mig under dagen. Det här är nog så våra hackdays kommer se ut framöver.

Frågan inför hackdays är inte längre “Hinner jag koda klart det här själv?” utan snarare “Hur mycket av det här vågar jag lita på efteråt?”

Spelar det någon roll?

I slutändan hade jag inte nödvändigtvis bättre koll på koden i v2 jämfört med v1. Jag hade trots allt inte skrivit den själv. Jag agerade kravställare och testare, men det är inte samma sak som att förstå varje beslut i koden.

Det märktes under veckorna efter hackdayen. Småsaker dök upp som behövde justeras, och varje gång fick jag sätta mig in i kod jag inte skrivit. Det gick, men det var inte friktionsfritt.

Spelar det så stor roll vem som skrev koden? Kanske inte. Men det spelar roll att någon förstår den.