The first working version of ScreenWeaver took me four days. I have never written a line of code in my life.
That sentence used to embarrass me. Now I just say it, because Vibe coding means building real software by describing what you want to an AI model instead of writing the code yourself, and in 2026 it is good enough that a filmmaker with zero engineering background can ship a tool people actually use in production. Andrej Karpathy coined the term in February 2025, describing a way of working where you “give in to the vibes” and barely look at the code the model writes. I did not know that term existed when I started. I just knew I needed a screenwriting and storyboard tool that treated story structure as a first-class citizen instead of an afterthought, and nobody was building it for filmmakers like me.
So I built it myself, with Claude writing the code while I directed the result the way I’d direct a scene.
Four days later I had a working draft. That part was the easy half of the story, and it’s the half every vibe-coding post on the internet already tells you.
What Is Vibe Coding, Exactly?
Vibe coding is prompting an AI model to write and modify software, testing what comes out, and iterating in plain language instead of touching theking version, you point at what’s wrong, it fixes it. No syntax, no boilerplate, no months of a computer-science degree standing between the idea and the thing that runs
That part is true, and it’s why tools like Cursor, Bolt.new, v0, and Replit have pulled thousands of non-developers into building their own software this year. For a filmmaker, it collapses a wall that used to be absolute: either you learned to code, or you paid someone who did, or the tool you needed simply didn’t exist and you worked around it forever.
Can a Non-Technical Founder Actually Ship Something People Use?
Yes, and I’m proof of it, but the honest answer has a second half nobody puts in the headline.
Shipping a working prototype is the part vibe coding is actually great at. I described the screenwriting problem the way I understood it as a director: a script, a scene breakdown, and a storyboard should live in the same document instead of three disconnected files. Claude turned that into a working interface faster than I could have hired, briefed, and waited on a developer to deliver a first draft.
ScreenWeaver exists because the tool I needed didn’t, and waiting for someone else to build it was never going to happen on my timeline. What vibe coding actually gives a creator isn’t a shortcut around becoming a software engineer. It’s a shortcut around the distance between “I wish this existed” and “this exists,” which used to be months and is now days.
But a prototype only has to survive you clicking around it once. A real product has to survive strangers.
What Breaks First Once Real People Start Using It?
Everything you didn’t think to ask the model about, because you didn’t know it mattered yet.
My own production became the first real stress test. Every episode of Lost Garden, my anime series, runs on a pipeline that starts in ScreenWeaver: script first, then story structure, then an AI storyboard, before a single shot gets generated. The moment I was using the tool daily, under deadline, instead of demoing it to myself, the list of what actually mattered changed completely.
A few things that only showed up once the tool had a real job to do:
- Edge cases a demo never hits. A scene with a flashback inside a flashback breaks a structure that looked airtight when I only tested straight three-act stories.
- The cost of “it mostly works.” A vibe-coded feature that’s 90% right is a liability the day you’re depending on it at 11pm before a render queue opens, not a curiosity.
- Your own feature requests becoming a backlog. Every time I used ScreenWeaver on Lost Garden, I noticed one more thing I wanted it to do, and each one is a decision about what the tool actually is, not just a bug ticket.
- The gap between “I built this” and “I understand this.” When something breaks at the worst possible moment, you need to know enough about your own system to tell the model what’s actually wrong, not just that something feels off.
Several write-ups this year have flagged the same pattern in vibe-coded products: the parts you never looked at are exactly the parts that fail in ways you cannot diagnose. I got lucky that ScreenWeaver is a creative tool and not a payment system, but lucky is not a plan. The weeks after launch were when I finally had to open the code Claude had written and actually read it, line by line, in the places that mattered most.
Shipping fast was never the hard part. Being the person who has to fix it at 11pm, on deadline, for a product you don’t fully understand yet, is the part nobody puts in the vibe-coding success story.
Does Vibe Coding Replace Needing to Understand Your Own Product?
No, and this is the part I’d tell any filmmaker or creator thinking about building their own tool in 2026.
Vibe coding removes the typing. It does not remove the thinking. You still have to know, better than anyone, exactly what the problem is and what a correct answer looks like, because the model will happily build the wrong thing with total confidence if your description is vague. “Make it better” produces nothing usable. “The storyboard panel needs to show the previous shot’s camera angle so I don’t repeat a setup by accident” produces something I could actually use on Lost Garden the same week.
What vibe coding actually replaces:
- Needing a computer-science background before you can start.
- Months of back-and-forth briefing a developer who has never made a film.
- The cost of a wrong first guess, since iteration is nearly free.
- Knowing your own problem well enough to describe it precisely.
- Testing with the people who will actually depend on the tool, not just yourself.
- Owning the result once it’s running something real.
The Year After Launch Is the Actual Story
A year in, ScreenWeaver isn’t a side experiment anymore. It’s the first stage of every Lost Garden episode, and every week it runs, I find one more thing that only becomes obvious under real use. That’s not a failure of vibe coding. It’s what building any real product has always looked like, minus the part where I’d have needed to be a developer, or hire one, to even get started.
If you’re a filmmaker, or any kind of creator, sitting on a tool you wish existed, the honest version of my experience is this: vibe coding will get you a working version faster than you think, and it will hand you the running of a real product faster than you’re ready for. Both things are true at once, and the second one is the part worth planning for before you start, not after.
I still open ScreenWeaver every day the same way I open a script: as something I’m responsible for getting right, not something I finished.
Is vibe coding safe enough for a real product, not just a demo?
It can be, but only if someone eventually reads the code in the parts that matter most (authentication, payments, anything touching other people’s data) instead of trusting the model’s output blind. For a creative tool with no sensitive data, the risk bar is lower than for a fintech or healthcare app.
Do I still need to learn to code if I vibe-code my product?
Not to start. You do need to understand your own system well enough to describe what’s broken precisely, which in practice means reading some of the code eventually, even if you never write it from scratch.
What’s the biggest mistake non-technical founders make with vibe coding?
Treating a working prototype as proof the product is done. The prototype proves the idea works once. Real users prove whether it survives contact with a hundred different ways of using it wrong.
