← All sessionsHomeSearch
AI Catalyst C3·Basecamp·3:13:53

Basecamp 4: Introduction to n8n — II

Harshit Trainer — same automation trainer as Basecamp 3 (Forbes contributor, YC-startup growth); runs an agency operating '60+ agents daily' and the agentmag.dev auto-written newsletter from a Mac mini · Niharika Cohort manager (opening LMS/recording logistics, drive-link upload, CSAT poll, close-out); Abhishek referenced as co-contact
▶local recording  ·  LMS lesson

Session map

ARCHITECTURETHE BUILDFRONT END & SHIPNewsletter architecturescrape → distill → write → sendJSON vs markdownabsolute vs readableSchemas by meta-promptClaude writes the schemaFirecrawl node/scrape, two formats, stealthThe token-saver node40-50% fewer tokensHumanizer agentskill → system promptDocs + Gmail deliveryarchive then sendAsk vs Build debugginglet n8n fix itselfFront-end bake-off7 tools, one promptThe taste skillanti-AI-slop designWebhook bridgeconnect blog to workflow
ArchitectureThe buildFront end & ship
click a node — its card pops up (drag it anywhere, × to close)
Concept

The map reads left to right — architecture flow into the build, then into front end & ship. Click any node to open that idea here; every timestamp jumps into the recording.

The short version

  1. Built the trainer's production Hacker News → AI newsletter workflow node by node: schedule trigger → Firecrawl scrape (JSON schema + markdown formats) → code node that distills the scrape → AI agent (humanizer-skill system prompt, GPT-5.5) → parser → Google Docs create/update → Gmail send.
  2. The money lesson: never pipe raw scrape output straight into an AI agent node — a code 'output parser' node strips field names, brackets, and noise first, cutting token spend ~40-50% on the same information.
  3. Format theory for non-coders: JSON (JavaScript Object Notation) when you need absolute, deterministic extraction — 'we don't want Firecrawl to think'; markdown when the LLM needs readable full context. Use both Firecrawl output formats.
  4. Front-end hour: the same meta-generated prompt (built by giving Claude the workflow JSON plus the anti-slop 'taste skill') was raced across Lovable, Base44, Emergent, Bolt, Replit, same.dev and Codex; Base44 finished first, Lovable's design won, and repos were pushed to GitHub for learners.
  5. Everything ships as a plug-and-play Google Drive pack: workflow JSONs (newsletter, webhook front-end variant, Product Hunt idea generator), implementation guides, Excalidraw board, prompts, and GitHub repos — with the mantra 'if it works, don't touch it'.

The concepts

01

Newsletter automation architecture

0:26:50

Before a single node lands on the canvas, the whole newsletter already exists — as a map Claude drew.

The session's spine is one production workflow, mapped in Claude before building: a schedule trigger fires daily; Firecrawl scrapes Hacker News; a code node distills the raw scrape into a clean brief; an AI agent with a humanizer system prompt writes the newsletter; an output parser cleans the result; Google Docs nodes create and update an archive copy; Gmail sends it. Every station exists for a reason — and one of them exists precisely because Claude's first draft was wrong (the code node, next concepts).

Two architectural notes elevate this above a demo. The Google Doc step is optional for delivery but doubles as a growing archive — the trainer flags it as the future knowledge base for a newsletter RAG chatbot. And the mind-map-first habit from Part 3 repeats deliberately: the blank canvas is the hard part, so you never start there.

Worked example · from the session

The map drawn live in Claude, then realized node by node over the next ninety minutes — the same pipeline that publishes agentmag.dev daily from the trainer's Mac mini.

Why it matters

This is what a production automation actually looks like: not one clever node but a chain of small responsibilities, with an archive step planted for a future feature. Architecture-before-canvas is the transferable habit.

People get this wrong

Claude's suggested architecture is the architecture.

Claude's first draft piped the scraper straight into the AI agent — the expensive design. The trainer overrode it with the code node. AI drafts the map; you still edit it.

Schedule trigger — runs daily Firecrawl scrapes Hacker News Code node distills the scrape the 40-50% token saver AI agent humanizer prompt GPT-5.5 · 3 iterations Output parser cleans agent output Google Docs create + update archive → future RAG base Gmail humanized newsletter out The production pipeline behind agentmag.dev — scrape, distill, write, archive, send.
The production pipeline behind agentmag.dev — scrape, distill, write, archive, send
For your projects

Your extraction pipeline has the same skeleton: source (transcript) → distill (condense) → AI write (this enrichment) → archive (YAML) → render (site). The 'archive doubles as future RAG base' note is literally your SQLite/vector phase.

This idea elsewherebuilds onthe Part 3 scraper, grown up
Go deeper

In one line: Target flow mapped in Claude before building: schedule trigger → Firecrawl scrape of Hacker News → code node (brief prep) → AI agent with humanizer prompt → output parser → Google Doc (create + update) → Gmail delivery with HTML formatting.

Google Doc step is optional but doubles as an archive and future RAG knowledge base for a newsletter chatbot (1:51:08)

Claude's first suggestion (Firecrawl straight into AI agent) was deliberately overridden — see the code-node concept (1:13:42)

The mind-map-first habit repeated from Part 3: blank canvas is the hard part; Claude gives you the starting map (0:28:51)

▶ Watch this taught: 0:26:50

Check yourself

Answer from memory first — the recall attempt is what makes it stick. Then reveal.

Walk the seven stations of the newsletter pipeline.

Schedule trigger → Firecrawl scrape → code node (distill) → AI agent (humanizer) → output parser → Google Docs create/update → Gmail send.

Why keep the Google Docs step if Gmail already delivers?

It's the archive — and the intended knowledge base for a future RAG chatbot over past newsletters. Deliverables die; archives compound.

02

Firecrawl node configuration

how-to0:47:14

One node does the whole harvesting job — if you configure it to extract exactly what you want and throw away everything you don't.

The Firecrawl node's power is in its scrape options, not its existence. The decisive move is requesting two output formats at once: JSON driven by an extraction prompt and schema — the deterministic 'give me exactly these fields' channel — and markdown, the readable full-page rendering the LLM can reason over later. The extraction prompt works whitelist-plus-blacklist: name the fields you want, and name the noise (navigation, footers, job ads, login links) you refuse to pay tokens for.

Around that sit the operational switches: strip base64 images and block ads (both are token ballast), disable store/cache when you want fresh scrapes, and pick your proxy tier — basic for normal sites, stealth for the sensitive or defended ones, at a higher credit cost. The economics are friendly: n8n's quick-connect creates a free hobby account with 100k credits, and the codebase is open source when the credits end.

Worked example · from the session

The trainer's production extraction prompt, shown field by field: whitelist rank/title/URLs/author/points/age/comments, blacklist everything navigational — the exact prompt shipped in the shared workflow JSON.

Do it in this order

