91 posts tagged with "vibe coding"

Canada's funding problem isn't discovery. It's the third question.​

Founders are told the hard part of non-dilutive funding is finding the programs. It isn't. SR&ED, IRAP, and OCI all ask the same three things: what are you building, why was it technically uncertain, and what record did you keep while you built it. Applications die on the third one.

The first two questions are a pitch. Founders are good at pitching — it's the muscle they've trained for two years across investor meetings, demo days, and accelerator interviews. Describing an ambitious build and explaining why it was hard is a story you can tell cold, at a table, with no preparation.

The third question is not a pitch. It's an audit. Nobody is asking whether you believe the work was novel. They're asking what exists, in writing, from the period when the work happened.

And that's the part almost nobody has.

The shootout that isn't​

Search "Bolt vs v0 vs Cursor" and you get a scoreboard. Feature grids. Pricing tiers. A verdict at the bottom declaring a winner.

The scoreboard is the problem. It assumes these tools are all competing for the same job, and they aren't. Bolt, v0, Cursor, and Emergent are four different categories of product wearing the same "AI builds your app" marketing. Ranking them against each other is like ranking a table saw against a blueprint against a general contractor.

Nobody writes the honest version of this guide, because everyone selling in this space wants to be the winner of the shootout. So we wrote it. We also put our comparison pages up publicly — including the parts where the right answer for a given founder is not Codalio.

Most AI tools will give you a demo. The question founders and operators actually ask is different: can I put a complete product in front of customers without hiring a CTO, a tech lead, senior developers, or cloud engineers first?

In April 2026 we ran that experiment. Four pipelines built the same meal-planning application. Codalio ran with no senior engineering team in the loop. Prompt-only Claude Code did not. We then scored every build against 111 things a customer would expect to work.

The Conversation I've Had Too Many Times This Year​

A founder gets in touch. Smart, non-technical, a year and a real budget into their idea. There's a build. An agency delivered it, or a freelancer, or a technical co-founder who has since moved on. It half-works. Nobody currently on the team can explain what's inside it.

And every developer who has glanced at it since has offered the same verdict: probably faster to start over.

I've heard that sentence enough times to script the whole exchange. What bothers me isn't the advice. It's that the advice is almost never based on evidence.

The quiet part, said out loud in a comment thread​

On July 30, a YC S26 company called Prized launched on Hacker News with a clean pitch: let non-engineer staff build secure internal tools. Seventy-three points, fifty-three comments. A good day.

Buried in that thread was a line worth more than the launch itself. A builder relaying a vendor conversation wrote that "Lovable is used primarily for prototyping, not internal tools" — not a competitor's jab, but a paraphrase of what the vendor's own team had told him.

Read that again, because it reframes the entire category. The prototype/product distinction isn't a talking point invented by people selling process. It's the vendors' own internal understanding of what their tool is for. They know. They say it out loud in sales conversations.

The problem is that nobody says it in the marketing. So founders ship the prototype and call it a product.

Three Posts, Forty-Eight Hours, One Argument​

On July 28th and 29th, three separate items landed on the Hacker News front page. Read individually, each is a curiosity. Read together, they are the same argument arriving from three directions.

The first was a Show HN: a formally verified 3D mesh intersection algorithm written in Lean 4, at roughly 111 points and 48 comments. The interesting part wasn't the algorithm. It was the review instructions the author attached to it. Read the 93-line specification. Run the Lean checker. You never need to inspect the 1,000+ lines of implementation the AI wrote — or the 60,000+ lines of formal proof the agent generated along the way. The work was built mostly with Claude Opus 4.8, with some early proof strategies from Fable 5, and individual steps consumed 24+ hours of autonomous agent time.

The second was SpecForge, a platform for authoring formal specifications, at 61 points the same week.

The third was Robert C. Martin — Uncle Bob, the man who taught a generation of engineers to care about the shape of their code — posting that his current strategy is "to not read any of the code written by my agents." Fifty-three points, fifty-three comments, and eighteen months ago that sentence from that author would have been heresy.

It isn't anymore. But it also isn't the whole story, and the missing half is where founders get hurt.

AI has already absorbed the junior coding work. Seniors set the plan, the architecture, and the task. AI writes the atomic pieces of code that used to be the first rung on every engineering career. So the hard question for new engineers isn't "can you code?" — it's "can you think like a senior and direct AI?"

That gap — between graduating and being trusted to lead — is the career problem of this decade. Codalio's Workshops & Training program exists to close it.

The morning test​

Here's the bar I hold every build tool to. Could a non-technical founder describe a feature at breakfast — "customers on the annual plan should skip the setup fee" — and have it live in production, working correctly, by lunch?

Not a prototype of it. The real thing, wired to the real data, that you can charge money against.

Almost nothing passes. So I spent a week reading the public docs and pricing pages of the three tools founders ask me about most — Lovable, Devin, and 8090 — to figure out exactly where each one stops. This isn't a takedown. Every one of them is good at the slice it owns. The problem is that a slice isn't a product.

"Fix it." "Fix it again." "You deleted the calendar??"​

If you've built anything with an AI app builder, you know that loop by heart. You type a prompt. Something breaks. You describe the break. It fixes that — and quietly snaps something else. You prompt again. The credits meter spins.

Founders on Reddit have documented burning 500K+ tokens on a single bug-fix spiral, and $1,000 weeks on agent platforms, while the app itself stayed broken. There are entire threads about credits evaporating in real time.

The reflex is to blame the model. Get a smarter one, a bigger context window, a better agent, and the loop ends. It doesn't.

The App That Almost Works​

You built it on Lovable. Or Bolt. Or Cursor. Or you didn't build it at all — you inherited it from a contractor who's gone now, or from an internal project that predates half your team. It runs. It demos well enough. It gets you most of the way to something you could actually charge money for.

And then it stops getting closer.

So you prompt again. The AI iterates, confidently. Something moves. Something else breaks. You prompt again to fix the thing that broke, and the original fix quietly comes undone. Three hours later you have a build that is differently broken than the one you started with, and no honest sense of whether you're nearer the finish line or further from it.

Most founders describe this as a code problem. It isn't.