Why I'm More Excited Now Than at Any Point in My Career

In 2004 I spent most of a March writing a load routine.

It moved order data out of a source system into a warehouse at a semiconductor company in Austin. It ran nightly. When it worked, roughly forty people got a report on Monday morning that they had previously assembled by hand from four extracts. I was proud of it, and I should have been — it was careful work and it held up for years.

It also took a month of my life to save forty people about ninety minutes a week.

I think about that ratio more than I expected to. It was not a bad trade in 2004; it was the going rate. The whole discipline was built around it. You spent months building a pipe so that information could reach the people who needed it slightly sooner and slightly more reliably than before, and the frontier of ambition was getting the right number in front of the right person.

That was the job for twenty-two years. Five platform generations, one accountability boundary that never moved: the machine informs, the person decides, the person is accountable.

The morning that changed

The first time I watched an agent close a loop end to end, I had the same feeling I remember from seeing HANA return a query I expected to take four minutes.

It was an invoice exception — genuinely mundane, the kind of thing that flows through a shared services team a few thousand times a month. The agent read the invoice, retrieved the purchase order and the receipt, identified that the discrepancy was a freight line billed against a term the contract did not carry, drafted the exception, routed it, and stopped at the threshold it had been given because the amount was above the band where it was allowed to act alone.

Eleven seconds, roughly. But that is not what struck me.

What struck me is that it had done the reasoning part. Not the retrieval — we have been good at retrieval since the warehouse era. The step where a human looks at three documents that disagree and works out which one is wrong and why. That step had been, for my entire career, categorically the human’s. Everything I had ever built existed to deliver information up to that step and then get out of the way.

I have been in this industry long enough to distrust my own excitement. So I sat with it for a few weeks before I said anything to anyone. And the conclusion I came to is that this is not a faster pipe. The frontier moved. We are no longer only in the business of getting the right number in front of the right person. We are in the business of designing systems that participate in decisions — which means the interesting questions have shifted from can it be computed to should it act, within what bounds, answerable to whom.

Those are much better questions. They are also questions where eighteen years of watching enterprise programmes fail turns out to be unusually useful, which I will admit is part of why I find the moment so energising.

Why the work got more human, not less

The assumption I hear most often, usually from people outside the delivery side, is that this makes the job more technical and less human.

My experience is the exact opposite, and I think it is the most under-appreciated thing about this shift.

When the constraint was technical, the conversations were technical. I spent 2004 to about 2016 in rooms discussing extract windows, aggregation strategies, cube design, memory footprints. Real craft, genuinely satisfying, and largely a conversation between engineers.

Now the constraint is trust, and trust is not a technical property. The conversations that decide whether an agentic use case reaches production are about accountability, about which named person reviews which class of decision, about what the honest worst case is, about whether the process being automated should exist in its current form at all. I spend more of my week talking to process owners, controllers, and risk officers than I ever did as an architect — and those conversations are harder, more consequential, and considerably more interesting than cube design.

There is a particular version of this I have come to enjoy. Someone in accounts payable who has done the same reconciliation for nine years knows things about that process that are written down nowhere. In the old model, that knowledge was an obstacle to requirements gathering. In the new model, it is the specification. She is the only person who can tell you which exceptions actually matter and which ones the system should never touch. The work has moved toward her, not away from her.

The part that worries me

I would not trust this essay if it did not include this section, and I do not entirely trust people who write about this moment without one.

Here is my concern, and it is not the one usually raised. I am not especially worried about agents taking actions they should not — that is a solvable engineering and governance problem, and it is exactly the problem I spend my time on. I am worried about how people get good at this work in the first place.

I learned judgement by doing the boring version. Reconciling things by hand. Writing the load routine that took a month. Sitting with a controller while she explained why the number was wrong. The tedium was not incidental to the expertise; it was the apprenticeship. I developed a sense for when a number is suspicious by looking at thousands of numbers, most of them fine.

If the boring version is now handled by an agent, I genuinely do not know where the next generation acquires that instinct. The person reviewing the agent’s edge cases needs precisely the judgement that used to come from handling the routine cases — and they will not have handled any. This is not an argument for keeping work manual out of nostalgia. It is an unsolved problem, and I have not heard a convincing answer to it, including from myself. The best I have managed on my own teams is deliberately routing a sample of straightforward cases to people who do not need to see them, purely so they keep their eye in. That is a workaround, not a solution.

The second thing I watch for is subtler. When a system produces a confident, well-structured answer, the effort required to challenge it goes up. Not because people are lazy, but because disagreeing with something articulate is socially harder than disagreeing with a spreadsheet. I have seen review queues where the approval rate is suspiciously close to a hundred percent, and the honest reading is not that the agent is perfect.

Both of those are reasons to do the work more carefully. Neither is a reason to be less excited about it.

Where that leaves me

Eighteen years into a senior career in enterprise technology, I am having the most interesting stretch of it right now. I did not expect that. The conventional shape of this career is that the intellectually alive part happens early and the later part is management.

What actually happened is that the frontier moved to a place where my particular accumulation is worth more than it has ever been — because the hard part is no longer building the capability, it is landing it inside a real organisation with real accountability and real controls, and that is a problem I have watched fail in five different costumes.

The load routine I wrote in 2004 saved forty people ninety minutes a week. The work I did last quarter changed how a finance function handles a class of exception permanently, and it took less than a month. I do not think I have got four hundred times better. The leverage changed.

That is the whole reason I am still excited. Not that the technology is impressive — it is, but I have been impressed before. It is that this far in, the question got harder and more interesting at the same time, and there is quite a lot of work left to do.