The Age of Responsibility: Introduction

A few weeks ago I talked with a colleague about something that’s starting to show up more often. Some companies are pushing the automation pretty far: AI writes the code, AI reviews it, AI decides what gets merged, and in a few places it even handles the deployment.

It’s an interesting direction. It’s also one I wouldn’t take all the way. At least not yet.

I’ve never worked in a fully AI-managed setup like that, and based on current experiences and quality assurance practices, even with good test beds in place, I wouldn’t allow it in anything I’m responsible for. We simply don’t know what the future will bring. The reason for my current stance is simple. No matter what tools we use, there still have to be people who own the outcome. The more you automate the chain, the easier it becomes for that ownership to get lost.

That’s the part that bothers me.

When things go wrong

When something actually breaks in production (real downtime, real money lost, clients losing trust) the question suddenly gets very practical. Who owns it? The person who built the workflow? The manager who said yes to this level of automation? The people who set up the tests and safety nets? Or has the whole process become so layered that it’s hard to point to anyone clearly?

I don’t think the basic rule has changed. Tools don’t take responsibility. People do. What has changed is how easy it is for that responsibility to fade into the background. When a lot of the steps are handled by systems, it becomes simpler for everyone to feel a little less accountable. You can always point to the process.

What well-designed systems reveal

I’ve been designing software systems for a long time. Every architectural decision usually has a reason behind it. I’m a strong believer in Domain-Driven Design and in the idea that real-life problems should be modeled properly, with clear contexts and boundaries in the code.

What I see daily is that when the codebase is already well structured, AI tends to produce cleaner and more understandable code. It often follows DDD practices surprisingly well, even when the original context wasn’t perfectly designed. It also adapts to the test beds you define, the ones that validate the actual business rules. In those conditions it can do a better job of following design guidelines than many humans do :D

Where the limits appear

The limitations become visible when the context grows. Rules start getting forgotten. Details that should stay consistent begin to drift. And this is usually the point where people introduce another agent to review the work, using the same guidelines and the same test beds. Then it’s easy to sit back and feel the task is done. The rules are defined. The tests are green. Profit.

Until you actually open the pull request.

Most of the time 90% of the generated code does what it is supposed to do. The tests pass. Everything looks fine. And then, occasionally, it isn’t. That final moment of looking at the change, understanding what it really does, and deciding to accept it is still the point where responsibility lives. That last human acknowledgment, the decision to say “yes, this can go in,” is what separates real ownership from the appearance of it.

The quieter cost

There’s also a quieter side to this. When you’re further away from the actual work, when you didn’t write most of the code and didn’t do most of the review, something shifts. The feeling that “this is mine” gets weaker. A lot of the care in engineering comes from that sense of authorship. When it’s reduced across too many steps, both the care and the ownership tend to drop.

We’ve seen lighter versions of this before. Outsourcing, heavy pipelines, layers of platforms. Each time the process got more efficient on paper, and each time companies later had to deal with the same problem: when no one feels full ownership, the system gets more fragile.

Drawing a line

One open question is whether the responsibility is just moving upward, toward the people who approved these setups in the first place. Maybe. It’s worth thinking about. What already seems clear is that the tools make it easier for accountability to disappear into the machinery.

I draw a fairly clear line here. Using AI as a strong assistant is fine. Handing over the critical decisions in the chain is not something I would take responsibility for. I still want people to be visible in the important places. Someone should feel the weight of the result.

This isn’t about rejecting better tools. The tools will keep improving. The harder part is making sure we don’t lose clear human ownership along the way. Because when things go wrong, people still look for a person who stands behind what happened. “The system decided” is not a good enough answer.

The Age of Responsibility

That’s what I want to look at in this series. I’m not against using AI. I think we should use it as much as we can, automate what can be automated, and integrate it well into our systems, our work, and even our daily life. The help it can provide is tremendous. But we must never forget the human touch, especially in the places where the consequences are real.

I’m calling it The Age of Responsibility.

Behind it sits a simple idea I keep coming back to: even when the tools get more powerful, the touch of human still has to mean something.