When everyone can build

When a prototype looks finished, people start discussing launch dates. The team may still disagree about the problem, but the demo has made the idea feel settled.

AI makes it easier to reach that point. A designer can build a working flow, a product manager can try several versions, and an engineer can explore the interface before a handoff. More people can test an idea while it is still cheap to change.

I want to know what the prototype actually proved before committing to that launch date.

What a prototype proves

In Direct the ship, don’t row it¹, Sherif Mansour argues that AI is expanding the reach of product managers, designers, and engineers. He doubts the three disciplines will become one job everywhere. A small team may need someone who can cover all three. In a larger team, deciding what deserves to be built may already be the slower part.

I agree with the distinction, with one reservation: building something is often how you discover what the team should do next. Direction can suffer when it gets too far from the work.

Consider a photo-sharing feature. A prototype can help test whether people understand who will see a photo. To learn whether they trust the service with family photos, you need to go further. What happens when an invitation goes to the wrong person? Can someone recover a failed upload or revoke access without guessing what the other person can still see?

These questions affect the interface, the data model, and the help people will need. Leave them until the end and a simple-looking feature becomes expensive to repair.

AI can help people work across disciplines. In a study of nearly 800 P&G employees¹³, individuals using AI produced product proposals rated as highly as those from pairs working without it. Technical and commercial specialists also produced more balanced ideas. Ethan Mollick describes these results in The Cybernetic Teammate¹⁰. The tool appeared to provide some of the benefit of working with someone from another discipline.

The study covered one day of product development. Implementation, customer feedback, and a year of maintenance were outside its scope.

The research behind Mollick’s Centaurs and Cyborgs on the Jagged Frontier⁷ shows why the limits matter. In the 2023 experiment¹², 758 consultants worked with or without GPT-4. AI users worked about 25% faster on tasks it handled well. On a problem outside that range, they were less likely to reach the correct answer. A persuasive result still needs checking.

Addy Osmani’s The 70% problem⁸ describes the gap between an impressive first version and software you can maintain. His percentage is a metaphor. The person making the demo may have little way to judge what is missing.

Simon Willison makes a related distinction⁹: using AI to write software can still involve understanding, testing, and taking responsibility for it. Whoever types the code, someone needs to find out where it is wrong.

Make judgment visible

Designers sometimes say that taste will become more valuable. I want to know what they mean by it. A preference for a quieter layout tells a team little. Showing how the layout helps someone spot and correct a mistake gives them a reason to care.

Paul Graham describes taste as something people improve through practice in Taste for Makers³. Julie Zhuo questions the assumption that it will remain beyond AI in When AI Has Better Taste Than You¹¹. Claiming special intuition does little to help either the profession or the project.

Point to the confusing choice and explain what it costs the person using the product. Compare an alternative. Test the claim when you can. Other people can then examine the reasoning, use it in their own work, or show where it fails.

Work from a shared problem

If every decision has to pass through one person, faster building can leave everyone waiting for that person. A longer brief will not necessarily help. People need enough context to make a decision without another meeting: which problem matters, what is still uncertain, and which trade-offs they can make.

Marty Cagan’s Empowered Product Teams⁵ puts responsibility for solving a problem with the team, supported by clear strategic context. Teresa Torres makes the collaboration more specific in The Product Trio⁶: product, design, and engineering learn from customers and test possibilities together. Their roles differ, but their understanding of the problem develops together.

For the photo-sharing team, that could mean watching the same person struggle to understand an invitation. The engineer might notice that the permission model makes the wording hard to explain. The designer might find that the screen exposes a distinction nobody needs. The product manager might question whether sharing with a group is the right starting point. A summary that says “improve onboarding” would lose most of that information.

Keep the customer example beside the decision, including why an option was rejected. Put important constraints where people do the work. AI can help organize this material, provided the team checks summaries against the originals. Someone changing the invitation screen should be able to find the permission problem that shaped it.

Senior people need that contact with the details, too.

In Do Things that Don’t Scale⁴, Graham describes founders learning by doing work manually for early customers. That involvement helps them discover what to automate. A small team searching for a useful product may need someone to do the awkward work themselves. In a large company, a prototype can settle a disagreement that has survived several documents.

Fred Brooks made room for this in No Silver Bullet². He distinguished the difficulty of expressing software from the difficulty of deciding how it should work, while arguing for prototypes that help people discover their requirements. Building can expose a question that a discussion never reached.

I would choose where to spend time by looking at what is holding the work up. An interaction people disagree about needs something they can try. A poorly understood customer problem needs time with the customer. A flow that keeps breaking needs better checks. Moving between disciplines helps when it resolves one of these problems.

Measure what improves

The feeling of moving faster needs checking, too. In METR’s early-2025 study¹⁴, 16 experienced developers took 19% longer on familiar repositories when allowed to use AI, despite believing it had helped. The study was small, and the tools have changed. METR’s 2026 follow-up¹⁵ could not reliably estimate the newer tools’ effect because participation and task selection had changed. Neither result can tell you how much time your team saves today. You have to measure your own work.

Follow a piece of work through to the customer. How long does the problem take to resolve? How often does it come back for repair? Can people use what shipped? Count the time spent inspecting generated work along with the time saved making it.

Sometimes a quick prototype will show that the feature should not exist. Stopping there, before another month goes into it, is a good result.