I didn't take a straight line into AI engineering. There was no tidy narrative where each step logically followed the last. What I have instead is a combination: engineering skills, a working sense of how a retail business runs, and years of creative technology experience. This post is about how those three things came together, and why the unconventional path turned out to matter.
The creative technology years
My first serious technical work was in 3D art and motion graphics. I was building visuals (rendered environments, animated sequences), the kind of work that requires you to hold an entire scene in your head: geometry, lighting, material properties, camera movement, timing. It's deeply technical work that looks creative from the outside.
The highest-stakes work in that period was election coverage for Monash. It taught me something that still shapes how I build software: clarity is a design constraint. When you're making something that has to communicate a message to thousands of people in seconds, every element has to earn its place. Noise is failure.
That lesson transfers directly to building AI systems. An agent that gives a five-paragraph response when one sentence would do, or a pipeline that produces verbose JSON when a clean schema would suffice, these are clarity failures. They make systems harder to debug, harder to maintain, and harder for humans to trust. The visual intuition I built creating motion graphics is the same intuition I use when designing output schemas and agent responses today.
The other thing that creative technology gave me was comfort with iteration under pressure. A creative project rarely survives first contact with a client brief unchanged. You prototype, you show it, you get feedback, you rebuild. You learn not to be precious about your work. That posture, ship something real, learn from how it actually behaves, is exactly how you build production AI systems.
The retail pivot
I moved into retail e-commerce at Fujian Footwear in 2022. The company sold footwear across multiple online channels, and I came on to manage digital operations, marketplace listings, campaign management, analytics, the operational machinery that keeps an e-commerce business running day to day.
The honest reason I took the role was practical. I needed broader business experience, and retail is a compressed MBA. You deal with inventory pressure, margin pressure, customer behaviour, seasonal demand cycles, and the constant tension between marketing spend and revenue return. Everything has a number attached.
I built analytics reporting in Looker Studio, tracked ROI on ad campaigns, and managed operations across channels. The work was messier than a report makes it look: a lot of hypothesis-test-revise cycles on campaign targeting, a lot of spreadsheet analysis to figure out which product categories were underpriced relative to demand.
What changed everything was when I started integrating AI tools into that workflow. Initially it was simple: using language models to generate product descriptions at scale, then to analyse customer reviews for sentiment patterns, then to help identify pricing anomalies in competitor data. Each small win made the next application more obvious.
The critical realisation was that AI tools aren't magic. They're incredibly capable at specific tasks and completely useless at others. Learning which is which: that skill came from retail, where you can immediately see in the data whether something worked. A business context where everything is measurable turns out to be an excellent place to develop an intuition for what AI can actually deliver.
The AI engineering transition
By 2024 I was building systems rather than just using tools. At CoralShades, I worked on InsightsLM, a document analysis and business intelligence system, alongside multi-agent orchestration projects. The technical stack expanded rapidly: Python, LangGraph, LangChain, FastAPI, Pydantic, vector databases, embedding pipelines.
Through Silvatron, the work stepped up in complexity and stakes. I built a 12-node LangGraph pipeline for an Australian state government client that extracts regulatory compliance documents one table row at a time and links each value to its source page. On one named benchmark it measured 90% F1; larger document sets varied.
That project is where LangGraph became central to how I think about agentic systems. The problem isn't just getting an LLM to extract fields from a document, any modern model can do that reasonably well on simple documents. The problem is making that extraction reliable at scale, handling edge cases gracefully, maintaining accuracy on complex layouts, and doing all of this in a way that lets humans audit and correct the results when needed. That's a systems engineering problem, and state machines with explicit routing logic are the right tool for it.
In parallel, I designed Sentinel, a code review and pipeline-diagnosis tool built on Claude Code, n8n, Bitbucket and Jira, with a person approving every fix. I estimate it saves 20-40 developer hours a month.
What the non-traditional path provides
I think about the combination this way: most AI engineers understand the technology deeply but have limited context for why any particular business problem matters. Most business people understand the problem space but can't build the solution. Creative technologists understand how to communicate clearly and iterate fast.
The creative background gives me a sense for when an AI system is producing output that humans will actually trust and use, versus output that's technically correct but practically useless. The retail background gives me the instinct to ask "what does success look like in the data?" before writing a single line of code. The engineering background gives me the ability to build it.
The combination also produces a different relationship with scope. When you've been on the creative side, you've watched well-specified projects balloon into endless revision cycles because no one thought hard enough about what "done" meant. When you've been on the retail side, you've watched marketing spend evaporate because someone optimised for the wrong metric. These experiences make you disciplined about requirements in a way that's hard to develop from pure technical work.
What I'd tell someone starting a similar path
First: don't flatten your background. Whatever you did before software engineering is probably more relevant than you think. The specific domain knowledge, the problem-solving patterns, the professional relationships, these don't disappear when you change careers, they compound. The question is how to make the connection legible to the people who are evaluating you.
Second: build things that are actually used. The difference between a prototype and a production system is mostly a matter of how much you care about what happens when things go wrong. Build something small, deploy it somewhere real, watch how it behaves, and fix what breaks. Do this repeatedly. The instinct for production-readiness is hard to develop any other way.
Third: pick a technical depth. AI engineering is broad enough that you can learn a lot about a lot of things without developing real depth anywhere. I went deep on agentic systems and multi-agent orchestration because that's where the hardest and most interesting problems are. Pick your area and go deep enough that you can navigate the failure modes.
Fourth: the business context is the rarer skill. Pure AI engineers are not rare. Engineers who can walk into a business conversation, understand the problem at the level it actually exists, not as a technical abstraction, but as a thing that costs money or loses customers or fails regulatory audits, and build the right thing to solve it: that's a much shorter list.
The path from 3D art to election coverage to retail e-commerce to government AI systems wasn't planned. But looking back, I can't identify any of it as wasted. Every phase gave me something that the next phase used.