GotchasFirecrawl's free credits are generous but finite — the trainer's answer when his ran out after ~2 months was to self-host the open-source codebase, not to pay. And don't over-buy stealth proxying: basic covers normal sites.

Why it matters

Scraping is the intake valve of most automations — configured lazily it floods every downstream node with noise you pay for three times: in credits, in tokens, and in output quality.

For your projects

The whitelist/blacklist extraction prompt is transcript-condensation logic applied to the web: name what survives, name what dies. Worth stealing verbatim if the KB ever ingests web sources (tool docs, Outskill lesson pages).

Go deeper

In one line: Install the Firecrawl community node, use the /scrape operation, and configure scrape options: two output formats (JSON with AI-extraction prompt + schema; markdown for LLM context), remove base64 images, block ads, disable store/cache, and choose basic vs stealth proxy.

Quick-connect from inside n8n auto-creates a Firecrawl account: free hobby plan + 100,000 credits for n8n signups; manual setup needs only the dashboard API key (0:53:20)

Trainer never paid for Firecrawl — when free credits ran out (~2 months) he self-hosted the open-source codebase (0:55:21)

Stealth proxy for sensitive/government targets, basic otherwise — stealth costs more (0:59:23)

The extraction prompt whitelists story fields (rank, title, URLs, author, points, age, comments) and blacklists navigation/footer/job/login noise (0:59:23)

▶ Watch this taught: 0:47:14

Check yourself

Answer from memory first — the recall attempt is what makes it stick. Then reveal.

Why request both JSON and markdown formats from one scrape?

JSON (with schema) delivers exact deterministic fields; markdown carries full readable context for the LLM downstream. Different consumers, one scrape.

When do you pay for the stealth proxy?

Only for sensitive or heavily-defended targets — basic covers normal sites and costs fewer credits.

What did the trainer do when the free credits ran out?

Self-hosted Firecrawl's open-source codebase — he's never paid for it.

03

JSON vs markdown (and why use both)

1:07:31

Two file formats run the whole AI economy: one for when nothing may be interpreted, one for when everything must be understood.

JSON — JavaScript Object Notation — is deterministic key-value structure: {"title": "...", "points": 342}. You use it when extraction must be absolute; in the trainer's words about the scraper, 'we do not want Firecrawl to think about what the heading is.' A schema pins exactly what comes back, every run, no interpretation. Markdown is the opposite instrument: hashtag headings and readable structure, the format LLMs digest best, carrying the full page so a model can reason over context a schema would have discarded.

Why do schemas steer models so reliably? Because LLMs were trained on oceans of JSON-annotated data — 'image = cat' pairs — so key-value structure is native to how they learned the world. The practical rule the session lands: don't choose. The scraper emits both formats side by side — JSON for the exact fields, markdown for the context.

Worked example · from the session

The formats made tangible live: Antigravity + Gemini generated example .md and .json files into a folder so learners could see the same content in both shapes.

Why it matters

Format choice is invisible until it bites — a 'thinking' extractor returns different fields on different days, and a context-starved model writes generic prose. Knowing which format serves which need is a daily non-coder superpower.

People get this wrong

Pick the one right format for your workflow.

Production scrapes request both: JSON for absolute fields, markdown for LLM-readable context. They serve different downstream consumers.

JSON — when extraction must be absolute {"title": "...", "points": 342} deterministic key-value structure a schema tells the scraper exactly what to grab "we do not want Firecrawl to think about what the heading is" Markdown — when the LLM needs context # Heading · **bold** · - list readable structure — what LLMs read best carries the full page for the model to reason over models are trained on markdown-shaped and JSON-annotated data alike The answer is both: Firecrawl emits the two formats side by side.
Absolute vs readable — and the answer is both
For your projects

The KB runs the same doctrine: YAML (JSON's cousin) for deterministic structure build_site.py consumes, markdown-ish teach prose for humans and models. The two-format scrape is your schema-plus-prose split, industrialized.

This idea elsewherereappears inn8n as a UI layer over JSONreappears inmarkdown as the KB upload format
Go deeper

In one line: Markdown (.md — hashtag headings, readable structure) is what LLMs read best, so it carries full-page context; JSON (.json, JavaScript Object Notation) is deterministic key-value structure, used when extraction must be absolute — 'we do not want Firecrawl to think about what the heading is'.

Both formats demoed live by having Antigravity/Gemini generate example .md and .json files in a folder (1:07:31)

LLMs are trained on JSON-annotated data ('image = cat'), which is why schemas steer them so reliably (1:03:28)

▶ Watch this taught: 1:07:31

Check yourself

Answer from memory first — the recall attempt is what makes it stick. Then reveal.

When must the output be JSON rather than markdown?

When extraction must be deterministic — exact named fields, identical shape every run, no interpretation by the scraper or model.

Why do JSON schemas steer LLMs so well?

Models trained on JSON-annotated data ('image = cat') treat key-value structure as native — a schema speaks their training language.

04

Generating JSON schemas by meta-prompting

1:01:24

You don't need to know how to write a JSON schema — you need to know how to describe the box you're standing in.

The schema field is where non-coders stall: it demands a formal structure in a syntax they've never written. The escape is meta-prompting with full context: tell Claude exactly where you are and what you're doing — 'I'm on the Firecrawl /scrape node in n8n, here's my target URL, here's my extraction prompt, I'm struggling with the schema — build the JSON schema for me.' The context does the work; the more of the node's situation you hand over, the more precise the artifact that comes back.

The live result made the point better than the technique: Claude returned a schema more detailed than the one in the trainer's own production workflow. The pattern generalizes to every formal-syntax field in every tool — cron expressions, regex, config blocks: describe the context, request the artifact.

Worked example · from the session

Run live during the Firecrawl setup: node named, URL and extraction prompt pasted, schema requested — and the returned schema out-detailed the production one.

Why it matters

This dissolves a whole class of 'I can't, I'm not technical' walls. Any field demanding formal syntax becomes a describable request — the skill is context assembly, which BC1 already taught you.

For your projects

This is BC1's meta-prompting layer applied inside a tool — the same move as having Claude write build_site.py's TOPIC_META entries or a YAML block: context in, artifact out.

This idea elsewherebuilds onmeta prompting
Go deeper

In one line: Non-coders get schemas by describing the node context to Claude: 'I'm on the Firecrawl /scrape node, here's my URL and prompt, I'm struggling with schema — build the JSON schema for me.' Claude returned one more detailed than the trainer's production version.

▶ Watch this taught: 1:01:24

Check yourself

Answer from memory first — the recall attempt is what makes it stick. Then reveal.

What goes into the meta-prompt for a schema?

Your situation, completely: which node, which operation, the target URL, your extraction prompt, and what you're stuck on — then 'build the JSON schema for me'.

What does this pattern generalize to?

Every formal-syntax field anywhere: cron expressions, regex, config files. Describe the context, request the artifact.

05

Code node before the AI agent (the token saver)

1:15:43

The most valuable node in the whole workflow contains no AI at all — it's the one that stops you paying the AI to read brackets.

Raw scraper output is JSON: field names, brackets, quotes, repeated structure — and every character of it bills as input tokens if you pipe it straight into an AI agent node. The fix is a JavaScript code node between scraper and agent that strips the packaging and hands the model clean readable text: just the stories, titles, points. Same information, roughly 40-50% fewer tokens. You don't write the JavaScript — AI does, and n8n can even self-generate a code node's contents once real data has flowed in.

The framing is what makes this a lesson rather than a trick. Claude's own suggested architecture was scraper-straight-into-agent (the trainer's joke conspiracy: 'the more tokens we burn, the more Claude makes'). At his agency's scale — 60+ agents running daily — the 40-50% cut 'is literally like hiring another employee.' The chat's proposed rule of thumb got an endorsement with a caveat: code node before AI agent, always for scraping workflows — not universally.

