Who Takes Responsibility When AI Gets It Wrong?

The Question That Shows Up After Something Breaks

A business owner needs a feature shipped. A login system. A customer portal. A CRM integration. So they hand it to the project manager, or the most tech curious person on the team, with one instruction: use AI and move fast.

Nobody asks whether that person can set requirements, choose the right stack, run meaningful tests, or spot a security flaw in generated code. The feature ships. It looks fine in a demo. Then something fails. A breach. A performance collapse. The entire site goes down over a weekend.

Now the room gets quiet. Who takes responsibility?

Capability Is Not Accountability

When you assign development to someone who relies on AI for decisions they cannot evaluate, you have not adopted AI. You have outsourced judgment to a tool that does not sign contracts or answer emails at 2am.

AI in 2026 is extraordinarily capable. I use it daily. But the model generates plausible solutions. A qualified engineer determines whether those solutions are correct, secure, and maintainable. That is where responsibility lives.

Without that validation layer, you get quiet failures: requirements that were never testable, stacks chosen because they sounded modern, test files that nobody ran, security and performance that were assumed rather than verified. These are not AI problems. They are validation problems.

I Saw This Play Out a Few Months Ago

A client brought me in to review code that had been written entirely by AI. The person who built it had no technical background. The requirements and context had been set by someone with no software development experience either. The business logic was simple: save money by bringing in a software engineer only at the very end to verify the work.

Within two hours, I knew we were not reviewing our way to a solution. We were deciding how politely to start over.

The technical stack was wrong for the job, probably chosen without the right context. Performance optimisation alone would have taken days to fix within that stack, because it was never designed for the load. The core flow had logic gaps that did not match the requirements the project manager had defined. The conclusion was clear: rebuild from scratch, with the right stack, the right requirements, and the right context from day one.

The analyst who spent hours assembling that output had wasted their time. The business owner paid for it. And they were still paying the full rate for me to deliver the result they expected on the first run.

That is what the "bring in an engineer at the end" model actually costs. It is the same as building a house yourself, then calling a builder once the walls are up only to hear that the foundation was wrong from the start. Not a saving. A duplicate bill.

The Blame Game Nobody Wins

When things go wrong, the business owner says the project manager should have known their limits. The project manager says leadership chose the approach. Both are partly right. Both are avoiding the real issue.

If you assign a technical outcome to someone who cannot verify the work, you have accepted structural risk. You would not ask your finance manager to perform surgery because they are good with spreadsheets. But the person who accepts the task without the skills to deliver it also carries responsibility. Accepting a technical mandate you cannot evaluate is a gamble with someone else's revenue and customer data.

Both parties created an accountability vacuum. AI filled it with confident code.

The Answer Is Not AI or a Software Engineer

You are not choosing between AI and a software engineer. You are choosing between unaudited AI output with unclear ownership, and a software engineer who uses AI with clear accountability for what ships.

A qualified engineer treats AI as an accelerant, not an oracle. They set context, reject bad suggestions, run the tests that matter, and can sign their name to the result. Project managers excel at coordination and timelines. That division of labour is healthy. Blurring it because AI makes coding look easy is not.

Engineers who know how to work with AI in 2026 ship faster and more reliably than either AI alone or unskilled intermediaries. Their tooling is far more sophisticated than a browser tab and a prayer. You are not giving up speed by hiring expertise. You are concentrating it.

Three Questions Before You Start

Before anyone opens an AI chat window, ask:

1. Can this person explain why they chose this stack, not just that AI suggested it?
2. Can they define what "done" means in tests you would actually trust?
3. If production fails tonight, is this the person you want on the call?

If any answer is no, you do not have an AI strategy. You have unowned risk.

Staff for the Outcome You Want

When AI gets it wrong, responsibility lands on the people who chose how the work would be done. Business owners own who they assign. Project managers own the honesty to say when a mandate exceeds their expertise. Software engineers who use AI responsibly own the systems they deliver.

That is the path most likely to get it right the first time. Not because AI is unreliable, but because judgment still matters, and in 2026 the best judgment comes from engineers who have made AI part of their craft.

If you are planning a build and wondering who owns security, performance, and uptime in your current setup, that is worth a conversation. The goal is not less AI. It is AI in the hands of someone who can stand behind what it produces.