Kreds 1-talken — renset stemme
Poul's 1-times AI-webinar delt i kapitler. Tre fyldord-tunge afsnit skrevet skarpere og læst op af en klon af hans egen stemme — fra netop det afsnit — i både syv.ai og ElevenLabs. FØR vs. EFTER.
Kapitler i talken
| 1 | Velkomst og hvem er PoulA/B | 9:18–12:53 | Poul byder velkommen, ridser dagens agenda (byg med AI uden at kode) op og præsenterer sin udviklerbaggrund samt hvorfor den både er en fordel og en ulempe. |
| 2 | Rejsen fra 0 til eget produkt | 12:54–19:09 | Gennemgang af trinene fra gratis browser-værktøjer over 25- og 100-dollars-planer til fuldt eget setup, med byggeklodser (tokens, stemme, billeder) og Pouls egen stak. |
| 3 | Første demo: Bolt og Lovable i browseren | 19:10–25:42 | Alt starter i browseren — en one-liner bygger på få minutter en aktindsigt-app, der kan itereres på, lægges i GitHub og publiceres på nettet. |
| 4 | Claude Design og designsystemer | 25:43–30:56 | Claude Design-demoen bygger samme app med et designsystem, tåler stavefejl og løst sprog, kræver multitasking pga. ventetid og kan sendes videre til Claude Code. |
| 5 | Explorer vs. spec-driven, skills og harnessA/B | 31:01–35:22 | Begreberne explorer-mode og spec-driven forklares sammen med skills (opskrifter) og harness, og hvorfor præcision upfront (en PRD) er billigere end løse prompts. |
| 6 | PRD-demo: fra idé til spec | 35:22–40:42 | En lille PRD-side genererer personaer og user stories ud fra en one-liner, og Poul viser at der bag UI'et blot ligger en prompt/webservice. |
| 7 | Claude Desktop og multi-agent workflow | 40:42–49:06 | Tredje demo kører på egen/fjern-maskine med ultra code-workflow, hvor flere agenter designer, bygger og reviewer en landingsside og aktindsigt-tracker ud fra PRD'en. |
| 8 | Skills, tunnels og at høste sin videnA/B | 49:06–58:04 | Designet sendes til Claude Code, køres lokalt (med supply chain-forbehold), eksponeres via en tunnel-skill, og level 1-5-modellen samt product-owner-rollen forklares. |
| 9 | Kundecase: Hempel IdeaLab | 58:05–63:55 | Hempel-casen viser hvordan udfordringer, personaer og gemte prompts genererer op til 1000 idéer, der scores og bringes ind i workshops — også relevant for journalisters brainstorm. |
| 10 | Afrunding, tilbud og farvel | 63:55–67:49 | Den færdige lommepenge-app eksponeres via en tunnel, personaernes datagrundlag forklares, og Poul inviterer til at connecte på LinkedIn og til et muligt kursus. |
A/B — original vs. renset klon (syv.ai vs ElevenLabs)
FØR er den originale levering; EFTERer samme stemme uden øh og æ, klonet fra netop det afsnit. «Klarhed» = hvor rent syv.ai's egen ASR genkender ordene igen — samme dommer for begge motorer.
Udviklerbaggrund: største fordel og ulempe
11:56–12:23Budskab: At være udvikler er både min største fordel og ulempe — som ikke-koder kan du faktisk have det lettere, for du skal bare være god til at beskrive dit mål.
Min største fordel, ulempe, er at jeg er udvikler. Det vil sige at jeg har været vant til at skrive kode. Det vil sige at når A1 sidder fast, så kan jeg nok komme ud af det igen. Men det er så også min største ulempe, fordi det det er en refleks eller en vane, man skal vende sig af med som og udvikler. Og det kan måske være nemmere at komme fra en verden, hvor man ikke er vant til at kode, og man nu egentlig bare skal være god til at beskrive sit mål
Min største fordel og ulempe er, at jeg er udvikler. Fordelen er, at jeg er vant til at skrive kode, så når AI'en sidder fast, kan jeg som regel få den ud af det igen. Men det er også ulempen, for det er en vane, man som udvikler skal vende sig af med. Nogle gange er det faktisk nemmere at komme fra en verden, hvor man ikke er vant til at kode — hvor man bare skal være god til at beskrive sit mål.
Andre varianter (let / skarp) — begge motorer
Min største fordel og ulempe er, at jeg er udvikler. Jeg har været vant til at skrive kode. Det vil sige, at når AI'en sidder fast, så kan jeg nok komme ud af det igen. Men det er også min største ulempe, fordi det er en refleks eller en vane, man skal vende sig af med som udvikler. Og det kan måske være nemmere at komme fra en verden, hvor man ikke er vant til at kode, og hvor man nu egentlig bare skal være god til at beskrive sit mål.
Min største fordel og ulempe er den samme: jeg er udvikler. Fordelen er, at når AI'en sidder fast, kan jeg som regel selv få den fri igen. Men det er også en vane, man skal lære at slippe. Faktisk kan det være lettere at komme helt uden kodebaggrund — for så skal du bare være god til at beskrive dit mål.
Dommer valgte «strammet»: MEDIUM is the best trade-off between faithfulness and publishable flow. It keeps every load-bearing beat of Poul's original — (1) being a developer is simultaneously his biggest advantage and disadvantage, (2) the advantage is that he can get A1 unstuck, (3) the disadvantage is that coding is a habit a developer has to unlearn, (4) it can actually be easier to come from a non-coding world where you just have to be good at describing your goal. It also introduces a clean rhetorical spine ("Fordelen er… / Men det er også ulempen…") that mirrors the fordel/ulempe framing already implicit in the verbatim, and it resolves the original's genuinely ambiguous "så kan jeg nok komme ud af det igen" (who comes out of it?) into the clearly intended "kan jeg som regel få den ud af det igen" (I can get A1 unstuck). It preserves Poul's generic "man" voice and does not invent any terminology. LIGHT is the safest for meaning but barely cleans anything — it drags the clunky "komme ud af det igen" ambiguity and filler "egentlig" into print, which is under-polished for a published voice-clone product. CRISP reads best as prose but drifts the most: it coins "helt uden kodebaggrund," asserts "den samme," and switches to second-person "du," none of which are in the source. For a published product you want the delivery cleaned without the meaning quietly shifting, and MEDIUM hits that line. Forbehold: Meaning-drift and register notes by variant: MEDIUM (recommended): Two mild confidence upgrades — "nok" (tentative, "probably") becomes "som regel" ("as a rule"), and "det kan måske være nemmere" ("maybe easier") becomes "Nogle gange er det faktisk nemmere" ("sometimes it's actually easier"). Both nudge Poul from hedging toward assertion, but stay within his intent. "få den ud af det igen" resolves the source's ambiguous subject by making A1 the thing that gets unstuck — a reasonable interpretation, not an invented fact. No fabricated claims; Danish reads natural and native. CRISP: Most drift. Invents "den samme" (asserts the advantage and disadvantage are literally identical), coins "helt uden kodebaggrund" which overstates the source's softer "ikke vant til at kode" (not used to coding ≠ no coding background at all), and adds "selv få den fri" / "lære at slippe" flourishes not in the original. It also drops the stated rationale "jeg har været vant til at skrive kode" and the word "refleks," and switches from Poul's generic "man" to direct "du." Cleanest prose, weakest fidelity. LIGHT: Essentially zero meaning drift — safe. But it keeps the ambiguous "så kan jeg nok komme ud af det igen" and the filler "egentlig," so it reads as lightly tidied speech rather than finished product copy. Cross-cutting: all three keep the agent label "A1" verbatim; confirm that's the intended on-air name for the clone (the core-message line omits it, so it won't clash).
Skåret væk: Fjernet: selvrettelsen "fordel, ulempe" i starten → samlet til "fordel og ulempe" (han mener jo begge dele). De to "det vil sige at" reduceret (light beholder ét, medium/crisp ingen). Dobbeltordet "det det" og den skæve "som og udvikler" rettet. Run-on-sætningen delt i tydelige punktummer. Bevaret: hans "A1 sidder fast", "refleks eller en vane", "egentlig bare skal være god til at beskrive sit mål" og førstepersons-varmen. Ingen nye fakta/tal tilføjet. Crisp skifter til andenperson ("du/dit mål") til sidst for den publicerede tales appel til tilhøreren — samme pointe som originalen.
Vær præcis upfront — spec-driven er billigere
34:39–35:22Budskab: Det er billigere at bruge lidt tid på at blive præcis upfront (spec-driven / en PRD) end at generere løst og køre i ring med rettelser.
Være meget præcise om hvad vi skal have for vores tokens så frem for at I sidder og genererer noget og så regenererer det og nu ændrer vi farven og så lidt ligesom klassisk udvikling hvis du kommer med en løs beskrivelse af hvad du skulle have udvikler en udvikler det så beder du om rette det og så kører vi lidt i ring øh indtil vi har nået noget vi synes der er godt det er typisk dyrere end hvis man har øh brugt lidt tid på at forstå hvad det er man ønsker og det er egentlig deraf vi begynder at tale om spec-driven at at vi bruger lidt mere tid på at blive specifikke på hvad der skulle laves før vi bygger det så det kalder vi et product requirement dokument så det er din idé der er skrevet ned så en AI kan bygge den
Vær præcis om, hvad du vil have for dine tokens. For alternativet er, at du genererer noget, ændrer farven, regenererer — ligesom klassisk udvikling: du giver en løs beskrivelse, udvikleren bygger det, du beder om rettelser, og så kører I i ring, indtil det bliver godt nok. Det er typisk dyrere, end hvis du havde brugt lidt tid på at forstå, hvad du egentlig ønsker. Det er derfra, vi begynder at tale om spec-driven: vi bruger lidt mere tid på at blive specifikke om, hvad der skal laves, før vi bygger det. Det kalder vi et product requirement-dokument — din idé skrevet ned, så en AI kan bygge den.
Andre varianter (let / skarp) — begge motorer
Vær meget præcis om, hvad vi skal have for vores tokens. For frem for at I sidder og genererer noget, og så regenererer det, og nu ændrer vi farven — det er lidt ligesom klassisk udvikling: hvis du kommer med en løs beskrivelse af, hvad du skulle have, så laver en udvikler det, så beder du om at få det rettet, og så kører vi lidt i ring, indtil vi har nået noget, vi synes er godt. Det er typisk dyrere, end hvis man har brugt lidt tid på at forstå, hvad det er, man ønsker. Og det er egentlig deraf, vi begynder at tale om spec-driven: at vi bruger lidt mere tid på at blive specifikke om, hvad der skulle laves, før vi bygger det. Det kalder vi et product requirement-dokument. Så det er din idé, der er skrevet ned, så en AI kan bygge den.
Vær præcis om, hvad du vil have for dine tokens. Alternativet er klassisk udvikling: du giver en løs beskrivelse, udvikleren bygger det, du beder om rettelser, og så kører I i ring, indtil det er godt nok. Det er typisk dyrere, end hvis du på forhånd bruger lidt tid på at forstå, hvad du faktisk ønsker. Det er derfor, vi taler om spec-driven — vi bliver specifikke om, hvad der skal laves, før vi bygger. Det kalder vi et product requirement-dokument: din idé skrevet ned, så en AI kan bygge den.
Dommer valgte «strammet»: MEDIUM is the best fit for a published product because it lands the sweet spot between fidelity and clean delivery. It retains every meaning beat of the original: (1) the "be precise about what you get for your tokens" opening, (2) the concrete generate → change-color → regenerate loop, (3) the classic-development analogy (loose brief → build → ask for corrections → go in circles until "godt nok"), (4) "typisk dyrere end hvis man havde brugt lidt tid", (5) the origin move into spec-driven ("Det er derfra, vi begynder at tale om..."), and (6) the PRD definition as "din idé skrevet ned, så en AI kan bygge den." It also keeps Poul's spoken hedges and connectors ("For alternativet er...", "typisk", "egentlig ønsker", "begynder at tale om", "lidt mere tid"), so the voice still sounds like him rather than like marketing copy. What it fixes is exactly the spoken raggedness that hurts on the page: the dangling "for frem for at..." construction and the pronoun churn are smoothed, and the sentences are given clear boundaries. LIGHT is the most literal but keeps that raggedness (the unclosed "For frem for at I sidder og genererer..." and the vi/I mix read as transcript, not published prose). CRISP reads best as a soundbite but pays for it by dropping a genuine beat of the argument — see concerns. MEDIUM keeps the argument whole while still reading cleanly aloud in a re-recorded voice clone. Forbehold: No variant invents facts about spec-driven or the PRD — all three preserve "product requirement-dokument = din idé skrevet ned, så en AI kan bygge den," which is faithful. The real drifts: (1) CRISP deletes the concrete generate → change-color → regenerate illustration and collapses straight to "Alternativet er klassisk udvikling." That is actual content loss — the original gives two illustrations (the token-generation loop AND the dev analogy); CRISP keeps only one. It also swaps Poul's "deraf ... begynder at tale om" for the flatter, more declarative "Det er derfor, vi taler om," losing the "this is where it originates" nuance, and adds slight intensifiers ("faktisk ønsker") not in the source. That makes CRISP punchier but less Poul and less complete. (2) Pronoun/register shift: the original mixes inclusive "vi/vores tokens" with "I sidder og genererer." LIGHT preserves that authentic mix; MEDIUM and CRISP normalize toward direct-address "du/dine tokens." This is a defensible clarity choice and reads naturally, but it is a voice change from "we" to "you" and should be a conscious call, not treated as neutral. (3) MEDIUM reorders "regenererer / ændrer farven" versus the original sequence — purely cosmetic, no meaning drift. The Danish in all three is natural and idiomatic; MEDIUM's is clean without sounding scrubbed. If maximum fidelity to Poul's exact "vi/vores" framing is the priority over polish, fall back to LIGHT; if a tight soundbite is wanted and losing the token-loop example is acceptable, CRISP works — but MEDIUM is the safest publishable choice.
Skåret væk: Cut both "øh", the stutter "at at", and smoothed the doubled word "udvikler en udvikler det" → "laver/bygger en udvikler det" (same meaning: a developer builds it). Broke the single run-on into sentences and put a real stop before "spec-driven" is introduced. The half-finished "kører vi lidt i ring" analogy is kept but given a clean ending clause ("indtil det er godt nok"). Preserved every fact and claim: tokens, generate/regenerate, change color, classic development, loose brief → build → fix → go in circles, "typically more expensive", spend time understanding, spec-driven, being specific before building, product requirement document, "your idea written down so an AI can build it". Nothing new invented. Crisp swaps the anglicism feel for "på forhånd" for a more published-Danish read; light keeps Poul's looser cadence and hedges ("egentlig", "lidt").
Træd ind i produktejer-rollen
57:24–57:52Budskab: Du skal træde ind i produktejer-rollen: følg op på dine agenter, spørg om de har cuttet corners, og test det de har lavet.
og og et godt trick at spørge de her agenter om det tror jeg ikke at vi sad og gjorde ved udviklerne det er sådan lidt om har du cuttet corners det kan de nemt finde på så så du skal træde ind i den her rolle som en produktejer hvor du skal halv projektledelse følge op på om dine agenter har lavet det du bedt om og spørge ind til det og teste det og alle de her ting og hvis man synes det er sjovt så kan man få rigtig meget ud af
Et godt trick er at spørge de her agenter, om de har cuttet corners — det kan de nemt finde på, og det er ikke noget, vi sad og gjorde ved udviklerne før. Du skal træde ind i rollen som produktejer. Det er lidt halv projektledelse: du følger op på, om dine agenter har lavet det, du bad om, du spørger ind til det, og du tester det. Og synes man, det er sjovt, kan man få rigtig meget ud af det.
Andre varianter (let / skarp) — begge motorer
Et godt trick er at spørge de her agenter, om de har cuttet corners. Det tror jeg ikke, vi sad og gjorde ved udviklerne, men det kan agenterne nemt finde på. Så du skal træde ind i den her rolle som en produktejer — lidt halv projektledelse — hvor du følger op på, om dine agenter har lavet det, du bad om, og spørger ind til det og tester det og alle de her ting. Og hvis man synes, det er sjovt, så kan man få rigtig meget ud af det.
Et godt trick er at spørge agenterne, om de har cuttet corners — for det kan de nemt finde på. Du skal træde ind i rollen som produktejer. Det er lidt halv projektledelse: du følger op på, om agenterne har lavet det, du bad om, du spørger ind til det, og du tester det. Synes man, det er sjovt, kan man få rigtig meget ud af det.
Dommer valgte «strammet»: MEDIUM is the best fit for a *published* piece because it cleans the delivery without losing any substantive content. It keeps all three of Poul's actual points — (1) the trick of asking agents whether they cut corners, (2) the aside that we didn't used to do this to human developers, and (3) the "step into the product-owner role / half project management: follow up, probe, test" throughline — while cutting only pure spoken filler. Its parallel triad "du følger op på… du spørger ind til det… du tester det" reproduces Poul's spoken cadence (he strings the actions with "og … og … og") in a rhetorically clean form that reads well on the page and speaks well in a voice clone, and the colon after "Det er lidt halv projektledelse" resolves the broken verbatim fragment "hvor du skal halv projektledelse" naturally. LIGHT is the most faithful but is really just lightly-tidied verbatim: it retains the run-on "og alle de her ting" and the piled-up "og"s, which read as unpolished for a republished product. CRISP is the cleanest prose but drops the developer contrast entirely and weakens "dine agenter" to "agenterne," so it sacrifices meaning and Poul's second-person framing for polish. MEDIUM sits exactly on the intended balance of intent + voice + clean delivery. Forbehold: Meaning drift / invented content, per variant: (1) MEDIUM inserts "før" ("det er ikke noget, vi sad og gjorde ved udviklerne før") — a mild interpretive addition. It is a faithful rendering of the implied past tense in the source ("det tror jeg ikke at vi sad og gjorde ved udviklerne"), so risk is low, but the word itself is not in the verbatim; drop it if strict fidelity is required. (2) CRISP omits the developer contrast ("det tror jeg ikke vi sad og gjorde ved udviklerne") completely — a genuine content loss of a real point Poul made — and downgrades "dine agenter" to "agenterne," dropping the direct second-person address; its added "for" (causal link) is fine. (3) LIGHT appends "det" to the trailing "…få rigtig meget ud af" — a natural completion of Poul's cut-off sentence, not an invented claim. Shared, meaning-neutral moves across all three: hedging the quoted second-person question "har du cuttet corners" into indirect "om de har cuttet corners," and grammar-fixing "det du bedt om" → "det, du bad om." No variant invents facts, numbers, or claims; the only item worth a second look before publishing is MEDIUM's "før," and the only actual meaning loss is CRISP's dropped developer aside. The Danish reads natural and idiomatic in all three; "cuttet corners" is retained as Poul's own anglicism (intentional voice, not an error).
Skåret væk: Kept all three of Poul's ideas intact: (1) det gode trick — spørg agenterne om de har cuttet corners, med sammenligningen til udviklerne; (2) træd ind i produktejer-rollen = "halv projektledelse": følg op, spørg ind, test; (3) den varme afrunding om at få meget ud af det, hvis man synes det er sjovt. Light: fjernede "og og" i starten, indskuddet "det er sådan lidt om", dobbelt "så så", og gjorde run-on'en flydende — men beholdt strukturen inkl. "og alle de her ting" og "halv projektledelse". Medium: samlede trick + "det kan de nemt finde på" + udvikler-sammenligningen i én sætning; brød projektledelses-opremsningen til tre klare led (følger op / spørger ind / tester); droppede "og alle de her ting" som tom hale. Crisp: strammede udvikler-tangenten til en kort bisætning (ellers ville den kræve mere setup end den er værd i en poleret version), gjorde produktejer-pointen til én ren sætning, og bevarede den personlige slutbemærkning. Beholdt bevidst "cuttet corners" og "halv projektledelse" i alle tre — det er Pouls egne ord/billede. Ingen nye tal, navne eller påstande tilføjet.