Your Product Manager Just Opened a Pull Request. Who Owns the Code Now?
Half of designers now say they have shipped AI-generated code to production, LinkedIn has replaced its APM programme with an Associate Product Builder track, and coding agents have made 'I'll just build it myself' a realistic sentence for anyone with a terminal. The code is arriving. The ownership model, review capacity and guardrails mostly are not.
The New Contributors in Your Repository
For most of software history, the line between people who decide what to build and people who build it was enforced by skill. A product manager could write a specification, a designer could produce a Figma file, but turning either into running code required an engineer. In 2026 that line is no longer enforced by anything except habit and policy, and in many companies neither has caught up.
The numbers are now large enough to be a planning fact rather than an anecdote. Designer Fund's AI in Design 2026 report, based on a survey of more than 900 designers in over 60 countries, found that 50% of respondents across product and brand design have shipped AI-generated code to production. Not only design engineers, but ordinary product designers. The same report found that leaders and managers ship code as much as individual contributors, and that 65% of designers say they are taking on more product or engineering responsibilities.
A second dataset points the same way. The UX Tools State of Prototyping survey for spring 2026, with 1,478 respondents collected between March 14 and April 6, found that 43.8% of designers and builders spend more than half of their building time on AI-generated code, and that 38.4% use Claude Code every week. Among design engineers, the figure for majority AI-generated building time reaches 80.9%. Among individual-contributor designers it is 35.0%, which is lower but hardly marginal.
Product managers are following the same path, and in some companies the job title itself has changed. LinkedIn has replaced its entry-level product management track with an Associate Product Builder programme, which leads into a Full Stack Builder role that combines product, design and engineering work in one person. Whatever you think of the label, the signal to the industry is clear: the expectation for product people is shifting from describing software to producing it.
Why This Happened So Fast
Three things changed at once. The first is capability. Terminal-based coding agents can now read a repository, plan a change across several files, run the tests and open a pull request. The entry cost for a non-engineer is no longer learning a language; it is learning to describe a change precisely and judge whether the result looks right. For many product managers, that is the job they already do.
The second is access. GitHub's Octoverse 2025 report recorded more than 36 million new developers joining the platform in a year, more than one per second, and linked the surge to the release of a free Copilot tier in late 2024. The same report counted 43.2 million pull requests merged per month on average, up 23% year on year. A meaningful share of those new accounts belong to people who would never have called themselves developers two years ago.
The third is permission from the top. AI companies have been open about how their own non-engineering staff build software. Anthropic's write-up of how its internal teams use Claude Code describes a legal team building prototype phone tree systems to route colleagues to the right lawyer, a growth marketing team generating hundreds of ad variations in minutes instead of hours, and data scientists without TypeScript experience building complete React applications to visualise model performance. When the toolmakers publish stories like these, every executive who reads them asks why their own product team still waits two sprints for a button change.
None of this is a fad, and trying to stop it is a losing position. A product manager who can validate an idea with a working prototype on Tuesday afternoon, instead of a specification reviewed the following week, will produce better specifications and kill bad ideas sooner. The question for engineering leaders is not whether non-engineers will touch the codebase. It is which parts they should touch, how their work reaches production, and who answers for it afterwards.
What Actually Goes Wrong
The obvious risk is security, and the evidence is not reassuring. Veracode's GenAI Code Security Report tested more than 100 language models on 80 coding tasks and found that the generated code introduced an OWASP Top 10 vulnerability in 45% of cases. The models failed to defend against cross-site scripting in 86% of relevant tasks, Java had a failure rate above 70%, and larger models did not perform meaningfully better than smaller ones. An experienced engineer reviewing that output will catch some of those problems. A product manager who has never heard of log injection will not.
The clearest real-world example came from the app-builder market. In 2025 a researcher scanned projects from Lovable's public showcase and, as Superblocks' breakdown of the incident describes, found 170 apps with 303 endpoints whose Supabase tables could be read or written with nothing more than the public key, because row-level security had never been switched on. The issue was recorded as CVE-2025-48757. The builders of those apps were, for the most part, exactly the kind of motivated non-engineers this article is about. The tool generated something that worked. Nobody involved knew what a missing access policy looks like.
The less obvious risks are structural, and in an established product they matter more. An agent asked to add a discount banner may implement its own price calculation instead of calling the existing pricing service, and now you have two sources of truth that will drift apart. A designer's change to a shared component may pass visual review on the screen they were looking at and break three others. A product manager's quick database change may work locally and lock a production table during migration. None of these is a security incident, and all of them are the kind of debt that quietly makes the next hundred changes slower.
Underneath all of it is a confidence gap. In the UX Tools survey, only 1.4% of respondents said they trust AI output for production with no oversight, which sounds healthy. But 8.1% said they ship it with minor tweaks, and the review the other respondents describe is their own review. A person can only check for the failure modes they know exist. We covered the same pattern in professional engineering teams in our article on why vibe-coded apps break in production. It does not go away when the author's job title changes. It gets worse.
Key Takeaways
- Generated code introduced an OWASP Top 10 flaw in 45% of tested tasks, and bigger models did not fix it
- CVE-2025-48757 exposed databases behind 170 apps because nobody switched on row-level security
- Structural damage such as duplicated business logic and unsafe migrations costs more over time than one-off bugs
- Self-review only catches the failure modes the reviewer already knows about
The Review Queue Absorbs the Bill
Here is the part that rarely makes it into the enthusiastic LinkedIn posts. Every pull request a product manager or designer opens is a pull request someone with engineering judgement has to read. If you increase the number of people producing code without increasing the capacity to review it, you have not removed a bottleneck. You have moved it to your most senior engineers and made it longer.
Review of non-engineer code is also more expensive per line than review of engineer code. The reviewer cannot assume the author considered error handling, concurrency, data migration or existing abstractions, so they have to check all of it. They often need to explain the problem rather than just flag it, because the author cannot fix what they do not understand. And the social dynamics are awkward: rejecting a pull request from the head of product is a different conversation from rejecting one from a peer.
This lands on teams that are already stretched. We wrote about how AI has doubled code output while verification capacity shrank, and the non-engineer wave adds a new stream on top of that. Automated review agents help with the routine findings, but the tools themselves are explicit that they are advisory. Claude Code's review feature, for example, posts findings as comments and a neutral check run, leaving the merge decision to a person. Somebody still has to decide.
The organisations that handle this well treat review capacity as a budget line, not an afterthought. They estimate how many non-engineer pull requests they expect per week, measure how long those reviews take, and staff for it. The ones that handle it badly discover the cost six months later, when the senior engineers who absorbed it are burned out and the codebase has three subtly different ways of formatting a currency.
Lanes, Not Gates: A Contribution Model That Works
The most useful idea we have seen teams adopt is to stop asking whether non-engineers can contribute, and start defining where. Not every part of a codebase carries the same risk. Changing marketing copy is not changing an authentication flow, and a policy that treats them the same will either block useful work or let dangerous work through.
A practical model has four lanes. The first is the sandbox: prototypes in isolated environments with synthetic data, where anyone can build anything and nothing touches production. The second is low-risk surfaces such as copy, styling through design tokens, feature flag configuration and content, where non-engineers can open pull requests that go through lightweight review. The third is product logic, where non-engineers can contribute but an engineer pairs on the change or owns the final version. The fourth is restricted: authentication, payments, permissions, data migrations, infrastructure and anything touching personal data, which stays engineering-only regardless of how confident the author or the agent is.
The lanes should be enforced by the repository, not by memory. Path-based ownership rules can require engineering approval for anything under the payments or auth directories. Branch protection can stop direct pushes. Preview environments let a designer see their change in context without anyone deploying it. The goal is that the safe thing is also the easy thing, so contributors do not need to remember a policy document to stay inside the lines.
Most importantly, a prototype is not a pull request. The best use of a product manager's agent-built prototype is often as an executable specification: proof that the idea works, a clear picture of the intended behaviour, and a set of edge cases discovered along the way. An engineer then builds the production version with the prototype as reference. That is still dramatically faster than the old flow of written spec, design review and first implementation, and it avoids merging code nobody fully understands.
| Lane | Typical changes | Who can author | What reaches production |
|---|---|---|---|
| Sandbox | Prototypes, experiments, internal demos | Anyone | Nothing; the prototype becomes a reference for engineering |
| Low-risk surfaces | Copy, design tokens, styling, content, flag configuration | PMs, designers, marketers | The change itself, after lightweight engineer review |
| Product logic | New UI flows, validation rules, non-critical features | Non-engineers paired with an engineer | Engineer-owned version, often rewritten from the draft |
| Restricted | Auth, payments, permissions, migrations, infrastructure, personal data | Engineers only | Engineer-authored code with full review and testing |
Make the Repository Safe to Contribute To
Lanes define where people may contribute. The second half of the work is making those areas hard to break, which is an engineering investment that pays off for every contributor, human or agent. Most of it is familiar platform work; the difference is that it is now urgent instead of nice to have.
Start with the defaults that would have prevented the Lovable-class failures. Row-level security and access policies should be on by default with a test that fails if a new table lacks one. Secret scanning should block commits, not just send alerts, a point we made in detail in our article on credential hygiene in the agent era. Dependency additions should require approval, because an agent asked to format a date will happily install a library to do it.
Next, give the agents the context engineers carry in their heads. Instruction files at the repository root can tell any coding agent which service owns pricing, which components are shared, and which directories are off-limits. We described this practice in our piece on turning institutional knowledge into agent skills. When a product manager's agent reads that file, it is far less likely to re-implement the discount logic, because it has been told where the existing one lives.
Finally, make the test suite the arbiter rather than the reviewer's intuition. Required checks for type safety, accessibility, visual regression on shared components and contract tests on internal APIs catch a large class of non-engineer mistakes before a human looks at them. That frees the human reviewer to focus on the questions automation cannot answer: is this the right abstraction, does it belong here, and will we regret it in six months?
Key Takeaways
- Secure defaults such as access policies on every table and blocking secret scanning remove whole classes of failure
- Agent instruction files tell every contributor's agent where shared logic lives and what is off-limits
- Required checks for types, accessibility, visual regression and contracts make review faster and fairer
- Path-based ownership and branch protection enforce the lanes without relying on anyone's memory
What Engineers Are For Now
If product managers and designers can produce working code, a reasonable executive question is what the engineers are for. The answer is not fewer engineers. It is engineers doing different work: owning architecture and the restricted lanes, building the guardrails that make everyone else productive, reviewing and hardening contributions, and staying accountable for what runs in production at three in the morning.
That is a real change in the role, and most organisations have not formalised it. Designer Fund found that only 28% of design leaders said their companies had formally updated evaluation, compensation or hiring for the new way of working. The engineering side is likely no better. If an engineer spends 40% of their week reviewing and coaching non-engineer contributions, but is still measured on features shipped, you have built an incentive to rubber-stamp.
Ownership needs to be explicit too. When a designer's change causes an incident, who is on call for it? In healthy teams the answer is the engineering team that approved and merged it, which is exactly why the engineering team must have the authority to say no or to rewrite. Accountability without authority is how review turns into a formality. Authority without capacity is how review turns into a queue nobody can clear.
There is also a talent-development angle that is easy to miss. Non-engineers who contribute code through a well-run process get better at it fast, and some of them become excellent technical product people. The UX Tools data showing much heavier AI coding use among design engineers than among other designers suggests this hybrid role is already forming. Engineering teams that teach, rather than just gatekeep, will grow those people and get better specifications as a side effect.
How a Dedicated Team Fits the Builder Model
Many of the companies where product managers and designers are shipping code most enthusiastically are also the ones with the leanest engineering teams, often because leadership assumed AI would reduce the need for engineers. That is precisely where the review queue, the production hardening and the guardrail work go unfunded. Adding builders without adding engineering ownership creates speed in the first quarter and debt in every quarter after.
At Stepto, we build dedicated development teams in Serbia that slot into this model as the engineering backbone. In practice that means senior engineers who own the restricted lanes, set up the guardrails described above, review and harden what product and design contribute, and turn validated prototypes into production systems. Because our teams work in a time zone that overlaps the full European day and the US East Coast morning, a product manager's pull request opened at 10am gets a real review the same day rather than the next.
We also help with the transition itself, which is where most of the value sits. That usually starts with a short assessment: mapping the codebase into lanes, writing the agent instruction files, putting secure defaults and required checks in place, and agreeing a review service level with the product organisation. It then continues as ongoing ownership of the engineering side. Clients who want to keep contributions flowing without hiring a large in-house platform team often find this the most cost-effective route, and our nearshore development model is built for exactly this kind of long-term collaboration.
The point is not to slow your builders down. It is to make sure the speed they have found does not turn into incidents, rewrites and a codebase no one wants to touch. If your product team is already opening pull requests, talk to us about putting the engineering ownership behind them.
Key Takeaways
- Lean engineering teams are where builder contributions most often go unreviewed and unhardened
- A dedicated team can own the restricted lanes, the guardrails and the review service level
- Time zone overlap with Europe and the US East Coast keeps reviews same-day
- Validated prototypes become executable specifications that engineers turn into production code
More People Can Write Code. Someone Still Has to Own It.
The arrival of product managers, designers and other non-engineers in the codebase is one of the most useful things AI has done for software teams. It shortens the distance between an idea and evidence about whether the idea works, and it makes specifications sharper. But code that reaches production is a liability as well as an asset, and agents have made it easy for people to create that liability without seeing it. Half of designers already ship AI-generated code; the companies that benefit will be the ones that respond with lanes instead of bans, guardrails built into the repository instead of rules in a wiki, and engineering capacity that is explicitly funded to review, harden and own what lands. If you want help building that engineering side, talk to Stepto about a dedicated team.
Building a team in Eastern Europe?
StepTo helps European and US companies build senior-led nearshore engineering teams in Serbia. Let's talk about what your next engagement could look like.
Start a conversationMore from StepTo on this topic
- Meta Tried 50 Engineers per Manager. Six Months Later It Asked for Managers Back.
Meta, Google, Amazon and Coinbase have all cut management layers on the theory that AI absorbs the coordination work managers used to do. The data on spans of control, review queues and engagement suggests the work did not disappear. It moved onto the remaining managers, senior engineers and executives. Here is what flattening actually does to an engineering organisation that runs on AI agents, and how to set a span of control that holds up.
- The Firmware Is the Cheap Part: What a Connected Product Actually Costs Once You Owe It Five Years of Updates
Your margin is consumed within months of shipping. Your security update obligation runs at least five years. The Cyber Resilience Act just made that asymmetry a legal requirement rather than a business choice.
- Your Agent Died at Step 41. It Had Already Charged the Customer.
Agents now run for hours, not seconds, and the runtimes they were deployed on assume a request finishes in milliseconds. The missing piece is not a better model, it is a state layer, and every major platform has now shipped one.
Written by
Igor GazivodaFounder & CEO · StepTo
Igor has 15+ years in software engineering and business development. He specializes in scaling engineering teams, nearshore strategy, and AI-driven product development. He holds a Master's in Computer Science from the University of Belgrade.
LinkedIn →