68 posts tagged with "vibe coding"

You can't see the price tag until after you've paid​

There's a new kind of dread in the founder Slack channels: the AI-coding invoice nobody can predict.

Replit moved to effort-based pricing. Vercel's v0 bills by token. Cursor, by one widely-shared account, pushed through a 20× silent price hike. The common thread isn't that these tools got expensive — plenty of good tools are. It's that you no longer know what a single prompt will cost before you run it. You type an instruction, you hit run, and you find out the price afterward.

For a non-technical founder, that's not a pricing model. That's a slot machine with a "build my app" button.

Amazon had infinite engineers. It still shipped from a stale wiki.​

In November 2025, Amazon told its engineers to use its in-house AI coding tool for at least 80% of their work each week. The goal was adoption — a metric, tracked weekly, with a number to hit.

Four months later, on March 5, 2026, a single AI-assisted deploy wiped roughly 6.3 million orders and dropped U.S. order volume by about 99%. The root cause wasn't an exotic model failure. The agent had read an outdated internal wiki, inferred what "correct" meant from it, and shipped accordingly.

Then about 1,500 engineers signed a petition. Their argument wasn't "AI is bad." It was that the company had chased a usage target instead of quality — and that they'd rather pick their own tools, like Claude Code, than hit a quota.

Here's the part that should bother every founder: Amazon has effectively unlimited engineers and the best tooling money can buy. It still broke. So the lesson can't be "hire more people" or "buy a better model."

For the last couple of weeks, this series has worked through what Codalio actually does. PRDs that read like a senior PM wrote them. UI prototypes generated from your real requirements, not stock components stitched together. Backend code that compiles, runs, and matches the spec. Every post has answered a different version of the same question: why does building an MVP cost as much as a luxury car and take as long as a graduate degree?

This week, we close the loop. Step 4. Deployment.

Because here's the part nobody tells first-time founders: writing the code is not the bottleneck. The bottleneck is everything between "the code works on my laptop" and "a stranger I've never met can sign up at a URL." That gap, the last mile of the build, is where more MVPs die than at any other point in the journey.

The rebuild isn't expensive because the code is bad​

There's a new line item showing up in startup budgets in 2026: the rescue. Reporting circulating this year claims roughly 10,000 startups tried to ship production apps on AI assistants, and more than 8,000 of them now need a rebuild — at $50,000 to $500,000 each. (Treat the counts as directional; they're secondary reporting, not an audited census.) Salesforce Ben called it: 2026, the Year of Technical Debt, thanks to vibe-coding.

The industry has already decided what went wrong. The AI wrote sloppy code. The MVP accrued technical debt. The fix is cleaner output, better models, more rigorous review.

That diagnosis is comforting because it's about the code. It's also wrong.

There's a moment every founder hits, usually around month three, when the no-code tool they chose to "move fast" becomes the reason they've stopped moving at all.

The workflow they built in a weekend starts hitting walls. Custom logic doesn't fit the drag-and-drop model. The API integration they need isn't supported. Scaling past a few hundred users exposes architecture decisions baked into the platform — decisions they never made and can't change. And the developer they finally bring in to fix it takes one look at the underlying structure and tells them what they didn't want to hear: we're rebuilding this from scratch.

This is the no-code trap. And it's entirely avoidable — if you start with real code.

This week, we're going deep on Rhino, Codalio's backend code generation engine. How it works, what it produces, and why the choice of Ruby on Rails as its foundation isn't just a technical preference — it's a strategic one.

For the last month, we've been pulling back the curtain on what it actually takes to go from product idea to buildable plan. We covered auto-generated PRDs. Scope estimation. User stories with real acceptance criteria. Pitch decks you can walk into a room with.

Every one of those posts answered the same underlying question: why is the gap between "I have an idea" and "I have a product" so expensive, so slow, and so full of miscommunication?

Today, we stop answering that question. Today, we fix it.

Codalio is live. And it doesn't just generate your PRD. It takes you from product description to deployed MVP in four steps — without a dev shop, without a six-figure budget, and without the three-month discovery sprint that burns half your runway before a single user touches your product.

Let's walk through the whole thing.

The HN Crowd Has a Point​

The Hacker News post titled "Spec-Driven Development: The Waterfall Strikes Back" hit roughly 332 points and dragged the same debate onto the front page three separate times in a month. The receipts piled up fast. François Zaninotto argued specs eat more than half of project time. A widely-shared Medium piece coined "Waterfall in Markdown." Someone posted screenshots of an agent generating 1,300 lines of markdown to render a date.

If you have watched a founder try to ship through a planning-heavy AI workflow, none of this is shocking. You write a spec. The agent half-reads it. You discover the constraint that actually matters two weeks in. You rewrite the spec. The agent forgets. The "spec-driven" part of the workflow starts to feel like every shoulder-tap meeting you have ever sat through, only now the meeting writes itself.

The critics are not wrong about what they are seeing. They are wrong about what is actually broken.

Last posts, we walked through turning your Codalio PRD into a polished pitch deck using Gamma. The response was clear: founders want structured outputs they can actually use downstream — not just documentation that sits in a folder.

This week, we're going upstream. Way upstream. Into the part of the process where most MVPs quietly start to fail: scope estimation, user stories, and the question of whether your PRD is actually complete enough to build from.

Spoiler: if you're writing user stories in a spreadsheet and estimating timelines on gut feel, it's not.

Two weeks ago, we laid out the MVP crisis — why most startups burn through their runway before they ever reach a customer. Last week, we broke down the PRD: what it is, why it matters, and why building without one is the most expensive mistake a founder can make.

If you followed the advice, you now have a PRD. Problem statement. Solution overview. User flows. Phased feature roadmap. You're ahead of 90% of founders.

But here's what nobody tells you: a PRD with those sections alone is a skeleton. It can hold shape. It can't move. The sections that give a PRD its muscle — the ones that turn it from a planning document into a strategic asset — are the ones most founders either skip entirely or fill with guesswork.

This week, we're going deep on three of those sections: Design Principles, Market Analysis, and Technical Requirements. These are the layers that connect your product vision to your actual users, your actual market, and your actual codebase. Get them right, and your PRD becomes the single source of truth for everything — development sprints, investor conversations, pitch decks, even your go-to-market strategy. Get them wrong, and you're building a product for an audience you've imagined, in a market you haven't sized, on architecture that won't scale past your demo.

Let's fix that.

On April 28, 2026, TELUS and L-SPARK announced the TELUS Sovereign AI Accelerator, a program designed to help Canadian AI startups and scaleups build, train, and deploy advanced AI solutions using Canadian-controlled AI infrastructure.

Codalio was named in the inaugural cohort.

That is the headline.

But the more interesting story is underneath it: Canadian AI is moving out of the demo phase.

The market has had enough prototype theater. Founders can already make impressive screenshots. Teams can already wire up a chatbot, generate a landing page, or produce a fake dashboard in a weekend. That is useful, but it is not the hard part anymore.

The hard part is building systems that can be trusted, operated, handed off, scaled, and improved.

That is where this moment matters for Codalio.