You Have Nine Months To Become An AI Builder

This morning I went back to Co Chocolate in Al Raha Beach. I had a few meetings in the area, and any excuse to drop in is a good one, not just because the chocolate is amazing, but because the food is soooo good. The breakfast melt, the mezze, a 65% dark chocolate with just water and a dessert I couldn’t even finish. Ninety-nine dirhams, the lot.

So AI training…

I’ve personally trained over 1,500 people in AI across the last two years. Different industries, different roles, different levels of starting confidence. By the end of a one or two-day session, something measurable has almost always shifted for attendees, call it a ten to fifteen percent productivity uplift. A small but real change in how they work day to day.

It’s genuine, and it sticks.

But most people stop right there, pocketing a useful productivity bump when what AI offers is a real change in how they work. This is the first step in a longer journey, and unfortunately most people never take it, because we’re in an ever-evolving space where the technology keeps moving while they’re still trying to get started.

Thanks for reading! Subscribe for free to receive new posts and support my work.

So why does this happen and how can people and organisatons get ahead.

Take any person, drop them into a well-run AI training day, and you can move them from never having properly used AI at work to getting a real, daily uplift from it by mid-afternoon. They learn the prompt patterns. They learn the few tools that matter. They build one thing they can show their manager. They walk out feeling clever.

That bit is genuinely solved. The tools for what I’d call the using layer (chat interfaces, document drafters, summarisers, deck generators, image tools, basic automations) are now extraordinarily good for people with no technical background. The friction has been engineered out. The interfaces are forgiving. The mistakes are recoverable. You can take a sixty-year-old finance director who has never written a line of code and have them producing useful, AI-augmented work by the lunch break.

Call it the first lift. Anyone can take it. Most companies are currently training their staff up to roughly this ability. It is, in business terms, where almost all of the AI productivity gains we’ve seen so far have come from.

The problem is what happens next or in most cases, doesn’t happen.

Once people taste the first uplift, they want more. This is good. It’s how you know the training landed. They start asking the next question. Can I get this thing to do X for me automatically? And X is usually something genuinely valuable. A repeated workflow they hate. A multi-step automation that crosses two or more systems they use every day. The Friday report that eats four hours of their week. A piece of work they could plausibly imagine running on its own in the background.

In these situations the honest answer is that yes, X is now possible. Most of these things are well within reach of someone willing to spend a couple of hours building.

But is where the trouble starts.

The next stretch, the move from using AI to building with AI, currently does not have great tooling for non-technical users. It’s the bit where the abstractions leak. The interfaces start asking for an API key. There’s a configuration screen with words on it like variable, endpoint, or scope. You have to log into a developer portal you’ve never seen before and click through three confirmation screens with code references. Something asks for your credentials and you’re not entirely sure why.

The term deer in headlights feels right here

For most people, it’s a glass door at full speed. They get to it, they bounce off, and a quiet sense of this isn’t really for me settles in. Worst of all, that bounce can undo some of the confidence they built in the first lift. The earlier ten-percent uplift was reinforced by feeling capable. Hitting the wall on a random Tuesday afternoon when the inbox is screaming with demands from others feels like being told, politely, that the tools were never really meant for them in the first place.

Most people are not wired to brute-force their way past a confusing screen at 2am, they want to close the laptop and get on with their lives at 5pm. That mindset gap turns out to be the single biggest predictor of who crosses the AI building gap and who doesn’t, far more than role, age, or job title.

Now drop this into a normal company.

Most people who come on AI training are, on some level, just grateful to have a day or two where their brain doesn’t have to be in the same place it usually is. The training is restful in a way that has nothing to do with the content. They learn something useful (well that is my objective when training) sure. But most attendees leave with a useful tweak to their day, not a transformation. They take the small win, and the much larger one, sitting just behind it, quietly slips away.

The reason isn’t that they didn’t enjoy it. The reason is that the rest of their working life isn’t designed to absorb the monumental transformation what they just learned. Going from 0 to 100x in a single day is simply too much of a change to land properly.

A normal nine-to-five is a steady stream of small, urgent obligations. Meetings. Reviews. Commitments made last week. The space required to sit with a new tool, hit the wall, and push through it doesn’t naturally exist anywhere in that schedule. So the moment people get back to their desks, the pull of the urgent overwhelms the pull of the new. The cognitive cost of crossing the wall, in that environment, is just slightly higher than the cost of going back to doing things the old way. So they go back to doing things the old way.

This isn’t a willpower problem. It’s a system design problem.

If the training itself is the only protected slot in someone’s calendar where they can actually concentrate, the obvious move is to give them more of that, but smarter.

