Ten Times the Man,
a Hundred Times the Team

Prologue

The Question

People keep asking whether artificial intelligence is going to replace human beings. After a few years of working with it almost every day, I've come to think that's the wrong question.

The interesting one is quieter: how much more capable does an ordinary person become when they work alongside it? Not a corporation, not a research lab, not a university with a budget. One human being.

In my case that human being is a veteran IT consultant whose career started well before personal computers were a normal thing to own. I've worked through typewriters, mainframes, minicomputers, PCs, the Internet, the cloud, smartphones, and now this. Decades of designing systems, solving problems, writing documentation, building businesses, and telling stories. And in all that time the limit was never a shortage of ideas. It was time. There were always more ideas than there were hours to chase them.

AI changed that equation. Not completely, but dramatically. My honest estimate is that it has multiplied my practical output by roughly an order of magnitude — that I now get through something like ten years' worth of intellectual work in what used to take one. That's an extraordinary thing to claim. The rest of this essay is my attempt to show the evidence, mark where the evidence runs thin, and explain why I believe it anyway.

Part I · The turning point

The Strawberry That Changed Everything

The most important thing I ever learned about artificial intelligence didn't come from a paper, a lecture, or a conference. It came from a strawberry. More precisely, it came from a friend.

I'd been working with a colleague for the better part of my career — decades — and at the time I was thoroughly intoxicated with how good this new technology seemed. It could draft a contract, explain a tax structure, walk me through the thermodynamics of a heat pump without breaking stride. I'd handed it a kind of authority without noticing I'd done it. My friend hadn't. He said, in so many words: you've got to be careful with this thing. Then he told me to go and ask it how many R's are in the word “strawberry.”

I did it half to humour him. It's a stupid little question — that's the point — and I expected the obvious answer. What I got back was wrong. The same calm, competent tone it used for everything else, and a number that simply wasn't right.

My first thought was that it was a joke — that some programmer had slipped a gag into the system. So I went digging. Three or four layers down into why it had happened, the laughter stopped. That was the holy moly moment: I realised I didn't actually understand what was going on inside the thing I'd been trusting all day. And that single crack — one misspelled fruit — is what sent me down the road of learning how to get genuinely better information out of these systems.

Up to that moment I'd been doing what most people do without noticing. The answers sounded intelligent. The explanations hung together. The language was persuasive, and most of the time the answers were even correct. But the strawberry showed me the gap I'd been ignoring. Feeling correct and being correct are not the same thing, and a language model is built to optimise the first one.

Why it couldn't count

What makes the strawberry useful isn't that the model failed. It's why it failed, because the reason explains almost everything else that goes wrong with these systems.

A language model doesn't read letters. Before your text reaches the model it gets chopped into “tokens” — chunks of characters the system treats as single units. “Strawberry” doesn't arrive as s-t-r-a-w-b-e-r-r-y. It arrives as two or three blobs, and the model has never seen inside them. Asking it to count the R's is like asking you to count the windows in a building you've only ever seen as a dot on a map. You can guess. You'll probably guess wrong.

So the failure wasn't a glitch. It was the architecture doing exactly what it does. The model predicts the most plausible next stretch of language based on everything it absorbed in training. It is, in the most literal sense, a very sophisticated autocomplete. It doesn't know facts the way a historian knows them or numbers the way a mathematician knows them. It knows what language usually looks like near your question, and it produces more of it.

Most of the time that works astonishingly well, because fluent language and correct language usually sit close together. The trouble is the times they don't — and when they part company, the model has no internal alarm. It hands you the wrong answer with precisely the same confidence as the right one. The industry calls these failures “hallucinations,” which is a bad word for them. Nothing mysterious is happening. The machine is doing the only thing it can do, and sometimes the most plausible-sounding sentence simply isn't true.

The more persuasive the prose, the easier it is to mistake fluency for accuracy. That is the trap waiting for every new user.

The second lesson: it won't even be wrong the same way twice

There was a second jolt, and it landed before I'd fully digested the first. A man I know here in Portugal — sharp, confident, sure he had the measure of the thing — had been asking ChatGPT about buying a car here: the process, the costs, what to watch for. He came away certain. The trouble was that the answer he'd been given was, on inspection, nonsense.

