Follow Your Curiosity - My Unexpected Path Into AI Engineering
Your quirks and differences aren't obstacles — they're your competitive advantage.
People often ask me, “Landon, Landon, how did you become an AI Engineer?”
My path may surprise you.
The Spark
I don’t know when I first had an interest in AI. It may be around the time the Marvel Iron Man movies came out, and Tony Stark unveiled his superhuman AI assistant Jarvis. I remember imagining how a Jarvis-like personal assistant could supercharge my life.
But fast forward to when I had the chance to audit an AI class a couple of years after finishing my Computer Science degree. I walked away feeling that traditional software development was more interesting to me than the nondeterministic systems of circa 2016. I wanted to spend my time with my community, just working and building. So I left AI alone.
Several years passed. During that time, I continued honing my craft as a software engineer.
The 4 AM Epiphany
In late 2022, ChatGPT was released, and the world began its first exploration of GPT-3.5. I kept seeing people post about the incredible things ChatGPT was creating, and my curiosity grew. Then one night in early January 2023, I sat down at my computer at around 5:00 PM and didn’t stop until 4:00 AM.
By the time I closed my laptop, one thought was crystal clear: everything is going to change.
When I woke up the next day, I began ranting to family members about how “everything was going to change.” Coursing through my blood was this strange mixture of fear, excitement, sleep deprivation, and grandiosity.
Software had been moving at a very linear pace and was potentially about to explode into a hyperbolic climb. It became clear that the models would make life so much easier and help humans achieve so much more. This seems obvious and hackneyed now, but in January 2023, it felt so novel.
I knew I couldn’t just go back to work on Monday as usual and pretend that everything wasn’t about to change. I began planning my transition and decided that year I would pivot my career to work with these models every week.
Why Ruby?
The answer? I was curious. Exploring why choose Ruby for AI projects would help me build valuable intuition, identify language limitations, and provide unique insights into the current tooling supporting AI.
On a deeper level, I also had a hunch that translating Python code into Ruby could increase AI literacy within the Ruby community.
But these were secondary objectives to my main focus: to scratch my own curiosity (the energy that motivated me to learn challenging topics in the first place) and to reposition my career to be more marketable in the AI era. And what better way than to combine two niches — AI and Ruby — and explore the tooling?
Bootstrapping My Learning
To bootstrap my learning, I began following the work of various software engineers and groups focused on ML and data science tools, including Andrew Kane, Andrei Bondarev, and SciRuby.
I decided to reproduce AI projects I found in Python in Ruby and began searching for an ML curriculum to give me a foundation in model training.
These activities unlocked a ton of value for me early on and gave me significant leverage.
I also began letting people at Test Double, the company I worked at, know that I was interested in this area. I would occasionally present internally to our team things I discovered or worked on during our weekly all-hands meetings.
For example, in one meeting, I demoed YOLO, an image detection model, and the langchain.rb framework—a LangChain-like framework for Ruby. My thesis was simple: if I could share what I was learning with others, I would (A) be forced to understand the material well enough to achieve mastery, and (B) become the go-to AI person when people had questions or wanted to engage with AI projects and initiatives that came up within the company.
Finding the Right Program
As I began my search for AI curricula, I struggled to decide which coursework would be best for me. I knew just enough to start digging into things curiously, but lacked a fundamental understanding of how ML models were created. This was outside my domain.
I considered Coursera courses and started a few, as I saw this as a low-touch way to expand my knowledge. But I wanted something that felt more formal, with more structure and pressure around due dates — something that felt like a traditional classroom setting.
I considered a master’s at Georgia Tech, but saw this as a longer commitment. I wanted to jump into something that would give me the skills to start building sooner.
So I compromised. I discovered that UT Austin offered a certificate program with projects, regular meetings with other students to review homework assignments, and the rigor of a traditional college program focused on the career skills needed to transition into ML. My foundation in software engineering positioned me well to quickly pick up the concepts and leverage what I’d learn in my career.
This turned out to be a great time and monetary investment. It gave me a solid foundation in what I needed to learn to land the type of roles I wanted.
The Consulting Advantage
Working at a consulting company afforded me several unique opportunities.
First, there’s a ton of encouragement in consulting companies to keep growing your skills. As a software consultant, I had built my career on being a generalist with a few specialties. Being able to pull ML/AI into my tool belt would be a valuable skill as interest in AI systems grows. I felt this would give me more opportunities—not just in ML, but also in data science and data engineering. These areas felt complementary, and we had clients who could benefit from what I would learn.
The other opportunity was evangelism on behalf of my organization. Test Double had a perk: conference talks were fully paid for — flights, food, hotel — and it didn’t count against my vacation time. At the time, there was also no limit to how many conferences you could attend. If you gave a talk, Test Double would cover the cost.
This seemed almost too good to be true. I will say, in retrospect, these conferences — though a ton of fun and professionally rewarding — were no vacations. I remember staying up many nights and weekends preparing for my first two conferences. But it was a great opportunity, and it felt like an amazing win-win that I hoped would generate additional interest for my organization and me, and establish me as a thought leader in the space.
My First Conference Talks
I had never spoken at a conference before, so I scoped out a few that would be good venues for what I wanted to speak about. My focus was on raising awareness of ML/AI in the Ruby community. But what was I going to present?
I got the idea that I could port a model I had built in my coursework into Ruby and pitch the process of training an ML model in Ruby. That would be fascinating to Rubyists new to ML.
When I decided to speak, I let a few folks know I wanted to give a talk. My organization was super supportive, and several people offered to help me proofread and think through my abstract — for which I am truly grateful. Justin, who was VP of Engineering at the time, and Cathy, the Director of Marketing, gave their time to provide me with invaluable feedback as I prepared for my first submission.
I pitched my first talk to two conferences: RailsConf 2023 and Blue Ridge Ruby. To my surprise, I was accepted to both. Then came the hard part: writing the talk.
I was confident I could build my project in Ruby, but I didn’t have all the kinks worked out. I decided to pick a simple model and a familiar project that people could easily understand in the domain of weather prediction. This took several weeks of working evenings and weekends to prepare.
Then came the conference date. My talk was on the second day, so I had a day to enjoy the conference and meet people before game time.
When I walked into the room, I was surprised to see it was full, with people lining up at the door at the last minute to get in. This topic really struck a chord and validated for me that people wanted to see more of it.
People came up to me after the talk to say, “Hey, sorry I missed your talk, but it was so packed in there I decided to go to a different talk and catch the recording.”
I really didn’t imagine things to blow up as they did. For the rest of the conference, I had many conversations with folks who were genuinely curious about how AI might impact Ruby development. I felt energized and encouraged by my teammates who came out to my talk and had supported me, by the Ruby community, and by random messages from folks who said they heard good things.
The GenAI Pivot
After the talk, I continued my AI self-study. Much of my focus was becoming more practical and more focused on generative AI — how it could be used in work and how one might architect an LLM system that could add business value for clients.
At the time, AI hallucinations were horrible. People don’t complain nearly as much now as they did back then. There were so many other problems we were facing: how to get the model to produce reliable JSON, how to manage severely limited context windows. We’re talking 4K context windows for GPT-3.5. Compare that to the context window of a modern state-of-the-art model like Claude Opus, which is 200K tokens. It’s wild to think about now.
To handle these challenges, developers were working away trying to find workarounds and various hacky ways to augment the capabilities of the LLMs. This was mostly happening on the software side. Obviously, ML engineers were working on the model side to increase context size and improve JSON outputs, among other things. But that took time, and leveraging code to work around these nondeterministic systems was the best we had.
A method for handling hallucinations and limited context windows, Retrieval Augmented Generation (RAG), was becoming more widely adopted and accepted. Frameworks and companies such as LangChain and LlamaIndex were showing people how to build these RAG pipelines in their applications.
I remember reading the RAG paper and browsing a few libraries, but my coursework — focusing primarily on traditional ML — didn’t prepare me for this newer generative AI paradigm. The world of linear regression models, random forests, and ensemble methods didn’t give me exposure to embedding models or the intricacies of prompt engineering (today, what we call context engineering). Furthermore, testing these systems and getting them to work reliably proved challenging.
I identified that there was once again a gap: many of these systems were built in Python, with few addressing the need for systems like these in Ruby. I also held onto my early curiosity that Ruby might have a place in the AI space, particularly in generative AI.
My thesis was this: RAG was mostly about system architecture. People weren’t running their own LLM inference — they were outsourcing LLM calls to model companies like OpenAI and Mistral because they didn’t have the capacity, expertise, time, or capital to build their own LLMs.
I felt that Python didn’t have any inherent properties to make it a better choice over Ruby, other than the community that better understood AI (since it was the de facto choice for folks wanting to explore AI), the researchers transitioning into the field with Python skills, and the plethora of libraries becoming more available to support this sort of development.
Ruby was still quite lacking. Some imagined building these sorts of apps in Ruby to be a nonstarter.
But upon further exploration, I saw that folks were finding success in languages similar to Ruby, such as Elixir. I could build a prototype RAG in Ruby to show that Ruby could, too, enable these types of applications.
I spent a ton of time trying to understand RAG and to implement examples that would make it easy for other Rubyists to look at my code samples and feel they, too, could leverage generative AI to create their own RAG pipelines.
I had also started exploring Jupyter notebooks as a way to work on AI and data science projects, since that’s what I used for my Python coursework project. The Ruby community would want something similar, I conjectured.
My First AI Engineering Role
For some time, I had the desire to found a company and work full-time on something that interested me. I had entered a startup competition with a cofounder in the past to secure funding for an online marketplace idea. Still, the realities of working an 8-hour job and putting in an additional 2 hours in the evenings and 6–8 hours on the weekends taught me my first lesson on the importance of funding and the pains of bootstrapping.
But I had entered a new era of my career as a Senior Software Consultant, helping companies of every size build and maintain systems to support their strategic initiatives. I had honed my craft and gained extensive expertise in both traditional software and AI systems. I could have an even greater impact on organizations struggling to leverage AI in their businesses. I could advise, build AI systems, and identify opportunities to achieve outcomes.
When I started, I had secured three clients and was confident I could drum up more interest as demand grew.
As Founder & AI Engineer, I began helping companies explore and navigate these new generative AI capabilities.
The work was a mix of AI strategy and advisement, custom implementations of traditional ML and generative AI, software development, project management, and AI training.
Along the way, I learned about marketing, sales, and how to better tailor my technical expertise to help companies find strategic value.
It was an exciting world, and it gave me a lot of grounding and further insight into the AI landscape within organizations, large and small, working to find value with generative AI.
Working for myself has been by far the most difficult work of my career — but also some of the most rewarding.
Madison Ruby
Luckily for me, I had the opportunity to speak at another conference — Madison Ruby in Wisconsin — to share more about leveraging RAG architecture in any Ruby project. My goal was to make this talk as accessible as possible and hopefully trigger the same lightbulb moment in others that I had while exploring this architecture.
You can check out a demo of what I built or check out my slides, which include an overview of the architecture.
Where I Am Now
Fast forwarding to now, I ended up in a position where the market was still trying to sort itself out. Going into election season and into a new year, I contemplated all the sales, marketing, and other functions that went into running a small business. Running a consultancy as a solo founder was fun. Still, I was ready to transition back into an IC role as an AI engineer and found new opportunities of interest.
Currently, I’m working at Dealmaker — powering the future of capital by helping visionary companies raise over $2B. I now dual-wield Ruby and Python and build AI applications as a Senior AI Engineer. Go figure.
I couldn’t have planned this out even if I’d tried.
What I’ve Learned
I’m incredibly grateful for this journey, and I loved (almost) every minute of it. If I can offer a few takeaways for other folks looking make a career transition: Invest your time strategically to pivot. Resumes are nice, but you need to be able to communicate the value you can offer organizations and foresee the sorts of problems they face.
Build in public. For me, writing, engaging in meaningful ways on social media, and sharing excerpts of me doing deep work and offering insights are what led many founders and recruiters to continually reach out to me about interesting opportunities.
Go deep in a few areas. You don’t have to know everything, but you should have some depth in a few areas and have those areas down tight. Learn the fundamentals, but understand how they tie into real use cases and challenges companies might face.
Talk about real problems you’ve solved. For example, when I worked on my Ruby RAG use case, I spent time thinking about the challenges I faced in preventing hallucinations. I discussed them in interviews and conversations with potential clients and engineering teams looking to build their own AI systems.
Show your expertise. Be aware of what you still need to learn and be open about it.
If you keep learning every day and continue to put out information or projects that organizations find interesting or valuable, it’s only a matter of time before your efforts get noticed.