Alle artikler
Prototyping7 min læsning

Hvordan bygger et team en fungerende AI-prototype på 48 timer?

Et team bygger en AI-prototype på 48 timer ved at holde sig til ét problem, én AI-behandling og én klar demonstration. Her er metoden, forløbet og de typiske fejl.

Af Jarle Kondrup, innovationsekspert og partner, Innovation LabOpdateret · Først udgivet

Nøglepunkter

  • 87% af de teams, vi faciliterer, har en fungerende prototype inden for 48 timer.
  • En hackathon-prototype skal kunne demonstreres for et publikum, ikke være klar til drift.
  • Formlen der virker: ét input, én AI-behandling, ét resultat.
  • Teams, der fejler, bygger næsten altid for meget og øver for lidt.

Et team bygger en fungerende AI-prototype på 48 timer ved at vælge ét afgrænset problem, lade AI løse én tydelig opgave og bruge den sidste del af tiden på at øve demonstrationen i stedet for at bygge mere. Hos os har 87% af teams en fungerende prototype inden for 48 timer, og forskellen på dem, der når det, og dem, der ikke gør, ligger sjældent i tekniske evner.

Hvad er en hackathon-prototype?

En hackathon-prototype er ikke færdig software. Den skal ikke håndtere alle tænkelige situationer, den skal ikke se poleret ud, og den skal ikke kunne bruges af hundrede personer på én gang. Den skal overbevise et rum fuld af mennesker om, at idéen virker og er værd at arbejde videre med.

Det lyder enkelt, men mange teams bruger første halvdel af hackathonet på at bygge for meget, fordi de tænker på det færdige produkt i stedet for på demonstrationen. Det er den fejl, der koster flest timer.

En stærk prototype kan demonstreres på tre til fem minutter. Den løser ét konkret problem og bruger rigtige data eller data, der ligner rigtige. AI-delen er til at forstå for et publikum uden teknisk baggrund.

Hvilken formel virker bedst?

Hold det simpelt: ét input, én AI-behandling, ét resultat.

Prototypen modtager noget, AI gør noget med det, og resultatet vises. Intet mere. Teams, der holder sig til den formel, har typisk den bærende del klar på første dag og kan bruge resten af tiden på at gøre demonstrationen overbevisende.

To eksempler på den type prototype, vi ofte ser:

Overblik over kundeanmeldelser. Input: kundeanmeldelser fra butikkerne. AI-behandling: sortering efter tema og opsummering. Resultat: et dagligt overblik på mail til butikscheferne.

Samtaleguide til rekruttering. Input: en jobannonce. AI-behandling: analyse af rollen og forslag til spørgsmål. Resultat: en færdig samtaleguide, der passer til netop den stilling.

Ingen af dem er teknisk komplekse. De virker, fordi de løser et reelt problem på en måde, alle i rummet forstår med det samme.

Hvilke værktøjer skal teamet bruge?

Vælg værktøjer efter de evner, teamet faktisk har.

Ingen teknisk baggrund? Brug AI-chatværktøjer som ChatGPT eller Claude til tekst og analyse, og kodefri automatiseringsværktøjer som n8n eller Make til at forbinde trinnene. Ingen af dem kræver, at man kan kode. Et team med forretningsforståelse og en skarp problemformulering kan bygge overraskende stærke prototyper på den måde.

Lidt teknisk erfaring? AI-værktøjer som Claude kan bygge en fungerende brugerflade ud fra en beskrivelse. I beskriver, hvad I vil se, og AI laver det. Resultatet er godt nok til at vise frem.

Udviklere på holdet? Brug dem til at bygge det bindeled, der gør prototypen troværdig, men hold arkitekturen enkel. De dygtigste udviklere i et hackathon vælger bevidst den enkle løsning og bruger den sparede tid på at gøre demonstrationen fejlfri.

Et team af forretningsfolk, der forsøger at bygge som udviklere, ender typisk med hverken en god prototype eller en god demonstration. Læs mere om værktøjerne på siden om AI-automatisering i hackathons.

Hvordan fordeles de 48 timer?

Forløbet følger det samme mønster uanset branche. Her er det vist for et 2-dages AI hackathon, hvor der går 48 timer fra start til præsentation.

Dag 1, de første par timer: problemet. Hvilket problem skal løses? Hvem rammes? Hvordan ser vi, at det er løst? Teams, der giver sig tid her, klarer sig næsten altid bedre end dem, der skynder sig videre.

Dag 1, resten af formiddagen: én idé. Teamet vælger ét koncept. Ikke to, og ikke "vi laver begge og ser". Fra nu af går al energi til den ene idé.

Dag 1, eftermiddag: kernen bygges. Input virker, AI giver et fornuftigt resultat, og resultatet vises. Ikke mere.

Dag 2, formiddag: finpudsning. Hvad ser forkert ud? Hvad forvirrer? Hvor går demonstrationen galt? Skift testdata ud med rigtige data, hvis det er muligt. Natten imellem er ikke spildt: mange teams kommer tilbage med et klarere blik for, hvad der skal skæres væk.

Dag 2, eftermiddag: generalprøve og præsentation. Der bygges ikke nyt. Demonstrationen øves mindst to gange i fuld længde, med det udstyr og i det lokale, hvor den skal vises. Teams, der stadig tilføjer funktioner til sidst, fejler næsten altid ved præsentationen.

Har I kun én dag, gælder samme rækkefølge i komprimeret form. På et 1-dags AI hackathon bruger teams den første time på problemet, bygger kernen i løbet af dagen og øver den sidste time.

Hvilke fejl koster prototypen?

For mange funktioner. Teams, der vil vise seks ting, viser ingen af dem overbevisende. Skær til, og byg ét øjeblik, publikum ikke kan overse.

Ingen testdata klar. En prototype, der afhænger af direkte adgang til et driftssystem, går galt under demonstrationen. Stærke prototyper har realistiske testdata klar fra starten.

Ingen generalprøve. Teams, der ikke har kørt demonstrationen fra ende til anden mindst to gange, støder på noget, der går galt under pres.

Forkert ambitionsniveau. Vælger et team den teknisk komplicerede løsning, fordi den lyder imponerende, går halvdelen af tiden med at lære nye værktøjer. Den enkle løsning, der virker hver gang, slår den avancerede, der hakker.

Hvad afgør, hvilken prototype der vinder?

Den vindende prototype er sjældent den mest avancerede. Den vinder, fordi problemet er til at forstå, løsningen er tydelig, og demonstrationen kører uden fejl.

Juryer og ledere vurderer ikke teknisk kompleksitet. De spørger sig selv, om løsningen kan løse et reelt problem, og om de kan se den i drift. Det kræver klarhed.

48 timer er nok, hvis I er præcise om, hvad I bygger, og holder fast i det enkle.

Hvad sker der før og efter prototypen?

En prototype er aldrig bedre end den udfordring og den idé, den bygger på. Artiklen om at vælge den rigtige udfordring til et AI hackathon viser, hvor det hele starter, og guiden til idéudvikling med AI viser, hvordan teams finder og vælger idéen.

Når prototypen er bygget, er næste spørgsmål, hvordan den kommer i drift. Med en struktureret opfølgning er 3 ud af 5 prototyper i drift inden 90 dage. Hvordan opfølgningen skrues sammen, står i guiden til facilitering af AI hackathons, og hvordan I beregner værdien, står i artiklen om afkast af AI hackathons.

Klar til at prøve det i praksis?

Kontakt os for en snak om et AI hackathon til jeres virksomhed.

Få en snak om jeres AI hackathon