I Wanted to Learn AI, So I Gave Myself a Real Problem

I'd done the tutorials. Or at least I'd started enough of them to know how they go.

Here's an API key. Here's a prompt. Look, it wrote a poem. Look, it summarized an article. Look, it answered a question about something it already knew. Every one of them ended right where I thought things were about to get interesting.

I’d worked through a hands-on Udemy course, Next.js & React – The Complete Guide (opens in a new tab), building applications while learning React, Next.js, routing, components, and modern frontend development. I’d also been experimenting with ChatGPT and AI-assisted coding, exploring how I could use these tools to build something beyond a typical website.

I didn't want to learn how to make AI do a trick. I wanted to find out what it was like to make it do something real. Something with messy data, real people on the other end, and an actual cost when it got the answer wrong.

The problem with that plan is that "something real" is hard to find when you're starting out. Most real problems belong to someone else, and they don't want you experimenting on them.

Then I realized I was already sitting on one.

The problem I already understood

I'm one of the developers who works on Kreg Tool's ecommerce and web systems. If you've never heard of Kreg, they make woodworking tools, best known for pocket-hole jigs. I spend my days around kregtool.com: the product pages, the product data behind them, the way the site is put together, and all the small ways it doesn't quite fit together.

That meant I already knew the hard parts that usually make a learning project fall apart. I knew the website. I knew where the data came from. I knew what a product page was supposed to contain, and I had a decent idea of what customers came there looking for.

What I didn't know was AI.

And that turned out to be a pretty good combination. If I picked a toy problem, I'd be learning two unfamiliar things at once: the AI and the problem. If I picked a problem I already understood, I'd only have one unknown. Everything else could be scaffolding.

The spark came when I noticed the chat icon on our website wasn't really a chat at all. It was just a way for visitors to submit a question and wait for a response. I started thinking, we're sitting on a lot of valuable product information, so why couldn't we use AI to give visitors real answers, right when they need them? It felt like an opportunity to turn something pretty basic into something genuinely useful.

So the question became:

• Could I build something that actually understood a real company's products?

Not a website agent that knew about woodworking in general. Not something that could write a convincing paragraph about pocket holes. Something that knew these products, from this website, and could answer questions about them the way someone who'd read every product page would.

Not "add ChatGPT to the website"

I want to be honest about how much I knew at this point, which wasn't a whole lot when it came to actually building something like this. I didn't have an architecture or a clear plan for how it would all come together. I knew about RAG (Retrieval-Augmented Generation), understood what it was designed to do, and could see the benefits of connecting AI to real, reliable information. What I hadn't done was put it into practice on this scale. This felt like one of the first real opportunities to take something I'd learned about and turn it into something genuinely useful.

But I did have one instinct from the very beginning, and it turned out to matter more than almost anything else in this project.

I didn't want an AI that made things up.

That sounds obvious. It isn't, once you've watched these models work. They're fluent. They're confident. They'll tell you a product's dimensions or its warranty terms in the same calm tone whether they know them or not. That's fine when you're asking it to brainstorm names for a dog. It's not fine when a customer is deciding which tool to buy, or whether they can return something, or how thick a board a jig can handle.

If this thing was ever going to sit on a real company's website, it couldn't invent a product spec. It couldn't guess at a price. It couldn't make up a return policy that sounded reasonable. Every answer needed to come from Kreg's own information, not from whatever the model happened to absorb from the internet.

I didn't have a name for that idea yet. I just knew that a wrong answer delivered confidently would be worse than no answer at all.

I had no idea how much work that one sentence was going to turn into.

Why a real problem is a better teacher

Looking back, the best decision I made in March wasn't technical. It was choosing a problem that would push back.

A tutorial is designed to work. Somebody already walked the path, cleared the obstacles, and picked an example that behaves. You learn the steps, but you don't learn what happens when the steps stop working, which is where most of the actual learning lives.

A real problem doesn't care about your learning plan. Real product data is inconsistent. Real websites have pages that don't look like the other pages. Real customers ask questions you didn't think of. Every one of those things is annoying, and every one of them taught me something a tutorial never would have.

I didn't know that yet, though. In March, I just thought I'd picked an interesting project.

Where this is going

I'm writing this series because the project turned into something much bigger than I expected, and I want a record of how that happened while I still remember what it felt like to not know any of this.

It started as an experiment to get a website to understand its own products. Along the way it picked up a lot of other things I didn't plan for, and each one showed up because solving the last problem revealed a new one underneath it.

That's really what this series is about. Not "here's the architecture I designed," because I didn't design it all up front. It's more like: here's what I thought, here's what I tried, here's what actually happened, and here's the next problem that showed up because of it.

I'm going to tell it in order, one month at a time, including the parts where I was wrong.

And I was about to be wrong pretty quickly, because at this point I genuinely thought I knew how to solve it.

The plan fit on a sticky note.