AI Makes It Easier to Build the Wrong Product
- Source
- x.com
- Author
- Grey
- Date
Context
When a team is unsure what users need, faster coding can spread a mistaken assumption through more software before anyone discovers it. Grey proposes matching implementation size to uncertainty: build a narrow but complete user workflow, observe it in use, and revise the next step from that evidence. Testing whether code follows a specification cannot establish whether the specification solves the right problem. Read the argument.
Larger batches remain appropriate when the desired behavior is stable and verifiable. This complements the Codex product interview, which explains why a polished prototype can precede a sound product decision.
- Validating at the end of a milestone proves the system matches the specification. It cannot prove the specification was right, and that is precisely the check large-batch work skips.
- Building is itself a source of information. Constraints, edge cases and real integration behavior only surface during implementation, so a large batch guarantees that learning arrives after you've built around the wrong assumption.
- AI weakens the case for horizontal specialist tickets. When one person can cover interface, backend, integrations, tests and docs, the organizational reason to slice work by layer instead of by user outcome mostly disappears.
- Kniberg's skateboard framing is sharper than 'ship an MVP': the first release is the earliest testable version of the whole user outcome, which later becomes usable and eventually lovable — never a component shipped alone.
“AI makes implementation cheaper; it makes evidence and judgment more valuable.”
“Testing at the end may prove that the system conforms to the specification. It cannot prove that the specification was the right answer.”
“AI accelerates the first question, but the others.”
“A team can now spread a flawed assumption across an entire milestone in days rather than weeks.”
Checking sign-in…
Loading comments…