AI Can Write the Code. But Who's Responsible for the Software?

AI Can Write the Code. But Who's Responsible for the Software?

AI coding tools are getting faster and more capable. Making sure they build the right software is another matter entirely.

Software developers have spent years chasing bugs. Now we have AI tools that promise to write the code, find the bugs, and fix them for us. It sounds wonderful. Unfortunately, somebody forgot to tell the bugs.

Anthropic's Claude Code provides a striking example. Its public GitHub repository listed 14,519 open issues on October 18, 2026. A snapshot from October 15 showed 9,723 open issues labeled as bugs.

Not every reported bug will prove to be a genuine or unique defect, and GitHub issue counts are not a scientific measure of software quality. Still, that's an awful lot of people telling a company that its AI coding tool isn't behaving as expected.

There's a certain irony in all this. We're building increasingly sophisticated software to help us build software, while discovering that the new software needs just as much engineering discipline as the old.

Perhaps the real problem isn't how quickly AI can write code. Perhaps it's how we're managing the process.

The difference between writing code and engineering software

After decades of software development, I've learned that writing the code is often the easy part. The difficult work involves understanding requirements, making architectural decisions, anticipating problems, and recognizing when an apparently reasonable solution is actually wrong.

AI is becoming remarkably good at implementation. Give it a clear task and sufficient context, and the results can be impressive. But AI can also misunderstand a requirement, make an unjustified assumption, or confidently implement something nobody asked for.

Worse, it can generate tests that confirm its own misunderstanding. Everything compiles. The tests pass. The AI congratulates itself. And somewhere down the road, an unfortunate developer discovers that the software does precisely what it was told to do, rather than what it was supposed to do.

This is why experienced software engineers remain essential. The industry is beginning to recognize that generating code and taking responsibility for software are two very different things.

But recognizing the problem is not the same as solving it.

The human-guided AI development challenge

I've been developing an experimental methodology called Alignment, my attempt to find a practical balance between AI autonomy and experienced human engineering judgment. The objective is to use AI throughout the software development lifecycle without surrendering control of requirements, architectural decisions, implementation boundaries, or verification. Just as importantly, the process must deliver genuine productivity gains rather than bury developers in additional work.

In one early experiment, an AI-generated implementation plan contained a subtle requirements error. The proposed solution looked perfectly reasonable and would probably have compiled. But it would have implemented the wrong behavior. We caught the mistake during human review, before writing the code.

That was encouraging. It demonstrated the value of human engineering judgment at the right point in the process.

Unfortunately, another problem soon became apparent.

We began adding instructions to prevent mistakes, documentation to preserve decisions, and verification steps to keep AI within agreed boundaries. Then we considered additional rules to make sure the AI remembered the original rules.

Before long, I was spending an alarming amount of time managing the methodology rather than developing software.

I had managed to create a system in which AI was supposed to save me time, provided I had enough time to supervise it.

There had to be a better way.

When the cure becomes worse than the disease

This is the challenge I'm now trying to address with Alignment.

Experienced developers need enough visibility and control to prevent AI from making costly mistakes. AI needs sufficient context to understand the project, its requirements, and its constraints. Decisions must survive between sessions, and important changes must be verified.

But none of this comes free.

Every additional instruction, approval, document, and verification step consumes time. Too little control invites mistakes. Too much control defeats the purpose of using AI.

Even the documentation itself can become a problem. An AI assistant that responds to a straightforward technical question with three pages of analysis isn't necessarily being helpful. Often, it's simply making the human's job harder.

The answer cannot be to keep adding more AI agents to supervise the agents we already have. That's an expensive way to create a management hierarchy in which nobody is entirely sure who's in charge.

The goal should be better software with less wasted effort, not an elaborate bureaucracy for supervising machines.

Finding that balance is what I'm trying to achieve with Alignment. The methodology uses local project context and a persistent knowledge base to help AI understand the requirements, architecture, and decisions that matter. It also explores lightweight ways to record changes and the evidence used to verify them, so there's a clear connection between what was requested, what was implemented, and what was actually tested.

The challenge is keeping all of this useful without allowing documentation and process management to become another full-time job.

It's still experimental. Some ideas have worked. Others have created exactly the overhead they were intended to prevent. That's part of the exercise, and I'd rather discover those problems now than publish another impressive-looking methodology that nobody wants to use.

One more problem for another day

There's another issue that troubles me about the industry's growing dependence on experienced software engineers.

If AI increasingly handles the work traditionally given to junior developers, companies may decide they don't need to hire as many of them. Yet those same companies will continue needing experienced engineers to supervise AI-generated software.

Where, exactly, are those experienced engineers supposed to come from?

Nobody starts their career with twenty years of experience. And those of us who already have it are eventually going to retire, change careers, or die. Preferably in that order, with a decent interval between the first and last.

That's a separate problem, and one the industry needs to think seriously about. We can't spend the next decade eliminating entry-level opportunities and then complain that nobody has enough experience.

I believe AI will transform software engineering, and I'm excited about what it makes possible. But the industry's obsession with generating code faster risks overlooking the much harder question of how we develop reliable software with these tools.

Experienced human judgment matters. So do clear requirements, durable project knowledge, effective verification, and a sensible division of responsibility between humans and AI.

The challenge is bringing those things together without making software development slower, more complicated, and more expensive than it needs to be.

That's the problem I'm exploring with Alignment. I'll share the methodology and what I've learned once the experiments are further along.

For now, I keep coming back to one simple thought.

AI can write the code. But somebody still has to engineer the software.