I handed Claude 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, along with 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 was still sitting there, complete with a giant red banner announcing that the app had been removed from sale. I no longer had the source code, and even if I found it, I had zero desire to resurrect an old Flutter application. But Apple still had the original App Store record, complete with its bundle identifier and ratings (of which there was exactly one, mine).
The idea of bringing Tip’t back to life was oddly appealing. 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 other app. I’d spent the last few years graduating from Copilot to Cursor to Claude Code and Codex, and I was particularly interested in seeing how far I could push Fable 5.1, the agentic workflow I was using around Claude Code. Rather than providing detailed requirements or making the architectural decisions myself, I wanted to 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, and considerable optimism. Of course, the specification didn’t stay that simple. Claude proposed features and directions, I approved or refined them, and those decisions gradually accumulated into a much more ambitious product plan. More often than not, I said yes, even when the ideas felt like overkill. At the time, I was less interested in exercising product discipline than in discovering just how much an AI coding agent could accomplish.
A Three-Hour Tour
This was not, in fact, a quick Saturday afternoon project. It became a multi-session epic that produced an 18,000-line native iOS application with receipt scanning, CloudKit synchronization, 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.
In 2026, it’s hardly surprising that AI can build these features in a fraction of the time they would have taken a human developer. What interested me was why neither of us stopped. Engineering effort has always been more than a cost. It’s also been a forcing function. When a feature represents six weeks of work, someone eventually asks whether the benefits justify the investment. When that same feature can be produced in an afternoon, saying yes becomes considerably easier. In this project, proposing features was cheap, approving them was easy, and implementing them was suddenly cheap too. The friction that ordinarily forces prioritization had largely disappeared.
With roughly 2% of my Claude Code usage remaining, 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, including our specifications, implementation plans, and decision history. I’m intentionally anthropomorphizing Claude for readability. Its answers are a retrospective analysis of those artifacts and interactions, not evidence that a language model had been silently harboring opinions about my product management. I’ve edited the transcript for clarity, length, and flow while preserving the substance of the responses.
When a Tip Calculator Gets Tombstones
Greg At any point did you think, “Greg, this is a tip calculator”?
Claude Yes.
We ended up with roughly 18,000 lines of Swift, hundreds of tests, multiple targets, CloudKit, receipt scanning, an Apple Watch application, and migration support.
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. History makes synchronization attractive, but sync introduces duplicates, deletions, offline behavior, migration, and conflict handling.
At some point your tip calculator has tombstones.
The Watch pushed it further. Once it could independently record a tip, two devices had 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 questioning a settled decision, but it also converted a preference into a constraint.
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.
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.
The Cost of 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, and release automation. 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 it also removed much of the resistance that ordinarily forces engineers to reconsider scope. A human implementer might have pushed back simply because they had to build everything. 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.
We still needed real 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.
Preferences Aren’t Bets
Greg So how should we handle this differently next time?
Claude Separate preferences from bets.
Preferences are taste decisions or things that are cheap to be wrong about. Bets are decisions about scope or whether a capability belongs in the product. For those, record why we’re making the decision and 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 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.
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 understanding 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. And I wasn’t much better. I kept approving features because the cost of adding them seemed so small, without spending nearly enough time considering whether they belonged in the product.
The bottleneck is shifting from our ability to build software to our ability to decide what deserves to be built. 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, and decisions recorded as bets rather than commandments are a starting point. Otherwise, you may start with one screenshot and a sentence on a quiet Saturday afternoon and emerge several session resets later with an 18,000-line distributed system, an Apple Watch protocol, a depleted usage allowance, and a coworker accusing you of deforestation. All for a tip calculator.
At least we know exactly how much to tip.