TWITTER_ARTICLE

Far33d argues that AI-assisted coding tools like Claude Code collapse three…

2026-02-04 · 19:14 UTC ·far33d ·4 min read

Brief

Far33d uses a short project with his son—prompting Claude Code to make 'a fun 3D browser game' and then iterating until it improved—to argue that AI changes the economics underlying modern product management. In his view, methods like Lean Startup, MVPs, PRDs, and sprint planning all assume software construction is the dominant cost, so teams rely on interviews, smoke tests, and careful prioritization to avoid expensive mistakes. If AI makes it possible to start quickly, run many iterations, and throw away bad work with minimal cost, he says the optimal process shifts from planning toward search: pick a direction, evaluate each version with a strong 'loss function,' and keep stepping toward a better product. He suggests customer discovery still matters, but now to guide the next experiment rather than conserve engineering time, and that PMs become more valuable for judgment, taste, and selection than for upfront specification.

Why it matters

Far33d argues that AI-assisted coding tools like Claude Code collapse three traditional software costs—starting, iterating, and deleting—to 'basically zero,' based on an anecdote where he and his son built and repeatedly revised a 3D browser game in a few hours on 2026-02-04.

Key details

  • The post claims classic product-management frameworks such as Lean Startup, MVPs, sprint planning, story points, PRDs, and roadmap prioritization were designed for an era when engineering time was scarce and expensive, making upfront research and specification rational.
  • He proposes replacing heavy upfront planning with a 'gradient descent' model: begin with a rough direction, run many cheap experiments, and use a clear loss function—such as 'is this fun?', retention curves, next-day return rates, or observed user reactions—to decide each next step.
  • The essay contends that when deleting work is cheap, sunk-cost bias weakens: teams can kill features built in an afternoon instead of defending work that took six weeks, allowing broader exploration of the problem space through rapid experimentation.
  • Far33d reframes the product manager's role from blueprint writer to evaluator, arguing that human judgment—taste, intuition, and the ability to assess iteration #7 and choose what to invest in—becomes more valuable as AI reduces the cost of implementation.
Source evidence

title: @far33d: Last week my son and I built a better product in a few hours than some teams shi...
author: far33d
contenttype: twitterarticle
published: 2026-02-04T19:14:02+00:00
source_url: https://x.com/far33d/status/2019127323581378758

word_count: 823

Last week my son and I built a better product in a few hours than some teams ship in a month. We did

Last week my son and I built a better product in a few hours than some teams ship in a month. We didn't have a plan. Didn't know what we were making. We just opened Claude Code and typed "let's make a fun 3D browser game" and hit enter.

Within a few minutes we had something running.

It sucked.

The mechanics were off, the pacing was weird, it wasn't fun. We didn't try to fix it though. We just asked ourselves "ok, what would make this more fun?" Came up with a half-baked idea, tried it, asked again. Over and over.

We were following the fun. And the game we ended up with was something we never could have sat down and designed. It came out of the process of building, not from any kind of plan.

I've been thinking about this a lot since. I spent over a decade in product management building and teaching the frameworks that tell you how to build software. And I think every single one of them is built on an assumption that isn't true anymore.

The assumption: building software is the most expensive part of the process.

The Lean Startup tells you to "get out of the building" because building the wrong thing is really expensive. So you learn through cheaper proxies — customer interviews, landing page tests, smoke tests. The MVP is a rationing concept. The "minimum" in minimum viable product is doing real work. It's saying build as little as you can get away with because engineering time is precious.

Sprint planning. Story points. PRDs. Roadmap prioritization. These are all just different ways of allocating scarce engineering resources.

So what happens when building costs almost nothing?

The cost to start dropped to basically zero. You don't need to know what you're building. You need a direction, a vibe, a rough area to explore. My son and I didn't need a game idea. We needed "3D browser game" and a willingness to just go.

The cost to iterate dropped to zero too. Each step is almost free so you can take hundreds of them. A team that's run ten experiments while another team is still writing their spec has explored more of the problem space than any amount of upfront research could have.

And then there's the one nobody talks about: the cost to delete dropped to zero . When killing your work is free, sunk cost psychology goes away. You don't agonize over cutting a feature because it cost you an afternoon, not six weeks of engineering.

When all three of these are expensive, you have to plan your way to an answer. Narrow the space before you move. Front-load your thinking into specs and research. That's rational. That's what every PM framework is designed to help you do.

When all three are cheap, the better strategy starts to look a lot like gradient descent. You don't need to know where the answer is. You need a starting point and a loss function — some way of evaluating "is this step better or worse than the last one?" For our game it was simple: is this fun? For a product it might be retention curves, or whether users come back the next day, or just the look on someone's face when they try it. You don't need to map out the whole space. You need cheap steps and good taste at each one.

Drop in somewhere. Evaluate. Step. Repeat.

Why build a minimum viable product when you can build three full versions and see which one people actually want? Why run a smoke test when you can build the real thing by lunch?

Customer discovery isn't dead. "Get out of the building" is still right, but the reason changed. It used to mean go learn so you don't waste engineering time. Now it means go learn so you know which direction to step next. Strategy doesn't disappear either — it moves downstream. You're not choosing what to build from a whiteboard. You're choosing which of the things you already built is worth investing in.

The PM role actually gets more interesting here. The planning and speccing and prioritization stuff was always just an allocation mechanism for expensive engineering. That part loses value fast. But the loss function? That's all human. Taste. Intuition. Being able to look at iteration #7 and know what's working, what's dead, and where to go next. Gradient descent with a bad loss function just thrashes around. With a good one you converge on something great. The PM isn't the person who writes the blueprint anymore. They are the loss function.

My son and I never wrote a spec. We never prioritized a backlog. We just followed the fun, one dumb question asked over and over, each answer feeding the next step. What we made was something we never would have planned.

The starting point doesn't matter. The loss function does.

Posted: 2026-02-04T19:14:02.000Z

Engagement: 62 likes, 10 retweets, 3 replies