I.
There’s a new kind of builder showing up: the one-person product team.
A few years ago, shipping a feature meant coordinating stakeholders, designers, engineers, domain experts and PMs. Now a single person can get surprisingly far with a model, a framework, and some taste. The “designer-PM-engineer” role collapsing into one.
This is real. It’s powerful. And for a little while it felt like a cheat code.
II.
When all your team can build anything, “shipping” velocity becomes the easiest thing to measure and celebrate.
The weird part isn’t that agents are writing code. It’s where the decision have moved.
A person has an idea, asks an agent to generate a plan, iterates a few times, ask other agent to review it, then hits “Accept”. It feels thorough. It’s fast and powerful. You then share the PR.
But by then, every product decisions has already been decided.
And the inertia push you that way. Asking an agent costs seconds. Asking a colleague costs minutes, plus the overhead of getting them into context. Do that a few times a day and you start optimizing for the thing with the lowest friction. Using your agent as head of product.
Over a quarter, a team can drift into a pattern where everyone is doing “locally rational” work: each change makes sense in isolation, each PR is defensible, each person feels productive and you’re shipping faster than ever.
And yet the product becomes a pile of decisions no one made together.
I’ve caught myself doing exactly this: aligning at the PR level instead of earlier. By the time anyone else sees the work, it’s not really challengeable. It’s already shaped.
But the deeper problem isn’t just when we review. It’s what we review.
III.
PRs show code. PRDs show intent. Figma shows pixels.
None of them show behavior.
The way teams have historically aligned on behavior is prototypes.
This isn’t new. What’s new is what your product can do now.
When your product has AI, AI behavior is the product.
Static artifacts are worst exactly where things are most uncertain: “What will the model do on real inputs?” / “Will this feel trustworthy?” / “What happens on edge cases?”
A prototype used to mean a clickable mock: shape without substance. That worked when content was deterministic and the hard part was UI/UX.
But AI plus probabilistic behavior changes the rules. Now you can prototype the thing itself: not what the main flow look like, but what the product does with AI.
Instead of arguing about what an answer should look like, you can look at real answers and decide whether they’re good and refine the prompts yourself.
That’s why designing in code in 2026 is far more superior than designing anywhere else.
IV. The solution
Prototype that helps team align have three properties:
They’re functional on real data. Not a Figma flow. Not a demo with fake inputs. All behavior has to be testable with edge cases handled.
They’re reviewed together. PM, design, engineering, founders, users: same artifact. The alignment isn’t a side effect. It’s the purpose.
They’re throwaway. This sounds wasteful, but it isn’t. “Throwaway” is the whole point: it prevents prototypes from turning into accidental production systems because they were “almost done.” You don’t have to care about code quality and can focus on the user experience. Engineers will help you build it right later.
Then you refine it, build the real thing fresh, informed by what you learned.
V. Examples
I’ve recently prototyped and implemented a fully agentic onboarding flow. Agent ask your role, your most important problem to solve and dive into a fully agentic onboarding task list with personalized integrations to connect.
I shared the prototype to the team. Everyone could test on their own machines with a preview link. Everyone gave their feedback. Recommendations didn’t felt accurate enough, we throw it away. The full loop took less than 24 hours.
I’ve recently designed an agent personalization flow with role, name and profile picture generation. We wanted the Agent profile pictures to be personalized and unique. Image is generated from (1) a database of names which, (2) define a gender then, (3) pick random ethnicity group then, pick brand primary color. Add these variable into the prompt and gets the avatar generated in a few seconds.
The logic looked right in the code. Then we looked at fifty outputs together and immediately saw problems: weird accessories, brand colors that clashed. You have to stress test the prompt. All of these creates a cohesive, unique and scalable experience. All of these are design choices we made from the prototype.
We iterated on it and shipped it.
VI. Conclusion
Fight that PR inertia. Prototype better.
Don’t optimize for shipping velocity. Optimize for user value.
Share the prototype before you share the PR.
Review it together.
Throw it away.
Rebuild it.
Ship it.
Thank you for reading
This newsletter is my attempt to deliver exclusive frameworks and actionable insights for entrepreneurs and designer to harness design as their strategic advantage.
Remember, this is your journey as much as it is mine. If you feel this isn’t what you’re looking for at any point, please feel free to opt out–there will be no hard feelings.
If you have any suggestions on how I can improve the format, reply to this email with your feedback, and I will personally reply to all emails.
Take care,
If you find this post helpful, consider sharing it with a friend using the button below
🔥