This was still in my own pre-strawberry days, so I half-believed it too. I took it to another friend who actually knew the subject, and tried to convince him the machine was right. He wouldn't have it. “Look, Rob,” he said, “that simply cannot be.” So I said: let me show you. I opened the thing up, asked the very same question in front of him — and got a completely different answer. I tried again. And again. I could not reproduce the original, no matter how I phrased it.

That was the second phenomenon, and in some ways the more unsettling one. The first lesson is that a confident answer can be wrong. The second is that you can't even count on it being wrong the same way twice. Ask the identical question twice and you may get two different replies. There is no fixed record behind the curtain to point at and check. Which is precisely why everything that follows — the sourcing, the grounding, the refusal to trust a single pass — stops being fussiness and becomes the only sane way to work.

Part II · The shift

From User to Operator

It took me the better part of a year to act on all this. I dilly-dallied — impressed, then burned, then impressed again — collecting wrong answers and half-trusting them. The intoxication is real, and I think everyone who picks this up feels it: a dopamine hit every time the machine hands you something fluent and finished. The hard part isn't learning the tool. It's letting go of that buzz long enough to see what's actually in your hand.

Where it finally came together for me was at Web Summit. Session after session, I picked up the thing nobody had told me at the start: how to ask. Not how to get a cleverer answer — how to get a more trustworthy one. The moment I learned to phrase the work properly, the productivity I'd been promised for a year finally showed up. Those are not the same question, and confusing them is what cost me the first twelve months.

A model can be brilliant and unreliable at the same time, the way a charming friend can be confidently wrong about everything. The job isn't to make it smarter. The job is to lower the odds that it quietly leads you off a cliff.

In practice that meant I stopped asking for answers and started asking for the scaffolding underneath them. Instead of “what happened,” I'd ask what's established, what's disputed, and what's genuinely unknown. Instead of “who was right,” I'd ask for the strongest version of each side and where the evidence actually backs each one. I demanded sources, assumptions, confidence levels, counterarguments, and a path to verify the thing independently. I made the model separate fact from inference from opinion from speculation, because left alone it blends all four into one smooth paragraph.

The pattern was consistent: hide the uncertainty and errors go up; force it into the open and quality goes up. The goal stopped being certainty and became transparency — not “give me the answer” but “show me your work, and show me where it's thin.” The reasoning often improved not because the model changed but because I did. The operator turned out to be the variable.

Training versus retrieval

The other thing I had to understand was where any given answer was coming from. Some answers come out of the model's training — the patterns it absorbed from billions of words. Others come from retrieval, where the system consults a specific document before it answers. These are not the same act, and confusing them is how people get burned. Training gives you patterns; retrieval gives you evidence. Point the model at real source material and it reads the streets off the map instead of guessing at them.

That single distinction is what pulled me toward retrieval-augmented generation — RAG — which I came to treat less as a technology than as a discipline. The core idea is almost embarrassingly simple: a system that can look things up beats a system that has to guess. Which is exactly as true of people as it is of machines.

Part III · The evidence

By the Numbers

Before AI, every project followed the same sad arc. An idea would show up. I'd make notes, gather references, sketch an outline. Then weeks would pass, life would intervene, and the thing would stall. Some projects survived that gap. Most didn't.

It wasn't laziness. It was that every worthwhile project is mostly mechanical work wrapped around a small spark. The spark — the actual idea — might be five percent of the effort. The other ninety-five is research, organising, drafting, editing, rewriting, fact-checking, formatting. So good ideas died in notebooks, not because they lacked value but because they couldn't clear the labour required to finish them. The bottleneck was never imagination. It was execution.

The discovery I didn't expect

The biggest gain turned out not to be speed. It was exploration. Before AI I filtered hard, and I did it without noticing — some ideas felt too ambitious, others too speculative, most simply not worth the hours. That filtering was rational when execution was expensive. It was also quietly killing things that deserved to live.

AI changed the economics of curiosity. When an idea can be tested cheaply, more ideas become worth testing. The strange result: the number of finished projects went up, but the number of attempted ones went up faster. The real value wasn't just faster execution. It was that the cost of experimenting fell through the floor.

