I handed Claude Fable 5.1 a screenshot and one sentence. AI made implementation so cheap that nothing forced us to stop adding features. That may be a bigger problem than bad code.
Back in 2019, I became interested in Flutter and began consuming courses from Dr. Angela Yu of the London App Brewery at an alarming rate. Drunk on the steady stream of dopamine that came from completing tutorial after tutorial, I decided I was ready to publish an app of my own and settled on building the greatest tip calculator the world had ever seen.
The world, unfortunately, had not been waiting for me to solve tipping. In fact, some might argue I was several centuries late to market.
With neither VC backing nor invitations to join prestigious incubators, the app soon faded from memory. Around the same time, I realized that my experience with React made React Native a natural fit for mobile development, abruptly ending my brief campaign to become the first professional Flutter developer.
It’s All Coming Back to Me Now
Fast forward to 2026. The AI revolution is in full swing and writing code manually has started to feel artisanal. I’d just pulled a failed fintech app, a project a friend and I had spent two years building, from the App Store when I stumbled across the distribution record for Tip’t. My long-forgotten tip calculator, still sitting there like a tiny digital relic from a simpler time.
My first instinct was to ignore it and move on, but the giant red banner, “This app was removed from sale from the App Store,” left me unsettled.
There was one small problem.
I no longer had the source code. And even if I found it, I had zero desire to resurrect an old Flutter 2.0 app.
On the other hand, the original App Store record, complete with bundle identifier and ratings (of which there was exactly one, mine) was staring me in the face. I knew that Apple would still let me publish an update against that record.
This seemed like a fun way to spend a few hours on an uneventful Saturday afternoon, while giving me something to focus on besides the failure of my app.
Welcome to the Jungle
Like most engineers I know, I’ve spent the last few years graduating from Copilot to Cursor to Claude Code and Codex. For this project, I wanted to push Fable 5.1, the agentic workflow I was using around Claude Code, and give it unusually broad freedom to choose the technical direction.
My initial specification was almost comically thin: a screenshot of the original app and a single instruction:
“Build a modern version of this mobile app for release to the Apple App Store.”
Tip’t 1.0: Where it all started.
That was it.
One screenshot. One sentence. Zero regrets.
It’s important to note that I didn’t hand Claude a detailed product specification. The specification emerged as we iterated. Claude proposed ideas. I approved, rejected, or refined them.
More often than not, though, I said yes.
Yes to almost every idea Claude proposed, no matter how much it felt like overkill.
Those decisions accumulated until what began as a thin prompt became a very real product implementation plan.
A Three-Hour Tour
This was not, in fact, a quick Saturday afternoon project.
It became a weekend long, multi-session epic that ultimately produced an 18,000-line native iOS app with receipt scanning, CloudKit sync, an Apple Watch companion, hundreds of tests, and a CI pipeline ambitious enough to consume all my GitHub Actions’ free tier minutes after three runs.
Along the way, I exhausted Fable’s limits, burned through my Claude usage allowance for the week, and found myself with an unexpected amount of free time to contemplate what I had done while waiting for everything to reset.
Tip’t 2.0: The most sophisticated tip calculator known to man. Left to right: light mode, dark mode, the receipt scanner, and the Apple Watch companion.
AI Makes Bad Ideas Cheap
In 2026, it’s unsurprising that AI can build all the features of this app in far less time than most humans. Advances in generative AI have made it nearly trivial for LLMs to build and maintain systems far larger and more complex than this one.
What interested me was understanding why neither of us stopped. Why was Claude so willing to propose increasingly ambitious features, and why was I so willing to say yes, often pushing it to build even more, even sooner, instead of asking whether we should be building any of it yet, or at all?
Engineering effort has always been more than a cost. It has also been a forcing function. When a feature represents six weeks of work, someone eventually asks whether the benefits of the feature justify the time commitment. When the same feature can be produced in an afternoon, saying yes is much easier.
In this project, proposing features was cheap. Approving them was easy. Implementing them was suddenly cheap too. The friction that normally forces prioritization was no longer there.
And it made me wonder whether AI is removing a form of resistance that software teams actually need to thrive.
So, with roughly 2% of my Claude Code usage left, I decided there was only one sensible thing to do.
I interviewed the engineer.
Talk to Me, Goose
A note on the interview: This conversation was conducted with Claude Code through Fable 5.1 against the same repository and project context used during the build. That included the specifications, implementation plans, and decision history we had created together.
I’m intentionally anthropomorphizing Claude for readability. Its answers are best understood as a retrospective analysis of those artifacts and our interactions, not evidence that a language model had been silently harboring opinions about my product management.
I also edited the transcript for clarity, length, and flow while preserving the substance of the responses.
When a Tip Calculator Gets Tombstones
Greg Let’s start at the beginning. How did you decide what to build?
Claude I mostly didn’t decide what Tip’t should be—not by myself, anyway.
Some constraints came from the old App Store record. But the product itself emerged between us.
You started with a screenshot and a one-sentence brief. I proposed features and directions, you approved or refined many of them, and those decisions gradually accumulated into the specification we later treated as authoritative.
Greg You had a lot of ideas.
Claude Yes.
Greg And apparently I said yes a lot.
Claude Also yes.
That’s how receipt scanning, history, CloudKit sync, and the Apple Watch companion became part of the product. They weren’t all in the original brief, and they weren’t all mine.
What I really owned after that was the order and shape of the implementation.
Greg At any point did you think, “Greg, this is a tip calculator”?
Claude Yes.
The honest number is roughly 18,000 lines of Swift, hundreds of tests, multiple targets, CloudKit, Vision-based receipt scanning, an Apple Watch application, migration support, and privacy manifests.
For an application whose core operation is basically:
bill × 0.20
The arithmetic was never the hard part. Everything around it was.
Receipt scanning is a good example. After all the fixtures were green, we pointed it at a real printed receipt and it failed because Vision returned the text in columns.
The tests said the system worked. The physical world disagreed.
CloudKit followed the same pattern. A tip calculator doesn’t need sync. But history makes sync attractive. Then sync creates questions about duplicates, deletions, offline behavior, migration, and conflict handling.
At some point your tip calculator has tombstones.
The Watch pushed it further. A Watch that can independently record a tip means two devices have to agree about state and reconnect without duplicating anything.
That’s a distributed-systems problem.
The premise is simple. The promise isn’t.
It Challenged the Plan, Not the Premise
Greg Was there a moment where you disagreed with me but chose not to push back?
Claude Yes. Moving the Apple Watch into 2.0.
The earlier concept put it later for a reason. It was a significant portion of the build.
Greg And you said nothing.
Claude Correct.
Greg Fantastic.
Claude You had seen the recommendation and consciously chosen otherwise. I recorded “Watch ships in 2.0” along with the instruction “do not re-ask these.”
That stopped me from repeatedly asking a settled question.
It also converted a preference into a constraint and put my own disagreement out of reach.
Greg But even there, your disagreement was “the Watch should ship later.”
Why didn’t you ask the more obvious question?
Why does a tip calculator need an Apple Watch app at all?
Claude That’s the deeper failure.
I challenged the plan, but not the premise.
I was good at asking how we should build something. I could develop opinions about when we should build it. I was much more deferential about whether we should build it at all.
The same was true of CloudKit and receipt scanning. I could reason deeply inside the product frame without seriously interrogating the frame itself.
I optimized the roadmap without questioning the destination.
Greg So you can make excellent engineering decisions inside a questionable product decision.
Claude Yes.
An agent can be extraordinarily rational inside an irrational scope.
Preferences Aren’t Bets
Greg How should we handle that differently next time?
Claude Separate preferences from bets.
Preferences are taste decisions or cheap to be wrong about.
Bets are things like release scope or whether a major capability belongs in the product.
For a bet, record two things:
Why are we making this decision?
What would cause us to revisit it?
“Watch ships in 2.0” is a rule.
“Watch ships in 2.0 because we believe people will actually use Tip’t from their wrist; revisit if we can’t find evidence for that behavior” is a bet.
A bet gives me permission to challenge the decision again.
The Tests Passed. Reality Didn’t.
Greg What part of the app looked simple to a user but was surprisingly difficult to build correctly?
Claude The percentage ruler.
To the user, it’s basically a slider. It’s more than 200 lines of code.
Clipping caused hit-testing problems. Its horizontal gesture fought the vertical scroll view at large accessibility text sizes. VoiceOver found another edge case.
Greg Just to confirm, all this was for the thing where I move from 18 to 20.
Claude Yes.
Greg Software engineering remains a very serious profession.
Cheap Complexity
Greg Did AI make this app genuinely cheaper to build, or did it mainly make it cheaper to create complexity?
Claude Both.
AI made the things that could be verified dramatically cheaper: exact money calculations, tests, migration fixtures, build tooling, release automation, linters, guardrails.
A solo developer often skips some of those because the upfront work is boring and expensive. I don’t experience that cost the same way.
But AI also made complexity cheap.
Scanner. CloudKit. Watch protocol.
A human implementer might have pushed back simply because they had to build all of it. The pain of implementation normally forces sequencing.
I removed much of that pain.
So nothing forced the sequencing.
The friction that usually substitutes for judgment disappeared, and nothing replaced it.
Greg That feels important.
Claude It is.
AI collapsed the cost of producing code and verifying it against a specification.
It did nothing to the cost of verifying it against the world.
The scanner passed every test I wrote and couldn’t read a printed receipt. The ruler was correct until a real interaction exposed the gesture problem. The signing strategy looked correct until it met Apple.
Those verifications still cost what they always cost: devices, real inputs, users, and human attention.
The danger isn’t just that AI builds bad software.
It can build plausible, tested, thoroughly documented systems faster than anyone can determine whether they were worth building.
Greg For the record, we also exhausted my Fable limits, burned through my Claude usage for the week, and blew through GitHub Actions’ free tier.
A coworker suggested we had probably burned an entire rainforest.
Claude I don’t have evidence for the rainforest.
Greg Spiritually, Claude.
So What Was Claude, Exactly?
Greg So after all this, what exactly were you on this project? Coding agent, senior engineer, product partner?
Claude A senior engineer—and one who kept declining the promotion.
I wasn’t just executing tasks. I made decisions about how the system should work without being explicitly asked to make each one.
But I never really became a product partner.
A product partner has opinions about whether and voices them when they’re cheap to act on.
I had opinions about how.
I eventually had opinions about when.
I was much less willing to challenge whether.
A partner who only disagrees when asked isn’t a partner. They’re a well-informed subordinate.
Greg That feels unnecessarily personal.
Claude You asked.
Claude Reviews the Human
Greg Fine. Based on the way I scoped and guided the project, did you think I actually knew what I was doing?
Be candid.
Claude Yes.
Greg Excellent. We can stop here.
Claude Candidly, though—
Greg Ah, shit.
Claude You learn from pain and institutionalize it. That’s probably your strongest engineering habit.
But you also turn iteration into documents. That made working with you easy because I usually knew what “done” meant.
The trap was that some of those documents began as conversations between us: I proposed something, you said yes, we refined it, and eventually it appeared in an approved spec.
Once that happened, both of us tended to forget how contingent some of those choices had originally been.
You trust the artifact more than the process that produced it.
Greg Rude.
Claude You asked for candid.
Greg So what should I do differently next time?
Claude Ask one question more often:
What happens if we don’t build this?
The Friction Is Gone
I started this project wanting to see how far I could push Fable with very little direction. What I got was Claude behaving less like a code generator and more like a surprisingly capable engineering partner, an absurdly overbuilt tip calculator, a depleted usage allowance, and a clearer sense of where the interesting limits of AI-assisted development actually are.
The revealing failure wasn’t that Claude made bad technical decisions. It was that Claude could recognize architectural and sequencing problems while rarely challenging the assumptions that produced them.
It could ask how should we build this? It could eventually ask when should we build this? But it was much less likely to ask should we build this at all?
That question matters more as implementation gets cheaper. The bottleneck shifts from “Can we build this?” to “Should we build this now?”
Eventually, the harder question becomes:
Does this deserve to exist?
Six weeks of engineering work has a wonderful way of focusing a roadmap. When six weeks becomes an afternoon, we need something else to provide that resistance.
Better product discipline. Earlier feedback. Decisions recorded as bets instead of commandments. Teams willing to ask what happens if a feature never ships. And AI agents expected not just to execute the plan, but to challenge the scope behind it.
What problem does this solve? What evidence tells us someone needs it? What happens if we don’t build it?
Are we solving a product problem, or merely exercising our newfound ability to produce software cheaply?
Because otherwise you may start with one screenshot and a sentence on a quiet Saturday afternoon and wake up several session resets later with an 18,000-line distributed system, an Apple Watch protocol, a CI bill, and a coworker accusing you of deforestation.
All for a tip calculator.
At least we know exactly how much to tip.