Worked example · from the session

Shown with the actual payloads side by side: the bracket-laden scrape JSON versus the code node's clean story list — the same Hacker News content at roughly half the token bill.

Why it matters

Token economics is the operating cost of the AI era, and this is its most learnable lesson: models should spend tokens on thinking, not on parsing packaging. One free node, 40-50% off, forever.

People get this wrong

More context into the agent is always better.

More INFORMATION is better; more FORMATTING is just cost. Strip structure the model doesn't need — it reads clean text as well or better.

WITHOUT the code node {"rank":1,"title":"...","url":"...", "points":342,"author":"...","age":"..."} field names, brackets, repeated structure — all billed as tokens WITH the code node 1. Story title — 342 points, 8h ago 2. Story title — 198 points, 3h ago same information, clean readable text −40-50% token cost, same information at 60+ agents running daily, "literally like hiring an employee" Never pipe raw scrape JSON into an AI agent — a code node strips the noise first.
Same information, 40-50% fewer tokens — the single most valuable node in the workflow
I have a conspiracy theory. I think Claude directly gave us this node because it wants us to burn tokens. The more tokens we burn, the more Claude makes money.1:17:47
Roughly 40 to 50 percent fewer tokens for the same information... a 40 to 50 percent reduction in token cost can save you a ton of money. It's literally like hiring an employee.1:23:50
For your projects

Your condensed transcripts are exactly this node: ~26k-token distillations standing between raw VTT and Fable. Same doctrine, same ~economics — the 40-50% figure is your pipeline's justification stated by someone else.

This idea elsewherebuilds oncontext is meteredreappears inthe same law: carry less, retrieve more
Go deeper

In one line: A JavaScript code node between scraper and AI agent strips raw JSON down to clean readable text — field names, brackets, and repeated structure removed — so the model sees only what it needs: ~40-50% fewer tokens for the same information.

Framed as real agency economics: 60+ agents running daily, so a 40-50% token cut 'is literally like hiring another employee' (1:23:50)

Trainer's joke-conspiracy: Claude suggested the direct-to-agent design 'because the more tokens we burn, the more money it makes' (1:17:47)

Rule of thumb from chat, endorsed with a caveat: code node before AI agent — always for scraping workflows, not universally (1:23:50)

The code itself is AI-written; n8n can even self-generate node code once incoming data exists (1:21:49)

Try it now

Open any workflow you have (or plan) with an AI node: what exactly flows into it? If the answer includes brackets and field names, you've found your code node.

▶ Watch this taught: 1:15:43

Check yourself

Answer from memory first — the recall attempt is what makes it stick. Then reveal.

What does the code node remove, and what survives?

Field names, brackets, quotes, repeated JSON structure go; the actual information — titles, points, content — survives as clean text. ~40-50% fewer tokens.

Who writes the JavaScript inside it?

AI — Claude/Codex, or n8n itself, which can self-generate node code once incoming data exists to look at.

Is 'code node before AI agent' a universal rule?

No — always for scraping workflows (structured noisy input), but not universally; some inputs are already clean.

06

AI agent node with the humanizer skill

how-to1:27:55

The writing station is Part 3's skill-conversion trick promoted to production: a humanizer skill becomes the soul of the agent that writes the newsletter.

