How AI is enabling startups to build and iterate faster

Executive overview

Execution speed is the strongest predictor of startup success. AI is now compressing every part of the build cycle — from prototyping to product feedback — but most teams haven't updated their practices to match.

The core levers are: concrete ideas that engineers can act on immediately, agentic coding tools that make prototyping 10x faster, and a portfolio of rapid feedback tactics to replace slow data cycles with high-quality gut decisions.

The bottleneck has shifted from engineering to product judgment — and the teams that adapt fastest will win.

Work on concrete ideas only

• A concrete idea is one specific enough that any engineer would build the same thing.
• Vague ideas ("use AI to optimise healthcare assets") feel safe because they're always right — but they're unbuildable.
• Concreteness enables speed: engineers can build, validate, and falsify quickly.
• Good concrete ideas come from deep domain immersion — talking to users, thinking hard about a problem for months or years.
• Pursue one hypothesis at a time with full commitment; pivot sharply when data disproves it.
• If every customer conversation changes your mind, you don't yet have enough domain knowledge to form a quality hypothesis.

Use AI coding assistance to prototype 10x faster

• Production code quality improves ~30–50% with AI assistance — useful but not transformative.
• Standalone prototypes are a different story: 10x faster or more, because there's no legacy integration, and reliability/security requirements are lower.
• Build 20 prototypes to discover what works; low cost-per-POC makes it fine if most don't ship.
• Code is no longer a precious artifact — rebuilding a codebase from scratch is now routine if the architecture isn't right.
• Tech stack choice is shifting from a one-way door to closer to a two-way door.
• "Move fast and be responsible" — not move fast and break things, and not slow down either.

Stay current with agentic coding tools

• Agentic coding assistants (e.g. Claude Code) represent a new generation beyond cursor/windsurf-style AI IDEs.
• Being even half a generation behind on tooling creates a meaningful productivity gap.
• Teams are taking fundamentally different approaches to software engineering compared to six months ago.
• Everyone should learn to code — CFOs, recruiters, front-desk staff included. Deeper computer literacy means better ability to direct AI to produce the outcome you need.
• Advising people not to learn to code because AI will replace it is some of the worst career advice possible.

The product bottleneck: getting fast feedback

Engineering speed has outpaced product decision-making. The ratio of PMs to engineers is shifting — one team proposed 2 PMs per engineer.

Tactics for rapid feedback, from fastest to slowest:

• Your own gut — if you're a genuine domain expert, this is surprisingly reliable and instant.
• Ask friends or teammates to use the product.
• Ask 3–10 strangers (coffee shops and hotel lobbies work well; most people welcome the distraction).
• Same prototype to 100 testers.
• Same prototype to a larger user pool.
• A/B testing — useful, but slow; best used to calibrate instincts rather than just pick winner A or B.

The key habit: after any data-gathering exercise, sit with the results to update your mental model — not just to make the immediate decision, but to sharpen future gut calls.

Build AI knowledge as a competitive advantage

• AI is emerging technology; knowledge of how to apply it well is not yet widely distributed.
• One wrong architectural decision (one bit of information) doesn't cost 2x — it can cost 10x in time chasing a dead end.
• Specific decisions that matter: what accuracy is achievable for a given chatbot, when to use RAG vs fine-tuning vs DSPy, how to get voice latency low enough.
• Building blocks — prompting, agentic workflows, evals, guardrails, RAG, voice, embeddings, fine-tuning, computer use, MCP — combine combinatorially. Every new block unlocks exponentially more possible applications.
• Architect software to make switching between foundation models easy; use evals to swap models automatically when a better one is released.

Where the opportunity is

• The application layer is where the largest opportunities sit — by definition, applications must generate enough revenue to support all the infrastructure layers beneath them.
• Agent orchestration has made application building easier, not harder.
• The amount of valuable, unbuildable software vastly exceeds the number of people with the skill to build it — white space is enormous.
• Focus first on building something users genuinely love; moat, channel, and pricing are secondary problems.

On hype, responsibility, and open source

• Many extreme AI narratives (existential risk, mass unemployment, only nuclear power can run AI) were amplified because they made certain businesses look more powerful — apply a "who benefits?" filter.
• AI is neither safe nor unsafe; safety is a function of application, not technology. "Responsible AI" is a more useful frame than "AI safety."
• Kill projects on ethical grounds, not just financial ones — AI Fund has done this.
• Regulatory capture via overstated AI dangers is a real threat to open source; preserving open-weight models matters for distributed innovation.
• Bring everyone along: non-engineers who learn AI and coding outperform those who don't, in every function.