The Only Way to Understand AI Is to Build It

Trail running. Vector search. And the lessons buried in doing hard things well.

There’s a deep satisfaction in doing hard things on purpose.

I’ve felt it on the trail—miles from the nearest person, legs burning, lungs on fire, alone with nothing but the sound of my breath and the rhythm of my footsteps. Trail running strips everything away. There’s no applause, no finish line photographers, no metrics to post—just the clarity that comes from pushing through discomfort, one step at a time.

This week, I found that same feeling in a very different place: behind a keyboard.

I built an enterprise-grade AI microservice on my laptop. No fancy infrastructure, no vendor integrations, no team of engineers. Just a set of open tools, a blank terminal, and a clear intention to learn by doing—and not lose my temper in the process.

I didn’t do it to make a product (much to Jenelle’s disappointment). I did it because I believe that in the post-digital economy, if you want to lead, you have to build.

A Philosophy of Discipline

The process wasn’t glamorous. It wasn’t optimized. At times it felt like a slog, tracking down bugs, tracing broken routes, learning how vector similarity actually works under the hood. But that was the point.

Whether it’s long miles on a trail or hours alone with a terminal, I’ve learned that clarity comes through repetition. Not through inspiration. Not through insight. Through reps.

It’s been a long time since I wrote a line of code, and it was kind of validating that I could still make it happen. What was most important was connecting with the wiring and understanding what an enterprise grade deployment of AI/ML looked like. As the world evolved, my perspectives need to evolve as well. I need to ground my strategic thinking in practical, firsthand experience. Because leadership without technical depth is increasingly a liability. Especially now.

If you’re in a position of influence and you don’t understand how AI systems actually work, you’re not equipped to make meaningful decisions about how to use them. Period.

What I Built

This system takes a document, remembers it, and answers questions about it using context-aware reasoning from GPT-4.

Here’s how it works:

1. A user uploads a .txt file or PDF

2. The content is split into 500-character chunks

3. Each chunk is embedded using OpenAI’s text-embedding-ada-002

4. The vectors are stored in a Pinecone index

5. The user asks a question

6. The question is embedded and used to query the index

7. The top 3 matching chunks are returned

8. GPT-4 is prompted with the context + question

9. A grounded, relevant answer is generated and returned

This architecture combines:

• FastAPI for the service layer

• OpenAI for embedding and language generation

• Pinecone for high-performance vector search

• Streamlit for a clean, real-time front-end interface

I ran all of this locally on my MacBook Pro.

No devops engineer. No cloud orchestration. Just modular tools, a clear design, and the willingness to follow the friction until it worked.

Why I Subjected Myself to This

There are easier ways to “understand AI.” I could’ve watched a webinar. I could’ve skimmed another trend report. But I’ve learned over the years, whether on the trail, in the weight room, or in combat, that real understanding comes from going through discomfort.

Trail running has taught me that momentum begins the moment you push beyond discomfort. This project reminded me that learning works the same way. You don’t need to master every topic, you just need to stay in the problem long enough to find the seams.

More than anything, this was about maintaining my edge. Last week, at ServiceNow K25, I realized just how far behind the curve I’d gotten. I’ve always taken pride in staying on the bleeding edge of technical trends, and let me tell you, I got soft.

Over the years, I’ve built and exited companies. I’ve helped global enterprises navigate digital transformation. I’ve advised on product strategy, enterprise architecture, and strategic readiness. But unless I keep building, my perspective risks becoming dated.

I wanted to go as deep and full-stack as I could without dropping serious cash on a PC. I wanted to reclaim an edge sharp enough to ask better questions, guide better decisions, and move faster.

The Takeaways

For anyone in a leadership role, especially in tech or strategy, here’s what this kind of build teaches you:

1. ou Can Only Learn by Doing. Get Out Your Laptop.

AI isn’t speculative anymore. With the right architecture, a $0 budget, and a few open APIs, you can build a fully functioning system that rivals the utility of enterprise software. The barrier to experimentation has never been lower, and the bar for leadership has never been higher. Before you mandate it, before you buy it, you need to build it. Get busy.

2. The Modern Tech Stack Is Composable

OpenAI isn’t a monolith. Pinecone isn’t a platform. Each component is a service you can integrate on demand. Maybe it’s the architect in me, but I believe the real technical skill isn’t knowing how to build everything, it’s knowing how to compose the right pieces. It’s about understanding which options are available to solve a particular problem, and how those pieces scale to meet future needs.

3. Vector Search Is the Real Power Behind Useful AI

Generative AI without storage and data is just theater. By embedding documents into a vector store and retrieving the most relevant context for a given query, you transform GPT-4 from a parlor trick into a knowledge worker. Pinecone was essential to making this system genuinely useful. Even on a small scale, it’s rewarding to see how all the pieces come together—and to step through the process in Visual Studio to understand what happens and where.

4. Streamlit Makes Experimentation Feel Like Product

With just a few lines of Python, I had a working front end. No React, no deployment pipelines, no wrestling with build tools. Just a clean, usable interface that let me see what I was building in real time.

Was it pretty? No. Was it production-grade? Definitely not. But it worked—and that’s what mattered.

Streamlit gave me a way to think out loud in code. It helped me see how the pieces connected, where they broke, and how users (even if that user was just me) might interact with the system. It didn’t get in the way. What more could a guy ask for?

So What?

There’s a reason I trail run. There’s a reason I lift heavy. There’s a reason I build systems like this. I believe discomfort is the clearest path to clarity—and that clarity, repeated, becomes capability.

You don’t have to be a Silicon Valley tech bro to stay relevant in this economy. But you do have to understand the terrain. And the best way to do that is to lace up and run it yourself—metaphorically or otherwise.

If you’re a product leader, a strategist, or an executive making decisions about the future of your company, do this:

Build something.

Something simple. Something that works. Something that forces you to engage the architecture—not just the outcome.

Once you’ve gone through all of this, your questions get better. Your understanding gets deeper. The blind spots shrink. The strategy tightens.

The future won’t reward those who spectate.
It will reward those who train.

And the best training is doing the hard thing, one deliberate rep at a time.