Magento to machine learning, and back

When I told people I was leaving commerce engineering to do a master's in AI, most of them heard it as a hard left turn. PHP to PyTorch. Catalogs to convolutions. Two different careers with a wall between them.

Two years in, the wall turned out to be mostly decorative. A good chunk of the master's was me recognising problems I had already been paid to solve, wearing better vocabulary.

I want to be precise about which parts transferred, because the honest answer includes a few that genuinely did not.

Data is wrong in the same ways everywhere

The first surprise was how much of machine learning is data plumbing with a research hat on.

I spent years keeping a product catalog synchronised across a PIM, a commerce platform, and five or six ERPs. The work was mapping one system's idea of a product onto another's, catching the records that arrived malformed, and figuring out why two systems disagreed about the same SKU.

Then I got to graduate school and built feature pipelines, which is the same job. Pull from several sources that each have their own opinion about schema. Normalise. Validate. Handle the rows that show up broken. Notice when two views of the same entity have drifted apart.

Three specific pairings kept showing up:

Training and serving skew is a sync bug. A model trained on features computed one way, then served features computed a slightly different way, fails for exactly the reason a storefront fails when its catalog and its ERP disagree about a price. Two systems, one entity, two answers.

Drift monitoring is reconciliation. In commerce you run a scheduled job comparing both sides and reporting the difference, because eventually something silently diverges. In ML you watch the input distribution for the same reason. Same job, more statistics.

Label leakage is a data-integrity failure. A column that quietly encodes the answer is the same class of bug as a field that gets populated from the wrong source. Both produce results that look excellent until they meet reality.

None of this makes me a better researcher. It did mean that when a project went wrong, my first instinct was to go look at the data, which turned out to be right more often than it had any business being.

Validation shows up again, with worse manners

My research assistantship involved adversarial safety work: prompt injection, jailbreaking, poking at classification pipelines to see what made them misbehave.

Underneath the terminology, a lot of it is input validation. Someone sends you something shaped to be misread, the system trusts it, and behaves in a way nobody designed. Commerce engineers know that shape. It is what a payment webhook handler is defending against, and it is what happens when a REST endpoint deserialises something it should have refused.

The difference is that a web application has a spec. You can enumerate what valid input looks like and reject the rest. A language model will cheerfully accept everything and there is no boundary to check against. That part was genuinely new and I found it uncomfortable, in a useful way.

What actually did not transfer

A post where everything maps neatly is a post nobody should believe, so here is the part that cost me real effort.

Backend systems are mostly deterministic. You write a test, it passes or it fails, and if it fails the cause exists somewhere in your code. That relationship is the foundation you build habits on.

Models are right about 94% of the time, and the 6% is not a bug you can go find. Getting comfortable with that took most of a year. So did learning to trust an evaluation harness over my own eyes, because a model that looks brilliant on the examples you happened to check is one of the easiest ways to fool yourself in this field. I have watched myself do it.

The mathematics was work too. I had used linear algebra as a tool for two decades without needing to sit inside it.

The return trip

Somewhere in the middle of all this I built a retrieval system over technical product documentation. A customer asks a question in plain language, the system finds the right passage in a pile of product docs and manuals, and answers from it. FastAPI, a vector store, an LLM on top.

It was the first time both halves of my experience were useful at once, and the balance surprised me. The model was the easy part. The hard parts were the ones I recognised: which documents are authoritative when two contradict each other, what happens when the catalog changes underneath the index, how to tell whether an answer was actually grounded in a document or invented near one.

Those are data problems with a model attached. Eight years of commerce work had prepared me for them better than the coursework did.

That experience shaped how I read the current wave of commerce AI. Adobe shipped an MCP server this year that exposes catalog, cart, pricing, and order management as tools an agent can call. Plenty of people are building shopping assistants on top of things like it.

The interesting case to me is narrower than the marketing, and it looks a lot like the catalogs I already worked on. Finding the right industrial component means satisfying several constraints at once: voltage, phase, coil rating, mounting style, enclosure protection, whichever regional certification applies. Keyword search is poor at that. A structured query against clean attribute data is good at it. Automotive parts have the same shape, where a component has to match a specific year, make, model and submodel before anything else matters.

There is real value there, and it depends almost entirely on whether the attribute data underneath is any good.

Which brings the whole thing back around. A retrieval system over a bad catalog is a bad catalog with a chat interface. An agent with access to inventory that disagrees with the warehouse will confidently sell things nobody has.

The unglamorous conclusion

The version of this story people expect is that I traded an old stack for a new one.

What happened is that I went away for two years and came back understanding that the commerce work had been a data job the whole time. The plumbing I used to apologise for, the reconciliation jobs and the validation logic and the dead-letter queues, turns out to be the substrate everything else sits on, including the parts with the interesting names.

The hard part was never the model.