The build took nine days. The argument took two months.
The agent worked, in the sense that it ran and returned answers. Whether those answers were any good was a question nobody could settle, because settling it would have needed someone to write down, in advance, what a good answer was. Nobody had. So the review meetings turned into a contest of anecdotes. Someone brought a question it got wrong. Someone else brought three it got right. Both were true and neither moved the decision an inch.
That project is not unusual. It is the normal shape of an AI project that skipped a step.
The step everyone skips
When implementation was expensive, vague requirements were survivable. A senior engineer would start building, hit the ambiguity in week two, and come back with questions. The build doubled as the discovery. Slow, but it worked.
Implementation is not expensive any more. Decent tooling turns a loose brief into a working agent in days, which means the ambiguity never surfaces. It gets implemented instead. Confidently, at speed, in the wrong direction.
The failure mode has flipped. It used to be that you could not build the thing fast enough. Now you can build the wrong thing before anyone notices it is wrong.
What writing the scoring first costs you
On an AI engagement we now write the scoring before anything else. A rubric, meaning a plain statement of what a right answer looks like, specific enough that software can check it, plus an environment that can run the check. Then we build something to score.
This is unpopular for roughly ten days. It looks like process, and nobody wants to spend the opening fortnight of an exciting project writing definitions.
After those ten days it stops being close. Every change becomes measurable, so the arguments end. You are no longer asking whether the system feels better this week. You run the suite and read the number. Those two months of review meetings never happen, because there is nothing left to have opinions about.
The hard part is not the harness
Building eval infrastructure is about a week of engineering. Deciding what counts as correct is where the work actually lives, and it is not a technical problem.
We were brought into a natural language analytics rollout that executives had quietly stopped using. Everyone assumed retrieval: the system must be pulling the wrong data. It was not. Finance defined an active customer as one who had transacted in the last ninety days. Operations defined it as one with an open account. Both were defensible, both were in use, and the system answered accurately under whichever definition it happened to retrieve.
No model fixes that. Someone has to sit with both teams, get a decision made, and encode the decision. It is a governance conversation that happens to produce a technical artifact.
Which is the practical case for putting senior people on site rather than taking a specification away and coming back with software. You cannot write a rubric for a business you have not sat inside. An engineer who has never watched the operations team on a Tuesday does not know that Tuesday's number is always wrong because of when the batch runs, and will cheerfully encode that error into the ground truth.
Where reinforcement learning fits
Later than people want it to.
Every optimisation method needs a signal saying this answer beat that one. Reinforcement learning on the model, an automated loop tuning the workflow around it, take your pick. They all need a way to score. No rubric and no environment means no signal, which means you are not ready for any of it.
Almost every team that asks us about RL has neither. They want to skip to the part that sounds like frontier research, from a position where nobody can yet say whether the system works at all. Build the rubric. Ordinary iteration by good engineers then gets you most of what is available, and when that stops paying, automated optimisation has something real to climb. Do it the other way round and you are hillclimbing a hill nobody measured.
What this does to team size
Our delivery teams went from ten people to three. Writing the criteria down is a bigger part of that than any code generation.
Ten people were never ten people of output. Most of that headcount was coordination: keeping everyone current, re-deciding things already decided, reviewing work whose acceptance criteria lived in somebody's head. Put the criteria somewhere a machine can check them and a large amount of that stops being necessary.
The three who remain are doing the part that did not get cheaper.
If you are hiring for this
The job description changed and most postings have not caught up.
The question is no longer how much of this can you build. It is whether you can tell when it is working. Those are different people more often than anyone wants to admit. An engineer who can produce a working agent in a week is now common. One who can sit with your operations lead, extract what a correct answer actually is, notice that two departments disagree, get that resolved, and turn it into something a machine can score, is rare.
Something to try this week
Take the AI project your organisation is currently arguing about. Leave the model alone.
Write down twenty questions it should answer, with the correct answers beside them, agreed by the people who own the domain.
One of three things happens. The system turns out to be fine and the argument was about something else. Or it is wrong in a specific way you can now see and fix. Or, most often, your organisation cannot agree on what the correct answers are, which was the real problem all along and had nothing to do with AI.
Any of those beats another sprint of prompt tuning.
If this is the argument you are currently having, talk to one of our engineers. We build AI systems on Databricks, and we run our own company on the same architecture.