The agent that writes the newsletter gets its soul the way Part 3 taught: pick a skill (the content humanizer, itself based on Claude's official humanizer), have Claude expand it into a full system prompt, paste. The expanded prompt has real engineering in it — a 3-phase structure that first detects AI writing patterns, then humanizes, then verifies, backed by an explicit blacklist of AI-tell phrases. The result: scraped tech stories go in, and prose that doesn't read like a bot comes out.

The configuration choices each carry a lesson: GPT-5.5 as the chat model for 'high thinking' (the trainer keeps ~$500 of credits loaded — this is his production spend); max iterations at 3 to bound cost; and no memory sub-node at all, because the Google Docs archive downstream already persists everything worth remembering. Memory is a component you justify, not a default.

Worked example · from the session

The full chain live: skills.sh copy → Claude expansion into the 3-phase prompt → paste into the node → GPT-5.5 selected → and the input-type error (agent prompt vs chat input) debugged in front of the room.

Do it in this order

GotchasThe live error worth remembering: GPT-5.5's node takes an AGENT prompt, not chat input — the mismatched-input failure was debugged on stream. When an agent node errors immediately, check what input type the model node expects before blaming the prompt.

Why it matters

AI-sounding output is the number-one tell of amateur automation. This station is where the session's output quality gets bought — and it costs one converted skill, not prompt-engineering expertise.

People get this wrong

An AI agent node needs all five components wired to be complete.

The five sockets are options, not requirements — this production agent runs with soul + brain only, because delivery and memory live in downstream nodes.

This idea elsewherebuilds onthe skill → system-prompt conversionbuilds onthe agent node's five sockets
Go deeper

In one line: System prompt built the Part 3 way: copy the 'content humanizer' skill (based on Claude's official humanizer) from skills.sh, have Claude expand it into a detailed system prompt — 3-phase structure (detect AI patterns, humanize, verify) with a blacklist of AI-tell phrases — then set max iterations to 3.

Chat model: OpenAI GPT-5.5, chosen for 'high thinking'; trainer keeps ~$500 of OpenAI credits loaded (1:25:52, 1:36:01)

Live gotcha: GPT-5.5 takes an agent prompt, not chat input — the mismatched-input error was debugged on stream (1:55:11)

No memory node needed — output persists in Google Docs (1:36:01)

▶ Watch this taught: 1:27:55

Check yourself

Answer from memory first — the recall attempt is what makes it stick. Then reveal.

What are the three phases of the humanizer system prompt?

Detect AI patterns → humanize the text → verify the result — with a blacklist of AI-tell phrases enforced throughout.

Why does this agent run without a memory sub-node?

The output persists in Google Docs — the archive IS the memory. Add components only when nothing else covers the job.

07

Google Docs + Gmail delivery

1:45:01

Delivery is two habits dressed as three nodes: reference data with expressions instead of hardcoding, and know when the Gmail node stops being enough.

The archive leg is a create-document node (pick the Drive folder, title built as an expression from the scrape's JSON — today's date, today's stories) followed by an update-document node, wired by dragging the document ID from the create node's output across. The delivery leg is a Gmail send-message node whose subject and body are again expressions fed from prior nodes. The anti-pattern named explicitly: hardcoding text that should flow from data — a hardcoded subject line means every email forever says the same thing.

Two working practices ride along. The bare Gmail node is a demo instrument: for real recipient lists you use a sending service — Resend, SendGrid, Mailchimp, or Azure Communication — built for volume, deliverability and unsubscribe compliance. And the canvas itself gets documented as you go: sticky notes and node colors, used heavily, are what make the workflow readable when you return in three months.

Worked example · from the session

The document ID dragged from the create node's output into the update node's field — expressions demonstrated as drag-and-drop plumbing, not syntax to memorize.

Why it matters

Expressions are what turn a chain of nodes into a living pipeline — data flowing forward instead of strings frozen at build time. And the Gmail-vs-sending-service line is the difference between a demo and something that actually reaches inboxes.

People get this wrong

If the test email arrived, the delivery design is done.

One email to yourself proves the plumbing. Lists need a sending service — the bare Gmail node has no list handling, unsubscribe or deliverability management.

Go deeper

In one line: Create-document node (drive folder, expression-based JSON title) then update-document node (drag the document ID across), then a Gmail send-message node; subject and message should be expressions fed from prior nodes, not hardcoded.

For real recipient lists use a sending service — Resend, SendGrid, Mailchimp, or Azure Communication email — not the bare Gmail node (2:09:24)

Sticky notes and node colors used heavily as canvas documentation practice (0:43:08)

▶ Watch this taught: 1:45:01

Check yourself

Answer from memory first — the recall attempt is what makes it stick. Then reveal.

Why must the email subject be an expression rather than typed text?

Typed text is frozen at build time — every send identical. An expression fed from prior nodes makes each send reflect that run's data.

When does the Gmail node stop being the right tool?

The moment there's a real recipient list — switch to Resend, SendGrid, Mailchimp or Azure Communication for volume, deliverability and compliance.

08

Debugging with n8n's AI assistant (Ask vs Build)

how-to1:55:11

n8n's assistant has two modes, and only one of them helps a non-coder: Ask explains your error, Build fixes it.

When a node fails, the assistant offers Ask and Build. Ask produces an explanation — accurate, and useless if you can't act on it. Build operates on the workflow itself: copy in the error, @-tag the failing node, and it edits the canvas. The live proof was the session's own blocking bug: the Google Doc update kept failing on the agent's raw output until Build mode auto-inserted the missing parse-AI-output code node — a fix the trainer didn't have to design.

The mode has a temperament: it rearranged the sticky notes while editing and occasionally stalls with internal errors (restart the session). Which is why the golden rule got stated twice: 'If it works, do not touch it.' Debugging tools are for broken things; working production code — like the shared workflow JSON — should be reused as-is, not regenerated.

Worked example · from the session

The end-to-end verification that followed: live Hacker News stories arriving as a humanized newsletter email — after Build mode's auto-inserted parser fixed the chain.

Do it in this order

GotchasBuild mode edits your canvas — expect side effects (it bunched up the sticky notes live). And once the workflow runs: 'If it works, do not touch it' — reuse the shared production JSON rather than regenerating a working thing for elegance.

Why it matters

This closes the non-coder loop: you can now build (paste JSON), run (executions view), and FIX — all without reading a stack trace. Fixing was the missing third leg.

People get this wrong

Once AI can fix workflows, regenerate freely — improvement is cheap.

'If it works, don't touch it.' Every regeneration risks new breakage; working automations are assets to preserve, and shared production JSON exists so you don't rebuild.

I have one golden rule. If it works, don't touch it.0:47:14
Go deeper

In one line: When nodes fail: 'Ask' mode explains (useless to a non-coder), 'Build' mode fixes — copy the error, @-tag the failing node, let it edit the workflow. It auto-inserted the missing parse-AI-output code node that made the Google Doc update work.

Side effects observed live: it bunched up the sticky notes and sometimes stalls/internal-errors — restart the session (2:03:18)

Golden rule stated twice: 'If it works, do not touch it' — reuse the shared production code rather than regenerate (0:47:14)

Final run verified end-to-end: live Hacker News stories delivered as a humanized newsletter email (2:05:20)

▶ Watch this taught: 1:55:11

Check yourself

Answer from memory first — the recall attempt is what makes it stick. Then reveal.

Ask vs Build — which and why?

Build. Ask explains the error, which a non-coder can't act on; Build edits the workflow — @-tag the failing node and let it fix things.

What did Build mode contribute to the live workflow?

It auto-inserted the missing parse-AI-output code node between agent and Google Docs — the fix that made the update node work.

09

Front-end bake-off across vibe-coding tools

2:11:26

Same prompt, seven tools, side by side — the fairest vibe-coding comparison you'll see, and its conclusion is that the wrapper barely matters.

The experiment: one meta-generated mega prompt with the workflow JSON attached, pasted simultaneously into Lovable, Base44, Emergent, Bolt, Replit, same.dev, and Codex (GPT-5.5 'extra high'), all racing to build the same blog front end for the newsletter. Results, as observed that day: Base44 finished first; Lovable won on design and typography (while eating tokens); Replit and Emergent produced working builds; Bolt was weak; Codex delivered a great back end with an average front end. Several tools paywall the GitHub push or deploy step — worth knowing before you commit work to one.

The trainer's synthesis cuts deeper than the rankings: no tool is 'better' — results track the underlying model, because these platforms are wrappers around the same few frontier models. Hence his actual setup: one subscription (Codex or Claude Code), not seven. History note for orientation: v0 by Vercel is the OG component-based vibe-coding tool that predates Lovable and Bolt.

Worked example · from the session

Seven browser tabs building the same site live, then toured one by one — with the Lovable, Bolt and Codex outputs pushed to GitHub as repos for learners.

Why it matters

One day's bake-off teaches permanent methodology: judge tools empirically on YOUR prompt, expect rankings to shift with model updates, and put your money on models rather than wrappers.

People get this wrong

The bake-off found the best vibe-coding tool — use that one.

It found that day's ranking on one prompt. The stable finding is that results track models, not wrappers — so re-test when models change, and don't collect subscriptions.

ONE mega prompt meta-generated from the workflow JSON + the anti-slop taste skill Base44 fastest build Lovable best design · "a token eater" Codex great back end, average front Replit · Emergent working builds Bolt · same.dev weak / login-gated No tool is "better" — results track the underlying model. Keep one subscription, race when it matters.
One prompt, seven tools, compared live — results track the model, not the wrapper
This idea elsewherebuilds onthe vibe-coding framework, raced
Go deeper

In one line: One prompt + the workflow JSON attached, run simultaneously on Lovable, Base44, Emergent, Bolt, Replit, same.dev, and Codex (GPT-5.5 'extra high') to build a blog front end that publishes the newsletters — outputs compared live.

Results: Base44 fastest, Lovable's design/typography the trainer's favorite, Bolt weak, Codex 'great back end, average front end'; several tools paywall GitHub push/deploy (2:23:39–2:31:59)

v0 (by Vercel) credited as the OG component-based vibe-coding tool that predates Lovable/Bolt (2:46:10)

No tool is 'better' — results track the underlying model; trainer's default is one subscription (Codex or Claude Code) (3:08:30)

▶ Watch this taught: 2:11:26

Check yourself

Answer from memory first — the recall attempt is what makes it stick. Then reveal.

What were the headline results of the bake-off?

Base44 fastest, Lovable best design ('a token eater'), Replit/Emergent working, Bolt weak, Codex great back end / average front end — as of that day's models.

What's the deeper conclusion beyond the rankings?

Tools are wrappers; output quality tracks the underlying model. One good subscription beats seven — race tools only when a decision matters.

10

The 'taste skill' (anti-AI-slop front ends)

2:13:28

'You cannot outsource taste' went viral as a warning — so someone packaged taste as a skill, and now you install it before building.

AI-generated front ends share a look — the purple gradients, the stock layouts, the design equivalent of AI-tell phrases — and BC2's fix was naming frameworks in your prompt. The taste skill upgrades that move: it's a skills.sh skill encoding an anti-slop front-end framework, named after the viral 'you cannot outsource taste' tweet, and you deploy it by embedding its install command in the build prompt itself: 'download this skill before building.'

Conceptually this completes the session's skill arc: the humanizer skill de-slops the writing, the taste skill de-slops the design. Both are the same maneuver — someone else's judgment, packaged, installed into your pipeline at the exact point where generic output would otherwise appear.

Worked example · from the session

The bake-off's mega prompt carried the taste-skill install command into all seven tools — every generated blog started from the anti-slop framework rather than the default look.

Why it matters

Output that looks and reads like AI is the adoption killer for anything you ship. The two-skill pattern — humanizer for words, taste for design — is a reusable answer you can apply in one prompt line.

For your projects
  • A 'Paul's-KB taste skill': encode the approved BC5 design conventions (palette, Public Sans, card anatomy) as a skill, so any future chat generating KB pages inherits the design system automatically.
Go deeper

In one line: A skills.sh skill applying an anti-slop front-end framework so generated sites don't look like default AI output; named after the viral 'you cannot outsource taste' tweet. Install command embedded in the build prompt with 'download this skill before building'.

▶ Watch this taught: 2:13:28

Check yourself

Answer from memory first — the recall attempt is what makes it stick. Then reveal.

How does the taste skill get applied to a build?

Its install command rides inside the build prompt — 'download this skill before building' — so the tool applies the anti-slop framework from the start.

What's the parallel between the taste skill and the humanizer skill?

Same maneuver, different medium: packaged judgment installed where generic output would appear — humanizer for prose, taste for front-end design.

11

Meta-prompting the front-end prompt from the workflow JSON

how-to2:42:07

The best front-end prompt isn't written — it's derived, by handing Claude the back end and asking for the prompt that fits it.

BC2 taught prompt-from-PRD-plus-vendor-guide; this is the automation-era version: the source of truth is the workflow JSON itself. Attach it to Claude and ask for a Lovable mega prompt. Because Claude can read the workflow — the webhook shapes, the document structure, the data fields — the generated prompt specifies a front end that fits this exact back end, down to code blocks, with the taste-skill install command folded in.

This is meta-prompting matured into a chain: skill → system prompt (the humanizer), context → schema (the Firecrawl node), and now workflow → front-end prompt. The pattern is always the same shape — give the model the machine-readable truth, request the artifact one level up.

Worked example · from the session

The bake-off's ammunition was made exactly this way: workflow JSON attached to Claude, mega prompt out, pasted across seven tools — one derivation, seven builds.

Do it in this order

GotchasThe quality ceiling is set by what you attach: the workflow JSON is what makes the prompt 'hyper-specific'. Without it, you're back to generic front-end guessing. (Also observed live: Claude's free-tier daily limit exists — the trainer hit it mid-demo.)

Why it matters

Hand-written prompts describe what you remember; derived prompts describe what IS. Any time a machine-readable source of truth exists, deriving beats describing.

For your projects

You already run this chain — the certificates work order and checklist manifests are 'derived prompts' from machine state. The reusable lesson: whenever YAML/JSON truth exists, generate the instruction from it rather than writing it.

This idea elsewherebuilds onmeta promptingbuilds onPRD → tool-compliant prompt
Go deeper

In one line: Attach the n8n workflow JSON to Claude and ask for a hyper-specific Lovable 'mega prompt' — including the taste-skill install command and code blocks — so the front end is generated with full knowledge of the back end it must serve.

▶ Watch this taught: 2:42:07

Check yourself

Answer from memory first — the recall attempt is what makes it stick. Then reveal.

Why attach the workflow JSON instead of describing the workflow?

The JSON is the ground truth — Claude reads actual node structures and data fields, so the generated prompt fits the real back end instead of your summary of it.

What three things ride inside the mega prompt?

The hyper-specific build spec derived from the JSON, the taste-skill install command, and any needed code blocks.

12

Connecting the front end via webhook trigger (bonus workflow)

2:34:01

The blog and the workflow are separate machines until a webhook marries them — one URL turns the front end into the workflow's remote control.

The shared bonus variant swaps the newsletter workflow's schedule trigger for a webhook trigger — Part 3's 'URL the outside world can call'. Now the wiring question is where the front end should call it, and the answer reuses the derivation pattern: give the workflow JSON to Lovable and ask it for (and where to put) the webhook URL. The blog gains a button that fires the pipeline on demand.

The operational catch is real: a webhook URL must be reachable from the internet, so the n8n instance has to be publicly hosted — a locally-running n8n can't receive calls from a deployed blog. This is where the hosting decisions from the Q&A stop being theoretical. A second bonus workflow shipped alongside: a Product Hunt RSS idea generator — daily scrape of launches into a sheet with taglines, categories and monetization notes.

Worked example · from the session

The webhook-variant JSON shipped in the drive pack: import it, hand it to Lovable with the 'where does the webhook URL go' question, and the generated blog wires itself to your workflow.

Why it matters

This is the moment automations become products: a UI anyone can press, driving a pipeline you own. Trigger choice — schedule vs webhook — is the difference between a routine and a service.

People get this wrong

Connecting a front end to n8n requires API development.

It's one webhook trigger plus one URL placed in the right spot — and the vibe-coding tool will tell you the spot if you hand it the workflow JSON.

This idea elsewherebuilds onthe webhook triggerreappears infront end meets back end
Go deeper

In one line: A shared variant of the scraper swaps in a webhook trigger; give the workflow JSON to Lovable and ask it for/where to put the webhook URL. The n8n instance must be publicly hosted for the connection to work.

Second bonus workflow: Product Hunt RSS idea generator — daily scrape of launches into a sheet with taglines, categories, and monetization notes (2:36:02)

▶ Watch this taught: 2:34:01

Check yourself

Answer from memory first — the recall attempt is what makes it stick. Then reveal.

What changes between the newsletter workflow and its bonus variant?

Only the trigger: schedule (runs daily by itself) becomes webhook (runs when the front end calls the URL) — the pipeline behind it is the same.

Why won't the bridge work with n8n running on your laptop?

A deployed front end calls the webhook over the internet — the n8n instance must be publicly hosted to be reachable.

13

Scraping and hosting operations (Q&A)

2:50:13

The Q&A drew the operational map: which scraper for which target, which host for which privacy need, and why your face still matters more than your stack.

Scraping operations have a division of labor. Firecrawl is the scraping-only service for ordinary web pages. Apify is the 'app store for APIs' — prebuilt scrapers for Instagram, YouTube and, critically, LinkedIn, where the ban-resistant recipe is Apify's LinkedIn scraper plus rotating geo-proxies (Bright Data, which ships n8n nodes). Hosting has privacy tiers: n8n cloud (easiest, least private) < a Hostinger-style VPS < fully local — and the fully-local stack is n8n + Firecrawl + Ollama all self-hosted, with a Mac mini M4 as a fine always-on server. The lazy path to a local install: paste the repo link into Codex or Claude Code and say 'run this locally' — it handles Docker.

The ecosystem answers filled out the edges — Typefully/Blotato for social posting, the WordPress node for blog publishing, arXiv (with an MCP server) for research feeds, Vercel for free front-end hosting — but the closing advice was human: put a face on your agency site and build in public on LinkedIn, because 'no matter what AI is, we still trust people.'

Worked example · from the session

The trainer's own setup as the proof: production workflows on his own hardware (Mac mini), agentmag.dev as the public build-in-progress, and his face on all of it.

Why it matters

These are the questions you hit in week two of really using n8n — LinkedIn bans, hosting choices, publishing targets — answered from production experience rather than docs.

People get this wrong

One scraper tool should handle every target.

Targets differ in defenses: Firecrawl for ordinary pages, Apify's purpose-built scrapers for platforms like LinkedIn/Instagram, geo-proxies where bans are the norm. Match tool to target.

No matter what AI is, we still trust people only. Keep posting on LinkedIn. Be public with whatever you're posting. That's what builds credibility.3:00:24
For your projects

The WordPress node is your sleeper: LWP/Elementor sites could receive auto-published content from an n8n pipeline — and the Mac mini always-on-server pattern is the same box the Ollama sparks pointed at.

  • TechOnCall build-in-public: a weekly LinkedIn post auto-drafted from your actual completed tickets (anonymized) — the 'we still trust people' advice, automated.
Go deeper

In one line: LinkedIn without bans: rotating geo-proxies (e.g. Bright Data, which has n8n nodes) plus Apify's LinkedIn scraper. Apify = 'app store for APIs' (Instagram, YouTube scrapers); Firecrawl = scraping-only service. Fully-local stack = n8n + Firecrawl + Ollama all self-hosted.

Run n8n locally the lazy way: paste the repo link into Codex/Claude Code and say 'run this locally' — it handles Docker (2:52:17)

Hosting privacy tiers: n8n cloud < Hostinger VPS < fully local; Mac mini M4 works as an always-on server (3:08:30)

Social posting via Typefully or Blotato (custom node); WordPress node for blog publishing; arXiv (with MCP server) for research-paper feeds; Vercel for free front-end hosting (2:54:18–3:10:31)

Agency credibility: put a human face on the site, build in public on LinkedIn — 'no matter what AI is, we still trust people' (3:00:24)

▶ Watch this taught: 2:50:13

Check yourself

Answer from memory first — the recall attempt is what makes it stick. Then reveal.

The ban-resistant LinkedIn scraping recipe?

Apify's LinkedIn scraper plus rotating geo-proxies (e.g. Bright Data, which has n8n nodes) — never raw scraping.

Name the hosting privacy tiers and the fully-local stack.

n8n cloud < VPS (Hostinger) < fully local; the local stack is self-hosted n8n + Firecrawl + Ollama — a Mac mini works as the always-on box.

Easiest way to get n8n running locally?

Hand the repo link to Codex/Claude Code and say 'run this locally' — it manages the Docker setup.

Every concept, three clicks deep

The same concepts as a quick reference: the closed row is the glance, open is the study card, and every timestamp jumps into the recording.

01Newsletter automation architectureTarget flow mapped in Claude before building: schedule trigger → Firecrawl scrape of Hacker News → code nod…0:26:50›

Target flow mapped in Claude before building: schedule trigger → Firecrawl scrape of Hacker News → code node (brief prep) → AI agent with humanizer prompt → output parser → Google Doc (create + update) → Gmail delivery with HTML formatting.

Google Doc step is optional but doubles as an archive and future RAG knowledge base for a newsletter chatbot (1:51:08)

Claude's first suggestion (Firecrawl straight into AI agent) was deliberately overridden — see the code-node concept (1:13:42)

The mind-map-first habit repeated from Part 3: blank canvas is the hard part; Claude gives you the starting map (0:28:51)

02Firecrawl node configurationInstall the Firecrawl community node, use the /scrape operation, and configure scrape options: two output f…0:47:14›

Install the Firecrawl community node, use the /scrape operation, and configure scrape options: two output formats (JSON with AI-extraction prompt + schema; markdown for LLM context), remove base64 images, block ads, disable store/cache, and choose basic vs stealth proxy.

Quick-connect from inside n8n auto-creates a Firecrawl account: free hobby plan + 100,000 credits for n8n signups; manual setup needs only the dashboard API key (0:53:20)

Trainer never paid for Firecrawl — when free credits ran out (~2 months) he self-hosted the open-source codebase (0:55:21)

Stealth proxy for sensitive/government targets, basic otherwise — stealth costs more (0:59:23)

The extraction prompt whitelists story fields (rank, title, URLs, author, points, age, comments) and blacklists navigation/footer/job/login noise (0:59:23)

03JSON vs markdown (and why use both)Markdown (.md — hashtag headings, readable structure) is what LLMs read best, so it carries full-page context;1:07:31›

Markdown (.md — hashtag headings, readable structure) is what LLMs read best, so it carries full-page context; JSON (.json, JavaScript Object Notation) is deterministic key-value structure, used when extraction must be absolute — 'we do not want Firecrawl to think about what the heading is'.

Both formats demoed live by having Antigravity/Gemini generate example .md and .json files in a folder (1:07:31)

LLMs are trained on JSON-annotated data ('image = cat'), which is why schemas steer them so reliably (1:03:28)

04Generating JSON schemas by meta-promptingNon-coders get schemas by describing the node context to Claude: 'I'm on the Firecrawl /scrape node, here's…1:01:24›

Non-coders get schemas by describing the node context to Claude: 'I'm on the Firecrawl /scrape node, here's my URL and prompt, I'm struggling with schema — build the JSON schema for me.' Claude returned one more detailed than the trainer's production version.

05Code node before the AI agent (the token saver)A JavaScript code node between scraper and AI agent strips raw JSON down to clean readable text — field nam…1:15:43›

A JavaScript code node between scraper and AI agent strips raw JSON down to clean readable text — field names, brackets, and repeated structure removed — so the model sees only what it needs: ~40-50% fewer tokens for the same information.

Framed as real agency economics: 60+ agents running daily, so a 40-50% token cut 'is literally like hiring another employee' (1:23:50)

Trainer's joke-conspiracy: Claude suggested the direct-to-agent design 'because the more tokens we burn, the more money it makes' (1:17:47)

Rule of thumb from chat, endorsed with a caveat: code node before AI agent — always for scraping workflows, not universally (1:23:50)

The code itself is AI-written; n8n can even self-generate node code once incoming data exists (1:21:49)

06AI agent node with the humanizer skillSystem prompt built the Part 3 way: copy the 'content humanizer' skill (based on Claude's official humanize…1:27:55›

System prompt built the Part 3 way: copy the 'content humanizer' skill (based on Claude's official humanizer) from skills.sh, have Claude expand it into a detailed system prompt — 3-phase structure (detect AI patterns, humanize, verify) with a blacklist of AI-tell phrases — then set max iterations to 3.

Chat model: OpenAI GPT-5.5, chosen for 'high thinking'; trainer keeps ~$500 of OpenAI credits loaded (1:25:52, 1:36:01)

Live gotcha: GPT-5.5 takes an agent prompt, not chat input — the mismatched-input error was debugged on stream (1:55:11)

No memory node needed — output persists in Google Docs (1:36:01)

07Google Docs + Gmail deliveryCreate-document node (drive folder, expression-based JSON title) then update-document node (drag the docume…1:45:01›

Create-document node (drive folder, expression-based JSON title) then update-document node (drag the document ID across), then a Gmail send-message node; subject and message should be expressions fed from prior nodes, not hardcoded.

For real recipient lists use a sending service — Resend, SendGrid, Mailchimp, or Azure Communication email — not the bare Gmail node (2:09:24)

Sticky notes and node colors used heavily as canvas documentation practice (0:43:08)

08Debugging with n8n's AI assistant (Ask vs Build)When nodes fail: 'Ask' mode explains (useless to a non-coder), 'Build' mode fixes — copy the error, @-tag t…1:55:11›

When nodes fail: 'Ask' mode explains (useless to a non-coder), 'Build' mode fixes — copy the error, @-tag the failing node, let it edit the workflow. It auto-inserted the missing parse-AI-output code node that made the Google Doc update work.

Side effects observed live: it bunched up the sticky notes and sometimes stalls/internal-errors — restart the session (2:03:18)

Golden rule stated twice: 'If it works, do not touch it' — reuse the shared production code rather than regenerate (0:47:14)

Final run verified end-to-end: live Hacker News stories delivered as a humanized newsletter email (2:05:20)

09Front-end bake-off across vibe-coding toolsOne prompt + the workflow JSON attached, run simultaneously on Lovable, Base44, Emergent, Bolt, Replit, sam…2:11:26›

One prompt + the workflow JSON attached, run simultaneously on Lovable, Base44, Emergent, Bolt, Replit, same.dev, and Codex (GPT-5.5 'extra high') to build a blog front end that publishes the newsletters — outputs compared live.

Results: Base44 fastest, Lovable's design/typography the trainer's favorite, Bolt weak, Codex 'great back end, average front end'; several tools paywall GitHub push/deploy (2:23:39–2:31:59)

v0 (by Vercel) credited as the OG component-based vibe-coding tool that predates Lovable/Bolt (2:46:10)

No tool is 'better' — results track the underlying model; trainer's default is one subscription (Codex or Claude Code) (3:08:30)

10The 'taste skill' (anti-AI-slop front ends)A skills.sh skill applying an anti-slop front-end framework so generated sites don't look like default AI o…2:13:28›

A skills.sh skill applying an anti-slop front-end framework so generated sites don't look like default AI output; named after the viral 'you cannot outsource taste' tweet. Install command embedded in the build prompt with 'download this skill before building'.

11Meta-prompting the front-end prompt from the workflow JSONAttach the n8n workflow JSON to Claude and ask for a hyper-specific Lovable 'mega prompt' — including the t…2:42:07›

Attach the n8n workflow JSON to Claude and ask for a hyper-specific Lovable 'mega prompt' — including the taste-skill install command and code blocks — so the front end is generated with full knowledge of the back end it must serve.

12Connecting the front end via webhook trigger (bonus workflow)A shared variant of the scraper swaps in a webhook trigger;2:34:01›

A shared variant of the scraper swaps in a webhook trigger; give the workflow JSON to Lovable and ask it for/where to put the webhook URL. The n8n instance must be publicly hosted for the connection to work.

Second bonus workflow: Product Hunt RSS idea generator — daily scrape of launches into a sheet with taglines, categories, and monetization notes (2:36:02)

13Scraping and hosting operations (Q&A)LinkedIn without bans: rotating geo-proxies (e.g.2:50:13›

LinkedIn without bans: rotating geo-proxies (e.g. Bright Data, which has n8n nodes) plus Apify's LinkedIn scraper. Apify = 'app store for APIs' (Instagram, YouTube scrapers); Firecrawl = scraping-only service. Fully-local stack = n8n + Firecrawl + Ollama all self-hosted.

Run n8n locally the lazy way: paste the repo link into Codex/Claude Code and say 'run this locally' — it handles Docker (2:52:17)

Hosting privacy tiers: n8n cloud < Hostinger VPS < fully local; Mac mini M4 works as an always-on server (3:08:30)

Social posting via Typefully or Blotato (custom node); WordPress node for blog publishing; arXiv (with MCP server) for research-paper feeds; Vercel for free front-end hosting (2:54:18–3:10:31)

Agency credibility: put a human face on the site, build in public on LinkedIn — 'no matter what AI is, we still trust people' (3:00:24)

Tools referenced

ToolCoverageMomentContext
n8ndemonstrated0:26:50Full production build: schedule trigger, Firecrawl node install, scrape options, code nodes, AI agent, Google Docs, Gmail, sticky notes/colors, Ask-vs-Build AI debugging, JSON download/import, webhook variant
Firecrawldemonstrated0:47:14/scrape with JSON+markdown formats, AI-extraction prompt + schema, proxy/stealth options, n8n quick-connect (hobby plan + 100k free credits), self-hosting the open-source repo when credits end
Claudedemonstrated0:28:51Workflow mind map, JSON schema generation, humanizer-skill → system prompt, Lovable mega-prompt from attached workflow JSON (Sonnet; free-tier daily limit hit live)
OpenAI GPT-5.5 (chat model node)demonstrated1:36:01Agent LLM; agent-prompt-vs-chat-input error debugged live; picked for high thinking
skills.shdemonstrated1:27:55Content humanizer skill (based on Claude's official humanizer) and the taste skill; top skill on the site is a 1.4M-download skill-finder skill
Google Docs (n8n node)demonstrated1:45:01Create + update document nodes, drive folder selection, expression-based titles
Gmail (n8n node)demonstrated1:53:09Send-message delivery node; hardcoded-vs-expression subject discussion
Lovabledemonstrated2:17:35Bake-off winner on design; 'a token eater' — free credits nearly exhausted; repo pushed to GitHub and shared
Base44demonstrated2:23:39Fastest build in the bake-off; trainer's first time using it; noted as recently acquired
Codex (OpenAI)demonstrated2:21:38GPT-5.5 'extra high' with live preview; strong back end, average front end; repo pushed for learners; trainer's YC early access; also his n8n-local-install helper; has 'pets' feature
Bolt / Replit / Emergent / same.devdemonstrated2:19:36Bake-off participants — Bolt weak, Emergent 'pretty cool', same.dev and Base44 login-gated mid-demo, Replit built a working blog
Antigravitydemonstrated1:07:31Used with Gemini to generate the example markdown and JSON files for the format lesson
GitHubdemonstrated2:27:44Repos published live (Lovable + Bolt + Codex outputs) and added to the resource pack
Excalidrawdemonstrated0:16:27Running mind-map board (day 1 + day 2), exported JSON shared in the drive
agentmag.devdemonstrated0:39:00Trainer's production proof: self-writing newsletter published same day ('Codex safety control and agent inference cost'), running on his Mac mini
Apifyexplained2:58:23'App store for APIs' — LinkedIn/Instagram/YouTube scrapers with free credits; pair with geo-proxies for LinkedIn
Bright Datamentioned2:50:13Geo-proxy provider with n8n nodes for ban-resistant scraping
Typefully / Blotatomentioned2:54:18Auto-posting to Twitter/LinkedIn; Blotato has a custom n8n node
Resend / SendGrid / Mailchimp / Azure Communicationmentioned2:09:24Proper multi-recipient newsletter delivery services beyond the Gmail node
v0 (Vercel)mentioned2:46:10OG component vibe-coding tool; prebuilt templates connectable to n8n
Vercelmentioned3:04:27Free hosting recommendation for learner-built platforms
Ollamamentioned2:54:18Third leg of the fully-local stack (n8n + Firecrawl + Ollama)
arXivmentioned3:10:31Deep AI research-paper source, scrapeable, has an MCP server
Claude Coworkmentioned3:10:31Q&A comparison: runs recurring tasks but dies with your laptop, closed-source, 'a UI wrapper on Claude Code' — vs n8n as purpose-built always-on automation
VoiceInk-style dictation app (heard as 'free flow')mentioned1:34:00Trainer's open-source, on-device whisper dictation tool (Apple-silicon-only); name garbled, learner-identified in chat

Session materials

Archived locally on V: — click to open. Companion pages link to the LMS.

pdf
HN AI Newsletter Workflow - Implementation Guide.pdf
98 KB
json
hn-ai-newsletter-firecrawl-openai-workflow.n8n.json
18 KB
json
hn-ai-newsletter-lovable-blog-publisher-v2-triggered.n8n.json
25 KB
pdf
Lovable Prompt - HN AI Blog Frontend.pdf
97 KB
xlsx
Product Hunt AI Product Ideas - Learner Demo.xlsx
11 KB
pdf
Product Hunt AI Product Ideas Workflow - Implementation Guide.pdf
71 KB
json
product-hunt-ai-product-ideas-to-sheets-manual-trigger.n8n.json
14 KB
lms
Basecamp Part 3 | Introduction to N8N - I - Pre Reads
companion page on the platform
lms
Basecamp Part 3 | Introduction to N8N - I - Post Read
companion page on the platform
lms
Basecamp Part 4 | Introduction to N8N - II - Post Read
companion page on the platform
lms
Introduction to N8N - Resources
companion page on the platform

Action items

Resources mentioned

Resources
  • docGoogle Drive resource pack (linked in LMS): newsletter workflow JSON + implementation guide, webhook front-end variant, Product Hunt idea-generator workflow, Excalidraw board, Lovable mega-prompt, GitHub repos 2:40:06
  • docFirecrawl extraction prompt + JSON schema (embedded in the shared workflow JSON) 0:59:23
  • docContent humanizer skill and taste skill links (skills.sh, dropped in chat) 1:31:59
  • docGitHub repos from the bake-off (Lovable, Bolt, Codex builds of the newsletter blog) 2:29:57
  • docTrainer's additional workflows at his site /n8n; agentmag.dev for feedback 2:40:06
  • docSlido Q&A + CSAT poll 2:50:13

Extraction notes

This page was built from an auto-generated transcript, which garbles product and people's names. Those were corrected silently in everything above and logged here for transparency. The warnings flag claims that were true on the recording day but change fast.

Transcript corrections applied

The transcript saysThe trainer actually means
file crawl / fire troll / FireCloak / Firepower / firewall / FireCloudFirecrawl
n a 10 / an ITN / any 10 / NITEL / n 8 n / n e 10n8n
notes (throughout)nodes
JSON script (in 'I want a JSON script that extracts')JavaScript
test skill / pay scale / taste scaletaste skill
codecs / g b d 5.5 / g p d 5.5Codex / GPT-5.5
Wersl / WERSL / VersalVercel
Sam OrtmanSam Altman
base cam 4 / AICPC 3Basecamp 4 / AI Catalyst C3
agent mind dot devagentmag.dev
hi at harshaat dot comtrainer's email (garbled, unverified)
free flow / free whisper flowtrainer's open-source on-device dictation app (exact name unresolved; learner identified it in chat)
Claude CowartClaude Code (in 'Claude Cowork is a UI wrapper on…')
Blotato AIBlotato (social-posting tool, as heard)
Wybob (YouTuber releasing daily videos)uncertain — learner-referenced YouTuber
geoprocessgeo-proxies
super baseSupabase
storyboard (learner hosting question)uncertain — possibly 'dashboard'
Charge GBD / chat GBTChatGPT
the loaferuncertain filler garble
Ola / o lamaOllama
graph QL (in 'give it to me in a complete graph QL')uncertain — likely 'graphical' rendering/artifact request, not GraphQL

True on recording day — verify before relying