A Redistribution of Code Ownership
September 23, 2026
Imagine being an engineer who is never allowed to see or edit the code. You can only describe what you want to an agent and look at the resulting product. Every tweak, every fix, every “move that two pixels left” goes through an intermediary, and you wait to see whether it came out right. Oh and it can take hours, days, or even weeks to do the task.
That’s the situation product managers, designers, analysts, and everyone else who works alongside engineering has always been in. The intermediary was the engineer. It was necessary because of two axioms: writing code takes a long time, and only engineers can make changes to the codebase. These axioms are now going away, and that changes how cross-functional teams could work together.
How engineers work with each other now that coding agents are in the mix is its own topic. Here I want to focus on the people who work directly with engineering to get the thing built.
The old process
In the classic mode of product development (either agile or waterfall), product managers and designers think through a great deal ahead of time. They gather rough estimates, produce a thorough spec and a pixel-perfect design, get sign-off, and hand it to engineering. Engineering builds to the spec. As blockers and edge cases come up, the spec is updated. Once the product is ostensibly built, product, design, and QA use it for the first time and send back a list of fixes. Then it launches.
All that up-front articulation existed because the build was a larger investment and the people paying for it wanted to know what they were getting before they committed. It was also the main lever non-engineers had. If you couldn’t touch the code, the source-of-truth spec and iterative feedback was how you steered.
The new process
With agentic coding, the collaboration I’ve been trying looks more like this:
- Estimates are cheap. Agents do the bulk of the estimation work. Engineers still sign off and own these estimates.
- Specs and designs are rougher. Only the critical aspects of the project are laid out. Nothing needs to be pixel-perfect or specified to every detail. New products can be very vague. I had one spec where pages were just a name and no other details.
- The engineer builds the first draft. They follow the details that are in the spec closely, since those were the details important enough to write about, and defer to the agent on everything else. Their attention goes more toward making sure the thing is built well.
- Partners polish the product. Once the feature, data model, API, and rough frontend exist, the PM or designer runs the branch in their dev environment and vibe-codes their own tweaks with an agent. Mostly they adjust the front end and change minor decisions the agent made.
- Engineering reviews and merges. PRs from PMs and designers get polished by engineering (or an engineering-owned agent) as needed and merged into the codebase.
The payoff is that nobody has to hold the whole vision in their head and transfer it losslessly to someone else in an expensive game of telephone. Partners decide many of the details of what they want by playing around with an early build rather than by exhaustively imagining it. Engineers aren’t the bottleneck for changes to layout, copy, color, or even the composition of a page. And when a change is small, a PR is a more precise way to communicate it than a conversation at standup or DM. The partner directly gets it looking and behaving how they want, and the engineer ensures the product is reliable, performant, and maintainable. For both, time is saved through a better distrubution of responsibility.
How it has gone so far
I’ve worked this way with a couple of PMs, both additionally wearing the designer hat, and it's served us well. The changes they made were small, because I’d gotten the product most of the way there, and that’s the point: the small changes are exactly the ones where an engineer in the middle adds the least and the communication overhead can overwhelm the value. Their PRs told me precisely what they wanted in a way a Slack thread never quite does.
It was particularly exciting when a small front-end-only feature one of the PMs had added on their own was helpful in the middle of an incident. Nobody had scheduled or estimated it, and it was there when it mattered because a customer had asked for it and the PM had been able to just make it happen.
That's a couple of people on one team making small changes to product, so take it for what it is. But in my experience this mode of collaboration is promising.
Beyond PMs and designers
I think the same shift applies to a good number of other partners. Analysts adding product events, QA fixing the bugs they find, copy editors fixing text. These changes are small enough that the cost of getting an engineer's time and describing the change to them is greater than the cost of just making the change, checking it works, and having engineering review the result. The mode of communication becomes PR contributions.
What has to be true
This only works if a couple of things are in place.
The codebase has to be ready (enough) for it. A non-technical contributor prompting an agent inside your codebase is a stress test for everything I wrote about in my last post. If the stack isn’t opinionated, patterns aren’t adhered to consistently, or the agent has to apply band-aids to deliver results, then things get messy. The worse the codebase is, the more time is wasted for both parties. A clean, agentic stack constrains the agent regardless of who is driving it, and that is what makes non-engineer PRs quick to build, cost-effective to review, and safe to accept. It also means the dev environment has to be one-command to start, with every integration mocked so no sensitive keys are needed. Dev environments must not be able to touch production in any way.
The people involved need to be amenable to it. A setup like this can easily rub people the wrong way. Having to clean up code generated by colleagues is not the greatest developer experience, even if it saves time. It shifts the engineer's job toward the platform and the review, and it makes tooling that keeps review cheap matter more, not less. And taking on both the power and the responsibility of making direct changes to the product can be exciting for some partners and disconcerting for others. This won't work for everyone, and it won't work if everyone involved isn't committed. It's a big shift in who does what and that can be understandably off-putting.
If you want to try this, improve your odds of it working by focusing on these two things. Invest in the codebase and the shared agentic tooling so that informally generated changes come out reasonable by making the easy way the right way. Find the people who are curious. Fund and provision dev environments for them. Expect some trial and error. It’s a process to overhaul a process.
Ownership
What I’m proposing is that every function gets the kind of direct access to their piece of the product that engineers have historically owned out of necessity, not necessarily because it made sense. It feels a bit silly for me as an engineer to take a change request from a partner and then just copy-paste that request into an agent and then pass back the result. I add little if anything to the process, and I don't have as crisp a vision of what the person wants to see from this change. It's just a holdover from when things worked differently.
I'd rather go toward a model of ownership and collaboration that is distributed a little more evenly. It's a better working arrangement.