This isn’t a replacement for adoption training, it’s what comes next. What I think most organisations should be running, on top of the training they’re already doing and as the natural follow-on to it, is what I’ve started calling build clinics. Half-day blocks, booked in like training, treated like training by the rest of the calendar, but structurally completely different from a traditional training day.

People book a half-day to come and build something they actually want to build. Not a generic exercise. Their thing: the report they hate writing every Friday, the client onboarding flow they keep doing manually, the spreadsheet that eats their Monday afternoon. They turn up to a room. There’s a ratio of about one technical supervisor to five participants. The supervisors aren’t there to teach a lesson. They’re there to unblock people the moment they hit the wall. What does this variable mean? Why is it asking for an API key? Where do I get one? What does this error message actually mean?

The point of this session isn’t to make everyone technical. It’s to make sure that the inevitable, predictable wall (the moment that would normally end the journey at home alone on a laptop or between meetings) gets cleared in five minutes by someone who’s seen it a thousand times. And critically, these aren’t one-off events. People come back, weekly, fortnightly, monthly, whatever rhythm the work demands, to push the thing they’re building forward, hit the next wall, and clear that one too.

The first session opens the door.
The repeat visits are where the compounding actually happens.

If the output of those sessions is a working tool that saves the participant several hours a week, the cost of running them is repaid almost immediately. Also once they get it they tend to share their wins with this colleagues and they do so in the organisational language that makes it accessible to a wider audience that an external trainer/educator.

The reason most companies aren’t doing it isn’t that the maths is bad. It’s that the format doesn’t fit cleanly into existing categories. It isn’t training. It isn’t a project. It isn’t a hackathon in the traditional sense. It sits awkwardly between learning and delivery, which is exactly the gap where the building work actually lives.

This is the bit organisations need to design for. Not more workshops. Protected build time with expert help on tap, on a recurring basis once people have the fundamentals. The shift of AI unlike other technologies is that once people get the understanding they don’t need to learn vertical streams of products they need to understand the systems thinking of their roles.

And to be clear about who this is for: it isn’t IT. It isn’t engineering. It’s the finance analyst, the marketing manager, the ops lead, the HR business partner, the customer success rep. The people who actually know where the friction lives in the day-to-day work, because they’re the ones living in it. With the right training and support, every one of them can build the tools that make their own role work better. That’s the real shift.

The builder layer of a company stops being a small specialist team in the technology department off to one side and becomes, in principle, everyone.

Now, the good news.

Some of this friction is starting to be removed by the tools themselves. Claude’s recent push around skills and the co-working features is genuinely interesting. The model itself starts to do some of the scaffolding work that used to require a human helper sitting next to you. Microsoft’s new Copilot cowork feature, currently in preview, leans on the same family of Anthropic models but inside the Microsoft data perimeter, which removes most of the security and trust objections enterprises have had about putting real AI workflows into these systems.

I don’t think enterprises have fully clocked yet how much this changes things.

The version of Copilot most people in big organisations have used so far has been, frankly, underwhelming. The new one is much closer to the experience of working in Claude or ChatGPT directly, but inside the Microsoft data boundary. When that lands properly over the next few months, you’re going to see a step change in what the average employee can build, because the wall between using and building will move significantly for everyone.

Now scale this up. Imagine fifty people in your business have crossed that gap. Each one is saving ten hours a week with automations they built themselves. Each one is producing work that used to take a small team. Each one is quietly making tools their colleagues start asking to borrow. Multiply that across a few hundred staff and the maths stops being subtle, both for the individuals and for the business around them.

The cost base shifts.
The output shifts.
The shape of the work starts to shifts with it.

And once it’s happening at any kind of scale, a question nobody has had to seriously answer before lands hard on the desk: who actually owns all of this?

Right now, when an employee builds an agent that quietly turns them from one-person to the output of a team of ten, that agent lives on their own account even in an enterprise setup. It is, in every meaningful sense, their creation.

What nobody sees is the engine producing it.

The agents aren’t on any org chart. They aren’t in any system the business audits. So whatever the legal answer turns out to be, in practice they sit with the person who built them, because the company doesn’t know they’re there in the first place. Tomorrow, those agents will live in the organisation’s environment. They’ll be governed, audited, shared, and reused.

Now think about what happens when one person inside a company crosses the gap and starts compounding agents.

Their personal output is enormous. They have, in the language of an earlier article, become a HALO, a human-agent led operator running a stack of agents around a clear outcome. Brilliant for them. Brilliant for the company that employs them.

Right up until the moment they leave.