Part IV · What accumulates

The Personal Knowledge Machine

The most consequential thing may be something I built entirely by accident. Without setting out to, I've assembled what any practitioner would recognise as a retrieval-augmented system of my own — a personal RAG.

Every project leaves a trace. Every conversation adds context. Every story, proposal, technical thread, and bit of family history becomes another layer in a growing archive, and over time that archive stops being a pile and starts having shape. It now holds my history, my technical expertise, my creative work, the family stories, business plans, the positions I've argued, the things I care about. That isn't just data. It's organised memory — it remembers not just what I said, but why, and what it connected to.

People have always offloaded memory onto something: first memory itself, then notebooks, then filing cabinets, then computers, then search engines. What's arriving now feels like a genuinely new link in that chain. For the first time it's practical not for billion-dollar companies but for one person at a kitchen table to ask: what did I conclude about this five years ago? What was my strongest argument? Pick up that abandoned story and keep going.

But an archive I have to feed by hand is only half a machine. The next four sections are about what happens when the machine stops waiting for me to bring it things.

Part V · The pipeline

The Capability Ladder

Everything so far has described a machine that knows things — one I consult, point, and correct. But the systems people are now building around these models climb a ladder, and each rung hands the machine more power. It's worth seeing the whole ladder at once before walking up it, because the shape of the climb is the shape of the risk.

The rungs are easy to name once you stop treating them as rival products. RAG is how the machine knows — it looks things up. MCP is how it reaches — it connects to live tools and data. Skills are packaged competence — a playbook it loads to do one kind of job the same way every time. Agents are autonomy — the machine given a goal and let off the leash to use everything below it. They don't compete. They stack. And they don't stop at the individual: two more rungs sit above, where the same stack goes collective — a team sharing one machine, and an organisation that can be asked about itself. That's where the second half of this essay is heading, and it's the steepest part of the climb.

Part VI · The first rung up

Hands, Not Just a Voice

There's a limit hiding in everything I've described so far: the personal knowledge machine, as I've built it, is something I feed by hand. I find the relevant document, I paste it in, I point the machine at the right corner of my own history. RAG taught the model to look things up — but in my setup the thing doing the looking up is me. The model has a superb memory and no arms.

That's the gap a thing called MCP closes. MCP stands for Model Context Protocol, and the grand name hides a deliberately boring idea: it's a standard plug. Think of the years before mains sockets were standardised, when every appliance needed its own wiring. A standard plug ended that — build the socket once, and anything with the matching pins just works. MCP is that socket between a model and the live world: your files, your email, your calendar, a search engine, the database that holds your archive. Wire it once and any tool snaps into any model.

The change is larger than it sounds. The model stops being a thing you consult and becomes a thing that reaches. Where RAG gave it a mouth, MCP gives it hands.

And the moment you hand a machine hands, the strawberry comes back to collect. A confidently wrong paragraph costs you a reread. Give that same machine the ability to send the email, move the money, delete the file, commit the code — and a confidently wrong action is a different animal. The fluency hasn't changed. The stakes have. Which is why, in any honest wiring of these systems, there's a small, unglamorous checkpoint marked something like approval request — the point where the machine stops and waits for a human to say yes. That box is the whole essay, rendered in plumbing. It's the operator keeping hold of the wheel.

Part VII · The second rung

Playbooks on the Shelf

If MCP gives the machine hands, Skills are what teach those hands a trade.

A skill is packaged competence — a small, reusable bundle of instructions and tools that tells the model how to do one specific kind of job properly, the same way every time. Not facts, the way RAG supplies facts. Not wiring, the way MCP supplies wiring. A method. A recipe the machine pulls off the shelf when the task calls for it: how to build a document to a house standard, how to fill a particular form correctly, how to lay out a deck the way we actually lay them out.

I'd been doing this by hand for years without a name for it. Every time I wanted a proposal formatted my way, I'd explain my way again. A skill is that explanation written down once and handed over as a standing instruction, so the machine stops asking and starts knowing. The first time I want it, I describe it. Every time after, it just happens.

Consistency is not correctness. A skill that bakes in a wrong assumption fails quietly and reliably — the same mistake on every job, with the calm competence of something that has clearly done this a thousand times.

