AI did not eliminate the engineering bottleneck. He moved it.
Code is cheaper than ever. Prototypes appear within hours. Complex systems that once took weeks can now be assembled in a few days. That sounds like progress, but on many teams it creates a new failure mode: sending the wrong thing faster and confusing motion with impact.
That's the trap.
When implementation becomes cheaper, the quality of decisions becomes more important, not less. If a team doesn't know exactly what problem it's solving and how success will be measured, AI becomes a force multiplier of confusion. It helps you produce more code, more architecture, more internal tooling, and more maintenance burden without increasing the likelihood that any of it will matter.
The discipline I keep coming back to is simple:
- Build for a measurable objective.
- Send to remove ambiguity.
Those two rules seem almost trivial. In practice, they eliminate a surprising amount of waste.
AI made overbuilding easier
Most engineers are not reckless. The problem is deeper than that.
Good engineers are usually systems oriented. They like coherent designs, scalable abstractions, elegant mechanisms, and solutions that look future-proof. Those are useful instincts. But AI turns those instincts into a liability when the goal is not yet clear.
Once the cost of implementation decreases, over-engineering becomes the default option. It becomes easy to build:
- AI pipelines for problems that are still hypothetical.
- widespread systems before limited use case is tested
- adaptive experiences that are impossible to evaluate cleanly
- layers of automation that create more operational burden than user value
The question is no longer "can we build this?" because now the answer is almost always yes.
The real questions are:
- Will this move the metric that matters?
- Can we prove that he moved it?
- Can we operate the system after the demonstration?
If those answers aren't clear, speed doesn't help. You are hiding the error for later.
Rule 1: Build to achieve a measurable goal
A team needs a scoreboard.
Not "improve onboarding."
Not "make the product smarter."
Don't "invest in AI capabilities."
A measurable goal.
For example:
Activation = percentage of new users who reach first moment of success within 10 minutes.
That definition does a lot of work right away. It forces clarity. Every idea now has to answer a simple question: how does this activation move?
If the answer is vague, it should not be built yet.
This rule also eliminates a common failure mode: bundling multiple ideas into a single version. The moment a team changes too many things at once, causality disappears. If the results improve, no one knows why. If the results get worse, no one knows what to undo. Teams end up replacing evidence with narrative.
Here's another important part: engineering should not define the goal alone. The company, product, or whoever owns the result must approve the metric. That alignment is not bureaucracy. It's a safeguard against teams embarking on technically impressive work that no one really needed.
Rule 2: Submit to remove ambiguity
Shipping is often framed as delivery of value. At the beginning of a project, that is incomplete.
Advance shipping is mainly about purchasing information.
Every product team works within ambiguity. People have opinions about what users want, where friction lies, and what kind of experience will unlock growth. Most of these opinions are partly wrong. The only reliable way to reduce uncertainty is to send something small enough that the result will teach you something specific.
That's why the second rule is important: send to remove ambiguity.
The pitch should be designed to answer a question, not satisfy everyone's wish list.
If the team believes that users are churning because account creation appears too early, the first report
