Asking for something is not the same as verifying you got it, and the gap between those two costs more project time than any other mistake I have watched.
This failure has not changed in forty years. It has only found new places to happen. A vendor sends a specification that does not match what their interface returns. A migration runs against documentation nobody updated. An AI tool gets pointed at a branch that no longer reflects production and confidently rewrites code that is not there anymore.
In every one, somebody asked, somebody answered in good faith, and the answer was wrong.
A port that should have been simple
A company that made the nails for roofing trusses gave their customers a free program. You fed it inputs and it designed a roof truss. The nails are flat pieces of metal with sharp points that hold the wood together, and that was the whole business.
The program ran on an older machine and they wanted it on the personal computer becoming standard at the time. A straight port. No new features, no redesign.
I was not the project lead. I was the interface to the client, which means the files came through me.
We asked them for the sources. They sent them. Nobody skipped a step and nobody was careless.
Then the port would not work. The team tried, and tried differently, and burned weeks on a job that should have been simple. Eventually we got the right sources, and it worked immediately.
The sources we started with were not the ones in production. The person who pulled the files believed they were current. They were not, and nobody in the building knew.
The step that takes an hour
Build what you were handed, run it, and check the output against the version customers are using.
If they differ, you have found the problem on day one instead of week three. Skipping it cost us weeks, and there was no way to detect the difference from outside. Same file names. Same structure. Same everything except behavior.
The same test applies to almost any handoff. Run the vendor’s example against their interface and compare it with the documentation. Take one record through the process the runbook describes and see whether the runbook is accurate.
The 2026 version arrives in seconds
An AI tool reading a stale branch produces work that is internally consistent and externally wrong. It refactors functions removed months ago. It updates calls to an interface that changed. It writes tests for behavior nobody ships.
None of it looks wrong. That is the difficulty. Bad output from a confused tool arrives formatted, commented, and plausible.
Nobody to blame, which is why it keeps happening
The client believed they sent the right files. The person who pulled them believed the folder was current. We believed what we were given. Every individual acted reasonably and the project still lost weeks.
The failure lives in the handoff itself rather than in either party.
I sat in that handoff. I asked correctly and I received what I asked for. Doing my job properly was not enough to keep the wrong thing out. Anyone who sits between a vendor and their own team occupies the same position, because the engineers cannot verify what they were handed when they are not the ones talking to the people who have it.
Three questions before you start
When was this last used in production, and by whom. Where did you get it, and is that the same place the running version comes from. Is there another copy anywhere, and do the two match.
None of those is an accusation. They are the same questions you would ask about a used car.
Then run the thing and compare it against reality. The questions establish provenance. Running it establishes truth, and only one of those is evidence.
The full article is on my site: https://thewritingking.com/asking-is-not-verifying/. It runs longer, carries the diagrams, and answers the questions readers ask most.
These are AI-made summaries of longer articles on my site, written with AI assistance from my own interviews and my own career. Nothing goes out that I have not read and approved.