That's the strawberry in a new coat. A bad guess fails loudly and occasionally; a bad skill fails softly and every time, and the better it looks the longer the flaw survives. So the operator's job doesn't shrink when the machine gets a playbook. It moves — from checking the answer to checking the method.

Part VIII · The top of the ladder

Off the Leash

Everything so far still waits for me. I ask, it answers; I point, it reaches; I invoke, it performs. An agent is what you get when you stop holding its hand at every step.

Give a model a goal instead of a task — not “draft this paragraph” but “get this done” — and let it plan its own steps, call its own tools through MCP, load its own skills, look at its own work, notice what's wrong, and try again, looping until it decides it's finished. That's an agent: the whole ladder put to work at once, with the human stepping back from the individual moves and watching the outcome instead.

When it works it's remarkable, and it's where the real leverage of the next few years will live. But this is exactly where the strawberry stops being a charming anecdote. A confidently wrong model given a mouth writes a bad sentence. The same model given a goal and the autonomy to chase it builds a wrong plan on a false premise and then executes every step of it — each step compounding the last, all of it fluent, all of it confident, none of it pausing to wonder — before any human looks. The error doesn't sit on the page waiting to be caught. It runs.

So the operator's job reaches its final form here, and it isn't doing the work. It's deciding the leash. Where must this thing stop and ask? What may it do without me, and what must it never do without me? The skill that matters at the top of the ladder isn't prompting or wiring or any of the clever parts. It's judgement about how much rope to give a brilliant, tireless, occasionally and invisibly wrong assistant — and the discipline to keep hold of the other end.

Part IX · The turn outward

A Hundred Times the Team

Everything in this essay has been about one human being and a machine. The title says as much — ten times the man, singular. But the most interesting question sitting at the edge of all this is what happens when it isn't one of you. And the honest answer is that the individual story, the whole of it, may turn out to be the small story.

Here is why. The easiest project in the world to run is a project of one. One person needs no status meetings, no governance, no communication protocol — most of what they know simply stays in their head, and there's no one to hand it to. Add a second person and you have to start talking: decisions shared, assumptions clarified, responsibilities split. Add a third and it gets worse, and it keeps getting worse in a way that isn't linear. The number of channels along which a group of n people must communicate is n(n−1)/2 — so ten people have forty-five lines to keep straight, and a hundred people have very nearly five thousand.

I've spent my career inside large programmes where that arithmetic does the killing — ERP rollouts, Lawson and Infor systems, healthcare and infrastructure work, the big ones. The technical problems were hard, but they were rarely what sank a project. What sank projects was that the knowledge was scattered: the sponsor knew one piece, the architect another, security a third, the vendor a fourth, and nobody held the whole picture. Warnings arrived too late. Dependencies stayed hidden. Decisions made in spring were rediscovered, painfully, in autumn. The expensive part of a big organisation was never the work. It was the talking about the work.

Which reframes the whole question. If the real cost of working together is communication, then the largest prize in all of this was never helping one person write faster. It's helping a group talk less and know more — compressing that quadratic curve back down.

You can see it arriving in three waves. The first wave, the one nearly everyone is in now, makes individuals quicker: draft this, summarise that, write the code. The interaction stays private and the org chart doesn't change. The second wave gives the machine the team's shared material — the transcripts, the tickets, the plans, the chat, the metrics — so it stops assisting a person and starts understanding the project. Now the question that used to mean an afternoon in old email threads gets answered in a sentence. The third wave is the one I find genuinely startling: every project feeding a shared, AI-held memory, until the organisation can be asked about itself. What's the status, what's at risk, what did we decide and why, what's the new person missing. Knowledge stops travelling person-to-person through meetings and starts living in something the whole enterprise can query.

That third wave is the real claim behind the slogan. It's not faster documents. It's a standing organisational memory — a kind of nervous system — that captures a fact once and makes it available to everyone who needs it, instead of transmitting it down forty-five separate wires and losing something at each hop. Humans still hold the things that are ours: judgement, leadership, ethics, negotiation, the actual decisions. The machine's job is humbler and enormous — making sure the people deciding can see the whole board.

