Some people got interested in AI because they loved the models. I got interested because I was tired of software that could tell me what happened but couldn't help me decide what to do next.
After more than twenty years in marketing, I knew what I wanted AI to do for marketing. I wanted systems that could weigh evidence, test competing explanations, connect information, and act on a decision. Most marketing platforms gave me another dashboard or a tool to perform another task. Even the AI-driven systems were becoming performing monkeys, executing commands instead of figuring out what ought to be done.
As large language models progressed, I realized it might be possible to build what I had in mind. But I would need to know how to build it myself. I would need to become an AI engineer.
So, over the past two years, I taught myself AI application engineering and systems architecture.
I started where the glamour goes to die: Python fundamentals. Variables, dictionaries, functions, classes, exceptions. The things that never make it into an AI keynote but determine whether your software works.
A Python interpreter doesn't care that you have twenty years of marketing experience. It doesn't care how persuasive your strategy is. If you hand it bad syntax, it tells you. Immediately. And with absolutely no interest in your feelings.
From there came SQL, Git, REST APIs, JSON, Docker, and the everyday mechanics of software development. I learned to work in the terminal, connect systems, manage data, and debug the inevitable difference between what I intended and what the code actually did. That last part is most of engineering.
Calling a language model through an API changes the way you see it. It stops being a place where you type questions and starts becoming a component you can put to work inside your own software.
I learned to work across model providers, write structured instructions, require machine-readable outputs, and make the surrounding code handle the messier realities: malformed responses, missing data, retries, cost, and speed. A model that writes a beautiful paragraph when your program asked for valid JSON isn't being creative. It's breaking the application.
This was the first major shift. I wasn't trying to become better at chatting with AI. I was learning how to give it a defined job, connect it to other systems, and check its work.
Then I ran into an awkward fact. A model can sound remarkably informed while knowing almost nothing about the specific business, project, or decision in front of it. Give it the wrong context and it can produce a polished answer to the wrong question.
This meant mastering retrieval-augmented generation, embeddings, vector search, and context engineering: getting the right evidence into the system at the right moment. I also learned that retrieval alone doesn't prevent invented claims. You still need evidence checks, source tracking, and a way to distinguish something the system knows from something it merely proposes.
That problem led me to create an AI extension of my own brain: AtmaOS. The work centered on keeping state, decisions, and evidence coherent beyond a single AI conversation. I became less interested in whether a model could remember a fact than in whether a system could explain why it believed that fact, where it came from, and what had changed.
A model that can write is useful. A model that can query a database, call an API, inspect a source, run a function, and hand its findings to another specialist is a different kind of thing.
I learned tool calling and agent orchestration, including the far less glamorous question of who gets to do what. Some decisions belong to models. Some belong to deterministic code. Some deserve a second opinion, an adversarial review, or a hard stop until the evidence improves.
That thinking runs through the systems I've been building: the Boswell Engine for research and relationship-driven outreach, a Bayesian platform for advertising decisions, and a dual-pass compliance engine for financial marketing. Edge Hunter won't touch a prediction market until the document that settles it actually exists. Dr. UX tests a website against what psychology and neuroscience know about how people feel their way through a page, and admits it doesn't know yet when the evidence isn't there. They're different products, but they come from the same instinct. I want software that can do more than produce an answer. I want it to help make a better decision.
The final lesson was the least photogenic. Software has to survive contact with the real world.
I got serious about testing, deployment, monitoring, access controls, failure handling, and the economics of running AI systems. How accurate is the answer? How often does it fail? How long does it take? What does each call cost? Can a smaller model do the job just as well? What happens when a provider is unavailable? Can I reproduce the result tomorrow?
That meant learning evaluation methods, building tests, using CI/CD, shipping through cloud platforms, and paying attention to latency, caching, and model routing. A system isn't finished because it worked once while I was watching. It's finished when it keeps working after I stop.
I didn't set out to train foundation models. I didn't spend two years reimplementing a transformer, proving every linear algebra theorem by hand, or chasing every framework that appeared on social media. I learned the mathematics I needed to reason about vectors, probability, and model behavior, then spent my time building with the models that already existed.
That's a distinction worth making. My specialty is AI application engineering and systems architecture, not foundation-model research. Some tools in my stack are production tools; others are technologies I'm designing with or evaluating. I don't confuse the two.
The surprising part is that I never really stopped being a marketer. I still start with the same questions: What are we trying to change? What would count as evidence? What would make us admit we were wrong? Now I can build the software that attempts to answer them.