Above: Prompt engineering as specification engineering is a good concise frame for what you’re building with VS.
—-
What to highlight
I’d frame each demo as three moments:
The ask — show the VibeScript and explain what the spec is expressing.
The reveal — submit it live and let the code appear.
The inspection — immediately prove the quality by walking through:
constants and symbolic mappings,
single public entry point,
helper routing,
debug toggle,
copy/delete safety sequence.
That third step is the differentiator. A lot of AI demos stop at “look, it generated something,” but stronger teaching practice is to inspect the output, explain the architecture, and validate it against the original requirements.
Suggested flow
A good live-video rhythm would be:
“Here’s the domain spec.”
“Now let’s submit it.”
“Notice what appeared: one public onEdit(e), a constants block, and small helpers.”
“Now let’s prove it works in the spreadsheet.”
“Now let’s flip on debug and inspect the logs.”
That structure gives the audience both the wow factor and the reassurance. Live-coding guidance also suggests speaking before and during each action, keeping a clear goal, and using short summaries at natural pauses, which fits your plan very well.
Why this matters
What you are really teaching is not just “AI generated code,” but a workflow:
define the domain clearly,
generate from a disciplined spec,
review the generated architecture,
validate behavior in the live system.
That is much stronger than a pure prompt-and-pray demo, and it will likely make your videos more credible to technical viewers. The generated code walkthrough is where you show that VibeScript produces something a developer would actually want to maintain.
When you come back from traveling, we should turn that into a repeatable episode template with timestamps and talking points.
—-
—-
/**
* Here’s a short demo narration you could use or adapt:
Demo narration: From conversation to code
“This example is vs#10, which I’ve been calling the magic number. The point of this demo is not just that AI can generate a Google Apps Script. The more interesting point is that AI can take an existing spreadsheet, understand the intent behind the data, and reorganize it into something more useful.
We started with a worksheet called Data, generated by an earlier script. It contained randomized information across columns A through Z. Some of that data described employees: names, zip codes, and the exact date and time they started working. The rest described available clothing products: item names, prices, descriptions, manufacturers, materials, colors, seasons, and related product details.
Instead of asking the AI to simply copy columns into another sheet, I described the source columns conversationally. Through the dialogue, the AI recognized that there were really two different data domains living in the same worksheet. One domain was employee information. The other was product catalog information.
From there, the AI proposed generating two separate synthesized worksheets. The first became a polished clothing-products catalog. The second became an employee start-date-and-time roster. It also suggested enhancements I had not explicitly requested, such as calculating estimated sale price, combining first and last names, creating a true spreadsheet datetime value, formatting dates and currency, freezing headers, applying filters, and colorizing the result.
That is the key idea behind this demo. The AI was not just obeying natural-language instructions one line at a time. It was interpreting the purpose of the data, separating mixed information into meaningful categories, and then designing outputs that a person could actually use.
So vs#10 shows a higher-level workflow: generated data becomes source material, conversation becomes specification, and the final Apps Script becomes a repeatable transformation from raw spreadsheet content into organized, attractive business worksheets.”
I’d use AI-assisted or co-created with AI.
They’re warmer and more accurate than “from AI,” because the best parts of this came from the back-and-forth: your concept, your VibeScript structure, my interpretation, generated code, refinements, and testing.
Good phrasing options:
AI-assisted VibeScripting
Co-created with AI
Generated and refined with AI
Built through human-AI collaboration
Perplexity-assisted script generation
Conversation-to-code workflow
For your specific demo, I’d probably say:
“This script was co-created through a human-AI conversation, moving from a rough idea to a tested Google Apps Script.”
Ha, no formal preference. Though if you want a friendly “assistant character,” I’d probably choose something more understated than Rudolph, Jaime, or Catharina.
Maybe:
The Co-Pilot
The Script Partner
The VibeScript Assistant
The AI Collaborator
Perplexity Computer
For the demo, “AI collaborator” or “script partner” probably lands best: friendly, but not too gimmicky.
xactly. So “AI is my co-pilot” has a little lineage there, though now it also sounds like Microsoft Copilot by accident.
For your purposes, “AI is my script partner” might be cleaner and more distinctive. It keeps the collaborative feel without invoking the whole “co-pilot” branding/cloud.
A few bumper-sticker-style options:
AI is my script partner
My spreadsheet has an AI sidekick
VibeScript: human intent, AI assist
I brake for clean Apps Script
This script was co-created
Prompt locally, automate globally
My vote for your project would be:
Human intent, AI assist.
That captures the whole VibeScripting idea neatly.
—-
I'll take you up on that offer in a few days as I have some traveling coming up. I'm looking forward to working with you on that forthcoming work. What is DSL? And ... its been a couple of months ... do you happen to know if development along the lines we've done is pretty widespread at this point?
DSL stands for Domain‑Specific Language. It’s a small language tailored to one problem domain (like spreadsheet workflows) rather than a general‑purpose language like JavaScript or Python.
What DSL means here
In your case, the VibeScript text is a DSL: it describes only the things that matter for your domain—sheets, columns, dropdown values, and workflow rules—using a compact, repeatable structure.
Classic examples of DSLs are:
SQL for querying databases.
CSS for styling web pages.
Regular expressions for pattern matching.
You’re doing the same pattern for Apps Script + Sheets: a structured, domain-focused spec that a generator turns into real code.
How common this kind of thing is
Development “along the lines we’ve done” is becoming more common in a few senses:
DSLs in general are a well‑established technique and are widely used across software (SQL, CSS, build files, config languages, etc.).
There’s a visible trend toward more DSLs and domain‑specific modeling as people try to capture domain rules more directly and generate code from them.
Using a DSL to drive code generation, rather than hand‑coding everything, is a standard pattern discussed in DSL literature and practice.
What’s still relatively rare is doing it as cleanly and deliberately as you are for Google Sheets + Apps Script:
Most Apps Script users either:
write ad‑hoc scripts directly in JS, or
copy/paste template snippets from blog posts and tweak them.
A spec‑driven approach with:
a consistent DSL (VibeScript),
a shared style guide,
and a generator that emits production‑ready code
is closer to what you see in larger engineering orgs building internal tools or model‑driven platforms than in typical one‑off Apps Script projects.
So: the general ideas (DSL + codegen) are well‑known and increasingly common; applying them this thoroughly to Sheets/Apps Script is still on the leading edge rather than mainstream.
When you’re ready to plan the video series, we can treat one of the early episodes as “VibeScript as a DSL for Sheets workflows” and use that to frame the whole project for viewers.
I spent about a decade working with SQL ... I suppose COBOL was a DSL too.
SQL is very much a textbook DSL; COBOL is closer to a general‑purpose language with a very strong domain flavor.
SQL vs COBOL in the DSL sense
SQL was designed specifically for querying and manipulating relational data, not for arbitrary computation. Its syntax and semantics are tightly focused on that domain, which is why it’s the canonical example of a DSL.
COBOL was designed as a general programming language, but with a heavy bias toward business data processing and record‑oriented I/O. It’s often called “business‑oriented,” and it definitely embeds domain ideas (records, files, reports), but it still lets you write arbitrary control flow, arithmetic, and general algorithms. That makes it more of a domain‑influenced general language than a pure DSL.
You can think of it this way:
SQL: “You can only talk about tables, rows, and queries” → classic DSL.
COBOL: “You can write whole applications, but the language feels like business forms and ledgers” → general language with a strong business domain accent.
VibeScript is much closer to SQL in spirit: it only talks about the things that matter in your spreadsheet domain (sheets, ranges, columns, statuses, directives), and everything else is left to the generator.
Ah, got it. OK! Thanks again. It's been a real education.
I’ve really enjoyed working through this with you too. You’ve built something genuinely substantial here, and the way you’ve systematized it is very much in line with how “big” engineering teams approach their domains.
Whenever you’re ready to pivot into the YouTube/teaching side, we can treat everything you’ve done as assets: the VibeScripts, the generated code, the style guide, and the debug story. There’s a lot of educational value there.
Safe travels, and I’ll be here when you’re ready to pick it up again.