Login to tech Twitter and you’ll see posts bragging about 40k LoC per day from an unnamed YC member 😛. There’s some hilarity to it, but the vibe shift is real. At Jenni, we’re shipping 3-5x faster than mid-2025. I perpetually have unread notifications in our #shipped channel. Bugs go from reported to resolved in 24 hours instead of 5 days. Two or three meaty features per quarter, not per year.
So far, so good.
My concern is what’s quietly happening to the design process. Traditionally, designers were away from the codebase. Frustrated, always bottlenecked, vying for someone else to commit time to the thing they desperately wanted built. But the friction forced creativity. The work was to de-risk and probe, revisit and iterate the problem statement until clarity emerged.
Techniques like wireframes, smoke tests, multi-round design iterations, and user interviews were deployed to realize this goal. The cost of being wrong was so high, so the process was heavy to match.
The friction quietly did 3 things we didn’t notice we relied on:
- It forced divergence
- It surfaced the why behind the problem
- It kept us honest about what stage of the process we were in
Divergence is dying
When everyone can create prototypes, more ideas get shared. This is a genuine gain. Everyone on the team finally has a path to communicate in a high fidelity way (a prototype is worth 1000 words). But the first plausible-looking prototype can lock the room. Before, we’d diverge and explore a range of directions before converging on one. We introduce the risk of converging on prototype number one.
I notice it in myself. I see a prototype branched from the production app and immediately start sweating the details of UX, interaction, error states. The fidelity is doing the talking, and I’ve forgotten we hadn’t yet decided this was our best fit solution given the constraints.
A/Bn tests don’t tell us why
When several competing solutions exist, the path of least resistance is to ship them all and let users vote. We do this too. But A/Bn tells you which variant won, it doesn’t tell you why. The old process of interviews, iterations, and smoke tests helped surface the why. And the why was where alignment lived: designers, engineers, sometimes the wider team converging on a shared mental model, not just a winning variant. The why also outlived any particular issue or feature, it compounded context and empathy about users needs and jobs to be done.
I see the cadence of user interviews going down as commits from designers go up. More A/Bn tests, fewer live usability sessions where you watch a user react non-verbally to a proposed design. Less qualitative insight, more data. You can ship fast without the qualitative half. You just account for the intuition you would have otherwise built.
What stage are we in?
In WTF is prototyping I discussed the history of and the function a prototype can take: testing the look and feel of something, exploring the role a feature plays in a user’s life, probing the technical implementation. In the old workflow, fidelity itself gave you a clue about the stage and intent of the prototype.
That signal has broken. Today’s prototype look almost ship-able because the tools don’t really have a “rough” mode anymore. The discipline now has to be verbal: are we spiking, or are we shaping? Are we set on this form or is this one of many potential solutions?
One argument for is to ship and iterate. It seems rational given the low cost of code and its disposability. However, once something is in production the form rarely radically changes. If not for the stifling of team creativity after seeing the form of v1 exist, radically changing a flow for an ABn test when >50k paying users rely on the product to get a job done has to be implemented with caution.
The middle way?
The middle way isn’t reverting to a slower process. It isn’t fewer prototypes either. I propose it might look like a handful of habits that travel cheaply:
- Hold divergence longer than feels comfortable.
- Relentlessly pursue the why, not just the winning variant.
- Make it clear if you’re spiking or shaping.
- Treat feature removal as a first-class move, not a cleanup task.