Skip to content

The Invincible Developer

R. Machado ·

This is the first post in a series about Bet-Driven Development — a framework for building software intentionally in the age of AI.

Throughout the series, I’ll follow Noah — a fictional developer — through two projects: ReplyBot (the cautionary tale) and StudioPulse (the disciplined build). The patterns are real. I’ve lived some of them. I’ve watched my team and other developers live the rest. The projects are composites, designed to show you the full cycle more clearly than my own messy, overlapping, still-in-progress work can. When I’m speaking from my own experience, you’ll know — that’s me, not a character.

It’s a Tuesday night and Noah is staring at something beautiful.

Three hours ago, he opened Claude Code and typed: “Build me a review response generator for local businesses. It should analyze the sentiment of incoming Google reviews and generate perfectly-toned responses — professional for complaints, warm for praise, and apologetic-but-firm for the unreasonable ones.”

By 11pm, he has a working prototype. Sentiment analysis that actually works. Tone-matched response generation. Multi-platform support for Google, Yelp, and TripAdvisor. The responses are good — better than what most businesses write themselves. He calls it ReplyBot.

He feels unstoppable.

If you’ve spent any time building with AI coding tools in the last year, you know this feeling. Something that would have taken weeks — designing the architecture, writing the NLP pipeline, building the API integrations — materializes in a single evening. You describe what you want. The machine builds it. And it works.

So Noah keeps going. Wednesday, an analytics dashboard. Thursday, response scheduling. The following week, competitor review monitoring. Multi-location support. Brand voice customization. Every session feels productive. Every feature feels necessary. The codebase grows.

Three months later, Noah lands his first demo with an actual business owner. A dentist. Noah walks him through the dashboard, shows the AI-generated responses, demonstrates the tone matching. The dentist watches politely.

“This is cool,” he says. Then a pause. “But… we don’t really struggle with responding to reviews. We get maybe four a month. My receptionist handles it. What we struggle with is getting reviews in the first place.”

Four more demos that week. Three say almost the same thing.

Three months building an elegant solution to a problem nobody had.

I know this story because I’ve lived the pattern

ReplyBot is fictional, but the pattern isn’t. I’ve been in some version of that story more times than I’d like to admit.

I manage nine engineers by day and build side projects at night. I have four of them going right now, which is itself a symptom of the problem I’m about to describe. Over the last two years, as AI coding tools went from novelty to default, I’ve watched the same failure mode play out in my own work, in my team’s work, and across the developer communities I follow.

The pattern is always the same. Building accelerates. Validation doesn’t. The gap between what gets shipped and what gets checked widens until something breaks — a demo that falls flat, a metric that refuses to move, or the slow realization that you’ve spent months on something nobody asked for.

On my team, I watched one of my best engineers build an entire notification preferences system in a week — customizable channels, scheduling, quiet hours. Beautiful engineering. Three months later, we checked the analytics: 94% of users had never opened the notification settings page. Not once. The feature was technically excellent and completely unnecessary. And the speed of AI-assisted building had made it feel too easy to question — it only took a week, so why not build it?

That reasoning is the trap. “Why not?” is the most dangerous question in AI-assisted development. The answer used to be “because it’ll take three weeks and we have other priorities.” Now the answer is “no reason, the AI can do it by Thursday.” So you build it. And the next thing. And the next thing. None of them validated. All of them feeling like progress.

In the developer communities I follow, I started noticing a genre of post that barely existed two years ago: “I built something amazing and nobody cared.” Always the same breathless opening — “I built X in a weekend using AI!” — and increasingly the same deflated update a few months later: “Nobody signed up.” The gap between building and validating was producing a whole generation of impressive, unused software.

And in my own side projects, I was bouncing between all four, making progress on each and finishing none. Not because any of them were bad ideas, but because the ease of building made focus feel unnecessary. Why commit to one direction when you can explore them all? The answer, which took me too long to learn, is that exploring everything means validating nothing.

The supply shock

Here’s the structural problem underneath all these stories.

Mihail Eric, who teaches Stanford’s first AI software development course, ran a survey of 195 developers in late 2025. He found that 98% now use AI coding tools multiple times a week. Around 40% of codebases had more than half their code generated by AI in the previous 30 days.

That’s a supply shock. When every developer can build anything, building isn’t a competitive advantage anymore. The technical moat — “I can build this and you can’t” — collapsed. Features that used to take months now take days, which means anything you ship can be cloned by next week.

This is what happened to Noah’s ReplyBot: thirty-plus competing products, all built in roughly the same timeframe, by developers who all had the same “obvious” idea. But it happens at smaller scales every day. Every “AI-powered [thing] for [niche]” launch on Product Hunt has a half-dozen near-identical competitors. The supply of software exploded. The supply of validated, well-directed software didn’t.

