Sådan holder du din egen AI-innovationsdag

Den ærlige guide til et hands-on byg-event hvor dit team løser et rigtigt problem med AI på én dag

Jeg har samlet alt det jeg selv bruger til at facilitere en AI-innovationsdag i denne guide. Du kan bruge den til at køre din egen. Jeg holder ikke noget tilbage, for jeg tror på, at jo flere der oplever hvad AI faktisk kan i deres egen hverdag, jo bedre. Vil du have hjælp, er jeg kun en besked væk, men du kan komme langt selv med det her.

Først: vær ærlig om hvad en innovationsdag er (og ikke er)

En innovationsdag er en byg-dag: et lille team tager ét konkret problem fra jeres egen hverdag og bygger en fungerende prototype på det med AI-værktøjer i løbet af en dag. Med vibe coding når I længere end de fleste tror. I går ikke fra dagen med en skitse, men med en demo-bar løsning på én værdifuld feature, I kan se virke. En reel andel af de cases der bygges på den slags dage, ender med at komme i drift bagefter.

Vær samtidig ærlig om hvad det ikke er: ikke et færdigt, produktionsklart system fra dag ét. I står med en prototype af én feature plus en klar vej videre, ikke en hærdet løsning. Den ærlighed fjerner presset der ellers skræmmer ikke-tekniske deltagere væk, uden at I behøver at tale dagen ned.

Den vigtigste indsigt i hele guiden: succes afgøres FØR og EFTER dagen, ikke på selve dagen. Bruger I ikke tid på forberedelse, går de første timer med adgangs-bøvl i stedet for at bygge. Aftaler I ikke en vej videre, dør prototyperne stille i ugerne efter. Begge dele kan I designe væk fra start, og resten af guiden viser hvordan.

Format og hold

• Fuld dag (ca. 7 timer, 09 til 17). Ikke halv dag (for lidt tid til at lære værktøjet og bygge), ikke to dage (for tungt til en førstegang).
• Hold på 3 til 5 personer, mindst én ikke-teknisk pr. hold. De ikke-tekniske former ofte casen bedre end den tekniske udførelse gør.
• 8 til 20 deltagere i alt er en god ramme.
• Facilitering: i jeres skala kan én facilitator klare dagen, hvis builds holdes enkle (se punkt 4) og adgang og data er sat op på forhånd. Hav jeres egen IT på standby på dagen. Først ved større hold eller meget tekniske cases giver en ekstra mentor mening.

Vælg den rigtige case (det her er 80% af slaget)

Når AI skriver koden, er flaskehalsen ikke længere at kode, men at vide præcis hvad der skal bygges. Brug derfor god tid på at ramme den ene rigtige feature.

• One-User, One-Problem. Kollaps et vagt tema til én bruger + ét problem + én løsning. Ikke «vi har data-rod», men «en travl sagsbehandler ved ikke hvilke mails der haster, så hun skal bruge en app der scorer og sorterer indbakken».
• Gør det SMART: specifikt, målbart, opnåeligt, relevant, tidsbundet.
• «If the judge can't see it, don't build it.» Vælg én synlig, demo-bar kerne-feature der løser hovedsmerten. Drop alt andet.
• 10-minutters feasibility-tjek før I committer: (1) Kan vi demo'e det visuelt? (2) Kræver det data vi ikke har? (3) Kan vi bygge «the magic moment» med no-code/AI? Og beslut eksplicit hvad I IKKE bygger (fx «ingen login-skærm»).

Værktøjer (vælg nul-installations-værktøjer)

Vælg browser-baserede vibe coding-værktøjer, så der intet er at installere, og så et hold af ikke-udviklere kan få en fungerende app (ikke bare en pæn skærm) på få timer.

• Lovable = default, «alle starter her». Pæneste UI for nul-kodere, indbygget database + auth + 1-klik hosting.
• Bolt.new = hurtigt alternativ til en delbar demo.
• Hold udvikler-IDE'er som Cursor og Claude Code ude af ikke-dev-sporet.

Den dyreste begynderfælde: credits. Alle værktøjer måler på credits/tokens, og det mest almindelige sted folk går i stå er midt i et build fordi gratis-tieren er brugt op. Pre-provisionér mindst én betalt seat pr. hold (Lovable Starter ca. $20). Undgå Replit til ukontrolleret brug, hvor prisen lydløst kan løbe op i $200+. Tjek aktuelle priser på værktøjets egen side ugen før, for de ændrer sig ofte.

