AI Is Writing Code. But Who’s Responsible for What It Gets Wrong?

by

A recap of our recent Tech Talks for Health Tech with Layer 8 Security

Last week, Chariot Solutions joined forces with our partners at Layer 8 Security to host an evening of honest conversation about a pressing question for businesses. As AI takes on more of the work of writing software, who owns the consequences when something goes wrong?

Moderated by Jeff Lipson of Layer 8 Security, the panel featured Dan Costantino and Matt Winter, two practitioners with deep experience in software development and security. The audience included developers, security professionals, and health tech leaders, and the discussion was exactly what we hoped it would be: grounded, candid, and a little uncomfortable in the best way.

The 45% problem and what’s hiding underneath it

The conversation started with a sobering stat: recent research found that 45% of AI-generated code contains security flaws, and fewer than half of developers review it before it ships. Does that feel accurate to people actually working in the field?

Matt Winter’s take: AI is roughly as reliable as talking to another human, which means it has flaws. The challenge isn’t the AI itself, it’s the speed at which decisions are being made and code is being shipped. We’re building fast. Are we governing fast enough?

Dan Costantino added a nuance worth sitting with that AI-generated code tends to look clean. Rudimentary bugs may actually decrease. But architectural problems, the ones that are harder to spot and more expensive to fix, are where the real risk lives.

Shipping fast vs. shipping safe

In health tech, this tension has higher stakes than almost anywhere else. A bug isn’t just a downed site,  it’s a potential HIPAA violation or a patient safety risk. So is AI too risky for core medical software right now?

Not necessarily, but it demands more discipline. Matt framed it as a balance between the accelerator and the brake.  You can’t capture the gains of AI development on the front end without investing in governance on the back end. Testing has to give you confidence. The risk is too high for anything less.

Dan pointed to a structural shift that’s already underway: security teams need to shift left into the development process itself, not just auditing at the end. AI can actually help accelerate that.

Who’s accountable when something goes wrong?

This was one of the sharper moments of the evening. When an AI-generated flaw leads to a data breach in a hospital system, who owns it?

Dan’s view was it depends on how bad the incident is, but ultimately the responsibility sits with the business. If governance structures aren’t in place, that’s a leadership failure, not a technology failure. Matt agreed that the measurement and governance frameworks that exist should be the standard, and the tension between speed and safety isn’t a bug, it’s a feature of a healthy engineering culture.

Are we building the last generation of traditional developers?

One of the more thought-provoking threads of the night: if developers are spending less time writing code and more time auditing AI output, does that change what we need from them and what we need to teach?

Both panelists pushed back on the idea that coding skills are becoming obsolete. Dan made the case that tools like Claude Code in a developer’s hands will likely produce higher quality code overall, but architectural judgment still has to come from a human. Pattern recognition, knowing when something is wrong, making the call on structure aren’t skills AI replaces. They’re the skills that make AI useful.

Matt added that teams need to be intentional about building those skills, not assuming they’ll develop on their own.

The defender’s advantage — and its limits

On the question of whether AI gives attackers or defenders the upper hand, Dan offered a clear-eyed answer: security teams have a structural advantage, but an attacker only needs one path in. The teams that are going to stay ahead are the ones using AI aggressively on the defensive side and are not stuck in old workflows while attackers iterate freely.

Matt raised a longer-horizon concern, as compute gets faster, encryption standards that feel safe today may not hold. Staying ahead of that curve requires thinking further out than most organizations are comfortable with.

Where do we go from here?

Cautiously optimistic was how Matt closed, not apocalyptic, but clear-eyed. He’s expecting a significant incident in health tech. Healthcare data is a target. The organizations that treat AI governance as urgent now will be better positioned when that happens.

Dan landed in a similar place: the 45% stat is a growing pain, not a permanent condition, but only if the industry treats it with the seriousness it deserves. Ignore it, and the technical debt becomes insurmountable.