The question isn’t “can I build it?” anymore. It’s: does anyone need this? Would they choose mine? And how would I know?

Vibe Coding Hell

The developer community has a name for the trap: Vibe Coding Hell.

It has four phases, and they’re consistent across every version of this story I’ve encountered — including my own.

Phase 1: Euphoria. Code flies. Features materialize. You’re shipping faster than you ever have. You tell a friend about the project and they’re impressed by how much you’ve built. You’re impressed by how much you’ve built. This phase feels like the future. It is the future. It’s also where the trap is set.

Phase 2: Accumulation. More features. More complexity. No prioritization. Every idea gets built because the cost of building is so low. “While we’re at it, let’s add this too.” “Actually, let’s also handle that edge case.” The codebase grows. The feature list grows. You’re making progress on everything and finishing nothing. But it doesn’t feel like a problem yet, because the output keeps flowing. You might even mistake accumulation for product-market fit: look at how much I’ve built! This must mean something. (It doesn’t. Volume is not validation.)

Phase 3: Confusion. The questions start. Which features matter? Is anyone using this? Did the thing I shipped last week move any needle? You don’t know, because you never set up a way to check. The backlog is enormous, and everything on it feels equally important — which means nothing is important. Every session starts with the same paralysis: what should I work on? You open your AI tool and stare at the prompt, unsure what to tell it. So you pick whatever feels most interesting, which is usually the most technically challenging thing, which is usually the least important thing. I’ve been here. You open your editor with fifteen things you could build and no way to know which one matters.

Phase 4: Hell. The product has no focus. You’ve built a lot and validated none of it. Starting over feels wasteful — look at all this code, all these features, all these evenings. Continuing feels pointless. You’re drowning in your own output. Noah is here when he finally does that demo. I was here when I realized I’d been juggling four projects for months and couldn’t point to a single validated outcome from any of them.

Stack Overflow found that 66% of developers experience a “productivity tax” from AI-generated code. Eric’s survey found something more counterintuitive: one in five developers say that context switching actually got worse with AI tools. You’re faster at each task and worse at connecting them into something coherent.

Vibe Coding Hell isn’t about code quality. Messy codebases have always existed. What’s new is building confidently in the wrong direction — at scale, at speed, with no feedback mechanism to tell you you’ve gone off course. Noah didn’t hit a wall of technical complexity. The code worked. The product was sophisticated, well-built, and aimed at a problem nobody had.

The bottleneck shifted

For most of software development’s history, the bottleneck was writing code. The difficulty of implementation was itself a filter — it forced you to pick your battles, because you couldn’t fight them all.

AI removed that filter.

Now the bottleneck is deciding what to build. Not what can you build — what should you build? For whom? Why would they pay? How will you know if it’s working?

These aren’t technical questions. They’re product questions. Strategy questions. Judgment questions. And they’re the questions that the current development workflow is almost perfectly designed to help you avoid.

Think about how most of us work with AI coding tools. You have an idea. You open your tool. You describe the idea. The agent builds it. You refine it. You add more. You ship. At no point in that workflow does anyone — not you, not the tool — ask: “Is this the right thing to build?” The tools are optimized for throughput, not direction. They’ll build whatever you describe, whether or not what you described is worth building.

Eric’s survey captures the result precisely. The top failure modes developers reported for AI coding tools weren’t about code quality. They were hallucination, incomplete solutions, and — this is the one that matters most — not understanding the project context. The tools are fast, but they’re fast without awareness.

I see this in my engineering team too. Talented engineers, newly empowered by AI, shipping features at unprecedented speed — with no mechanism to validate whether those features moved the product forward. Speed without direction. It’s organizational vibe coding, and it’s happening at companies that should know better.

What’s actually scarce

When building is free, what becomes valuable?

Not speed — everyone has it. Not technical sophistication — the AI handles that. Not even a good idea — ideas are abundant and cloneable.

What’s scarce is knowing you’re building the right thing. Validation. Direction. The discipline to stop building and start checking. The judgment to find a niche narrow enough to own.

The ReplyBot story illustrates this in compressed form. Thirty developers, same idea, same tools, same speed. None of them talked to a customer first. They all built and asked questions never. Noah eventually found what worked: automated post-visit review request SMS for dental practices. Not AI-powered responses for all businesses. Not even review solicitation broadly. Automated SMS specifically for dentists, sent three hours after an appointment. Boring. Narrow. And it made money — because nobody building “AI review tools” was focused enough to own that tiny niche. But it took three months of building the wrong thing to get there.

This is the pattern I see everywhere. The winning move isn’t building faster — everyone is fast now. The winning move is validating faster. Figuring out, in days instead of months, whether the thing you’re building matters to anyone.

What if, instead of opening Claude Code on that Tuesday night, Noah had picked up the phone?

