My View Of AI (September 2026)

AI is not taking anyone's job. The person sitting next to you who has learned to use it well is going to take yours, and that distinction matters more than almost anything else being said about this technology right now.

I want to be precise about that claim, because it gets flattened into a slogan too easily. The tool itself has no ambition. It doesn't want your role, your title, or your client relationships. What it does is remove the excuse for doing the slow version of your job when a faster version is available to whoever picks it up first. Every capability shift in the history of work has followed that pattern, and the people who suffered were rarely the ones replaced by the machine directly. They were the ones who refused to stand next to it.

There's a fact I keep coming back to when people ask me whether AI is going to "wipe out" some category of job the way factories once wiped out entire trades. The last job actually eliminated by automation, in any complete and total sense, was the elevator attendant. Think about how specific and how narrow that is. We automated flight, we automated arithmetic, we automated global logistics, we automated document retrieval that used to take a research librarian a week — and still, almost every occupation touched by that wave didn't disappear. It changed shape. The travel agent became a specialist in trips regular software can't plan. The bookkeeper became a controller who spends their week on judgement calls rather than data entry. The tasks inside the job got rewritten; the job itself mostly survived, just doing something more interesting than before. I'd be cautious betting AI breaks that fifty-year pattern completely, though I'll admit the pace and breadth of this particular wave is unlike anything that came before it, which is exactly why the response to it matters so much.

What I think is actually happening, and what I see happening in my own work, is a change in what a "team" looks like day to day. A year or two ago, if you wanted more output, you hired more people. Now a meaningful amount of new capacity comes from directing more agents. I don't mean that abstractly — I mean the literal daily experience of reviewing several parallel streams of work, deciding which one deserves your attention first, and stepping in only where judgement is actually required. That's a management skill. It has always been a management skill. The difference is that it used to apply only to people with mortgages and career aspirations of their own, and now it also applies to software that will happily work through the night without complaint or ego. Learning to manage a team well — set direction, delegate with enough context that the delegate doesn't need you every five minutes, review outcomes rather than micromanage steps, know when to intervene — turns out to be exactly the skill this moment rewards. The engineers and operators I know who were already good at leading people are adapting to leading agents faster than the ones who were only ever good at doing the work themselves.

The practical upside of all this is real and it's not subtle: things get to market faster. A body of work that used to take a small team a quarter can, in the right conditions, take a fraction of that. I don't say this to hype the technology — I say it because it changes the economics of trying things. When the cost of building a first version drops, you can afford to be wrong more often on the way to being right, and that's a genuinely good trade for anyone building a product, testing a business idea, or trying to solve a problem that matters to real people. Commercial viability, which I think about a lot, gets easier to reach when the distance between "idea" and "something a customer can react to" shrinks.

But — and this is the part that gets skipped in most of the AI commentary I read — none of that speed shows up reliably unless you do the unglamorous work first. I've watched this closely enough now to be confident about it: the difference between a team getting brilliant, dependable output from AI and a team getting an expensive mess isn't the model they're using. It's whether anyone bothered to write down what "good" looks like before they started. Context, coding standards, and architecture patterns aren't bureaucracy you tolerate on the way to the real work anymore — they are the real work, because they're the mechanism by which you turn a genuinely capable but context-free tool into a genuinely reliable one. An agent that doesn't know your testing conventions will write tests that pass and teach you nothing. An agent that doesn't know your data-handling obligations will build something fast that a security review then has to unwind. The organisations getting consistently good outcomes are the ones that treated "tell the AI how we do things here" as seriously as they'd treat onboarding a senior hire, because functionally, that's what it is.

That last point is the one I'd underline for anyone still deciding whether this is worth their attention. This isn't a tool you can politely decline and carry on as before, the way you might skip a fad framework or a productivity app that never quite stuck. It's already changing what the job looks like for the people who do choose to use it, which means it's changing the job for everyone in the same market whether they've opted in or not. I don't think that's a comfortable thing to say, and I don't think it needs to be dressed up as anything other than what it is. The people who get good at giving clear direction, setting real standards, and reviewing outcomes rather than doing every step by hand are going to look, within a few years, like the people who got good at spreadsheets in the nineties or the internet in the two-thousands. Not because they were smarter, but because they showed up to something that was going to change their work regardless of what they decided about it, and they decided to be curious rather than defensive.

So here's the thing I'd actually ask companies to commit to, and it isn't the thing most of them are currently drafting. Almost every responsible use of AI policy I've read so far is written in one direction only: here is what you, the employee, may not paste into a chat window, here are the tools you're permitted to use, here is the disclosure you must make, sign at the bottom. All of that is fine as far as it goes, and some of it is genuinely necessary. But it's a policy that binds the least powerful party in the arrangement and asks nothing of the organisation writing it. The clause I want to see is the one pointing the other way — a written commitment that the company will keep hiring junior people, keep giving them real work rather than the scraps an agent didn't want, and keep senior people accountable for mentoring them. Put it in the same document, with the same weight as the confidentiality rules, because it's a commitment of exactly the same kind: a constraint you accept now to avoid a harm you can already see coming.

The reason it needs writing down is that the incentive runs hard the other way. Junior work — the first draft, the small well-specified ticket, the test suite nobody enjoys writing — is precisely the work an agent does most cheaply, so the saving from not hiring a graduate is immediate and visible on a spreadsheet this quarter, while the cost of not hiring them is deferred by about a decade and lands on somebody else's watch. But you don't source senior engineers, you grow them, and they grow by doing the unglamorous work badly a few times with someone experienced telling them why. Cut that pipeline for ten years and you arrive somewhere genuinely difficult: enormous volumes of machine-generated work and a thinning population of people with the earned judgement to tell good from plausible. Everything I've argued above — that the value moves to direction, standards and review — depends entirely on there still being someone competent enough to do the reviewing. That capability is not a natural resource. It's the direct output of organisations deciding, repeatedly and at some short-term cost, to employ people who aren't useful yet. Not using AI is not the answer to any of this; it never was. Committing to people is.

None of this requires panic, and I'd gently push back on anyone selling panic as the appropriate response. It requires the same thing most durable career decisions have always required: paying attention, being honest about what's actually happening rather than what you wish were happening, and doing the boring groundwork — the standards document, the architecture pattern, the clearly written context — that makes the exciting part actually work. The elevator attendant didn't lose their job because a machine got ambitious. They lost it because the machine got reliable enough that reliability stopped being the scarce thing. Reliability is still the scarce thing today. It's just being built by people who take the time to teach their tools how to be reliable, rather than people hoping the tools will figure it out alone.