When Code Is Free, Verification Is Expensive
Writing the code used to be the slow part of my job, and everything else was scheduled around it. AI has made that part quick. Checking the results to verify they do what the business needs takes as long as it ever did, so finished-looking work now queues up in front of the people who can say whether it meets their request. This is where I’d expect a team’s schedule to break next.
The Check Passed
At many manufacturing companies, a production order can’t start on a given line until the operator tells the control program which raw materials were loaded, and the program checks that selection before accepting it. Every material in the recipe or bill of materials, or BOM, has to be covered by itself or an approved substitute, and the percentages need to total one hundred.
At the manufacturing company I worked for, the line program worked from its own setup, which a separate team maintained. The ERP, though, worked from the finished item’s BOM of record when the order was created. When a recipe changed, the change was first made in the ERP and the line’s item setup was changed later. This meant that for a while a new order carried the new recipe while the line still offered the old materials.
The operator picked from what was offered, the program accepted it, and the line ran normally. Each finished skid then went to the ERP, which checked the same selection against its own copy of the recipe and rejected the skid. Nobody at the line was told. The rejections turned up in the daily reconciliation, when somebody compared the skids the line had claimed against the skids that had posted, and the missing ones were entered by hand. It happened about once a month and generally involved fifteen skids, out of about ten thousand a month initially.
Nothing in that chain was broken. Each check compared the selection against a reference, and the two references had drifted apart. A check that passes tells me the work agrees with whatever it was checked against, and it can’t tell me whether that was the right thing to check against.
As we added more production capacity, we started seeing more discrepancies in our monthly inventory of raw material. The inventory clerks were also having to enter a growing number of manual skids as we nearly doubled our production. The team lead figured something was wrong in the system and enlisted me and my ERP programmer to track down what was stopping the ERP from accepting skids.
This led to discovering the differences between the ERP’s BOM and what the line setup was configured to produce. We traced it back to a disconnect between the departments responsible for making the changes. Our month of investigation resulted in a number of process changes which brought the issues down to a couple of skids a month caused by emergency BOM changes that can’t be avoided. Of the two checks in place, against the ERP BOM and the line setup, one passed successfully and one failed because they were checking different references.
The Checking Didn’t Get Faster
In “What Is a Developer for Now?” I said system knowledge used to be free, because you picked it up while building. A good share of the checking was free in the same way. A developer who spent two weeks writing a feature ran it dozens of times along the way, and the person who had asked for it had those two weeks to think about what they would look at when it arrived.
This is no longer the case. A new feature now arrives in an afternoon with four more behind it, and each one looks complete. A wrong one looks as finished as a right one, because AI will build a misunderstood request as fast and as clean as a correct one. The people who can say which is which are the same people working at the same speed: the developer reading code they didn’t write, the tester running the feature against what may be an outdated test suite, and the person in accounting or on the floor who has to try it against a real day’s work. Asking the tool to check its own work doesn’t shorten that process. It will write tests in seconds, and those tests tell me the code does what the code does.
In “Nobody Can Tell You What They Want” I wrote about the front of the job, which is finding out what is being asked for. This is the back of it, where somebody has to prove that what got built is that thing. The person who couldn’t fully say what they wanted beforehand is also the only one who can say whether they got it, and their afternoon is as short as it was last year.
Decide How You’ll Know
I decide what would constitute success before I generate anything. For the request in front of me, that means writing down what the person who asked will look at on the day it arrives, and what they will compare it to. If I can’t write that down, the code will show up in minutes and I’ll have nothing to hold it against.
I also want to know what every check is checked against. The check at the line compared against the line’s setup and the ERP compared against its own copy, and one of the proposed and implemented changes was comparing those two for every scheduled order, which catches the mismatch before the run. A failed check has to be loud on the day it fails. The rejected skids sat unseen until the next reconciliation, and by then the order that produced them had kept running.
The last practice is the one that costs something, which is generating only as fast as I can check. A stack of generated features that nobody has confirmed is a stack of guesses, and every one I add makes the confirming take longer. They bloat the code base and add to the tech debt for the application. More importantly, the knowledge debt around the application drastically increases. This encompasses the technical aspects, the business knowledge, requirements, and troubleshooting information about the application. This is quickly becoming more critical than tech debt now that coding is virtually free.
The amount of proof should follow the cost of being wrong. In the requirements article I asked what happens if this is wrong, and the answer to that question sets how much checking a thing deserves. A report that nobody acts on can ship on a read-through. Anything that posts inventory gets proven in the place where it runs.
When somebody asks how long a change will take, the honest answer has two parts. Building it is the short, easy part and verification is the long, arduous part, and I’d give that one first.