Imagine taking delivery of a new customer portal. The forms work, the dashboard looks sharp and someone mentions that AI helped write parts of it.
Pretty cool. My next question would be the same if every line had been lovingly carved into stone: who understands this system well enough to look after it?
AI-assisted development does not remove software ownership. A business still needs someone accountable for how the product behaves, what information it can access and what happens when a useful feature becomes an unusually expensive misunderstanding.
Simon Willison’s October discussion of “vibe engineering” puts responsibility back into the conversation.1 That is a useful distinction. For a business owner, though, the practical test is the handover, not the label.
A hypothetical handover, with the awkward questions included
Say a service business commissions a portal where customers request work, staff prepare estimates and managers approve discounts. This is an illustrative example, not a client project.
The demonstration goes beautifully. A customer submits a request, an estimate appears and a manager clicks Approve. Everyone can enjoy that moment. Then we need to try a few things that nobody volunteered to do during the presentation.
Does it know who is allowed to do what?
What happens when a customer changes an address in the browser request to reference somebody else’s job? Can a staff account approve its own discount? Does an exported spreadsheet contain information that the screen correctly hides?
These are questions about the implementation and its permissions, not about how convincing the generated code looks. A responsible technical reviewer needs to follow the request through the application and establish where those rules are enforced.
A neat interface can make software feel more trustworthy than it has earned. It is the digital equivalent of putting a blazer on a raccoon. Strong presentation; further investigation advisable.
We build AI agents with clear jobs and sensible limits. See how.
Can the team explain a wrong result?
Suppose the estimate uses an old labor rate. The customer has already received it.
The handover should make it possible to trace which rate applied, how the calculation worked and whether the estimate can be corrected without quietly changing an accepted agreement. Acceptance criteria should cover these business consequences before launch.
Tests help show that agreed examples behave correctly. Review should also examine whether those examples represent the business properly. A passing test for the wrong discount rule is wonderfully consistent at being wrong.
What arrives besides the application?
The business needs access to its repository, hosting and relevant service accounts, with clear arrangements for credentials and permissions. It also needs understandable deployment instructions, a record of important configuration and a named route for support.
Those details affect whether another developer can maintain the product. “The AI knows” is not documentation. It is a remarkably optimistic succession plan.
If this was useful, try Developers can use AI and still check its homework.
Ownership should survive the original developer’s holiday
I would want a named person or team responsible for technical decisions, an agreed business owner who accepts the workflow, and a clear support arrangement after launch. Those responsibilities can sit with different people. The handoffs between them should be explicit.
Review effort should match the consequences. A decorative animation and a customer payment workflow deserve different levels of scrutiny. Changes involving money, permissions or sensitive records need appropriately qualified review and realistic checks before release.
If the product also contains an AI feature, such as a generated estimate explanation, that introduces a separate quality question. The team needs representative examples to assess whether the output is useful, accurate enough for its purpose and handled appropriately when uncertain. Reviewing AI-written application code does not automatically evaluate the behavior of an AI feature.
None of this requires treating AI as an unwelcome guest. It can be a useful development tool in capable hands. The important part is that those hands remain attached to someone who can explain the decisions.
Before signing off a portal, I would ask the maintenance team to walk through one correction and one deployment using the supplied handover material. That small exercise tells you much more than another flawless tour of the homepage.
Good software ownership should feel reassuringly ordinary. You know what you have, who can change it and whom to call. The code’s route into existence can be interesting. Your business still needs the keys.