Opinion
When teams can build faster than they can agree
“AI makes features cheaper to revise,” writes Roman Labunsky, co-founder and CTO of Copperhelm. “That changes what teams need to agree on before they ship.”
A task raised in the morning can be done fifteen minutes later. That changes what’s worth debating in a planning meeting. When a late change takes days of rework, an extra discussion is worth the time. As AI cuts some of that work, product, design and engineering have more room to decide what to settle before launch and what to learn from a first release.
To act on what they learn, teams need someone who can carry a decision through from design to release. I’ve had engineers own features end to end since well before coding agents. They work out the requirements with a product manager, who keeps the customer’s problem in view as the design changes. I set the architectural boundaries and leave the implementation choices to the engineer.
We used to split features between front-end and back-end developers. With a coding agent on each side, each agent gets only part of the context. One engineer can now work across both layers, drawing on specialists’ input in the agent’s instructions and in code review. The engineer who owns the feature tells the agent what to deliver and how to check the result.
Giving the engineer room to revise a feature changes what my co-founder and I settle up front. He leads product. I’ll be thinking about how to make a system scale, and he’ll point out a simpler version that solves the same problem for the customer. We agree on the problem early and settle the choices that would be costly to revisit.
Say you choose Postgres for a feature and the way you’ve designed its tables becomes a bottleneck under load. Changing course used to mean writing migration scripts by hand and rewriting the code that used those tables. On a live service, a bad migration risks downtime or data corruption. You could save an hour in a meeting and pay for it with three days of development. Today, a coding agent can draft the scripts and handle much of the rewrite in hours. That gives teams more room to revisit a choice once they see how the feature behaves under load.
The cost of a late change used to shape interface design, too. When mockups took longer to produce, a missing field discovered during development could send a screen back through several rounds of design and coding. Now AI helps designers revise mockups faster, and developers get a working interface into customers’ hands sooner. Designers and engineers hear from customers about the screen they actually use, including whether it gives them the information they need.
A change needs wider agreement when it becomes someone else’s responsibility, too. For a database migration in production, the team that runs the service needs to plan the switch and verify the move. If a release creates ongoing work for another team, we bring them in before customers come to depend on it. In the cloud security software we build, even a limited release goes through mandatory security checks, and an engineer signs off on what goes live. When someone tells me Claude wrote the code, I remind them they own it.
When a planning meeting gets stuck on a detail, I ask what it would cost to change later and what we’d learn by trying it first. If a limited release can answer the question, we agree on who owns it, which customers will try it and when the teams will review the results. At the next meeting, I want product, design and engineering to bring back what customers did with the first version and decide together whether that changes what we build next.
Roman Labunsky is co-founder and CTO of Copperhelm
