What stays irreducibly human as AI does everything? Accountability, taste, and trust. A senior engineer on why judgment and ownership outlast automation.
A client once asked me, half-joking, whether he still needed my team now that he could "just ask the AI." I didn't get defensive. I opened the model, gave it his exact problem, and let it produce a genuinely good answer in about forty seconds. Then I asked him the only question that mattered: "Great — so who signs off on shipping this to your fifty thousand users on Friday?" The room went quiet. He wasn't paying me for the answer. He was paying me for the signature under it.
That's the whole essay. The machines are getting frighteningly good at producing the output. What they cannot do — not because the tech is immature, but for structural reasons a bigger model won't fix — is stand behind the output. As AI absorbs the measurable work, the durable human advantage stops being intelligence and becomes the small set of things that only matter because a human did them: accountability, taste, and the willingness to be blamed.
I've spent six-plus years shipping production software, most of it as the person whose name ends up on the release. So this isn't an abstract futurist take. It's what the job actually feels like from the inside now that a capable coding agent sits in the loop with me every single day.
For most of my career, the mental model was a comfortable one: humans do the thinking, computers do the typing. Write the logic, let the machine execute it. That model is dead. I now watch an agent read a stack trace, form a hypothesis, patch three files, and run the tests — the "thinking" part, the part I was told was safe.
So it's worth being honest about the shape of what's happening. The island of "things only humans can do" is shrinking, and it's shrinking from the inside, starting with the tasks we were proudest of. Not the grunt work. The clever work.
Here's the trap: most people defending human value are defending the wrong hill. They say "AI can't really be creative" or "AI can't truly understand." Those are claims about the machine's inner life, and they're both unfalsifiable and, frankly, losing arguments. Every year the "AI can't do X" list gets shorter, and every deletion makes the defenders look a little more like the people who insisted a computer would never beat a grandmaster.
I want to defend a different hill. Not "what can't the machine do?" but "what doesn't count unless a human does it?" That's a much stronger position, because it doesn't depend on any limitation of the technology. It depends on what the work is for. Capability is a moving line. Meaning is not. Anchor your value to the second one and the model's progress stops being a threat and starts being leverage.
Think about what accountability actually is. It's not knowledge. It's not skill. It's a person who can be held responsible — praised, sued, fired, trusted again next quarter. It's a name attached to an outcome, with consequences that flow back to that name.
A model has no name to attach and no skin in the game. You cannot fire it in any way that hurts. You cannot sue it. It has no reputation that a bad call damages and no future that a good call protects. When it's confidently wrong — and it will be, eloquently — the accountability doesn't evaporate. It rolls straight downhill to the nearest human. Usually you.
This isn't a temporary gap that scale closes. It's structural. Accountability requires a subject that persists through time and bears consequences. That's the thing we mean by a person. You can bolt an audit log onto an AI, but the log doesn't feel the weight of being wrong, doesn't lose sleep, doesn't change its behavior next time because its neck is on the line. It records; it does not answer for anything.
I felt this hard on a payments integration a while back. The AI-generated code was clean, idiomatic, and passed review. It also had a subtle rounding assumption that would have quietly under-charged on a fraction of transactions. The model didn't catch it. I caught it, at 11pm, because I was the one who'd have to explain the shortfall to the client — and that specific dread, the "this lands on me" feeling, is a piece of cognitive equipment the machine simply does not run. Being on the hook makes you look harder. It's not a bug in humans. It's the job.
Money bugs are the cleanest example, but the pattern is everywhere the stakes are real: a migration that silently drops a column, an auth check that's almost right, a retry loop that hammers a downstream service under load. The model produces plausible code for all of these. Plausible is exactly the failure mode that gets past review, because it looks like the correct thing. Someone has to be paranoid on purpose, and paranoia is downstream of ownership.
The practical version, the thing I now tell my team:
If you're building a team or a process around AI, encode that last point. Let the machine widen throughput; keep a named human on the hook for every irreversible action. That's not distrust of the tool. It's the only design where trust is even possible.
Taste is the second irreducible. And I mean something specific by it, not "having good aesthetics."
Taste is judgment under ambiguity — knowing which of ten technically-correct options is the right one here, for these users, given this messy context that was never written down. It's the API you don't build. The feature you kill. The abstraction you refuse because you can smell that it'll rot in six months. It's choosing the boring solution when the clever one is right there, tempting you.
Models are trained on the average of what exists. That's their nature and their strength — they regress beautifully toward the mean of everything they've seen. But taste is almost the opposite of the average. Taste is a considered deviation from the average, made on purpose, because you understand the specific situation better than the general case does.
Ask a model to design a data schema and it will give you something reasonable — the mean of a million schemas. Here's the kind of thing you'll get for "store user notifications":
CREATE TABLE notifications ( id BIGSERIAL PRIMARY KEY, user_id BIGINT NOT NULL REFERENCES users(id), type VARCHAR(50) NOT NULL, payload JSONB NOT NULL, read_at TIMESTAMPTZ, created_at TIMESTAMPTZ NOT NULL DEFAULT now());
Perfectly fine. Textbook, even. But should this even be a relational table? If you know reads outnumber writes forty to one on one exact screen and notifications expire after thirty days, maybe this is a capped, denormalized document keyed by user, or a Firestore subcollection you page through directly, and the "correct" normalized table is quietly the wrong call. Should you index (user_id, read_at) because the only query that ever runs is "unread for this user"? Should you not build the flexible type/payload version at all, because you know — from being in the room — that the "future notification types" the client mentioned will never actually ship?
None of that is in the training data. It's in the context that lives in your head and refuses to be typed out. The model optimizes the query you asked. Taste is knowing which query to ask, and when the honest answer is "don't build this."
A few taste calls I'd stake real money on, and no model would make unprompted:
Here's the uncomfortable part for people who think taste is safe forever: models are getting tasteful-adjacent, because good taste leaves traces you can imitate. Prompt one well and it'll suggest the boring, sensible option surprisingly often. But imitated taste breaks exactly when it matters — on the genuinely novel call, the one with no precedent, where you have to choose rather than retrieve. That gap is narrow and it's real, and it happens to be where all the value lives.
We keep talking about AI as a producer of outputs. But most of what senior people actually sell isn't an output. It's trust — and trust is a relationship that accrues over time, not a thing you can generate on demand.
When a client hands me a hard, high-stakes decision, they're not buying my keystrokes. They're cashing in years of watching me be roughly right, own my mistakes, and not disappear when it got hard. That balance was built one kept promise at a time. A model starts every conversation at zero, and worse, it starts fresh — it has no memory of the promise it made you last week and no stake in keeping it. Even with a context window stuffed full of history, there's no self on the other side that the history is happening to.
I think this reframes the whole "will AI replace me" panic. If your value is a transaction — one input, one output, no relationship — then yes, you're exposed, and you should be planning your move. But if your value is a relationship that compounds, the machine can be the fastest, cheapest labor in the world and still not touch the core of what you do. It can write the code. It can't be the person the client calls at 2am when it's on fire. Trust doesn't fork, and it doesn't transfer to whatever produced the diff.
There's a specific sentence that captures the irreducible thing, and I've started listening for it. It's when someone stops hedging and says: "I'll stake my name on this."
That sentence does something no amount of computation can. It converts a probabilistic answer into a personal guarantee. It says: I have looked at this, I understand the stakes, and I am voluntarily putting my reputation on the line so that you don't have to carry the risk alone.
An AI cannot make that move, and not because it lacks confidence — it has far too much of that. It can't stake a name because it has no name to lose. Its "confidence" is a number, a softmax over tokens. A human's confidence, when it's the real kind, is a wager against their own future. Those are not the same object wearing different clothes; they are different in kind.
This is, quietly, most of what senior engineering is. Juniors produce code. Seniors produce judgment calls they'll be held to. The market has always paid a premium for the person willing to say "ship it, on me" — and that premium is about to go up, not down, because the supply of raw answers is going to infinity while the supply of people who'll genuinely stand behind one stays exactly as scarce as it ever was.
Not everything that can be automated should be. Some human involvement isn't inefficiency to be optimized away — it's the entire point of the activity. Automating it doesn't make it cheaper; it makes it worthless.
A short list of things I refuse to fully hand off, on purpose:
The pattern: **automate the production, never the accountability.** The moment you let the machine own the part where a human is supposed to be on the hook, you haven't saved effort — you've removed the only thing that made the output trustworthy in the first place. This is a good design heuristic for any AI-in-the-loop workflow: draw the line at the point where a decision becomes irreversible or personal, and keep a human on the far side of it.
So what do you actually do with this, if you're an engineer watching the ground shift? I don't think the answer is to out-type the machine. You'll lose. The answer is to move up the stack, toward the parts that only count because you're the one doing them.
Concretely, this is where I'm putting my own energy and steering my team's:
The irony is that the more capable the machines get, the more human the top of the job becomes. When answers are abundant, the bottleneck moves to judgment, ownership, and trust — the things that were always the hardest part anyway. We just used to be able to hide them behind the labor. The labor is evaporating. What's left is the part that was always the actual job.