68 posts tagged with "vibe coding"

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 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.

Your agent didn't overspend. It guessed for six hours.​

On July 2, Replit finished rolling its effort-based pricing model out to everyone, after a two-week trial. Within days, Reddit filled with builders reporting projects that suddenly cost up to 4x more than before. The story that stuck was a single screenshot: a $607 bill from an agent session nobody was watching, quietly burning credits for hours.

Replit conceded the rollout "did not meet our standards" and handed affected users $10 in credits. The pricing-page anger is real, and some of it is fair. But if you read the $607 story as a billing glitch, you'll miss the part that actually costs you money.

That agent wasn't malfunctioning. It was doing exactly what it was told, which was almost nothing. It had a vague prompt, no definition of "done," and permission to keep working. So it kept working — thrashing, looping, rebuilding the same feature three ways — and every one of those hours had a meter running.

Two Valuations Went Up. One Number Stayed Missing.​

On July 8, 2026, TechCrunch reported that Lovable is in talks to double its valuation to $13.2B — up from $6.6B in December 2025 — on roughly $500M in ARR, after a $300M round led by Menlo. Cursor is separately reported to be chasing a $50B round on the back of $2B ARR.

Those are real numbers. Money moved. Contracts got signed. The revenue is not a mirage.

But notice which number nobody quotes alongside the ARR: how many products actually shipped. Not prototypes. Not weekend demos. Products that survived contact with real users and stayed in production without a rescue.

That number doesn't appear in any deck. And its absence is the entire story.

Every new feature breaks two old ones​

You ship a feature. A week later, something unrelated stops working. You fix that, and checkout breaks. You fix checkout, and the login flow starts throwing errors on mobile.

If this is your product, you've probably concluded your developers aren't good enough. Most founders do. It's the obvious story: bugs mean bad engineering.

It usually isn't. The teams shipping fragile apps and the teams shipping stable ones are often equally skilled. The difference shows up long before anyone writes a line of code.