Javeed Ali explains how code ownership, human review and a clearer design handoff help teams maintain what they build with AI-assisted development.
Across my company, AI has become part of everyday work. Teams can move from an idea to something reviewable faster. In AI-assisted development, that progress is easy to see: more code arrives, prototypes take shape sooner, and work moves through the queue.
What takes longer to see is whether we can maintain what we shipped.
A feature can look finished today and become difficult to change six months from now. If the team cannot explain how it works, the time saved during construction becomes someone else's investigation. As Head of IT, I keep coming back to that gap between producing work and taking responsibility for it.
Two situations in our teams made the gap particularly clear: developers submitting code they did not fully understand, and designers handing over working HTML. Both raised the same practical question: who is responsible for turning this output into something we can safely maintain?
AI-assisted development needs code ownership
We encourage developers and DevOps engineers to use AI. Writing every line by hand is not the standard I care about. Understanding the code you submit is.
The difficulty starts when a developer can demonstrate that a feature works but cannot explain the decisions behind it. A successful demonstration leaves plenty unanswered. How does the code handle a failed request? Why was a new dependency needed? What happens when the assumptions change?
These are ordinary maintenance questions. AI-generated code still has to survive them.
Our rule is straightforward: the developer submitting production code is responsible for understanding it and supporting its maintenance. Code ownership does not mean one person has to maintain it forever. It means there is someone accountable for the change, with enough explanation for another developer to take over.
That distinction matters during code review. A reviewer approves a change against the team's standards; approval does not make the reviewer the new owner of every line. Equally, the author cannot hand responsibility to the tool that generated it.
Review tools support the process; ownership stays with the person submitting the code.
Four checks before a pull request is accepted
We use four gates to make that responsibility visible.
A linked task establishes the scope. Every pull request connects to an assigned task. Before reading the implementation, the lead should know what problem the change is supposed to solve. Extra work needs a reason, even if generating it took only a few seconds.
SonarQube checks defined quality conditions. Static analysis handles part of the repeatable checking. A quality gate evaluates the configured conditions; a pass is evidence about those conditions, not proof that the whole feature is correct. SonarQube documentation
Greptile adds an AI code review. We use it to look for potential bugs and departures from our conventions. Its custom rules support written review instructions, including project-specific expectations. The team still needs to evaluate the findings. Greptile documentation
A human lead makes the final review decision. Does the change fit the task? Can the author explain it? Are there unresolved questions that the automated checks did not settle? A green set of checks does not remove the need for that conversation.
If the author cannot walk through the change, the pull request goes back. That is a gap in the team's ability to maintain the feature, even when the demonstration looks convincing.
There is a cost here. These gates add review time, and developers initially pushed back. We accepted that trade because discovering a misunderstanding during review gives us a chance to address it before other work depends on it. I would rather discuss an unclear decision now than ask a different developer to reconstruct it months later.
The point is to spend review time where it changes the outcome. Repeating an automated warning adds little. Working through an assumption the author has not considered can be the most useful part of the review.
When the design-to-development handoff includes HTML
Our designers increasingly use AI to deliver working HTML alongside, or instead of, static Figma screens. I understand the appeal. An interaction that is awkward to describe in a handoff document can be much easier to demonstrate in a browser.
The question is what the team believes it has received.
A prototype can communicate the intended behaviour without being ready for production. Its value is that a developer can explore the interaction and ask better questions. We should not lose that benefit by insisting every conversation happen through static screens.
We should also avoid treating a working prototype as an already approved implementation.
For this handoff, we make the boundary explicit. The designer owns the intended experience and its presentation. The developer taking on implementation evaluates the HTML, decides which parts to reuse, and refactors or rewrites what is needed. The resulting production change goes through the same review process as other code.
The developer accepts implementation responsibility before the code is merged. That is different from merely clicking approve on someone else's pull request.
For me, this is a useful way to think about AI in UX design: the prototype makes the intended interaction easier to discuss, while the team remains responsible for how that interaction reaches the product. A convincing screen does not settle the implementation questions underneath it.
Our next step is to give designers direct access to our design system components. That should bring prototypes closer to the product's existing patterns. It remains a next step, and it does not remove the need for a developer to assess the implementation.
What I would measure beyond output
Counting completed tasks tells me how much work moved. To understand whether our approach is working, I would also look at what happens after release: how often changes need rework, whether another developer can take them over, and where maintenance stalls because nobody understands a decision.
These are proposed checks, not results I am claiming we have already measured. They would make a digital maturity assessment more useful than simply counting how many people have access to AI tools.
I would start small. Pick a recent AI-assisted change and ask the author to explain it with the person likely to maintain it next. The conversation will show where the explanation is clear and where the team is relying on an assumption.
More output is useful when the organisation can absorb it. For the teams I lead, that means a clear scope, a real review, and someone who can stand behind the production change. The question I want answered before we merge is simple: when this needs changing, will we know where to start?
Further reading
GitClear's analysis of about 153 million changed lines of code written between 2020 and 2023 found more copy-pasted code as coding assistants spread, and projected that the share of code reverted or rewritten soon after it was written would double in 2024 compared with 2021.
Google's 2024 DORA report on the state of DevOps associated greater AI adoption with an estimated 7.2 percent drop in delivery stability and a 1.5 percent drop in delivery throughput.
