I recently spoke at a multi-day event for product leaders across SaaS and enterprise software. The audience included PMs, product execs, and teams responsible for shipping and adoption. Across conversations, one question kept coming up: How do I get engineering leadership on board with this way of working?
The answer starts with how work moves.
Teams are starting to split the work differently. Developers use tools like Claude Code for the parts that require deep engineering judgment: core logic, architecture, anything that touches systems or performance. That work stays with them.
Once that foundation is in place, the rest of the work can move forward. The branch gets pushed into Builder. From there, other roles take over directly in the code:
- QA finds bugs and fixes them without routing everything back through engineering
- Designers refine spacing, interactions, and visual details themselves
- Product updates copy, tracking, and small requirements without opening new tickets
The last mile of development, which tends to be the most fragmented and time-consuming, stops flowing through engineers.
This shift resonates with engineering leaders for a specific reason. When product and design generate and refine working code themselves, engineers spend more time on architecture, performance, and system design. Work moves in parallel across the team. Throughput increases without adding headcount.
That shift in ownership also changes when teams learn. Engineering teams spend significant time rebuilding work after launch. Requirements evolve once real users interact with a feature, which drives rework and slows teams down.
Teams at the event connected quickly with a different approach: validate earlier, while the work is still easy to change. With Builder, product and design teams generate working code, push it to a branch, and share a live preview with customers. Feedback comes from real usage through those previews.
By the time something reaches engineering, the direction is clear. The team has already seen how users respond. Engineers review and finalize work that reflects real usage. Iteration cycles shrink. Quality improves.
One idea kept coming up in follow-up conversations: iterate before production. That principle carries through to the rest of the workflow. Engineers still start work as they normally would. They open branches and push changes. From there, review and refinement move to the right roles:
- Designers adjust directly in code
- Product refines scope based on feedback
- QA tests and resolves issues before a pull request reaches engineering
Engineers stay focused on code quality and system-level decisions. The rest of the team contributes directly to building and validating what ships.
The experience feels familiar. It mirrors how teams already collaborate in tools like Google Docs or Figma. Work is shared, visible, and easy to evolve. AI agents handle repetitive tasks. People focus on judgment and decisions.
Underneath this is a broader shift toward agent-native development, where the agent and the interface operate as a single system. Work moves fluidly between people and automation across the entire workflow.
The takeaway from the event was consistent. Teams want faster delivery. They want less rework. They want to involve more of the team in building and get closer to real customer feedback earlier in the process. This model supports that shift.
If you want to put this workflow into practice, you can start using Builder today.