An AI platform can look ready long before it is safe to sign off. I learned that again on acceptance day for a manufacturing client, when I found a permission bug in the live system.
In August 2026, I read a discussion about research showing that AI improved homework while exam scores fell (Hacker News, 2026-08). Students got a polished result without doing some of the work that builds understanding.
I see the same trap in AI adoption. A tool helps build a convincing platform quickly. The missing work is in the paths nobody went back to test.
I'm Young. I've worked across healthcare, education, and long-term care for 20 years, and on more than a dozen traditional-industry digital and AI projects. I've written about turning manufacturing knowledge into an AI question-answering system and why AI projects fail.
From the first version to the second
I built an AI platform for a traditional manufacturing company and delivered the first version. The client paid and came back for a fuller analysis platform.
That return mattered to me. The first version hadn't simply been set aside. The client saw enough use in it to invest in another phase.
For the second version, I delivered two documents: a 40-page acceptance report covering 23 items, each with a screenshot from the production environment, and a 43-page task-based user guide with 29 images. The guide was written for the people who would use the system, not just its engineers.
The bug I found on acceptance day
While testing in production, I tried an analysis API as a user with a restricted role. The API checked whether the person was logged in. It never checked that person's role. The response was 200, with the full analysis data.
A normal screen review would not have found it. The problem appeared only when I followed a real user's path and made the request as the role that should be denied.
I fixed the check, added a test for the failure, deployed again, and repeated the production check with a positive control. The restricted role received 403. The authorized role received 200.
That was the evidence I needed before signing off. AI had helped build the platform, but it hadn't caught the missing role check for me.
Why I start on the factory floor
Across more than a dozen traditional-industry projects I've worked on, fewer than half succeeded. The failures I saw usually began before the code: somebody chose the technology without first seeing how the work happened.
Information in these businesses lives on paper, in a veteran worker's head, and in processes built over many years. A polished AI interface is useless if it doesn't connect to that reality. I start by watching the work, then decide what to build.
| A pattern I've seen fail | How I work |
|---|---|
| Choose the technology first | Watch the work before choosing tools |
| Deliver when the AI output looks good | Test the real user path before delivery |
| Hand over a running demo | Provide item-by-item acceptance evidence and a usable guide |
| Treat handoff as the end | Build something the client wants to use and improve |
Questions I get
Can we feed our documents to AI and let people ask questions?
Yes, once we understand how those documents are used. In one manufacturing project, I turned data on more than 80 products and over 460 material properties into a live question-answering system based on real documents.
Can one person deliver a manufacturing platform?
I built both versions with AI assistance. The important part was understanding the work and taking responsibility for the delivery.
What told you the first version had value?
The client paid for a second version. That was a concrete signal that the first one mattered to them.
I'm Young. I've spent 20 years working across healthcare, education, and long-term care. The manufacturing company in this story remains anonymous. If you need AI in an existing industrial workflow and want evidence before signing off, book a free conversation with me.