How I Actually Learned to Work With AI

Published by

on

It didn’t start with a course. It started with seam checks.

My path into applied AI didn’t begin with Power BI, or agents, or anything I’ve built since. It began where two trajectories crossed: I’d become convinced AI was coming — inevitable, and probably faster than most people expected — and at the same time I had a problem in front of me I genuinely couldn’t solve.

In beverage manufacturing, can-seam integrity isn’t optional. Our inspection process generated detailed measurements from multiple heads on a seamer. The data was there. What I didn’t have was a way to see the process behind the numbers. Which heads were stable? Which were producing too much variation? Was anything drifting slowly toward a spec limit? Was an odd reading a one-off — or the first sign of a developing mechanical problem?

Answering that required statistical process control and process-capability analysis. I understood the process and why the measurements mattered. I did not have all the statistical skill to do the analysis I could picture in my head.

That doesn’t mean I was empty-handed. I ran the seam reports through QIMacros — my SPC add-in for Excel — and for the descriptive work it was excellent. It built out a full process-capability suite, and by trending the data on an XmR chart I could watch each head over time and actually see a drift developing. That got me the What and the So what. What it couldn’t do was the Now what. It showed history with real precision, but it couldn’t tell me the probability that a head was about to walk out of spec, or turn that into a forward-looking risk profile I could act on before it happened.

That gap — the prediction, the Now what — is what I took to ChatGPT. And here’s the part that mattered: not to hand me a finished report, but as an analytical partner and a teacher. I gave it the data, explained the inspection process, defined the specs, and described the questions I actually wanted answered.

Together we built the piece QIMacros couldn’t: a model that estimated drift probability for each head and rolled it into a risk profile — a ranked, forward-looking read on which heads were most likely to cause a problem next, and why. Just as important, we worked to translate the statistics into plain operational language a mechanic, a quality tech, a supervisor, or a plant leader could use.

I didn’t trust that model just because it sounded right. For a good while I ran the two in parallel — the AI making its prediction, QIMacros standing as my source of truth — and only after the model proved accurate over time, across different heads, runs, and conditions, did I start letting it look ahead for me. My SPC add-in could tell me with confidence where we’d been. The model, once it earned that confidence, could tell me where we were headed.

It was slow and iterative. I’d bring a new set of seam pulls, note whether we’d made an adjustment or a changeover, point out readings I doubted, and add context. AI would run the analysis and explain the method. Then I’d compare its conclusions against what I knew about the equipment — and push back on anything that didn’t fit the process.

One of the earliest lessons was the most important thing I’ve learned about AI, period. The analysis surfaced a mismatch between the spec we were applying and the type of measurement we were evaluating. The math was flawless. The conclusion was meaningless — because the context feeding it was wrong.

A technically correct answer is not the same as an operationally correct one.

AI didn’t know our seamer. It didn’t know when we’d made an adjustment, whether a strange value was a data-entry error, or which mechanical condition might explain a pattern. I had to bring that. And at the same time, AI could apply methods, spot patterns, and explore the data faster and deeper than I could alone. The value wasn’t in either one of us. It was in the combination.

Looking back, that project is where a framework I now use constantly was born:

  • What? — What do the measurements show? Which heads are stable, variable, drifting, or near a limit?
  • So what? — Is that pattern ordinary variation, a developing mechanical problem, or a real risk to seam integrity?
  • Now what? — Which heads do we inspect, adjust, monitor more closely, or hold up as the benchmark?

We stopped just documenting seam measurements and started using them to focus attention and drive decisions.

It also changed how I understood the tool. Before that project, it was easy to see AI as a way to get answers or generate content. Through the seam work, I learned to use it for iterative problem-solving — to supply context, question assumptions, verify outputs, sharpen what I was really asking, and tie technical findings back to operating reality.

That seam project eventually became a deployed Copilot agent — one that now watches for seam drift and warns us before we go out of spec, with a recommendation to bring the process back to stable. And it became the mental model for everything I built after: the Power BI rebuild, the other agents, the data-analysis skills. None of it started with a class. It started with one real problem, and a willingness to work the problem with the tool instead of just pointing the tool at it.

Here’s what I want an operations leader to take from this. I didn’t learn AI in a workshop and then go looking for a place to use it. I learned it on my own floor, against real constraints, on a problem that was genuinely mine. I brought process knowledge, purpose, context, and accountability. AI brought reach, speed, and methods I hadn’t mastered. Neither of us could have produced the result alone.

The seam checks were the first project. The real outcome was learning how to work with AI — not as a replacement for what I know, but as a way to expand it.

Leave a comment