The Professional Standard: Why AI Doesn’t Change Who’s Accountable for Your Code

The contractor analogy

Imagine you hire a contractor to build your house. It looks exactly as specified, so you move in. First morning, you turn on the oven while the kettle is boiling and the electricity trips. An electrician comes out and tells you that all of the appliances are running on the same circuit, a basic wiring mistake.

You call the contractor. They agree it is a trivial error, but they point the finger at their subcontractors. Fast, cheap, should have known better.

That explanation is not acceptable. You hired a professional. You were not hiring them to manage a supply chain and pass on the blame when it fails. You were hiring them to own the internals; to make sure that what they handed over was sound, not just functional.

The same principle applies to software. Your clients are not hiring you to ship features. They are hiring you to take responsibility for everything that comes with those features. AI is a subcontractor. A very capable one. But the professional accountability stays with the team.

The professional ceiling

There is a point on the AI autonomy spectrum where something important shifts. Below that point, your team is using AI to work faster while maintaining genuine ownership of what it produces. Above it, ownership starts to blur. Reviews get rubber-stamped, dark code accumulates, and nobody can say with confidence whether the system is actually sound.

We call this the professional ceiling, the threshold beyond which you can no longer take full accountability for what you are delivering.

This is not an argument for slowing down. Quite the opposite. The goal is to use AI as aggressively as possible while staying below that ceiling. The teams that do this well move faster than those that do not, because they are not spending time unpicking problems that crept in unnoticed.

What crossing the ceiling looks like in practice

The Vinext project is a useful case study. An engineering manager at Cloudflare rewrote most of Next.js using AI in about a week. It was an impressive piece of work. The project passed over a thousand automated tests and had running production deployments.

When security researchers audited the code, they found cache poisoning vulnerabilities, authentication bypasses, and a file exposure bug that allowed users to access any file on the server. Every one of those issues was a design choice made by AI. Every one of them passed the existing test suite.

The tests were not wrong. They checked what they were designed to check. But nobody had taken ownership of the internals. The security assumptions, the trust boundaries, the things that a professional would have caught during a proper review. The AI delivered something functional. It did not deliver something sound.

Using AI within the professional ceiling

None of this means avoiding AI or treating it with suspicion. It means building the right habits around it. Smaller pull requests. Meaningful code reviews that go beyond rubber-stamping. Clear intent captured before AI starts writing, so that what gets produced is aligned to what was actually needed. And a culture where taking accountability for AI-generated code is treated as non-negotiable, not optional.

The developers and teams that will thrive in the next few years are not the ones moving fastest. They are the ones who have figured out how to move fast and own what they ship.

---

This post is the first in a four-part series based on our recent webinar on Agentic Software Development. Watch the full 49-minute session free

Want to discuss how this applies to your team? Eman is making time for a limited number of 30-minute conversations with engineering leaders working through these challenges. Register your interest here