Your Customers Can Tell

I approved nine hundred lines of code in less than a minute.

The tests were green. The description was complete. The change touched files I did not know particularly well, but everything looked finished. I scrolled through the diff like a receipt I was never going to itemize, left two comments about naming that I barely believed mattered, clicked approve, and moved on.

Later, I tried to remember what I had approved.

I couldn’t.

A year ago I ended a talk called Meet My Virtual Engineer with a line I believed completely: AI does not care. We do.

I still believe it. I just had the mechanism wrong.

I thought the human at the end of the process was the safeguard. The model could generate the code, but a person would review it, exercise judgment, and care about what happened when the software reached a customer.

That assumes care survives regardless of how the work gets done.

Care has conditions, and software development used to force us to spend enough time with the work for that relationship to form.

You had to understand the problem because there was no implementation until you made one. You traced callers, opened surrounding files, found the thing the ticket had failed to mention, wrote the obvious solution, discovered why it failed, and stayed in the problem long enough for it to teach you something.

Then somebody else looked at what you had done.

One of my first pull requests at a new company was tiny. My manager left more than twenty comments on it. I had read all the advice. You are not your code. Review is about the work. Feedback is how we improve.

I still felt fucking stupid.

I was embarrassed. I wondered what my manager thought of me. I looked at this tiny change covered in comments and decided I was never putting up another pull request that needed that many fucking cycles again.

So the next time I looked harder before I opened one. I checked the surrounding code before somebody had to tell me to. I anticipated the questions. I thought more carefully about the naming, the tests, the assumptions I had made, and whether the thing I was asking another person to review was actually ready for them.

Over time, fewer comments came back. Eventually I became the person leaving them.

We call that judgment now, as though it simply appeared with seniority. A lot of it is accumulated embarrassment: the thing somebody caught that you should have caught, the system you misunderstood with complete confidence, the production incident that permanently changed the way you looked at a certain kind of decision.

Say “time zones” to any developer who has ever touched scheduling code and watch them flinch.

Those moments stay with you because you were invested enough for them to hurt, and because they hurt, they changed the next decision. By the time something shipped, you had lived with it. You had made decisions inside it, changed your mind, defended choices, been corrected, learned the edges of the system. If it broke, the failure reached you through work you recognized as yours.

That investment trained judgment. It also produced care.

You are not your code. Your worth as a person does not depend on whether a reviewer finds twenty things wrong with your pull request.

But your code should mean something to you.

There was value in caring that you had put sloppy work in front of people you respected, in the embarrassment of discovering that your judgment was weaker than you thought, in wanting to do better next time before anybody had to put “quality” on a dashboard and tell you to care more.

We treated much of the process that produced that investment as friction, then got very good at removing it.

We reduced the time between problem and implementation, implementation and test, test and review, review and merge. We automated the mechanical work, shortened cycle times, pushed review queues along, and celebrated the ability to move more work through the same number of people.

Then AI arrived and gave that instinct a rocket engine.

Now I can ask for an implementation and get the tests with it, have the failures fixed, the surrounding code adjusted, and the pull request description written before I have spent enough time inside the problem for the result to feel like mine. I can start another change while that one finishes.

That is an extraordinary capability. It also means I can produce work faster than I can become invested in it.

I can see the difference in my own code. There are lines I wrote years ago that I can still recognize almost immediately. Sometimes it is a method. Sometimes it is nothing more than an if or an unless buried in a file I have not touched in years.

There is no stylistic signature hiding in the syntax. Another developer could have written the exact same line. I recognize it because I remember the fight that produced it. I remember the failing test, the edge case, the reason the obvious version did not work.

I remember being there.

Now I can put my name on a commit and fail to recognize the code an hour later.

And somehow we have decided the answer to that is: your name is still on it. You are still accountable.

Your name was always on it. The name mattered because there was a person behind it who had lived through the decision. The signature pointed to judgment that had actually been exercised, mistakes that had actually been made, questions that had actually been answered.