“Do you struggle with responding to online reviews?”

“Not really. My receptionist handles it.”

“What do you struggle with?”

“Getting reviews.”

Five minutes. Everything he needed to know. Three months of building saved by one conversation.

The scarce resource in AI-assisted development isn’t code. It’s the conversation you have before you code. The bet you make — explicitly, with a way to check — before you invest months in a direction.

Why I started building DevKeel

Now let me tell you a real story.

After recognizing this pattern in my own work and my team’s, I tried to do things differently with my next project. I told myself: this time, I’ll talk to users first. This time, I’ll define what success looks like before I code. This time, I’ll check.

And I did, mostly. I had regular calls with advisors who knew the problem space. I wrote down what they said. I built something more focused than my previous attempts.

But the tooling worked against me. My AI coding tool didn’t know about any of this context. Every session started fresh. I’d re-explain the project, re-explain the goals, re-explain why I was not building a feature even though it seemed obvious. My advisor conversations lived in transcripts. My decisions lived in my head. My AI agent — the thing doing most of the actual building — was completely blind to the product context.

I’d have a call where an advisor said something that shifted my priorities, and the next morning I’d start a coding session and the agent would cheerfully start building the thing I’d decided to deprioritize. Because it didn’t know. It couldn’t know. Every session was a blank slate.

The absurdity of it hit me one afternoon when I spent the first twenty minutes of a session re-explaining to my AI tool what I’d explained to it the day before. I was briefing my own assistant on a project it had helped me build. This is what passes for the state of the art: tools that can write beautiful code at superhuman speed, that forget everything the moment you close the terminal.

Eric’s survey confirmed what I was feeling: developers’ top desired improvement for AI coding tools is better context understanding. The tools don’t know what you decided last week. They don’t know what you rejected. They don’t know why you’re building this feature instead of that one.

That’s when I started building DevKeel. Not as a project management tool — I don’t need another kanban board. I wanted something simpler: a structured memory that my AI agent could access. My bets, my signals, my decisions, my learnings from past experiments. A system where every coding session started informed instead of blank.

DevKeel went through its own evolution — it started as HypoShip, a hypothesis-driven development platform that was too academic for anyone to actually want to use. Then it became BetShip, an AI coaching tool where the AI costs were on me, which wasn’t sustainable. Finally it became DevKeel — an MCP server where all the intelligence stays with your own LLM, not mine. Three pivots, three names, each one a bet that taught me something. The naming journey alone is a case study in the framework I ended up building.

The keel metaphor stuck because it captured what I was trying to build: the structural backbone that keeps you on course. Not the engine — your AI tool is the engine. Not the sails — your ideas are the sails. The keel. The invisible part underneath that prevents you from capsizing when the first wave hits.

What grew out of it is something I call Bet-Driven Development. But the core insight was personal: the tools made building effortless. Nothing made deciding what to build effortless. That gap was eating my time, my focus, and my confidence as a builder.

The missing layer

There are tools for writing code faster — Cursor, Claude Code, Windsurf, Copilot. They’re excellent.

There are tools for tracking tasks — Linear, Jira, Notion. They tell you what to do. They don’t tell you why or whether it matters.

There are tools for measuring outcomes — PostHog, Amplitude, Mixpanel. They tell you what happened, if you set them up, which most solo developers don’t until it’s too late.

What’s missing is the layer in between. The layer that answers: What am I betting my time on? What’s my hypothesis? How will I know if it worked? When will I stop and check?

This is the layer that would have caught Noah in week one instead of month four. It’s also the layer I was missing in my own work — and the layer I built DevKeel to provide.

That’s what the rest of this series is about.

I’ll walk you through the ReplyBot and StudioPulse stories as they encounter each part of the framework — the bets, the signals, the moments where checking changes everything. And I’ll show you how these same patterns played out in my real work building DevKeel, managing my team, and juggling the side projects that taught me all of this the hard way.

Along the way, I’ll ask you to apply each concept to your own project. Not as homework. As a way to test whether this actually works for you, with your constraints, on your timeline.

Your Turn

Think about your current project — the one you opened your AI coding tool for most recently. Can you name the bet?

Not the feature. The bet. What did you believe would happen? How were you going to check? If you had to stop building today and evaluate whether the last two weeks of work actually moved you forward, could you?

If you can’t answer those questions, you’re in good company. Most of us can’t. I couldn’t, across multiple projects, for longer than I’d like to admit.

That gap — between what we build and what we validate — is exactly what the rest of this series is about.

If you want to follow along, grab a notebook or open a doc. Write down your current project and what you think your bet is, even if it’s vague. We’ll sharpen it in the next post.

References

Next in the series: Think in Bets, Not Tasks — why the shift from task lists to testable bets changes everything, and how a single phone call can save you three months of building.

← Back to blog