The chain is worth spelling out, because the leap from “less talking” to “more output” is exactly where this kind of argument usually cheats. It isn't that the machine makes the team a hundred times cleverer. It's that compressing the communication shortens every link after it: facts surface sooner, so decisions get made faster; faster decisions mean the work stops waiting on the work; less waiting means less rework, fewer dead ends, fewer warnings that arrive too late to act on. The productivity gain is the last link in that chain, not the first — the pay-off for removing friction a large team otherwise spends its days generating.

So I'll put the figure plainly, and flag it as the most speculative thing in this essay: an individual lands near ten times. A team that does this right can reach into two orders of magnitude. A hundred times the team — not because anyone works a hundred times harder, but because most of what a big organisation wastes was never work in the first place.

Part X · The catch

The Multiplier Has a Sign

Everything I've just described has a shadow, and it's the same law this whole essay keeps running into. The organisational nervous system only helps if what flows through it is true. A shared memory the whole company trusts will distribute a confident mistake exactly as efficiently as it distributes a fact — faster, in fact, because nobody re-checks the thing everybody already believes. A confidently wrong answer in my own workspace costs me a reread. The same answer in a shared system that a dozen people trust travels through all of them, each one reasonably assuming somebody else had checked. The verification habit that protected one careful operator only protects a team if the whole team holds it. The error rate of the group is set by its least sceptical member.

So the very thing that makes the hundred-times figure possible — one source of truth everyone draws on — is also what makes it dangerous. Fragmented human knowledge at least fails in small, local ways. A single trusted memory fails globally. Which means the discipline from Part II can't stay personal. It has to become a team norm, or the compression just gives you a faster route to being wrong together.

The evangelist's problem

I know this because I've watched it go wrong. Somewhere along the way I became the man who tells everyone what they're doing with this technology improperly — and there's no comfortable way to be that man. People resist. Some are sure I'm inventing the danger. I've learned to walk away from the conversation more often than I'd like. Meanwhile the proposals go up to managers half-mutilated by errors nobody checked, written in the bloodless voice of a machine nobody steered. And then, often enough, the same people come back: Rob, you were right.

It's the Cassandra position, and I've made my peace with it, because the thing I'm warning against is real and I felt it myself first. It's an intoxication — close to a dopamine hit — that the fluency of these tools sets off in nearly everyone who picks them up. We've all felt it. Getting the leverage means letting it go: seeing past the buzz to what's actually in your hand. That's the move that turns a dazzled user into a ten-times operator. And when a whole team makes that move together, the discipline stops being one person's private virtue and becomes shared craft — which is the only thing that lets the hundred-times figure mean anything but a hundred times the mess.

Part XI · The honest part

How Much Should You Trust These Numbers?

An essay that argues confidence isn't correctness has no business presenting its own figures as hard fact. So here is the register, with the basis and the confidence for each claim laid out plainly. This is the strawberry lesson applied to my own writing.

Almost everything above is a self-reported estimate built from a partial record. Conversations happened across different systems, some anonymously; plenty was never saved. That doesn't make the numbers worthless — it makes them estimates, which is a different thing from measurements, and they should be read as such.

The pattern in that table is itself the finding: the claims about how the technology works are solid, and the claims about my own output are soft. The team figure is the softest of all — it's a direction I'm confident in and a magnitude I'm guessing at. That's honest, but it's also fixable, which is the point of the next section.

Part XII · Doing it properly

A Framework for Honest Self-Assessment

If I were going to make these claims rigorously rather than impressionistically, here is what I'd instrument. The good news is that AI work throws off measurable exhaust — we just don't usually capture it. The principle is the one this whole essay turns on: replace recalled impressions with retrieved evidence. Apply RAG thinking to the assessment itself.

Do that, and the next version of this essay won't need a reliability register at all. It'll have the logs.

Part XIII · The case against

Where This Breaks

I've spent twelve sections making the case for. An honest essay owes a section to the other side — not as a courtesy, but because the failure modes are real and I've walked into several of them myself. Here is where the argument above goes wrong.

