SÅDAN VIBE-KODER DU SIKKERT — PROMTE Transskription af den redigerede video. [00:00:00] Sådan vibe-koder du sikkert [00:00:04] I dag der skal vi kigge lidt på generelt, hvad vibe-kodning er og kan. Og så skal vi helt konkret vise et nyt produkt fra Promte, som er Promte Kodning. Som er et vibe-kodningsværktøj til det, vi kalder samfundskritiske organisationer. Men inden vi gør det, så vil jeg lige præsentere, hvem vi er fra Promte her på kaldet. [00:00:27] Men dem, vi har på kaldet fra Promte i dag, det er blandt andet Christian. Som er teknisk ansvarlig her i Promte og har arbejdet med AI meget længe. og anvender agentisk kodning hver dag til at bygge videre på vores produkt og tilføje funktioner til det. Jeg selv er kommercielt ansvarlig i Promte og har været med til at implementere Promte og generelt AI på tværs af en række offentlige organisationer og større virksomheder i Danmark i løbet af de seneste år. Jeg er måske lidt nyere til vibe-kodning. Jeg har prøvet at vibe-kode blandt andet de her slides og vores hjemmeside og sådan nogle ting. Så det er sådan lidt mit perspektiv ind i det. Og så har vi allieret os med vores gode medstifter Victor, som kommer til at være chat-moderator i dag. Så det vil sige, alt hvad I skriver i chatten, det vil han sørge for, at vi får fulgt op på. Så det er hans stemme, I hører, hvis der lige bliver brudt ind undervejs i min eller Christians talestrøm. Så er det ham der lige kan sikre at vi får jeres spørgsmål med. Så endelig bare brug chatten som sagt undervejs. [00:01:45] Men inden vi går i gang, så kan man sige sådan helt konkret at kigge på vibe-kodning, så kan man sige at Promte er den her fælles modulære AI-platform. Og vi har teamet her, og vi bygger vores løsning på nogle principper, som vi har prøvet at beskrive her til højre. Så først og fremmest så er løsningen udviklet i fællesskab med vores brugere. Så det er i tæt samarbejde med vores kunder, at vi bliver ved med sådan at finde på nye funktionaliteter og udvikle vores produkt. Og høre, hvilke problemstillinger der er derude, så prøver vi at komme med løsninger i samarbejde med vores kunder. Og det er sådan kommuner, styrelser og virksomheder og større virksomheder. De funktioner, vi bygger på Promte, og det er også noget som Promte Kodning her, det bliver gjort tilgængeligt for alle. Og når der kommer opdateringer på de løsninger, så bliver det også gjort tilgængeligt løbende. Så det er sådan set, at hvis man som en kunde har et problem, og vi løser det, så kommer det alle andre kunder til gode også. Så på den måde bliver platformen ved med at udvikle sig, efter man er kommet ombord. Vi har også set, at især i det offentlige er der et stort potentiale i at kunne samarbejde på tværs. Det gør sig også især gældende her med vibe-kodning, at hvis man bygger en god app, en god løsning til et eller andet problem, så er det jo tosset, at det kun kan komme én organisation til gode. Så især inden for det offentlige, så giver det her med at kunne dele applikationer på tværs en rigtig god mening. Det har vi allerede understøttet med et bibliotek inde på Promte, som er fyldt med AI-assistenter og AI-agenter, her til at starte med, gennem de sidste år eller to. Men nu begynder det så også at være AI-apps og AI-produktivitetsværktøjer, som bliver delt herinde på tværs. Så det er vi rigtig glade for at se, og det fortsætter vi selvfølgelig med. Og alle de her ting, det gør så, at platformen ligesom også er i stand til at følge med den udvikling, der er i AI, og der kan man sige, at vi er gået fra at lave assistenter og agenter, til nu ligesom at have det her vibe-kodning også med inde i platformen. Så på den måde håber vi sådan at kunne understøtte de mange trends, der er inden for generativ AI. de kunder, vi arbejder med her, som er med til at udvikle platformen hver dag. Helt konkret så er der sådan et overblik her over vores løsning, og det er bare sådan, at I har en fornemmelse af, hvad man kan lave herinde. Og mange af de værktøjer, som vi har, det er også med til at understøtte det, man så i dag kan bygge med det her vibe- kodningsværktøj. Så tingene begynder ligesom at kunne tale sammen på tværs, og nogle af de fx integrationer, vi har brugt lang tid på at lave, det kan lige pludselig anvendes inde i det her vibe-kodning også. Og det her governance-lag, der går på tværs af alle de her løsninger, det er så også noget, der kan være med til at give en større form for sikkerhed og kontrol, når man gerne vil begynde at bruge vibe-kodning i sin organisation. [00:04:41] Hvad er vibe-kodning? [00:04:44] Yes. Godt. Men hvad er vibe-kodning, og hvad er ligesom mulighederne i det? Lad os kigge på det sammen her, inden vi går i demo-mode. Så vibe-kodning er helt basalt set den her mulighed for, at man kan beskrive med ord, hvad det er, man godt kunne tænke sig bygget, og man egentlig ikke behøver at kunne kode selv. Så det giver lige pludselig et væld af nye muligheder, hvor det før har været afgrænset til en mindre gruppe af udviklere, der har kunnet omsætte idéer til løsninger. Så er det nu også fagpersoner, som sidder tættere på problemstillingen, der kan komme med løsninger selv og prøve selv at finde en løsning på deres problem. Så man har ligesom mulighed for at tale sig frem til, hvad det er, man gerne vil have bygget. Så man kunne f.eks. sige, at man vil have en nem beregner til, hvad et arrangement skal koste. Man ved, at hvis der kommer x antal deltagere, så skal der være så og så meget forplejning. Så kan man udvikle en beregner som en lille applikation og på den måde hjælpe en med at holde styr på det arrangement, man skal til at afholde. Prøve at lave noget først, teste løsningen, få noget feedback og så kan man rette til bagefter med de kommentarer. Helt ligesom man ville sige det til en kollega, hvis det var kollegaen, der skulle udvikle løsningen gennem gammeldags kodning, skulle jeg til at sige. Man selv har kunnet kode. Yes. Så det giver altså mulighed for ligesom at gøre en masse ting i forhold til at kunne komme tættere på nogle løsninger hurtigere. Og det er også lidt det, vi vil tale om i forhold til potentiale ved vibe-kodning. Der er flere, der kan bygge løsninger tættere på hverdagens behov. Og det vil sige, at man kan hurtigere teste nogle ting af og hurtigere finde ud af, om det her giver værdi eller ej. Så kan man sige, at processen fra tanke til handling eller fra idé til afprøvning, den bliver reduceret meget markant. Og det gør den både i forhold til tid, men selvfølgelig også i forhold til penge og ressourcer. Så man kommer altså tættere på hverdagens problemer og udfordringer, når man tager vibe-kodning i brug. Det bliver også hurtigere ligesom at teste af og afprøve sin idé og få noget feedback og så tilpasse undervejs. Så det vil sige, at man kan komme markant hurtigere hen til at vurdere, om det her giver mening at fortsætte med eller om man skal afslutte projektet. Der er også mulighed for, når man kan lave de her produktivitetsværktøjer til meget små problemer, at man pludselig kan automatisere en masse små manuelle opgaver. Hvor før i tiden har man helt sådan skulle vurdere, om det giver mening økonomisk i forhold til, hvor meget tid man kan spare. Det skal man selvfølgelig også stadig gøre med vibe-kodning, for der er stadig en udgift. Men den udgift er blevet reduceret markant. Så hvor man før også skulle gå hen til et konsulenthus og bede dem om at lave en løsning. Der kan man nu selv lave løsningen på en eftermiddag, og derfor kan man altså tillade sig at bygge løsninger til markant mindre problemer. Og det er også det sidste punkt her, at der er plads til at løse små problemer med det her vibe-kodning. Så der er altså mange potentialer i vibe-kodning, og det giver en stor mulighed for at lige pludselig lave en masse forskellige software til alle mulige små problemer. [00:07:52] Fra prototype til drift [00:07:54] Men hvad er så udfordringerne i vibe-kodning? Og det er så også noget, vi gerne vil komme ind på her. Fordi det er jo en fantastisk ny mulighed, og det åbner op for en masse nye spændende ting. Men som I nok kan forestille jer, så er der i hvert fald en del overvejelser, man skal gøre, når man tænker på sådan noget som drift fx. Hvis vi nu spoler tiden frem, og vi har en masse medarbejdere, der har lavet et hav af værktøjer, hvem skal så stå for at drifte de her værktøjer og sørge for, at de virker? Også om en måned, om et halvt år, om et år? Det er nogle af de ting, man skal overveje ind i det her. Hvem håndterer for eksempel, når der kommer en ny AI-model? Vi ser jo, at de her modeller bliver udgivet løbende og med kort mellemrum. Og hvem sørger så for at få dem opdateret og sørger for, at ens løsning kører på nogle af de nyeste AI-modeller, hvis der bliver anvendt AI i den applikation, man har bygget med vibe-kodning. Noget andet, vi kan se, det er jo også i forhold til at sidde og udvikle i Lovable eller noget andet. Jamen, hvem må gøre hvad, og hvad for noget data må vi bruge ind i det her system? Og hvordan styrer vi delingen på tværs og beskytter vores dataadgang, når vi skal lave nogle af de her systemer? Også når slutbrugerne skal have det i hænderne, kan der være forskellige brugere, der må tilgå forskellige data i de her applikationer. Så igen, hvordan laver vi et setup, der ligesom har det her governance- og styringslag på tværs, så vi sikrer, at de løsninger, vi bygger, ikke kun kan bruges af få mennesker, men faktisk kan rulles ud i en organisation og gøres på en driftssikker måde. Så er der noget i forhold til test og vedligehold af løsningen. Det er jo super nemt at lave en hurtig prototype, men hvem står for løbende at holde den ved lige, hvis tanken er, at det skal være en løsning, der skal indgå i en arbejdsgang fast? Og fx også, hvis vedkommende, der har bygget den, pludselig stopper eller bliver syg, hvem har så kendskab og viden til, hvordan løsningen fungerer og kan fortsætte dens levetid i organisationen? Sidst men ikke mindst, så er der jo noget omkring det her med overblik og økonomi. Som jeg også kom ind på, så er det jo markant billigere nu at bygge software i forhold til at skulle aktivere et konsulenthus for eksempel. Men der er jo stadig en økonomi i det i forhold til, at når man vibe-koder, så bliver der jo for eksempel brugt en masse tokens. Hvem må bruge hvor mange tokens, når de sidder og arbejder? Så hvordan styrer vi økonomien ind i det her, så vi sikrer os, at vi ikke pludselig har fået sat en AI-agent til at stå og køre? Eller at forbruget efterfølgende, når vi stiller det ud til slutbrugerne, ikke stikker af, og vi har en kæmpe regning, vi ikke havde forestillet os. Så det her med at have indblik i ens forskellige applikationer, man får bygget over tid, og kunne økonomistyre på tværs, det er også noget, der er ret vigtigt. Det var min sådan hurtige indflyvning til vibe- kodning. Og nu er planen egentlig, at vi giver ordet over til Christian, som vil vise Promte Kodning. Men inden jeg gør det, så vil jeg lige høre, om der har været nogle spørgsmål. Jeg har ikke lige mulighed for at holde øje med chatten her, Victor, så vi må lige se, om der har været noget, eller så går vi over til demoen. Yes, der er et enkelt spørgsmål, og det kan også være, at det er Christian, der skal hjælpe med at svare lidt på det. Men spørgsmålet går på, det er Jeanette fra Odsherred Kommune, der spørger, om man vil kunne overføre projekter fra Lovable til Promte. Det kan være, Christian, at du kan starte med at svare på, hvordan man kunne gøre det. Ja, det kan jeg sagtens. Ja, så det er samme teknologi, det bygger op omkring, både Lovable og Promte. Så for i hvert fald langt de fleste projekter, der burde det være rimelig lige til at rykke det over med lidt ændring af konfiguration og sådan noget. Så det burde nok være rimelig nemt. [00:11:40] Byg en app i Promte [00:11:43] Yes, ja. Så jeg prøver lige at klikke lidt rundt i vores produkt her og så vise lidt frem, hvad det er, vi har bygget her til vibe-kodning. Så til at starte med så er nu jeg inde på vores produkt i administratorinterfacet her, hvor man kan gå ind og oprette forskellige ting. Og det er mange af alle de her forskellige produkter, som, som Mathias han også kom ind på, at vi havde lige nu. Der er det, det her, det er kun slået til, at jeg kan oprette apps herinde. det er, det er, det er det eneste modul, der er, der er slået til herinde. så jeg starter lige med at prøve at lave en app her. Hvor vi skal tage det her. og så kommer jeg ligesom ind i det her app workspace, hvor jeg kan se, når jeg har en app her, så kan jeg se et preview af den her og holde øje med mine udgivelser og sådan nogle ting her. Så det, jeg især vil kigge på i dag, det er det her, kodning, som er noget af det nye, vi har lavet. hvor man kan gå ind og, og sidde og så bygge en app direkte inde på vores platform her. man starter bare med sådan en, en, demo-app her, som, når man, når man starter en ny app, som jeg har gjort nu her. Og så kan man egentlig bare gå ind, som mange nok kender det og, sidde og skrive, ligesom man kan også på Lovable og sådan noget, så sidde og chatte med, med den her agent, som der så sidder og skriver koden for en. Så jeg skal jo lave et program til et event. Og så sætter jeg den i gang. Og så er det ellers bare en... Så står den her agent her og arbejder og skriver noget kode. Og så kan jeg sidde herovre i den her live-forhåndsvisning og holde øje med, hvordan den udvikler sig, og selv give feedback på. Nu kan man se, nu begynder den at opdatere sig herhenne, og så, så kan jeg give feedback på, hvis jeg gerne vil have nogle ændringer og sådan noget til den, og sidde og prøve appen af herhenne. sidde her og så se, hvis man gerne er lidt mere interesseret i, hvad er det egentlig for noget kode, den sidder og skriver og sådan noget, så kan man også sidde og følge med i det, mens den arbejder. Så det er ligesom, man kan i, ligesom de fleste, af de her værktøjer. Så nu har den lavet en app, man kan se, hvad den har ændret, og, jeg kan se min app her, og så kan jeg sige, det ser egentlig fint nok ud, men jeg kunne godt tænke mig, at man også lige kan søge. Og så kan man ellers bare sidde og have den proces kørende, de fleste, de har nok prøvet at vibe-kode et eller andet, nu, det er jo nærmest indbygget i alle værktøjer, nu om dagen, så, det er. Det er egentlig meget det samme som det er. Det er baseret på en open source motor nedenunder her også, som også bliver opdateret løbende og følger med. Nu begynder der at komme noget søgefelt frem her. Den laver lige noget interface, og så kan jeg søge på noget. Og nu har man noget kaffe her klokken 9. Ja, så det er det basale. Så kan man sidde og gøre det. Og så når man så er færdig med at udvikle sin app her, så kan man trykke op på den her opret release. Og nu har jeg lavet sådan i det setup her, som jeg har lavet til den her demo, at når man trykker op den her opret release, så siger den. Så går den ind og laver sådan en release her. Og nu har den så fundet nogle noter her på det. [00:15:33] Yes, men ellers så går jeg bare lige videre herinde i det her styring her. Det kan være, jeg lige har kommet til at få sat noget op, som blokerer lidt mere end det skal. Men det der ellers sker som nummer to ting herinde, det er, at når jeg så opretter en release her, så kommer man ind i den her inbox her, hen i det her styringsmodul. Så det er en bruger, der er ansvarlig for de her applikationer og kan sidde og holde øje med, hvad kommer der ind af folk, som laver releases. Man kan godt slå til, at folk bare kan lave de her releases af apps selv. Men nu har jeg sat det op sådan, at der skal være en bruger, som der sidder og en administrator, som sidder og holder øje med det. Så det der ville ske, hvis den nu ikke lige var blokeret, det var, at den ville komme ind her, og så ville der stå, at den venter på at blive godkendt her. Og så får man sådan en overblik over, hvad det er for en app, der er blevet bygget, hvad den kan, og hvad dens formål er, og hvad for nogle risikoer der er. Jeg tror, det er i forhold til de her politikker, som man kan have lokalt på sit setup. Som der også bliver tjekket af en AI, inden at den ligesom bliver godkendt til at komme ud her. Så hvis jeg går igennem den her app, og så siger jeg, at det ser godt ud, så kan jeg trykke på den her Approve & Publish, og så bliver den så godkendt. Og så bliver der lavet det her release. Og når det så bliver lavet, nu kan jeg lige prøve at gå tilbage til en af de andre her, som der har en udgivelse her. Jeg tror, der er den her. Så kommer det ligesom, det kan man se herinde i det her forhåndsvisning, at der er en app, som er udgivet, og man kan se herinde i releases, at nu er der en, der er udgivet. Og det man så kan herinde på Promte Platform, det er, at nu alt det her er hostet på Promte Platform, og man kan gå ind og dele det internt med e-mailadresser, eller man kan gå ind og dele det med et link. Og man kan også gå ind her og dele baseret på afdelinger og sådan noget, så man kan ligesom få det ud rigtig hurtigt, når man sidder og udvikler det på den her måde. Ja. Så det er ligesom, hvad skal man sige, udviklingsflowet, når man sidder og arbejder på apps. [00:18:10] Styring og sikkerhed [00:18:13] Det vi så har brugt rigtig lang tid på at udvikle, det er det her med hele det her governance-lag, som der kommer ovenpå det. Fordi det er jo rigtig fedt det her med, at man kan sidde og bygge en masse ting rigtig hurtigt, men som Mathias han også kom ind på, så er der jo meget af det her med hvor ender data egentlig henne, og hvem har styr på udgivelser og alle de her ting. Og der jo ofte sker det her, at man sidder og chatter med en AI, og den bygger en app, og så bygger den det på en eller anden infrastruktur et eller andet sted, hvor dataen ender et eller andet sted i et andet sted, end der, hvor man egentlig havde regnet med, at det skulle ende. Så det vi har lavet her, det er at, som jeg allerede har vist det her med releases, men vi har også det her med de her permission requests. Som standard bokset ind, når man sidder og udvikler herhenne i kodning. Så den her frontend-del af appen, som kører inde i brugernes browser. Den er fuldstændig boxet ind, så den kan ikke sende noget data ud. Og man kan også udvikle de her backendfunktioner, som der også er boxet fuldstændig inde. Så den kan ikke sende data ud til andre services. Det den så kan, når man sidder og chatter med den, det er, at den kan bede om tilladelser til specifikke ting. Og det kommer så ind i den her inbox også, som en administrator så kan sidde og se, okay, den her vil gerne kunne sende, den vil gerne have noget data fra Azure med nogle brugere. Kan jeg godkende det? Og det, man så kan på tværs af alle de her arbejdsområder, det er, at man kan gå ind og sætte op, hvad vores politikker for de her ting generelt er. Så det, jeg snakker om med selve frontenden, altså det, der kører ind i brugerens browser, er boxet ind, det har jeg slået til her i det her miljø. Og så kan jeg sige, at den skal gå ind og blokere alt, hvad den prøver at sende ud af data, fordi det er meget vigtigt i vores organisation, at man ikke kan det. Men så kan en specifik assistent gå ind for sit eget arbejdsområde her, gå ind og bede om tilladelse til, at jeg vil gerne på grund af det her og det her, så vil jeg gerne kunne have lov til at hente data om vores brugere fra vores Azure, eller gå ind og oprette en kladde i vores fællesindbakke, eller hvad det nu er, man gerne vil lave. Og det kan man så sidde igen som administrator her og sidde og holde øje med og godkende, om man må eller ej. Og man kan gå ind og så sætte op, at her fx på tværs af alle apps, så vil vi gerne altid have lov til at kunne kalde vores Azure-miljø, for eksempel. Og det kan man så både gøre for det her frontend og for backend, så når de her to er slået til, så er appen fuldstændig boxet ind, og der er ikke noget data, der kan gå ud eller ind af det miljø, som I har. Man kan også styre, hvilke pakker, der må blive installeret. Udvidelser til ens app. Hvis man ikke stoler på visse pakker, så kan man også slå det fra. Lige nu har jeg slået det fra, men man kan så slå det til. Så man kan styre, at det eneste kode, der er, det er det kode, man selv har lavet. Det her, det er, fordi vi har jo en masse funktioner. Vi har bygget den her modulære AI-platform, som har funktioner med LLM'er og embeddingmodeller og med alle mulige AI-features. Og de bliver selvfølgelig stillet til rådighed, når man sidder og bygger de her apps. Sidder og bygger en app, og så kan man bruge alt det, som der allerede er sat op på Promte for en. Så vi har allerede integreret med for eksempel Azure i forhold til LLM'er og sådan noget. Og det skal man ikke sidde og gøre, når man sidder og bygger de her apps selv, fordi man bare kan bruge det direkte igennem Promte. Det kan man også gå ind og styre specifikt, hvad vil man gerne have slået til af de her features her for apps. Vi vil fx ikke have nogen AI-brug, så kan man slå modellerne fra her og AI-chatten fra. Og så videre, vi vil ikke have noget, der har med lyd at gøre, text to speech og sådan noget, så kan man slå de ting fra. Så det kan man styre. Man kan også gøre, så man bare logger det, så man kan holde øje med, hvad det egentlig brugen er. Og så kan man holde øje med det på den måde, hvad det er, der egentlig foregår. [00:22:56] Databeskyttelse i praksis [00:22:58] Det næste, der er, det er, når man så, hvis man så siger, at man gerne må bruge nogle af de her features her til at sende data ud til LLM'er, så har vi det her guardrailslag. Som gør, at du kan styre, at du kan gå ind og holde øje med, hvad er det egentlig for noget data, der bliver sendt. Fx ud til en LLM i Azure. Eller der bliver skrevet ned i en database lokalt, som vi gerne vil undgå. Så der kan man gå ind og sige, fx CPR-nummer, det vil jeg gerne blokere fuldstændig. Det vil vi aldrig nogensinde have, at vi har sendt nogen steder hen. Hvis at vores model her, det her guardrailsmodel her, som der holder øje med, med de her forskellige ting, den opdager sådan noget, så blokerer den det. Telefonnummer, det siger vi, det er måske okay, men vi vil gerne lige have en log. Og alt det andet her, det er egentlig bare slået fra her. Så det er en måde at kunne åbne op for, at man kan bruge til nogen ting. Men at man stadig sikrer, at hvis der er et utilsigtet databrud eller et eller andet, man kommer til at gøre, så kan vi stadig gå ind og sikre det og blokere nogle af de her ting. Det her er mere specifikt i forhold til at skrive dataen ned i databasen, og så den anden her: Outbound data checks. Det er i forhold til data, som går ud i de her forskellige services, som Promte stiller til rådighed. Så det er mange af de ting, som man kan sidde og styre her. Så kan man også styre det her logging her. Det slår til som standard, at vi logger alt, hvad der foregår i de her apps. Og så kan man styre, hvor mange dages retention man gerne vil have på de her logs. Og det kan vi gå over og se her også. Der kan man se logs her for de sidste syv dage. Så kan man se hver gang en app bliver åbnet og et release bliver reviewet og hvem har gjort det osv. Så der er ligesom logs på alting her i virkeligheden. En anden ting er, at vi kan også lave, at der er både det her frontend og så det backend her, som jeg har snakket om. Og der kan man også gå ind og slå det fra, hvis man siger, at vi vil simpelthen ikke have, at der er noget, der bliver lavet noget backend. Vi vil kun bygge frontend-apps, som kun kører i brugernes browser. Vi vil ikke have noget, der kører fælles. Så vi slår det fra. Og man kan også sætte sådan nogle, de her backendfunktioner, de kan køre på de her schedules her, så de kan køre hver dag og gøre et eller andet. Måske tjekker man, at der er kommet en ny mail ind i en indbakke, Og så lave et eller andet på baggrund af det. En ny kladde eller et eller andet. Og det kan man også styre, om det skal slås til inde på det her governance. Så det smarte ved rigtig mange af de her ting her i forhold til det her policies and access, det er, at vi har, fordi at vi både har harness her og vi har det her governance-modul her på samme tid i en pakke. Så kan vi lave sådan, at det her harness her, det kan selv spørge om tilladelse til de her ting. Så når du sidder og chatter med dem, så behøver du ikke at være teknisk og vide, at jeg skal kalde det her Azure API eller jeg skal kalde det her, jeg skal gemme den her type af data. Det behøves du ikke at vide, fordi det ved den model, du sidder og chatter med, den ved alle de her ting her, alle de tekniske ting, og den kan så sige, okay, nu spørger jeg lige om tilladelse til, at jeg må skrive telefonnummer ned, fordi det har vi brug for i den her app. Og så skriver jeg en beskrivelse ud fra det, vi har siddet og snakket om, til den her administrator. Og så får administratoren så inden i det her permission requests en permission på, at den her app, den vil gerne have lov til at gemme telefonnummer. Og det er fordi, det skal bruges til lige præcis det her brugsscenarie. Og så kan man så give godkendelse til det. Og hvis der så er noget, der ændrer sig i appen, et eller andet med, hvordan den her app bliver brugt. Så den her permission request her, den er gemt med det formål, og så holder den her release-AI, som der læser alle de her releases igennem, den der blokerede mig før. Den holder altså øje med, om der er noget af det, der har ændret sig, og der er noget ny permission, der mangler at blive bedt om tilladelse til. [00:27:44] Forbrug og budgetter [00:27:46] Det sidste, jeg lige vil komme ind på, inden jeg er helt færdig her, det er det her, som du også nævnte, Mathias. Ja. At når man, altså klassisk set, så har vi jo siddet og brugt de her ChatGPT og de her agenter her til at sidde og få svaret på nogle spørgsmål. Og det koster ikke særlig meget. Det har været sådan, typisk så har man ikke rigtig haft brug for at holde øje med, hvor meget det har kostet. Men de her agenter her, de kan jo, der kan du sige til den, jamen du skal bygge den her kæmpe store app, der kan 100 forskellige ting. Og så går den i gang med arbejde, og så fortsætter den bare i timevis og bruger en masse tokens. Så det er noget, der kan komme lidt ud af kontrol. Så det har vi også lavet som del af det her app-governance, at du ligesom kan sætte nogle af de her begrænsninger her. Så du kan gå ind og sætte op hver person. Der vil vi bruge mere end 200 kroner om måneden og 20 kroner om dagen. Så kan man så lave personlige undtagelser her. Så hvis der er en eller anden, som hvis job det er fx at sidde og bygge de her ting, så kan man gå ind og sige, du må gerne bruge meget mere, fordi det giver mening. Og man kan også gøre det på afdelingsniveau. Så kan man sætte priser op for forskellige modeller, alt efter hvilke aftaler man har med sine leverandører her. Det er også noget, jeg ikke fik vist, men man kan gå ind og vælge. Man kan køre modulært på den måde, at vi ikke er bundet fast i nogen bestemt model. Så hvis man gerne vil køre på Anthropics modeller og noget Claude, så kan man gøre det. Hvis man gerne vil køre på OpenAI's modeller, så kan man gøre det. Igennem Azure fx. Og hvis man gerne vil køre på open source modeller, nogle af de danske modeller, blandt andet har vi et samarbejde med Corti, hvor vi også integrerer med nogle af deres modeller, som de snart kommer til at hoste i Danmark. Så har vi også en integration til det, som man kan sidde og køre på danske modeller. Og så kan man også sidde og holde øje med, hvor mange penge man bruger på tværs i sin organisation. [00:30:02] Spørgsmål og svar [00:30:05] Det første spørgsmål var, om det var samme setup i forhold til tokens som ved andre værktøjer. Det er rimelig meget det samme, men der er nogle flere muligheder for at styre det. Det kan være, du vil tilføje, Christian. Og så i forlængelse der er der spørgsmål om, om det vil kunne betale sig at forberede et projekt i fx ChatGPT eller andre værktøjer, inden man går i gang herinde for så at bruge færre tokens herinde. Det er faktisk et rigtig godt spørgsmål. Jeg tror, det kommer meget an på, hvad det er for nogle aftaler, man har i de forskellige værktøjer. Så hvis man har en god aftale med ChatGPT, hvor man kan få nogle rigtig billige tokens derhenne, så kan det godt give mening at lave noget af det. Vi har også nogle skills og sådan noget, som gør, at du kan bruge andre harnesses til at sidde og udvikle i. Det du mister, det er sådan noget af det her sandboxing og sådan noget. Hvis du sidder og udvikler det et andet sted, så når du sidder og udvikler det her med at kunne spørge om tilladelse til forskellige ting og sådan noget. Det er ikke noget, vi har i de her skills endnu. Det kan være, det er noget, der kommer snart. Men det kan godt give mening, også hvis man er vant til at bruge noget andet, og man allerede er en, hvad skal man sige, garvet udvikler, og man er vant til at bruge Claude eller et eller andet. Så kan man godt sidde og udvikle det herhenne, og så bruge nogle af vores skills og udviklertools derhenne. Og så stadig få vores hosting og monitorering og sandboxing og sådan noget, når man så går i produktion med de her apps. på en eller anden måde, hvor jeg vil sige, det her harness her, det giver mere mening til folk, hvor det bare skal være så nemt som overhovedet muligt. Og man er måske ikke ultrateknisk og har sit helt eget setup, som man selv har lavet og sådan noget. Der kan man så vælge at bruge det harness, som vi har direkte ind i dem her, som gør mange tingene meget nemmere. Jeg tænkte også på, at jeg vil lige tilføje, og du kan rette mig, Christian, hvis det ikke er rigtigt, det jeg sidder og siger. Men som du også kommer ind på, så kan vi jo understøtte alverdens forskellige sprogmodeller. Så vi har nogle spændende samarbejde med Corti, som vi også kommer til at fortælle lidt mere om om et øjeblik. Men i det element med at kunne bruge, altså udskifte sprogmodeller og bruge forskellige sprogmodeller rundt omkring, der vil jo også være en mulighed for organisationen i at prisoptimere, hvis man gerne vil køre med en model, som er billigere på den ene eller anden måde. Eller eventuelt køre en model lokalt. Ja, der har vi også nogle andre muligheder for at styre, hvem der har adgang til hvilke modeller og sådan noget. Så man kan også sidde inden for det her governance, det er så på tværs af hele Promte-platformen og sidde og styre, hvilke modeller der er tilgængelige for hvem og sådan noget. Så der er helt klart nogle muligheder der også. Alright, der er masser af spørgsmål på chatten. Så jeg vil også lige tage, hvis vi bare lige tager dem sådan lidt mere fra toppen, så var der jo Janette her, der spurgte med det her med, om man kan få projekter fra Lovable ind i Promte. Der kom et spørgsmål mere i forlængelse af det: Hvad med andre typer af vibe-kodningsprojekter, der ligger inde i Git, men som ikke er udviklet i Lovable? Jeg svarede bare lige hurtigt på skrift, at det var en hurtig måde at gøre det på. Det er at downloade det som en zip-fil eller noget, inde fra Lovable eller Git. Og så lægge det i en samtale i Promte, men det kan også være, at du har en smartere måde at gøre det på, Christian, eller andre måder at tænke på det. Ja, så i princippet kan du godt bare importere en hel mappe med kode til Promte. Det er ikke sikkert, at alt vil virke direkte, en til en med koden, men så er det smarte, at man har de her agenter, som kan sidde og ændre funktionerne, så det hele kan køre. Så man kan sige, at hele frontend og hele den del, som kører i browseren, ofte er det bygget på samme måde som det, som vi har lagt op til her, som er det her Vite/React, hvis det siger nogen noget. Så hvis det er bygget på den måde, og det gør de fleste modeller, når de bygger apps i dag, så vil det virke lige med det samme, uden at agenten ligesom rigtig skal gøre noget. Og så hele backend-delen her, der har vi vores egen infrastruktur, som har den her sandbox her, som ligesom pakker hver eneste af de funktioner, man har i backenden ind. Så hvis man har en backend til sin app, som er mere custom, så er der noget omskrivning der, der skal laves, som agenten her så heldigvis også kan stå for. Så det eneste, det koster, det er jo nogle tokens og noget tid til at debugge og sådan noget. Perfekt. Så er der et spørgsmål her til ændringer, man laver i appen. Hvordan fungerer det, og kan man gå frem og tilbage mellem versioner og sådan noget, når man laver nye ting? Ja, ja. Så inden for den her releases side her, der har du forskellige versioner, som du så kan skifte. Altså hvis du gerne vil lave et rollback, eller hvad man siger, hvis du gerne vil tilbage til en gammel version, så kan du godt hoppe tilbage, og så sige, at den, som der er i drift lige nu, det er version 1. Fordi at vi fandt ud af, at version 2, der var et eller andet galt, eller et eller andet folk ikke forstod i den app, eller hvad det nu var. Så der kan du ligesom hoppe imellem versionerne også, ja. [00:35:42] Hosting og egne data [00:35:44] Super. Så er der et spørgsmål til tanker omkring governance. Men så næste spørgsmål hænger også lidt sammen med det, med omkring, hvordan det her differentierer sig fra for eksempel Lovable, når det kommer til sikkerhed. Så det kan godt komme lidt ind på det. Jeg tænker også på sådan noget som mulighederne for self-hosting og sådan noget, der ligesom er indbygget. [00:36:00] Ja, så vi har mulighed for både for self-hosting, og vi har mulighed for hosting i Azure EU, enten på private cloud, og vi har også mulighed for hosting i danske hosting provider. Så vi kan ligesom lægge det hvor som helst. Det, der er mange af vores kunder, der gør, det er, at de hoster hele Promte-platformen her lokalt på deres egne server, hvis man har det. Det er så mange kommunale kunder, der gør. Og det gør så, at vi kan sørge for, at al databehandling er noget, der bare foregår lokalt. Nede ved den kunde. Der er sådan nogle af de her ting, som er mere sådan... Det er rå kode, og det er så ikke databehandling efter, at man er i drift. Når den er i drift, så foregår al databehandling kun der, hvor miljøet er installeret, om det så er hostet ved os eller på ens egne servere. Men når man sidder og udvikler og sådan noget, hvis man så hælder data ind i det, så har vi en integration til ens eget... Vi kan egentlig gøre det på to måder. Standardmåden er, at vi kører det på folks eget Azure-miljø, hvor vi så kan lave de her sandboxes, der man sidder og udvikler i. Og det andet, man kan gøre, det er selvfølgelig at sidde og udvikler i sin computer. Og det tredje, vi kan gøre, det er at sætte det op på... Så det kører på ens egen serverinfrastruktur. Og det kræver så, at man har en serverinfrastruktur, hvor vi kan sætte mange af de her kodesessioner her i gang. Yes, så tænker jeg bare, der er lige et spørgsmål mere i den samme genre, så vi kan lige tage det. Så helt specifikt, så står der... Hvis nu man har brug for at hoste sine løsninger på forskellige net, f.eks. DMZ, er der support for det? Ja, der har vi også forskellige muligheder. Så det vi normalt gør, det er at lægge sådan hele administrationsdelen af platformen. Den kan vi i hvert fald lægge nede i et mere sikkert lag. Så der ikke er adgang udefra til alt, hvad der er i administration og sådan noget. Men så kan vi så lægge bestemte moduler ud i DMZ'en for eksempel. Så man kan tilgå fx, hvis man har brug for, tænker det nok er ideen om at udstille apps ud på internettet og sådan noget, som man har bygget her. Så man kan lægge det modul, som der er appvisningen, ud i DMZ'en. På den måde kan vi sikre, at man skal sidde på netværket for at kunne lave om på konfiguration eller ændringer i app-releases. Men du kan stadig godt udstille appen og bruge appen uden for et netværk. Så det er også muligt. Og det er for hele Promte-platformen egentlig, så det er også for assistenter og for alting, den funktion. Perfekt. Jeg tænker også sådan helt lavpraktisk, hvis man sidder og udvikler en app, og ligesom, altså jeg tænker mange af de ting, hvor det skal være på netværket, det er noget, man sætter op, når man sætter op i første omgang det her, Promte Kodning eller hele Promte-platformen, men når man så sidder som almindelige brugere og har bygget en app, hvordan fungerer det så med hosting? Hvad skal man gøre for at få den her app live? Ja, når man bare sidder og udvikler på Promte-platformen, så er det bare det her release-flow her. Og hvis det så er slået til, at man skal have den her menneske her, som skal, der er human release approval, som også er slået til som standard, så skal der så være et menneske, når man går ind og trykker på den her create release, så skal der være et menneske, der går ind, som selvfølgelig er en, der er godkendt til at gå ind og godkende de her apps her, som så går ind og trykker OK, når de har læst igennem, hvad appen er, og hvad der er ændret og sådan noget. Så hver gang du laver en ny version, så kommer det ligesom ind igen i det her release flow. Vi har også det her AI release review, som man kan godt sætte det op, hvis man slet ikke vil have den her human, så kan du ligesom gå ind og sætte de her policies op her. Det tror jeg slet ikke, jeg fik vist, men vi har de her policies her, hvor du kan sætte op blandt andet baseret på AI Act. Der er der måske nogle ting, man gerne vil have sat op der, for at sikre, at man ikke udvikler apps til formål, som man ikke må, og man har sikkert også mange specifikke ting for ens egen organisation, som er ting, man ikke må i forhold til persondata og alt sådan noget, og det kan man så sætte op ind i det her policies. Og der er den her AI her, den går ind og så laver et review på koden, som den var, og hvad der er blevet godkendt, og så de ændringer, som der er blevet lavet. Ja, så oplevelsen, når man sidder og udvikler, det er egentlig bare at logge ind i Promte eller bruge dit eget harness, hvis du er mere sådan teknisk, og så laver dine opdateringer, og så laver du release, når du er færdig, og så kan det så enten blive godkendt af en AI eller et menneske, eller begge dele. Yes. Ja, og så er det sådan set bare hostet, ikke? Så det er ikke noget, man skal tage stilling til hver gang. Det er der bare... Ja, lige præcis, ja. Så hosting er indbygget, ja. Perfekt. Så er der også et spørgsmål om, hvad med rigtige Windows-apps, for eksempel, og ikke bare webløsninger. Kan man lave det, eller er det uden for scope på det her? Ja, så vi har vores egen, faktisk, Windows cross-platform-app under udvikling også, som man kender det også fra ChatGPT og sådan noget, som der har, og Claude, der har sine apps, der kører på tværs. Og der kan man så lave de her apps her, så de så kan køre ind i den, men i forhold til sådan mange af de funktioner, som man har, når man så sidder og bygger sådan en native app her til Windows eller Linux eller Mac, er oppe i, altså lave notifikationer og sidder oppe i de her tray-ikoner og mange af de ting, der ligesom kommer der. Det er ikke en del af scope for det her, som det er lige nu. Det kan være, det bliver på et tidspunkt, ja. Det, vi har lavet, det er sådan, at man kan ligesom... Nu får vi den her desktop app her. Forhåbentlig inden så længe, som så gør deling af de her apps nemmere. Og vi har også en iPhone- og Android-app, hvor de her apps, man bygger, de også kan blive udstillet igennem. meget nemt. Og så kan man også, når man deler dem, bare udstille dem som et iframe, hvis man skal have dem ind og ligge i sin egen app eller et eller andet. Så der er mange muligheder for distribution af de her apps her, som kommer indbygget. Yes. Så er der lidt andet spørgsmål, der handler om de her guardrails eller filtret for forskellige oplysninger. Hvor spørgsmålet går på, at det her ligner meget fokus på almindelige oplysninger, personoplysninger og CPR-nummer. Hvad med mere følsomme oplysninger, som f.eks. helbredsoplysninger eller fagforeningsmæssige tilhørsforhold? Det kan godt være, at man kunne kigge på det hele og så blokerer det, som behandler det. Så det kan være, du kan fortælle lidt om, hvordan det virker, hvad teknikken er. Ja, så det lag, som vi har lige nu, som vi kalder guardrails, det er lavet på den måde, at det kører lokalt der, hvor appen kører, direkte inde i brugerens browser. Det vil sige, at der aldrig nogensinde er noget data, der når at forlade der hvor koden bliver kørt. Det vil ofte allerede være i brugerens browser, at det her data bliver blokeret. Så vi har lavet den her meget lille model, som kan køre direkte inde på folks device, som kan blokere mange af de her ting. Det giver nogle fordele, fordi det kan blokere de her informationer, som man helst ikke vil have delt om folks navne eller specifikke personoplysninger. Men begrænsningen i det er så, at du kan ikke mere brede og fuzzy ting, kan det så ikke fange, hvis man skriver fx lidt om noget med ens helbred. Og der skal du så typisk have noget AI indover og gøre det alligevel, hvor behandlingen så kommer ligesom til at ske af en anden AI, end den AI, man så ville oprindeligt have sendt det til. Men der kan man så gå ind og sige sådan noget som, at hvis der bliver smidt noget data ind om helbredsoplysninger eller et eller andet, så lad være med at gemme det fx i en database. For at kunne fange mange af de her ting kræver det en eller anden form for behandling af en AI-model. [00:45:21] Test, kvalitet og ejerskab [00:45:24] Perfekt. Ja, så et spørgsmål her går på QA og testcases. Så spørgsmålet er, at der ofte bliver stødt på spørgsmålet, om man kan stole på logikken eller arkitekturen i sådan en AI-løsning her. Så er der noget QA eller testcases indbygget her, eller hvordan er det en del af sådan det her release review? Ja, altså det er et godt spørgsmål der med, om man så kan stole på AI'en. Fordi vi kan jo sætte alle de her policies op og så sige, så får du ligesom noget QA i forhold til det. I forhold til hvert fald, hvad må man bruge appsene til og sådan noget. Så er der jo så det andet, som er det her med, er det egentlig en god app og sådan noget, som skal udvikles, eller som skal udgives her. Man kan ligesom have en app ude, uden at den ligesom er blevet published endnu til det brede internet. Så kan du godt have en version 2 liggende, men det er stadig version 1, der er ligesom i drift. Og så den version 2, den kan du så have menneskelig QA på, inden at du laver din udgivelse. Så det er i hvert fald en måde, at man ligesom kan lave det her på, uden... Altså hvis man gerne vil have det her human in the loop også på visse ting, hvor det er mere kritisk. Og det er jo så også ofte fra use case til use case, at man gerne vil kunne styre, hvor kritisk er det, at vi har sådan helt QA flow på. Versus at det er nok, at det er for eksempel en AI, der går ind og kigger på, at den her app, den lever op til vores design guidelines, eller den behandler ikke de her typer af data og sådan noget. Yes, super. Så er der et andet spørgsmål her, som går på, hvis nu en medarbejder har bygget en app, og så stopper, kan den her app så overføres til en anden person i organisationen? Kan du tale om, hvem der sidder i styringsmodulet og byggemodulet, og hvordan man kan overføre ting? Ja, så når man sidder inde i det her styring her, det er ligesom, der sidder nogle administratorer inde i det, som er blevet givet specifik adgang til det i organisationen. Og det kunne fx være, hvis man har en IT-afdeling i sin organisation, så kan det typisk være, at det er en, der sidder der, og som er teknisk kyndig og har styr på, hvordan de her ting virker. De har adgang på tværs af hele organisationen. Og de kan jo så også have adgang på tværs af alle de her apps. Så vi har ligesom sådan en superbrugerrolle, som har adgang på tværs af hele organisationen. Og de kan styre, hvis der er en, der bliver syg eller et eller andet. Så kan de gå ind og se alle apps, der er oprettet af alle workspaces, der er oprettet faktisk i Promte. Så det er også assistenter og agenter og alle sådan nogle ting her. Og så gå ind og styre brugerstyringen på det og overføre det til en anden medarbejder. Hvor når man sidder inde i det her, der er det mere sådan en specifik workspace, hvor det er mig, som udvikler, som sidder herinde og arbejder. Og der har vi så det her brugerstyring her. Nu er det så mig, som sidder som ejer her, og der vil en superadministrator kunne gå ind og lægge en anden bruger herind i stedet og sætte dem som ejer her. Super. Yes. Så er der spørgsmålet til, om man vil kunne bruge det her i en undervisningssituation i folkeskolen. Og der er så spørgsmålet, at der virker til at der er en hel del af opsætninger, som kan gøre det ret besværligt at komme i gang. Så er der bud på, om produktet kunne være egnet til det. I forhold til undervisning i vibe-kodning? Jeg forestiller mig, ja. Jeg ville nok ikke anbefale at bruge det her produkt til undervisning, fordi det handler mere om at lave governance på. Alt det her med at få en app rent faktisk ud i drift og ud at leve. Så der kommer til at være en masse lag og en masse styring på det, som gør, at du måske kan få en meget mere iterativ og bedre læringssituation ud af, og bare bruge sådan noget som ChatGPT eller et eller andet til at sidde og undervise i de her ting. Perfekt. Det giver god mening. Jamen, super godt, Christian. Vi siger tak. Så kan Mathias lige i gang med lidt skærmdeling, og så kan jeg lige i overgangen her besvare spørgsmålet fra Jeanette her. Og spørgsmålet er, om Promte sådan generelt er at betragtes som alle andre fagsystemer, som med databehandleraftaler osv., kan man vel godt bruge at behandle følsomme og fortrolige oplysninger. Og ja, det er helt rigtigt. Det er jo bare et IT-system eller et fagsystem, så det er sådan almindelige GDPR-regler, der gælder for det. Så det kan jo godt håndteres i databehandleraftaler osv. [00:50:36] Hvorfor bygge i Promte? [00:50:39] Jamen, jeg runder lige af for i dag og prøver at få opsummeret nogle af pointerne, som Christian kom igennem ud fra jeres spørgsmål. Så sådan lige for at opsummere, hvorfor det giver mening at bygge på Promte. Og det her harness-begreb, der er blevet brugt også, som jo egentlig bare er den her ramme omkring AI-agent og hvad for nogle ting den må og ikke må, og den kontekst, som den arbejder inde i. Hvor vi har prøvet at lave det her sikre miljø, som Christian også sagde med. Det ligesom er bokset inde og de her ting. Men helt konkret, så er det jo noget omkring det her med at få den her fælles infrastruktur. Så som Christian og Victor også sagde, når man har bygget noget, så er det egentlig bare tryk udgiv, og så er der styr på alt det her backend og hosting og den her fælles app-miljø i forhold til det her fælles bibliotek, vi snakker om og sådan noget. Vi har prøvet at gøre hele den der infrastrukturdel så nemt som muligt. Så er der hele det her adgang- og delingslag, som der også blev vist. Altså det er nemt at dele på tværs af brugere. Det er nemt at udskifte, hvis en bruger lige pludselig ikke er i organisationen mere, så kan man give ejerskab videre. Så hele det der element har vi prøvet at få gjort nemt at administrere. Det her i forhold til AI-modeller. Både hvilke modeller kan vi køre på, som er bedre end andre, så vi kan få de bedste modeller. Der er det helt udskifteligt, hvilke modeller man vil bruge. Men vi kan også sige, okay nu vil vi gerne prøve at kostoptimere. Vi vil gerne sikre os, at vi kører på de billigste modeller, så vi kan kode en masse uden at bruge alt for mange penge på tokens. Så det her kan man fuldstændig gå ind og styre alt afhængig af, hvad det er, man gerne vil optimere for. Så det sidste er det her omkring drift og datasuverænitet. At vi har prøvet at gøre opsætningen og dataflowet så fleksibelt som muligt. Så alt afhængig af jeres organisations risikoprofil og hvad I gerne vil køre på, så kan vi stort set understøtte alle de driftsmodeller, der kunne være derude i forhold til, hvor data ligger henne og hvordan data flyder fra løsningerne. [00:52:42] Tak fordi du så med [00:52:42] Så det var sådan set det, vi havde med til jer i dag, og vi håber, at I har lyst til at tage fat i os, så vi kan vise jer lidt mere. Jeg håber, det var en god inspiration i hvert fald på mødet her. Så tusind tak for at lytte med.