The Engineer Who Owns the Outcome

Audio summary: a short spoken version of this post.

In an earlier post on the changing developer role, I described how AI shifts a developer’s work from writing code toward designing and validating systems. I still think that is right, but it leaves a harder question open: if a model can produce the code, sketch the architecture, and propose the workflow, what is the engineer responsible for?

My answer is not another skill for the list. It is responsibility for an outcome that matters: knowing which problem is worth solving, making the result trustworthy where it runs, and finding out whether it helped. Code is part of that work. It is not the result.

A fluent draft is not a better support process

Take a hypothetical support team considering AI-generated replies. A model that writes fluent drafts is a promising component. It is not evidence that support got better.

Someone still has to decide what information a reply may rely on, which policies apply, when a human must review it, how odd cases are handled, and how staff correct mistakes. Then someone has to find out whether it helped. Replies may be more accurate. Or the team may be sending more of them, faster, with the same errors.

These are not cleanup tasks for after implementation. They cross code, data, operating rules, and people, and together they decide whether the feature becomes a system people can use and trust. Ordinary software is no different: automate a step without knowing why it exists and you get an ineffective process that runs faster. “Can we build this?” is the easy question. “What should improve, for whom, and how would we know?” is the one that matters.

Designing the workflow is not the moat

It is tempting to say the human part is designing the workflow. I do not think that holds. Models can already propose steps, integrations, handoffs, and failure cases. Calling workflow design permanently beyond AI repeats the old mistake of equating engineering with typing code, one level up.

What a model cannot do is answer for the choice. A plausible design still has to be tested against a specific organization, its users, and the cost of being wrong. What can run automatically, and what must stay reviewable or reversible? Who approves the change, and who looks after it once the demo is over? Someone has to make those calls and change course when the evidence disagrees. That is responsibility, not design skill.

Trust is engineering work

Trust in an AI-enabled system does not come from a capable model. It comes from clear limits on what the system may do, checks suited to the risk, a way for people to inspect and correct its work, and a sensible response when it is uncertain or fails.

For one task, the right limit is a draft a person approves. For another, the system can act alone within a narrow, reversible scope. The choice depends on what an error costs, how good the checks are, and who lives with the result. This is not paperwork around the real engineering. It is the engineering. A demo that works once but cannot be checked, corrected, or operated is not finished.

Evidence is the other half of trust. Lines generated, agent steps completed, and impressive screenshots describe activity, not value. The measure has to follow the goal: fewer errors, faster turnaround, less repetitive work, or whatever the people affected care about. If I cannot say what evidence would show a change helped, I am not ready to call it done.

Responsibility is not the same as authority

“Own the outcome” can sound like asking one engineer to answer for everything. That is not what I mean. Engineers rarely control the policy, the staffing, or whether the organization adopts a change. Product owners, domain experts, operators, leaders, and users all shape whether it succeeds. Holding someone accountable for decisions they cannot make is not ownership. It is blame looking for a target.

So the line I draw is this. Within my authority, I own the quality of the system, the honesty of what we claim about it, and the evidence for whether it works. Beyond that authority, my job is to make risks and trade-offs visible to the people who can decide, and to say plainly when a decision is not mine to make. The organization owes the other half: explicit ownership, involvement from the people affected, and enough authority for whoever is accountable for a risk to address it. An engineer can make consequences legible. They cannot replace the organization around the system.

The case for craft

There is a fair objection here. If the job is outcomes and trust, does deep technical craft matter less? Is domain expertise just one input among many?

The objection gets something important right. Craft and domain knowledge are how anyone notices that generated output is plausible but wrong: code that passes the obvious tests and mishandles the case that matters, a shortcut that breaks a real constraint, a metric that improves while users get worse service. Without that expertise, owning the outcome is a promise nobody can keep, because the failures that matter look correct.

Where I differ is on what follows. Expertise does not matter less. It matters more when it is aimed at the whole outcome instead of measured by how much code it produces.

The question that stays

AI will change the mix of engineering work. Some implementation gets faster, some tasks disappear, new failure modes appear, and the balance will differ by team and domain. Under all of that is the question I want to be able to answer for any system I put my name to: did it make something that matters better, within limits people understand, and can I show it?

Getting a model to produce code does not answer that. It is where the question starts.