Last week, one of our Product Managers (PMs) created and shipped a feature. This is not specified. Did not file ticket for this. Built it, tested it, and shipped it to production. In one day.
A few days ago, our designer noticed that the visual appearance of our IDE plugins was gone from the design system. In the old world, this meant screenshots, a JIRA ticket, a conversation to explain the intent, and a Sprint slot. Instead, they opened an agent, adjusted the layout themselves, experimented, iterated and tuned in real time, then pushed improvements. The person with the strongest design intuition directly decided the design. No translation layer required.
In principle there is nothing new in this. Vibe coding opened the doors to software creation for millions of people. That was Akanksha. When I shared data about how our engineers doubled throughput, moved from coding to validation, rapidly moved designs toward experimentation, it was still an engineering story. What changed was that theory became practice. Here’s how it actually played out.
the obstacle has been removed
When we went AI-first in 2025, implementation costs fell. Agents took over the scaffolding, testing and iterating glue code that ate up half the sprint. Cycle times decreased from weeks to days, from days to hours. Engineers started thinking less in files and functions and more in architecture, constraints, and execution plans.
But once engineering capability stopped being a hindrance, we noticed something: the decision was velocity. All the coordination mechanisms we had created to protect engineering time (specifications, tickets, handoffs, backlog grooming) were now the slowest parts of the system. We were adapting to a constraint that no longer existed.
What happens when construction is cheaper than coordination?
We started asking a different question: What would it look like if the people closest to the intent could ship software directly?
The Prime Minister already thinks about the specifics. Designers already define the structure, layout, and behavior. They don’t think in syntax. They think in consequences. When the cost of converting ideas into working software became low enough, these roles were no longer needed "Learn to code." The cost of implementation simply dropped to their level.
I asked Dmitry, one of our prime ministers, to explain what changed his approach. He told me: "While agents are generating tasks in Zenflow, there is an idle time of a few minutes. Just dead air. I wanted to make a little game, something that you could interact with while you wait."
If you’ve ever run a product team, you’re familiar with this type of idea. It does not transfer KPIs. It is impossible to justify this in a priority meeting. It gets postponed forever. But it adds personality. It makes the product feel like someone cared about the little things. These are exactly the same things that are adapted from each backlog grooming session, and exactly the same things that users remember.
He made it in one day.
In the past, that idea would have ended up in a prioritization spreadsheet. Not because it was bad, but because the cost of implementation made it illogical to pursue it. When that cost falls close to zero, the calculation changes completely.
Shipping became cheaper than explaining
As more people started building directly, entire layers of the process quietly disappeared. Less tickets. Less handoffs. fewer "Can you tell what you mean…" Conversations. Fewer moments lost in translation.
For a meaningful class of tasks, it’s faster to simply build the thing than to describe what you wanted and wait for someone else to build it. Think about that for a second. Every modern software organization is structured around the assumption that implementation is the expensive part. When that perception is broken, the organization has to change with it.
Our designer fixing the plugin UI is a perfect example. The old workflow (screenshot the problem, file a ticket, clarify gaps between intent and implementation, wait for a sprint slot, review results, request adjustments) existed solely to protect engineering bandwidth. That whole pile disappears when a person with design intuition can act directly on it. Not because we killed the process for ourselves, but because the process was solving a problem that no longer existed.
compound effect
Here’s what surprised me the most: It’s compounded.
When PMs create their own ideas, their specifications become sharper, because they now understand what the agent needs to execute well. Faster specs produce better agent output. Better output means fewer iteration cycles. We’re seeing increases in velocity week over week, not just because the models have improved, but because the people using them have moved closer to the work.
Dmitry said it well: The feedback loop between intention and outcome went from weeks to minutes. When you can immediately see the result of your specification, you learn what precision the system requires, and you begin to provide it intuitively.
There is a second-order effect that is hard to measure but impossible to miss: ownership. People stop waiting. They put off filing tickets for things they could fix. "manufacturer" Ceased to be a job title. This became the default behavior.
What does this mean for the industry
lots of "everyone can code" Last year’s narrative was theoretical, or focused on single founders and small teams. What we experienced is different. We have ~50 engineers working in a complex brownfield codebase: multiple surfaces and programming languages, enterprise integrations, a whole load of real production systems.
I don’t think we are unique. I think we’re in a hurry. And with each new generation of models, the gap between who can build and who can’t is shrinking faster than most organizations. Every software company is about to find that their PMs and designers are sitting on unrealized manufacturing capacity, blocked not by skill, but by cost of implementation. As costs continue to fall, the organizational implications are profound.
We started with the intention of accelerating software engineering. What we’re becoming is something different: a company where everyone steers the ship.
Andrew Filev is the Founder and CEO of Zencoder.
<a href