I finished AI Engineer Core Track: LLM Engineering, RAG, QLoRA, Agents in September 2026. I did not take it to collect an engineer title. I took it because the technical background I already had — a master’s in information technology focused on NLP, and years on Standard Chartered’s conversational AI — was still not enough for the work I care about now: designing an AI solution, and the strategy and transformation roadmap around it, so that it actually addresses a business need.
At WPP Media I worked in analytics and MarTech, across measurement, tagging, and modelling, and spent a lot of time turning those into something marketers could use. Vendors are happy to fill any remaining gap with a demo. A demo is not a design, and it is not a roadmap.
What I think a useful AI transformation needs
I keep seeing “AI transformation” presented as a slide. My view is simpler, and I have held it for a while: the work only holds if three things are present together.
The first is technical understanding. Retrieval, fine-tuning, and agents are different methods. If you do not understand what each one is for, it is hard to choose a method that fits the problem, and easy to copy whatever a vendor put on the slide.
The second is commercial gain. The work has to change a decision, save time that someone will actually use, or reduce a cost the business already feels. A fluent answer is not the same as value. I wrote about that gap in AI adoption is still a translation problem. On this site I also showed that TabFM could forecast the KPI and still could not answer the planner’s budget question.
The third is delivery that fits the company you are in. A design that assumes a new platform team, a new data estate, and a new operating model is often too far from what the organisation can run this year. A useful roadmap starts from current talent, current tools, and current constraints, then sequences what to build first.
If any one of those three is missing, the programme usually stalls. At best it becomes a launch announcement. At worst it becomes another failure that people remember the next time someone asks for budget.
That is why I took an engineering course rather than another strategy deck. I wanted to be able to design the solution and the transformation path, including the roadmap, around a real business need — not around a model name.
How the course changed the way I design
The course did not give me a new job title. It gave me a working order I can use when I design: start from the business decision, prepare the data, compare a simple baseline, try the methods, and only then talk about production. “Build an agent” is not a business requirement. Helping a marketer brief tracking without inventing GA4 guidance is. Helping an analyst get to a Meridian-ready table without a week of manual cleaning is. Stopping a forecast model from being treated as a budget tool is.
I had to run the labs on my own providers. OpenAI fine-tuning is blocked from Hong Kong by the company, not by local policy, so I could not copy the course-video setup. That was inconvenient, but it matches the point: a design has to work with the access, budget, and tools you actually have, not with the stack in a lecture.
The capstone was a small example of method choice. An untrained small model was off product prices by hundreds of dollars on a held-out set. After retrieval and a specialist model were measured on the same 200 items, the error dropped sharply. Combining them in an ensemble barely beat retrieval alone. That is not production ROI, and it is not a pricing product. It is a reminder that a roadmap should put a method on the plan only after you have tested it against the decision you care about. The lab is at github.com/anthony-tsui/the-price-is-right.
During the same months I used those building blocks on marketing-analytics prototypes. They are still prototypes, not live client systems. The line I already posted on LinkedIn still holds: use AI to speed up repetitive preparation, validation, and first-pass analysis, and keep experts responsible for interpretation and the final decision.
That is also how I would build a transformation roadmap. Start from a workflow that already hurts — tracking briefs, tagging proposals, MMM data preparation, mix decisions — and test whether an AI design actually helps, with the team and tools already in place. The public tests include a retrieval assistant over official GA4 and GTM documentation (marketing_tracking_poc), a tracking-proposal reviewer (tracking_proposal_poc), a Meridian data-preparation generator (meridian_mmm_data_pre_gen_poc), and the TabFM versus Meridian comparison already on this site.
I am continuing with the agent and production tracks, and with a live cohort for technical marketers, for the same reason. I want to get better at designing AI solutions and the strategy around them, so the roadmap addresses a business need instead of becoming another slide.
Course: AI Engineer Core Track: LLM Engineering, RAG, QLoRA, Agents