Vil du dybere ned i værktøjsvalget, har jeg skrevet en guide til de fem største vibe coding-værktøjer i almindeligt dansk, baseret på 20+ uafhængige tests: hvad de kan, hvad de koster, og hvornår du vælger hvilket.

Forberedelse: 2-ugers nedtælling (hackathonet starter før hackathonet)

Alt det tekniske (adgang, data, værktøjer og API'er) skal være sat op og testet fra ende til anden ca. 2 uger før. Den hyppigste fejl er at undervurdere adgang: tilladelser tager altid længere end man tror.

Checkliste, ca. 2 uger før

• ☐Lås temaerne / kvalificér casene med deltagerne. Specifikke processer, ikke teknologi. Hver case skal have en ejer.
• ☐Opret konti pr. hold (Lovable/Bolt), mindst én betalt seat pr. hold.
• ☐Byg starter-skabeloner + 1 til 2 eksempel-projekter så ingen starter på en blank side.
• ☐Klargør 3 til 5 anonymiserede eller syntetiske datasæt pr. tema i en sandbox, med en data-ordbog i klart sprog. Default til syntetisk/anonymiseret data af hensyn til GDPR. (Tip: tal med jeres IT om hvordan et typisk datasæt for problemet ser ud, og lav et lille script der genererer syntetisk data i samme form, så I aldrig rører rigtige følsomme data på dagen.)
• ☐Sæt 2 til 4 API'er op med simpel nøgle-auth (aldrig OAuth), med spend-caps på nøgle-niveau. Test alle nøgler 24 til 48 timer før.
• ☐Skriv bedømmelses-rubrikken og del den med deltagerne på forhånd.
• ☐Aftal vejen videre + en navngiven ejer hos jer FØR dagen.
• ☐Send én briefing-pakke 48 timer før alle links, logins, skema og FAQ i én besked.
• ☐Lås 2 til 3 godkendte værktøjer/modeller ikke «brug hvad I vil» (det giver spredte, usammenlignelige resultater).

Deltagerne, før dagen: medbring én konkret proces fra eget arbejde, få adgang/logins på forhånd, læs rubrikken, og tag relevante data-eksempler eller før-tal med.

Køreplanen time-for-time

Undervisning FØR build er bevidst: deltagerne skal se «the magic moment» før de selv kan ramme den.

Roller på dagen

• Facilitator (én person er nok): rammesætter dagen, introducerer værktøjet, går rundt og hjælper holdene i gang, tvinger scoping til én feature, og holder energien. Det er rollen du selv kan stå i.
• Deltagerne er domæne-eksperterne: de kender problemet og former casen. I behøver ikke en separat forretnings-mentor.
• IT på standby: aftal med jeres egen IT, at de kan give hurtig adgang på dagen, så ingen blokeres af en adgangs-ticket. Det aftales på forhånd, det er ikke en bemandet rolle.

Demo og bedømmelse

• 3 til 4 minutter pr. hold, live demo frem for pitch. I bedømmes på hvad I byggede, ikke hvor god jeres pitch er.
• Rubrik (vis ved kickoff): forretnings-impact · fungerer end-to-end · vej til adoption (pilot inden 90 dage) · risiko-profil · demo-klarhed for en ikke-teknisk sponsor.

Efter dagen: vejen til værdi (her fejler de fleste)

Prototyper dør uden en sponsor og en vej fremad. Design det ind fra start:

• Navngiven ejer hos jer, ansvarlig for opfølgning, aftalt før dagen.
• Beslutningstager/budget-ejer involveret allerede i idé-fasen, så der er en sponsor på dag ét.
• Behandl al kode som en prototype, ikke som færdig produktionskode. 62% af AI-byggede apps har kritiske sårbarheder. Intet i produktion uden et sikkerhedsreview. Ingen hardcodede nøgler.
• Rut 1 til 2 vindende cases ind i et rigtigt pilot-forløb.
• Lever en kort efter-rapport: hvad blev bygget, hvad er det værd, anbefalet næste skridt.

De typiske faldgruber, og hvordan du undgår dem