How I'd Learn AI From Scratch, As a Marketer Rather Than a Computer Scientist

There's a whole genre of content built around the phrase "how I'd learn AI if I were starting over." You'll know the thumbnails. They promise a clean roadmap, usually ninety days long, and tend to finish with you installing Python and pushing something to GitHub by the weekend.

I've taken more of these courses than I'd care to admit. They're well made and they're well marketed, and I'd leave every one buzzing, head full of ideas. Then I'd sit down at my desk the next morning and think, right, now what? The gap between the excitement and a single useful change to my actual work was enormous, and nobody had warned me about it.

So this is the other version. Five years in, written by someone who came at AI through marketing rather than engineering, for people doing the same. I won't pretend it's quick, because it isn't, but you can absolutely do it. The honest advice up front is that this is a significant change to how you work, and the temptation is to skip straight to building an agent or automating something clever.

Get the basics right first. Everything good I've built came after a long stretch of doing exactly that.

‍

Why marketers have a head start and don't know it

The good news, if you come from marketing or operations, is that you're starting closer to the finish line than you'd think.

AI, for all the talk of magic, is really an operations problem at heart. It only does anything useful when there's a process behind it, something feeding it the right context in the right order. A model on its own is a very clever box that sits there doing nothing. The value turns up when you wrap a workflow around it.

So the intuition you've built doing the actual job matters far more than any technical understanding.

Someone who knows how to do the work but has none of the tools will always outperform someone who has every tool but no idea what the task actually requires.

It might take the first person longer, but they'll get there, and they'll know whether the answer is any good. Marketers and ops people have that intuition already, usually without naming it. You know which bit of the campaign always runs late, which handover drops the ball, which report nobody reads but everyone still builds. That judgement is the difficult part, and it's the part AI can't do for you. Knowing what's worth automating in the first place is the bit you walked in with.

The first ninety days: be nosy, then ask why

The honest starting point is curiosity, not a course. For the first stretch, your only job is to point these tools at your actual work and see what comes back. Not toy prompts, but the real tasks that fill your week.

When I started, the first thing I tried to hand over was account research. I wanted to type the name of an account and get a proper, useful brief back, all in the context of cyber security.

This was early enough that putting a real client name near a chatbot was off the table, so everything got anonymised first. And the first attempt was a real lesson. It got me excited at first, because the response came back full of confidence, with stats and quotes that fit the proposition perfectly.

Then I read it properly and realised most of it was bogus. The stats weren't real, the quotes weren't real, and the actual research underneath was thin enough that I could have found better on the company's website and their LinkedIn in ten minutes flat.

So I completely understand why someone hits that point and decides this is far too risky to let near their work. That's a reasonable reaction. More on why it does that, and how you stop it, shortly.

The most useful habit you can build in these first ninety days, though, is to stop judging the output and start asking why it came out the way it did. Not "this is rubbish," but "why is this so generic, why did it invent that, and what would I change to fix it?"

That single question is the difference between someone who tried AI once and someone who's actually learning it. And you don't have to work it out alone. Often the fastest route is to ask the model itself: show it what it gave you, say that's not good enough, and ask what it needs from you to do better.

That panic about made-up answers is worth understanding rather than fearing, because once you do it mostly goes away. Part of it is how the models were built, rewarded for a confident answer whether or not it was true, because sounding sure scored better in training than admitting "I don't know."

Newer models flag uncertainty far better, and that's deliberate. The rest was on me: tell a model it must give you something that isn't there to find, and it'll invent rather than admit it. The fix was to tell it where to look, or let it say when it can't. Most of what looked like the AI failing was me briefing it badly.

So the real measure of your first ninety days isn't expertise, because you won't have any yet. It's that you've pointed the tools at real work, got a feel for where they're sharp and where they go soft, and started treating a disappointing answer as a clue rather than a verdict.

You don't need to know all the tech, just the bits that matter

Asking why enough times has a side effect, and at first it's maddening. You find yourself having to look up what every other word means, starting from somewhere near the bottom with technology you assumed wasn't for you.

But it builds. After a while something flips, and you realise you understand parts of your own field better than the model does. You start pushing back on it, questioning its answers, because it only knows what it was trained on. A new model lands, or you come across a method it hasn't seen, and you're the one correcting it.

That's the point you stop being a user and start becoming a master of your own trade again, just with new tools in your hand.

When my research kept coming back generic, the fix was never a cleverer prompt, it was understanding why a model behaves the way it does. So I read about context windows and how much a model can hold in its head at once, about semantic search and chunking and vector databases.

Don't worry if those words mean nothing yet. The short version: there's a real mechanism under the bonnet, with real limits, and once you can see them you stop fighting them.

That's where everything shifted. The problem was never that the model was thick, it was that I was asking a single prompt to do the work of sometimes thirty steps, across four or five different tools, sometimes eight or nine.

The more you add, the more there is to break, as I've learned the hard way more than once. Once I understood the constraints, I broke the work into smaller, deliberate steps that each played to what the model was good at, and the output went from generic to something I'd actually use.

What's worth underlining is the order it happened in. I didn't learn this from a computer science syllabus, top to bottom. I learned it because something broke, and fixing it meant getting my head around the next concept along.

The blocker told me what I needed to know, not a curriculum. That matters more than it sounds: you never waste time on something you've no use for yet, and what you do learn sticks, because you picked it up solving a real problem.

I find this stuff fascinating, to the point where I've carried on well past anything the day job demands. But that's me, and you don't need to follow me down every rabbit hole. You need just enough to stop being at the mercy of the tool, and you'll know you need the next piece when something stops working and you want to know why.

The long middle, where the time actually goes

Once you've got a feel for the tools, the obvious next move is to stop firing off single prompts and start stringing them into workflows, where the output of one step feeds the next.

Take a report that used to take us about thirty hours. The fantasy every agent demo is quietly selling is that you press a button and it appears in five minutes. What actually happened is we got it to roughly six hours at better quality, but it took the best part of two weeks to set up before it saved a single minute.

That pattern has held for nearly everything I've built. You spend more time up front than the manual task would have cost, and only once it's bedded in do you see those seventy-five to eighty per cent savings, usually with a quality bump alongside.

What makes that worth it is that the pieces are modular. Once a component exists, the next thing you build can lean on it, and the one after that, so the work gets faster and faster across the business.

It's only ever that first setup that takes longer than anyone would have you believe.

The compounding is the whole game.

It's why the platform we've built can now turn out a full value report in under ten minutes, the sort of report that used to take two to four months to write.

It won't get a client one hundred per cent of the way there, nothing will, but ninety per cent in ten minutes, because all those separate components are finally feeding into each other in a sensible way.

And it doesn't stop once it's built, which is the part people don't price in. Anything agentic, anything stitched from a few tools, needs maintaining. The models change their connections almost monthly, APIs break without warning, and newer standards like MCP smooth some of that over but aren't everywhere yet.

My first proper agent, back in late 2022, was a lead scoring setup in HubSpot that enriched every new contact and suggested how we might position to them. It worked. The trouble was the upkeep, set against the handful of leads it actually touched each month, never quite justified itself.

We could have done that by hand. Building something clever and slowly realising it wasn't worth the clever is a rite of passage.

‍