When that person walks out, they are no longer taking one person’s experience with them. They’re taking the equivalent of a small department’s productive capability, encoded in agents they built, in workflows they designed in their own time, in tooling that knows how their domain actually works. The IP that used to walk out of buildings as tacit knowledge in someone’s head now walks out as concrete, reusable, automated capability.

Organisations have not really woken up to this yet, but they will. Fast. The natural response, once they do, is to centralise. The business will start owning the agents. Experts inside a domain will be asked, gently at first and then less gently, to publish their agents into a shared environment. Those agents will be deployed across the wider organisation in much the same way presentation templates are today, except instead of a layout, the artefact being shared is a working capability.

This is going to be a very useful thing for businesses, and a slightly uncomfortable thing for the individuals who built the agents in the first place. There’s a real contention sitting under all of this. Do you employ someone to be productive, or do you employ them to move the dials? For a long time, those two things were close enough to the same answer that nobody had to resolve it.

Once individuals can compound their personal productivity by twenty or thirty times, they’re not the same answer any more.

There is, I think, a small window opening right now.

For the next nine months or so, before centralisation hardens, the people who’ve genuinely crossed the gap have a moment of real leverage. Not in the IP they built on company time, that question is about to get a lot more legally tidy, and rightly so. The leverage is in the capability itself. The instinct for spotting where AI can help. The experience of having shipped something useful. The comfort with the tooling. That capability travels with the person, not the laptop.

For the genuinely productive, this is also the moment to renegotiate the deal. If you’re producing the output of three or five people, the conversation with your employer can stop being about hours in a seat and start being about what you actually deliver. Push for output-based compensation. Ask about equity, shares, profit share, anything that ties your reward to the value you’re creating rather than the time you’re spending. Some companies will say yes, faster than you’d expect, because they’d rather lock in a builder on better terms than lose one. Others will say no, and that tells you something useful too.

Some people will use this window to negotiate harder where they are. Others will use it to build something of their own, in their own time, on their own systems. Both are good options.

That window will close. Once organisations get serious about owning the agent layer, employment contracts will change. Tooling will lock agents inside corporate tenancies. The default will quietly shift from employee-owned to employer-owned, and most people won’t notice until they try to leave with their stack.

There’s also a quieter version of this for everyone who isn’t building. If you’re using agents someone else made, sitting on top of an internal stack that’s quietly doing forty percent of your job in the background, your role is changing whether you’ve clocked it or not. The work that used to need you is increasingly being done around you, and the interesting question isn’t whether the tools are good, they are, but whether you’re adapting alongside them.

The move that sets people up well is to keep developing the thing the tools can’t replace: the judgment, the framing, the ability to spot when the AI is wrong, the relationship with the work itself. The CV is yours. The experience is yours. The judgment is yours. The stack is the company’s. People who keep growing with the work tend to come through this fine. People who lean entirely on tools they didn’t build can find, the day they move, that the role they thought they were doing wasn’t quite the one they were actually doing. That isn’t a story to be afraid of. It’s a prompt to stay engaged with the craft underneath the productivity, not just the productivity itself.

This, in the simplest possible terms, is why I keep telling people the move right now is to build, not just to use. Using will be the default of every tool inside two years. Everyone will have it, and it will count for very little. Building is what compounds. Building is what walks with you when you move. And the window where being a builder genuinely sets you apart is wide open right now.

If you’ve built something genuinely valuable in your own time, this is the moment to lean in. Push it further. See how far it can go. Use it to negotiate, to take on bigger work, to start something on the side. The people who treat this window as an opportunity rather than a curiosity will come out of it with leverage they didn’t have before.

And if you haven’t built anything yet, this is the moment to start. The more of your output that’s powered by tools you didn’t shape, the more your work starts to look interchangeable, and the more of the value the technology absorbs rather than you. Build something small. Build it for yourself.

Build something that solves a problem only you’d notice, in a way only you would solve it. That’s the thing that keeps the work yours.

Organisations are going to cut anywhere between thirty and sixty percent of their headcount over the next few years, some quickly, some slowly, depending on how aggressive their leadership is willing to be. Some will do it because of genuine AI productivity gains. Some will do it because their boards want the share-price story now and intend to figure out the productivity later. The latter group is going to find the next twelve months harder than they think.

If you’re personally good at what you do, none of this needs to feel like a threat. The same forces that are making organisations smaller are making capable individuals dramatically more leveraged than they have ever been. You will either become one of the small number of people doing the work of ten, and you should fight to be properly paid for that, or you will take that capability outside and build something of your own. Both are good options. Both are, for the moment, available.

The thing not to do is sit still. The Builder Gap is real, the wall in the middle of it is real, and the world on the other side of it is being built by the people willing to climb over it now.

That’s almost always been how these moments worked.