We are keeping the signature while removing more and more of the experience behind it, then calling that ownership.

If you routinely ship work you do not deeply understand, stop congratulating yourself for caring about the customer.

I approved the pull request. I barely understood it. I knew I had not really held nine hundred lines in my head, and I clicked approve anyway.

That is getting the work out of my queue, not customer obsession.

If the change breaks, the customer does not receive my intentions. They do not receive the fact that I am usually careful, my throughput, my AI leverage, or the explanation that every check was green.

They receive the software.

Developers know when this is happening. We know when we have actually reviewed something and when we have performed the motions of review. We know when we understand a change and when we are trusting the shape of it. We know when “looks good to me” means I believe this is good and when it means nothing looked wrong quickly enough to make me stop.

And we click approve anyway.

Then managers reward the behavior.

Keep the queue moving. Reduce cycle time. Carry more. Use AI to increase leverage. Get more output from the same team. Engineering leaders put the numbers on dashboards and celebrate when they move in the right direction. The organization gets faster. The graph improves. We tell ourselves we have removed waste.

Then quality slips and everyone suddenly rediscovers the language of ownership. Review more carefully. Take accountability. Your name is on the commit.

Fuck that.

You built a system that rewards people for spending less time with each decision and then moralized at them when they stopped feeling attached to the decisions. You asked for distance and called the result productivity. Now you want intimacy on demand.

You want senior judgment while removing the experiences that produce senior judgment. You want engineers to own more surface area while caring about every part of it with the same depth. You want people to feel when something is wrong while rewarding them for moving on before that feeling has time to form.

And then you call the company customer obsessed.

A company that says “customer first” while optimizing engineering almost entirely around output is asking the customer to absorb the difference between its values and its incentives.

That difference has to land somewhere.

A practitioner opens a scheduling screen with a patient sitting in front of her. It does not load. She refreshes, tries another computer, gets the same error, and watches twenty minutes disappear while the rest of the clinic day compresses behind them.

Eventually somebody in engineering will fix it. Maybe the change that caused it has my name on it. I may not remember the change.

She will remember the twenty minutes.

Support will remember because they have answered the same problem four times this week. The customer will remember the workaround because tomorrow they have to use the product again.

The cost of bad software did not disappear when we made development faster. We moved it away from the people with the greatest ability to prevent it.

The engineer saved the hour they might have spent understanding the edge case. The reviewer cleared the queue. The team shipped more. The organization recorded the productivity gain. Meanwhile, the practitioner waited, support answered, and the customer learned which part of the product not to trust.

The expense stays with the ones who cannot fix it.

And then we have the nerve to say the customer comes first.

Care for the customer has to travel through care for the work. There is no values statement strong enough to bypass that mechanism.

The customer will never see the test we trusted too quickly, the pull request we skimmed, the strange condition we decided was probably fine, or the moment somebody noticed something felt wrong and kept moving because three other reviews were waiting. They experience the accumulated result.

Every time somebody upstream cares enough to stop, look again, ask the annoying question, admit they do not understand the change, or risk feeling stupid in front of a colleague, the customer gets the benefit without ever knowing it happened.

That is what care looks like before it reaches them.

It requires density: enough contact with the work for investment to form, enough contact with other people for judgment to be tested, and enough contact with consequences for mistakes to stay with you.

We have been thinning that density for years and congratulating ourselves every time the graph moved faster.

AI gives us the ability to thin it almost completely. A person can now technically author, review, approve, and own work they barely experienced.

So “AI does not care. We do.” does not comfort me the way it used to.

It is a requirement we are making harder to satisfy.

We confused the removal of friction with the removal of waste. Some of what we removed deserved to go. Some of it was mechanical bullshit that should have been automated years ago. But some of it was where judgment was being trained, investment was forming, and care was becoming real enough to affect what eventually reached the customer.

If we cannot tell the difference, are we going to keep optimizing until the only person left with a meaningful relationship to the quality of our software is the person trapped using it?

And then ask them how likely they are to recommend us to a friend?