When Building Becomes Cheaper Than Planning
How AI tools changed software economics and created a skillset that doesn't exist yet
Ten days ago I wrote about using AI to learn faster. Today is about using it to build faster.
Not “a little faster.” Not “incrementally faster.”
Fast enough that the rules change.
I keep having this experience at work. Someone suggests a feature during a meeting. I nod, open my laptop, and five minutes later say “refresh the screen.”
The look on their face never gets old. They’re still thinking about whether their idea is good, and I’m showing them the working version.
This isn’t about being clever. It’s about the tools reaching a point where building software is no longer the bottleneck. The bottleneck is everything else. Product judgment. Organizational navigation. Knowing what to build and what to throw away.
Ten years ago, I lived the opposite problem.
I was at a credit rating agency. We’d built something transformative - a platform that would fundamentally change how the business operated. Early wins. People excited. Requests flooding in.
And then we drowned.
That experience taught me what’s possible when you move fast. And what happens when you can’t move fast enough.
Today, with Claude Code and Cursor, I move faster than I thought possible back then. Fast enough to change the game.
This post is about what changes when building becomes cheap. And about finding someone who wants to learn to operate at this new speed.
Let me tell you about that credit rating agency.
Act I: The Frustration
The platform started strong.
We built the early pieces of a system that would transform how the credit rating agency handled the entire rating process. The first features shipped. People loved them. Word spread.
Then came the requests. Dozens of them. Good ideas. Important ideas. Features that would genuinely help.
We did what you’re supposed to do. We got organized.
We built a 3x3 scoring matrix. Effort on one axis, value on the other. Business cases, steering committees, the whole thing.
After a few rounds, we had more than 50 features and three years of estimated work.
People at the bottom of the list stopped coming to meetings. Can you blame them? Their request landed at number 47. Three years out. And we all knew we wouldn’t hit that timeline.
The momentum died.
We ended up building what we had to build. Regulatory requirements. Things that would break the business if we didn’t do them. Critical path items.
The transformative features, the ones that would actually change how people worked, that would make their jobs better, that they were excited about, those kept getting pushed.
Not because they weren’t important. Because we ran out of time.
I used to talk about this chart. Expectations on the Y-axis. Time on the X-axis. A curve that climbed dramatically.
The moment someone requested a feature, expectations started low. “This would be really helpful.”
But as weeks turned to months, their mental model evolved. They imagined integrations. Edge cases. Polish. By the time we delivered, if we delivered, they’d built up this elaborate vision of what it would be.
We were always disappointing people. Even when we built exactly what they originally asked for.
The system designed to help us prioritize was actually killing us. The success of the platform created demand we couldn’t satisfy, which forced us into triage mode, which killed momentum, which pushed transformative work years into the future.
Three years. For 50 features. One team, working one thing at a time.
If we had these tools then? Two months. Maybe three.
Act II: The Transformation
Fast forward to today.
Last week, someone on my team said during a meeting: “This tool is great, but it would be even better if we could filter by state and see the data aggregated by region.”
I opened Claude Code. Five minutes later: “Refresh the screen.”
The filters were there. The regional aggregation was working. They stared at it for a moment, processing.
“Wait, when did you build that?”
“Just now.”
This keeps happening. Someone suggests something. I build it while they’re still talking through whether it’s a good idea. The conversation shifts from “should we” to “let’s try it and see.”
A few days ago, different meeting. We were reviewing a dashboard. Someone said: “I’d use this daily if it pulled in the <whatchamacallit> data.”
“Give me a minute.”
Pulled the data. Added it to the view. Deployed.
“Refresh the screen.”
The time between idea and implementation collapsed from months to minutes. Not because I’m writing code faster. Because I’m not really writing code anymore. I’m having a conversation with an AI about architecture, data flow, and product decisions. Claude Code does the implementation.
The economics inverted.
Remember that High Effort / Medium Value quadrant from product prioritization frameworks? The features we’d always deprioritize because the return wasn’t worth it?
Most of them just became Low Effort / Medium Value. Which means you build them. All of them.
The effort axis of that classic 3x3 matrix compressed toward zero. Now I’m making decisions almost entirely on value and coherence. Does this fit the product? Does this solve a real problem? Does this make the experience better or just cluttered?
If I’m unsure, I build it and find out. An hour of development to test whether something works beats three meetings debating whether it might.
Sometimes a feature lands perfectly. Sometimes it doesn’t. When it doesn’t, I delete it. No big deal. It cost an hour.
I can experiment with real implementations, not mockups. The feedback loop became empirical. I’m doing science at product scale.
But here’s what really changed: I can keep all those promises now.
That list of 50 features at the credit rating agency? I could clear that in two months today. The regulatory stuff still gets done. But I’m not stuck in triage mode. I have bandwidth for the transformative features. The ones that actually change how people work.
The momentum doesn’t die anymore. It builds.
People stay engaged because they see their requests get built. They start suggesting more ambitious things because they realize speed isn’t a constraint anymore. The scope of what’s possible expands.
And those expectations? They stay low. Because I’m delivering before they have time to build elaborate mental models. The comparison isn’t their imagined ideal feature after six months of anticipation. It’s the problem they described five minutes ago.
Act III: The New Game
But speed creates new problems.
Not technical problems. People problems.
Moving this fast makes people uncomfortable. Some love it. Some feel threatened. Some worry about control and governance and whether we’re moving too fast to be careful.
You need to read the room constantly.
That feature someone just suggested - is building it going to move the conversation forward? Build credibility? Unlock the next thing? Or is it a distraction that will dilute focus?
You’re doing product prioritization at conversation speed. While people watch you work.
And you can’t just build everything. The lack of build constraints means you could easily end up with feature sprawl, a product that does 50 things adequately instead of 10 things exceptionally well.
The discipline required is different now.
It’s less about gatekeeping and more about:
Recognizing quickly what’s working and what’s not
Being ruthless about abandoning dead ends
Maintaining product coherence when you could build anything
Managing people’s fear and discomfort with the pace
This isn’t just about tools. It’s a different skillset entirely.
You need product sense. Not just “what should we build,” but “what should we build right now in this conversation.” Understanding workflows deeply enough to see possibilities users can’t articulate. Knowing when to push boundaries and when to stay within guardrails.
The best product frameworks still matter - what problem are we solving, for whom, how does this fit their workflow. But you’re applying them in real time, not in quarterly planning cycles.
You need political navigation. The ability to build trust and credibility fast enough to move at this pace. Bringing people along. Addressing fears about AI and change. Building enough relationship capital that people will say “trust me, let’s try this” when you’re three features ahead of where they’re comfortable.
This is change management on steroids. You’re not managing a six-month rollout. You’re managing reactions to things you shipped this morning.
You need technical depth. Not “can you code from scratch” technical. But enough understanding of architecture and engineering tradeoffs to have a real conversation with Claude Code. Knowing when it’s going down a path that will create technical debt. When to push it toward a different approach. When to accept its suggestion versus when to redirect.
You’re not writing the code. You’re guiding it. Which requires understanding what good code looks like.
These three things have to operate simultaneously. Product sense without political skills means you build great things nobody adopts. Political skills without technical depth means you can’t actually deliver. Technical depth without product sense means you build impressive things that don’t matter.
And there’s no established path to develop this combination. Software engineering programs don’t teach it. Product management bootcamps don’t teach it. You learn it by necessity, in the field, usually by frustrating people with your pace until you figure out how to bring them along.
The people who can do this are probably already doing some version of it. Building things on the side. Shipping faster than they “should” be able to. Working around slow organizations.
They’re probably frustrated. Technical enough to be dangerous. Curious enough about products and people that they care about more than just the code.
Act IV: The Call
I’m looking for someone who wants to learn this.
Not someone who already knows it all. That person probably doesn’t exist yet. But someone who read this and felt something. Recognition, maybe. Or excitement. Or frustration with how slow things move where they are.
Someone technical enough to have a conversation with an AI about architecture. Who’s written code, understands systems, knows enough to guide rather than just prompt.
Someone curious enough about products and people that they care about impact beyond the code. Who wants to understand workflows, solve real problems, build things that matter.
Someone who’s been frustrated with slow organizations. Someone who builds things on the side because waiting for approval feels impossible. Someone who’s suggested features only to watch them die in prioritization committees.
Someone who can navigate politics without losing momentum. Who understands that moving fast means bringing people along, not running past them.
This isn’t a traditional role. I can’t point you to a job description or a career path. We’re figuring this out as we go.
But if you’re that person - if you read about the “refresh the screen” moments and thought “I want to do that” - I want to talk to you.
We’re building an investment analytics platform at ZAIS Group. I’m documenting some parts of that journey here on prompts.finance. And I’m looking for someone to mentor through this process.
Someone who wants to learn to operate at this new speed. To build things that used to take quarters in days. To move fast enough that the rules change.
If that’s you, reach out. Let’s see what we can build.