The shared memory can be confidently, permanently wrong. Everything good about the organisational nervous system — one trusted source everyone draws on — is also its worst failure mode. Feed it a bad assumption and you haven't made one person wrong; you've made the whole enterprise wrong, in unison, with great conviction, and you've removed the friction that used to let a sceptic somewhere catch it. Fragmented human knowledge at least fails locally. A single source of truth fails globally. The strawberry doesn't get safer at scale. It gets worse.

Garbage in is now garbage at speed. A retrieval system is only as good as what it retrieves. Point it at a tidy archive and it reads the streets off the map; point it at a decade of contradictory documents, stale decisions, and half-finished threads — which is what most real organisations actually contain — and it will synthesise that mess into something fluent and authoritative and wrong. The curation problem from Part IV doesn't shrink when you scale it. It becomes the whole game.

The machine can only hold so much in its head at once. These systems have a context window — a hard limit on how much they can consider in a single pass. Past it, things silently fall out of view. A model can give you a confident answer about a long document while having quietly lost the middle of it, and it will not tell you that's what happened. The bigger and more ambitious the task, the more this matters, and the easier it is to miss.

Then there's what you're handing over. Wire a model into your live systems and let agents act, and the question stops being “is it right” and becomes “what did I just grant access to, and where does this data go.” Security, privacy, who-can-see-what, which regulator cares — these are not afterthoughts to bolt on once the productivity arrives. They are the price of admission to the upper rungs of the ladder, and in regulated worlds like the healthcare and finance work I've lived in, they can be the thing that decides whether any of it is allowed at all.

And the people problem is the one I'd bet on. Two versions of it. The first is resistance: plenty of capable people will not adopt this, on instinct or principle, and a hundred-times team with three hold-outs is not a hundred-times team. The second is worse, and quieter. A junior who arrives into all this tooling, having never worked without it, inherits the leverage without ever learning the discipline that makes it safe — the interrogation, the scepticism, the strawberry scar. They get the wheel without learning that the car drifts. The whole argument of this essay rests on the operator being the variable, on a human keeping hold. That assumption is exactly what an over-reliant culture quietly dissolves.

None of these sink the thesis. But every one of them is a way the order-of-magnitude turns negative — and the same property is behind all of them: the better this technology gets at sounding right, the more expensive it becomes to be wrong.

Which is, in the end, the strawberry again, wearing its largest coat. The case for is real. So is the case against. The whole essay has only ever been arguing one thing: that the gap between the two is closed by a human who refuses to stop checking.

Epilogue

Ten Times the Man, a Hundred Times the Team

The title is deliberately provocative, and I should be honest about what it doesn't mean. I'm not ten times smarter than I was, or ten times more creative, or ten times more knowledgeable. What I am is ten times more able to turn an idea into a finished thing. That distinction is the whole essay.

For nearly all of human history, ideas were cheap and execution was dear. AI flips that balance. But the gift came wrapped in a warning, and the strawberry was the warning: a tool this fluent and this confidently wrong will run off a cliff if you don't keep hold of the wheel. The people who get the most from these systems aren't the ones who trust them most. They're the ones who learned to interrogate them.

So the deeper story was never “AI made me ten times more productive.” It was this: I started by believing the machine knew things, and I ended by learning how to interrogate knowledge itself — its own, and my own. The greatest gift these tools gave me isn't faster writing or tidier numbers. It's that I can finally chase more of the ideas that make a life interesting, and that I've gotten better at telling confidence from correctness while I do it.

And the part I'm only beginning to see is that this doesn't stop at one person. The discipline travels. Hand it to the people beside you and the man who became ten times himself becomes a team that is something nearer a hundred times what it was — if, and only if, the scepticism travels with the tools.

If I had to make one prediction, it would be this. The story everyone tells about AI is replacement — the machine that does the thinking instead of us. I think that's the wrong story, or at least the small one. The thing I keep running into, in my own work and in every team I've watched try this, is that the machine's largest effect isn't on any single mind. It's in the space between minds — the meetings, the handovers, the forty-five wires down which a hundred-person organisation loses a little of the truth at every hop. The most important thing these tools may do is not replace human thought. It's reduce the friction between human thoughts. AI as a connective layer between people, not a substitute for them. That's the idea I'd stake the essay on.

For the first time, the limiting factor isn't whether I can make something. It's choosing which of the many things I want to make next. The strawberry taught me that. Everything else followed.