You said the same about BIM

Last week I wrote a post about the anxiety many sectors are feeling in the face of AI, and about integrity as a tool to approach the technological shift we’re undergoing. It was a good post. I’m happy about that post. Some people reached out, and it’s not the first time they point out I used to be a technology enthusiast, half-jokingly wondering what happened to me. Some others were more direct, and stressed that those same things I’m calling out about AI, I used to say about BIM, especially when I argued that the industry’s favourite reassurance about AI is a threat in disguise.

BIM won’t replace you: someone using BIM will.

I can neither confirm nor deny that I said that in a conference. My moral compass had been weakened back then (God knows if it had been weakened), and it’s possible I did. So what’s happening, here? Am I the one thing that changed? Hell, maybe I’m just getting old. Plato complained that writing would ruin our memory, and every generation finds a new technology to distrust. Some of my colleagues, after all, are still technology enthusiasts, and some are even saying that we’re just witnessing another technology with the same impact, basically implying that AI is “three BIMs in a trenchcoat”.

Well, I’ve got some good news and some bad news.

The good news is that I’m still a technology enthusiast, and if I write about anxiety and pitfalls this doesn’t mean I don’t believe Artificial Intelligence has the genuine power to improve how people learn and grow and communicate.

Now, every tool changes the way we think. The thermometer turned weather into numbers, the clock turned time into something you spend, and GPS has measurably eroded our sense of place. So when colleagues say AI is just the next BIM, they’re half right: it’s another tool, and like every tool it will reshape us. This is also something I used to say, if you’ve been paying attention. Now, for the bad news: it’s easy to say that AI is just like BIM. Specifically it allows you, if you were considered a BIM implementation expert, to pass as an AI implementation expert with zero effort. Thing is, research doesn’t back that claim: put the two technologies side by side, using what labour economists, cognitive psychologists and computer scientists have actually measured, and they differ on almost every axis that matters.

So this week we take a look at what’s different in the impact between BIM and AI, conscious we’re comparing a rhino and a typewriter. We’ll talk about general-purpose vs. domain tools, about when and how the two technologies fail, about determinism vs structural errors. And we’ll see what it does to the younger generations. AI hits the juniors: BIM made the juniors. And I’ll leave it to you to decide whether I’m getting old (of course I am: the alternative, trust me, is no fun at all).

1. A Rhino and a Typewriter: what BIM actually automated

Let’s start by being fair to BIM, ’cause it made the second part of my career and I owe it that much: before arguing about what AI does, we need to be honest about what BIM did, and that means looking at work as the economists do. Not jobs, but tasks.

In 2003, three economists (David Autor, Frank Levy and Richard Murnane) published a paper that should have become the reference point for anyone studying technology and work, and their idea was simple: every job is a bundle of tasks, and some of those tasks are routine, meaning you can write them down as a procedure, step by step, with no judgment required. Be careful because having a procedure doesn’t mean that a task is routine: the judgment part is the important part. Other tasks are non-routine: they require problem-solving, adaptation, communication, and stuff you can’t easily spell out. Their finding, across four decades of data, was that computers replaced the routine tasks and boosted the demand for non-routine ones. Bookkeeping went to the spreadsheet, and yet deciding what the numbers meant stayed with people who, in the process, became more valuable.

Now look at BIM through that lens.

Do you remember what coordinating a drawing set looked like before BIM? Some of you won’t, and I envy you. Somebody, usually not the most senior person in the office, had to check that the sections matched the floor plans, that the elevations matched the sections, that the door on the plan was the same door in the schedule, with the same width, the same fire rating, the same hardware, that the number referenced in the details actually matched the detail number in the detail sheet. Then a design change came in, someone rummaged through the drawings with their senior paws, and the whole check started over. It was routine cognitive work in the most textbook sense: tedious, error-prone, and perfectly describable as a procedure. Design. We were doing it badly, not because we were stupid, but because humans are terrible at checking the same thing four hundred times without getting bored.

BIM didn’t become better at that check than we were: it made the check unnecessary. When sections, plans and schedules are all views of the same model, they can’t disagree, by construction, unless you really made an effort to break everything your software is trying to fix. Consistency became a property of the method, not the result of someone’s patience. That’s the person BIM automated: the one manually tasked with making sure the drawings agreed with each other. And, of course, it didn’t automate the designer, the engineer, or the person deciding what the door should be. If anything, it gave them more time for that, exactly as Autor and his colleagues would have predicted. BIM complemented the non-routine work and substituted the routine. Hurrah for that.

There’s a second thing BIM did, and it’s the one we tend to forget when we talk about the “pain” of BIM adoption: to work at all, BIM forced us to make our knowledge explicit. Families with parameters, classification systems, naming conventions, levels of information need, schedules with formulas: every single one of these is a piece of professional know-how that used to live in somebody’s head, and now needs to be written down as a rule so that the software can follow it. That’s why BIM implementation hurt so much, and why it takes years: not because the software is hard, but because encoding what we know, and how we do things, is the hard part. Every template we build, every shared parameter file I argue about, is an exercise in turning tacit knowledge into explicit rules. That’s also the part I love about that job.

Once the rules are written, I can move on: the machine follows them, exactly, every time. Remember that, because it’ll matter a lot further down this rabbit hole.

This is where AI turns everything upside down.

The distinction between routine and non-routine rests on an idea from the philosopher Michael Polanyi, and the idea is that we know more than we can tell. There are things we do well without being able to explain how, like recognising a face, sensing that a detail won’t work on site, or knowing that a client’s “small change” is going to blow up the programme. Autor later called this Polanyi’s paradox, and for decades it was a wall that automation couldn’t climb: if you can’t write it down, you can’t program it.

Large language models climb that wall from the other side. They don’t need us to write the rules: they learn patterns from enormous amounts of examples, including patterns nobody ever made explicit, and divine a rule-of-thumb from those examples. That’s why the tasks economists considered safe harbours (drafting, summarising, interpreting, advising, writing the first version of a specification) are exactly where generative AI is landing. Recent research is quite clear on this: the main targets of generative AI aren’t the routine tasks the previous waves of computing went after, but the non-routine cognitive ones.

So here’s the first difference: BIM asked us to make our knowledge explicit, and then it executed our rules, while AI skips the rules entirely and goes straight for what we never managed to write down, making assumptions of its own. BIM took the boring checker job and handed the interesting work back to us. AI goes after the interesting work itself.

A rhino and a typewriter, as I said: both are heavy, both make a hell of a noise, both have the ability to produce an enormous amount of shit, and that’s where the similarities end.

2. A warm light for all mankind to share

Economists have a name for a very special, very rare kind of invention: a general-purpose technology. The term goes back to Timothy Bresnahan and Manuel Trajtenberg in the mid-1990s, and it encompasses a limited about of stuff: the steam engine, electricity, the computer. To qualify, a technology has to spread across practically every sector of the economy, keep improving over time, and spawn waves of further innovation built on top of it. A hammer is useful, but it’s not a general-purpose technology. Neither, and I say this with motherly love, is BIM.

BIM is a domain tool. It was built by and for one sector, it speaks that sector’s language, and outside that sector it means very little, though we’ve adopted it from automotive and adapted it to mean something for the gaming industry. Your accountant probably doesn’t care about IFC, your lawyer has never opened a federated model (lucky bastard) and, god willing, they never will. Even inside our own world it took decades to get where we are, from the first research prototypes in the 1970s, through the first commercial packages in the 1980s and software that actually works in 2000, to public mandates that, in Italy, only became fully binding for most public works in 2025. And every step of that adoption was a sector decision: our standards, our committees, our national annexes, our heated arguments about what a level of information need should mean.

Generative AI didn’t knock on our door, and it didn’t wait for a committee. In March 2023, a team of researchers from OpenAI and the University of Pennsylvania published a paper with the cheeky title “GPTs are GPTs. Generative pre-trained transformers” in which they argued that GPTs (in the sense of Generative Pre-trained Transformer) are GPTs (in the sense of general-purpose technologies). They estimated that around 80% of the American workforce could see at least 1/10 of their tasks affected, and almost 1 worker out of 5 could see at least half. Other teams, using different methods, found the same shape: the most exposed sectors include legal services and finance, and the International Monetary Fund estimated that in advanced economies around 60% of jobs are exposed.

Now, exposure studies have their limits (more on that later), but look at what they describe: AI isn’t a tool for architects, engineers or construction managers, but a technology for everyone at once. A warm light for all manking to share, as Loki would say. And that changes the game in ways that the reassuring crowd keeps missing.

First: we don’t control the adoption. BIM came into our offices through the front door, with a mandate, a standard, a contract clause, a budget for training. You could argue about it, and we did, but there was a moment when someone decided. AI, on the other hand, walked in through every door simultaneously, mostly through people’s phones. Your client is using it to draft the brief and maybe their bosses don’t even know it. Your contractor is using it to read your specifications, and won’t tell you about it. Your client’s lawyer is using it to find holes in your appointment, and God help us all. Most importantly, people are using it whether your policy allows it or not. Nobody decided this, and nobody can undecide it. There’s no UNI committee for that.

Second: our standards don’t reach far enough, and not (just) for lack of trying. ISO 19650 governs how information is managed within the delivery of an asset, between parties who signed up to the same rules. It’s a beautiful system, when everyone’s inside it. But AI crosses every boundary we drew: the text our contractor fed into a chatbot, the clause our client’s assistant rewrote, the summary of our own meeting produced by a tool on someone else’s laptop that states I said something I never said. A domain tool can be governed by a domain standard. A general-purpose technology can’t, or at least not by a domain standard alone.

Third: the real impact comes later, and it comes from reorganisation, not from the tool itself. The economic historian Paul David pointed this out in 1990 with electricity: factories took decades to get the productivity benefits of electric motors, because at first they simply replaced the big steam engine with a big electric motor and kept the same building, the same layout, the same line shafts. The gains came only when someone realised you could put a small motor on each machine and redesign the whole factory around the workflow. Erik Brynjolfsson and his colleagues call this pattern the productivity J-curve.

Does that sound familiar? It should, because it’s exactly what happened and is still happening with BIM. The firms that bought Revit and kept producing the same drawings in the same way got very expensive CAD and doubled their efforts (and their errors). The ones that got the benefits were the ones that rebuilt their processes around information. We know this pattern. We’re living in it. The difference is that with BIM we went through it as one sector, at our own pace, with our own standards to guide us. With AI, every sector is going through its own J-curve at the same time, and they all touch each other.

And this is why I get suspicious when someone with a long career in BIM implementation, people like me, presents themselves as an AI implementation expert overnight: our expertise is real, and some of it transfers, we know how painful it is to make tacit knowledge explicit, we know that tools without processes are just expensive toys. But BIM implementation is about reorganising one sector around a shared model. AI implementation is about reorganising work in a world where the model is everywhere, belongs to no one, and is being reorganised by everybody else at the same time.

A tool for us, a technology for everyone.

3. Chickens Go In, Pies Come Out

There’s a zen-like peacefulness to be found in something like a Revit schedule. If the door schedule says a door is 90 centimetres wide, it says so because somewhere, someone set a parameter to 90. If that’s wrong, the error has an address and, often, a name: a family, a type, an instance, a person who typed the wrong number, a parameter that wasn’t rigged to the right geometry, a formula that was written badly. This doesn’t mean schedules are always right, far from it. Somewhere there’s a list of the gazillion reasons you don’t see your stuff in a Revit view, and deep into my toolbox I have the same list of reasons a schedule might be wrong. The point is: you can trace the reason, you can fix it, and once you’ve fixed it, it usually stays fixed. Run the same model through the same rules tomorrow and you’ll get the same schedule. Honest to God. Same input, same output. Computer scientists call it determinism, and it’s not boring at all, at least if you’ve ever spent a night chasing a coordination error: it’s what makes the job juicy, that the error is findable in the first place.

When BIM fails, it usually fails spectacularly: a warning pops up and pop goes the model, a join refuses to happen, a clash report comes back with four thousand items (or none at all) and ruins everybody’s Friday. Annoying, yes, but straightforward. The software doesn’t pretend it worked when it didn’t. As I was saying, BIM executes our rules, exactly, every time. Now let’s see what happens when there are no rules to execute.

A large language model doesn’t look anything up and doesn’t apply a rule nor a procedure: sure you can direct it with a well-crafted prompt, but its point is that it will try to be flexible and work around stuff you might have misspelled, overlooked, forgotten about. That’s where its power lies, isn’t it? It generates the most plausible continuation of what it’s been given, based on the patterns it learned. Usually, the most plausible continuation is also the correct one, which is why these tools are so astonishingly useful. But plausible and correct aren’t the same thing, and the gap between the two has a picturesque name: they call it hallucination. Ask a model which article of the procurement code governs something, and it might give you the right one, or a beautifully formatted, perfectly confident item that doesn’t exist, never did, and we’re all hoping it never will. Ask it again, and it might give you a different answer, because unlike our schedule, the same input doesn’t guarantee the same output.

The industry’s usual response is that mistakes are a bug that will be fixed in the next version. Here’s the bad news when it comes to AI: hallucinations won’t be fixed because they’re a structural risk in how these tools are assembled. In 2024, three computer scientists from the National University of Singapore (Ziwei Xu, Sanjay Jain and Mohan Kankanhalli) published a formal proof that hallucination is inevitable for large language models: regardless of how the model is built, how it’s trained, what data it’s fed, or how cleverly you prompt it, every mitigation we have can reduce the rate but it can never bring it down to zero. Everything, from retrieval of verified documents to asking the model to check its own work, can help up to a point because hallucination isn’t a defect in the product: it’s a property of the method.

If you’re thinking that humans make mistakes too, you’re right and that’s exactly the problem: human errors and BIM errors have something in common, which is they both tend to look like errors. A tired junior’s wrong dimension is often clumsily wrong, and a broken rule produces visibly broken results. An AI error is polished, hence it looks exactly like a right answer. Nothing in the output tells you which sentence is the invented one, and lawyers in New York learned this the hard way in 2023, when they filed a brief citing cases ChatGPT had made up, complete with names, dates and quotes, and a judge sanctioned them for it.

Now bring this back to our sector, where errors don’t stay on paper. When researchers like Abdullahi Saka asked construction experts about language models in the industry, hallucination came out as one of the main barriers to adoption, precisely because wrong information in our line of work can endanger lives and property, not just cost money.

That’s why last week we were talking about integrity: if we could build it into the method with BIM, the method can’t guarantee anything of the kind with AI, so the process has to assume the errors are there and go looking for them. That’s a completely different stance. BIM let us move from checking to trusting the rule, and AI forces us back from trusting to checking, except now the thing we’re checking is fluent, fast, and very good-looking.

So the question to ask of any AI tool isn’t about the level of accuracy, which is a number that changes with every model update and every new type of task, and no procedure can fix it. The only useful procedure in this situation is a verification strategy: who carries it out, and what does it cost? If the answer is “nobody, nothing, and I’ll trust the tool”, then congratulations: you’ve just signed something you don’t understand, and we’ve already talked about that.

Further readings: Xu, Jain and Kankanhalli (2024), “Hallucination is Inevitable: An Innate Limitation of Large Language Models”, National University of Singapore. The paper formalizes the problem and shows that it is impossible to eliminate hallucination in LLMs, with a result that holds for any computable LLM, regardless of model architecture, learning algorithms, prompting techniques, or training data. The paper also covers mitigations: retrieval-based methods reinforce LLMs with knowledge graphs or databases, and prompting models to reason and verify their answers reduces hallucination.

4. Here Be Dragons

Old maps had a lovely habit: where the cartographer’s knowledge ended, the blank space got sea serpents, monsters, and sometimes a warning. You might not know what was out there, but at least you knew where you stopped knowing.

BIM has a map like that, and every one of us has drawn it by navigating at the edge of the map and finding the dragons for everybody else: we’ve seen a certain kind of join always misbehave, a family built a certain way break when you flex it, a certain export lose your property sets. You learn it once, you write it in your notes, and it stays true until the next major release. The limits of the tool are stable, and they’re mappable.

AI’s map doesn’t work like that, and this is where things get genuinely strange. Like quantum dragons strange.

In 2023, a group of researchers from Harvard, Wharton, MIT and Warwick (with Fabrizio Dell’Acqua as lead author) ran one of the most rigorous experiments on AI and knowledge work to date, alongside Boston Consulting Group. Together, they took 758 consultants (about 7% of the Group’s individual contributors) and gave them realistic consulting tasks, some with access to GPT-4, some without. On tasks inside the model’s capabilities, the results were impressive: consultants with AI completed more tasks, faster, and with quality ratings over 40% higher. Then the researchers added a task deliberately designed to sit outside the frontier, what the model could do well, except it looked just as doable as the others. There, consultants with AI did worse than those without: noticeably less likely to get the right answer, because by that point they trusted the output.

The researchers called it the jagged technological frontier, and I’ve talked about it before. The boundary of what AI does well isn’t a smooth line between easy and hard: tasks that look equally difficult to us can fall on opposite sides of it, and nothing in the task tells you which side you’re on. Inside the frontier, AI makes you better. Outside, it makes you worse. And the frontier moves every time the model is updated, without release notes telling you where it moved to because nobody really knows.

In the same experiment, one group got AI with a short training on how to use it. On the task outside the frontier, that group did worse than the group that just had the tool. More familiarity, more confidence, more over-reliance. Shitty training? Perhaps. Fabrizio Dell’Acqua had seen something similar in a separate study with recruiters: those given a very good AI assistant disengaged and stopped checking, while those given a deliberately mediocre one stayed alert and improved over time. He calls it falling asleep at the wheel.

Now, you might think: fine, the frontier is jagged, but surely I’d notice if the tool were slowing me down or making my work worse. Well, about that.

In 2025, a research organisation called METR ran a randomised trial with sixteen experienced software developers, people working on large, mature open-source projects they knew inside out: across 246 real tasks, each task was randomly assigned to “AI allowed” or “AI not allowed”. Before starting, the developers predicted that AI would make them about 24% faster. Afterwards, they estimated it had made them about 20% faster. The measured result? With AI, they took 19% longer. Not only were they slower, but they were convinced they were faster, after the fact, having done the work themselves. The study is small, the tools have improved since, and many participants were new to the specific editor being tested, so I wouldn’t build a whole theory on the number, but the gap between perception and reality is the finding that matters, and it isn’t a quirk of programmers. Cognitive psychologists Evan Risko and Sam Gilbert, reviewing years of research on what they call cognitive offloading, found that we hand tasks to external tools when we believe it’s more efficient than doing them ourselves, and that those beliefs often don’t match reality. We’re not good judges of when a tool is actually helping us. We never were. With a calculator, it hardly mattered. With a system that writes your specification, it matters a lot.

Put the two findings together and you get an ugly picture:

1. AI makes you better on some tasks and worse on others that look exactly the same;
2. you can’t tell in advance which is which;
3. the boundary keeps moving;
4. training can make it worse;
5. your own sense of whether it’s helping is unreliable.

Compare that with BIM, where the gains, or the lack of them, ended up in the dashboard for everybody to see: fewer RFIs, fewer site clashes, longer hours modelling to reduce design mistakes, or a very expensive CAD with a lot of colours. You might have disagreed about the numbers, but you could count them.

So here’s another important difference: with BIM, experience was enough to map the limits; you learned them once and passed them on. With AI, experience alone isn’t enough, because the map keeps changing and your instincts are part of what’s being fooled. You need to measure. That means comparing work done with and without the tool, sampling outputs, and checking results against reality rather than against your feeling of how smoothly the afternoon went. It’s the only way to know where the dragons are this month.

5. The Kids Aren’t Alright

If you’re still reading, we arrived at the difference that matters the most: BIM made the juniors; AI hits the juniors.

If you entered this profession in the 2000s or early 2010s, you probably remember the strange inversion BIM produced in many offices: all of a sudden, the twenty-five-year-old who knew Revit was worth more, in some very practical ways, than the fifty-year-old who didn’t. Juniors were hired because of BIM, sometimes over more experienced candidates, they got put on projects they’d never be allowed to touch otherwise, sat in coordination meetings with consultants twice their age, and learned the trade by modelling it. You can’t model a wall build-up you don’t understand, not for long anyway. BIM automated the person checking sections against plans, sure, but it opened a new first rung on the ladder, and a lot of people climbed it. Some of them are reading this now. To me, this meant I went from being the junior team member in an office to being the staff’s oldest person in another office. Fun times.

AI should be even better for juniors, right? At first glance, research seems to be saying that it is.

Remember Erik Brynjolfsson? Together with Danielle Li and Lindsey Raymond, he studied what happened when a large company gave its customer support agents an AI assistant, using data from more than five thousand people. On average, productivity went up by about 15%, but the gains weren’t spread evenly: the less experienced and less skilled agents improved in both speed and quality, while the most experienced ones saw small gains in speed and, interestingly, small declines in quality. The BCG experiment found the same pattern: the consultants who started at the bottom gained the most. The researchers’ explanation is elegant: AI had learned from the behaviour of the best workers, and was quietly passing their best practices on to the newcomers. In Brynjolfsson’s words, high-skilled workers had less to gain because the AI’s recommendations already captured the knowledge embodied in their own behaviour.

There’s a catch, of course. If the tool absorbed what the experts knew and handed it to the novices, that sounds like the greatest apprenticeship programme ever invented and also a very good reason not to hire the novice in the first place. It’s not my assumption: it comes from research as well. Brynjolfsson (again), with Bharat Chandar and Ruyu Chen, took a better look at payroll data from ADP, the largest payroll processor in the United States, covering millions of workers. They wanted to see who was actually losing work since generative AI became widely available. Workers aged 22 to 25 in the occupations most exposed to AI saw a 16% relative decline in employment. Experienced workers in the very same occupations? Stable, or growing. On top of that, the decline was concentrated in occupations where AI is used to automate tasks rather than augment people. The authors called their paper “Canaries in the Coal Mine”, and the canaries are young people.

Their data are from the US, their examples are software developers and customer service, and it’s a working paper, not the final word. There’s no equivalent study for AEC yet, and they’re very different industries. But look at what entry-level work in our sector actually consists of, and ask yourself which side of the frontier it falls on: drafting standard details? Writing the first version of a specification from the specifications of older projects? Taking meeting minutes that allowed you to be in the room and learn, doing quantity take-offs that allowed you to sit touching elbows with the senior estimator, producing the first draft of a report, checking documents against requirements. Those are exactly the tasks generative AI does fluently. They’re also exactly the tasks through which juniors could approach the job and learn the craft.

And that’s the real problem, because those tasks were apprenticeship. You learned why a detail works by drawing forty of them, most of them wrong, with a senior circling things in red. You learned what a specification needs by writing a bad one and having it torn apart. Tedium was the tuition fee, I know. BIM changed what juniors did, but it kept the principle: they were still doing the work, just with a different tool, and the work was still teaching them.

Lisanne Bainbridge saw this coming in 1983, writing about industrial process control in a paper called “Ironies of Automation”. She pointed out that when you automate most of a job and leave the human to supervise, two ironies follow:

1. the tasks left to the human are the hardest ones, precisely the ones the designers couldn’t automate;
2. the human no longer practises the skills needed to do them, because the machine is doing the practising.

She was talking about operators in control rooms, but the logic transfers perfectly: the expertise you need to catch a machine’s mistakes develops only through doing the work and getting feedback on it. Take away the doing, and you take away the learning.

So here’s the question we should be asking: who are the seniors of 2040 going to be? Experienced workers are the ones who recognise when a confident answer is wrong, when a pattern doesn’t fit, and when the case in front of them is something new. That’s what AI can’t do for itself, and that’s what the jagged frontier demands of us. But those skills are built over years, by people who did the junior work. If we stop hiring juniors, or hire them and let the tool do the work they would have learned from, we’re not saving money: we’re spending the next generation’s expertise, and we won’t notice until it’s gone.

BIM gave juniors a new first rung. With AI, the first rung is being sawn off while we admire the top of the ladder.

I don’t think the answer is to ban AI from junior work. It wouldn’t work, for one thing ‘(see section 2: ’cause nobody controls the adoption. But there’s a hint in the research. Remember Dell’Acqua’s recruiters, who stayed alert because their AI assistant was mediocre? Friction kept them thinking. That suggests training paths where some tasks are done without the tool, on purpose, declared as Human-First not because the machine can’t do them, but because the person needs to learn to. Tasks where the AI’s output is compared against the junior’s own, parameter by parameter, with a senior in the room. Apprenticeship needs to be brought back to something that happens by design rather than by accident. It costs time, and time is the thing the achievement society has taught us not to budget for, but the bill for skipping will land on the people who come after us, and we’ve seen fucking enough of that.

6. We Shape our Instruments (but do we really?)

There’s a line everybody attributes to Marshall McLuhan: we shape our tools, and thereafter our tools shape us. He never actually wrote it (see the Bumblebee phenomenon discussed a few weeks ago), it was his friend and colleague John Culkin, in 1967, summarising McLuhan’s ideas. But I think McLuhan would have signed it, and so would I. If you’ve followed me for a while, you know it’s one of my recurring points: every instrument changes the way we think, and sometimes even what we are.

So, on that account, I would like (if I may) to take you on a strange journey.

Fire is the oldest example in the book. The primatologist Richard Wrangham has argued for years that cooking didn’t just change what our ancestors ate, it changed their bodies: more calories from the same food meant smaller guts, smaller teeth, and energy left over for bigger brains. The exact timeline is still hotly debated, but the core idea is striking: a discovery reshaped human biology, and not the other way round.

The thermometer is a gentler one, and it’s another favourite of mine. The historian Jan Golinski has shown how, in eighteenth-century Britain, the spread of thermometers and barometers changed the way people experienced the weather itself which, in Britain, is a whole cultural thing: daily readings, recorded and published, turned the weather from something you felt into something you measured. The barometer became a status object in living rooms, a conversation piece more than a scientific instrument. Today, nobody steps out without checking how many degrees it is, and we decide what to wear based on a number. Nobody did that three hundred years ago.

The clock is another one. E.P. Thompson’s famous essay on time and work-discipline traces how clock time reshaped not just how work was organised in the Industrial Revolution, but how working people felt time: from something that passed to something you spent, saved, or wasted. If Han’s “achievement society” has an ancestor, it’s probably the factory clock.

And then there’s a contemporary one. In 2020, neuroscientists Louisa Dahmani and Véronique Bohbot discovered that people with more GPS use in their lifetime had worse spatial memory when they had to navigate on their own. Importantly, those who used GPS more didn’t do so because they had a bad sense of direction to begin with: the use seemed to come first, and the decline after. The tool took over the route, and the brain stopped bothering to learn it.

Psychologists have a neutral name for all of this, and we’ve seen it before: it’s called cognitive offloading, using something outside our heads to reduce the effort of a task. It’s as old as tying a knot in a handkerchief, and it’s usually a good thing, ’cause our heads would otherwise overload and explode. I’m glad I don’t have to remember fifty phone numbers anymore: it’s supposed to leave room for something else (except your home landline if you were a child before the 80s: that never goes away). Anyway, the fact that AI changes how we think isn’t news, and anyone presenting it as an unprecedented threat to the human mind is selling something (probably it’s one of those awful self-help books).

But (you knew there was a but) two things are genuinely different this time: what we offload, and how fast.

Let’s tackle the What first, by taking another look at the list of innovations. The thermometer gave us a measurement, and we still had to interpret it: is 12 degrees cold? For whom? The clock gave us a time, and we still decided what to do with it. GPS gave us a route, and we still decided where to go. Every one of those tools took over a perception or a calculation and handed the judgment back to us. Generative AI hands us the judgment itself: the interpretation, the summary, the recommendation, the first draft of the decision. And in our sector, judgment is precisely what the signature certifies.

There’s early evidence on what this does to our lives. In 2025, a team from Microsoft Research and Carnegie Mellon surveyed 319 knowledge workers about nearly a thousand real examples of using generative AI at work. Two findings stand out in their work. First, the more people trusted the AI, the less critical thinking they reported doing, while the more they trusted themselves, the more they did. Second and most important, the nature of the thinking itself changed: from gathering information to verifying it, from solving problems to integrating the AI’s answer, from doing the task to supervising it. The researchers call this last one “task stewardship”, which is a lovely phrase from Microsoft who’s constantly trying to push Copilot down our throats. It’s exactly what you’d expect if the thing being offloaded is judgment, though: we don’t stop thinking, we start thinking about something else, and the thinking we used to do atrophies, like the spatial memory of a GPS addict.

How fast is it happening? Fire reshaped our bodies over hundreds of thousands of years, thermometers took a century or two to change how ordinary people talked about the weather, clock discipline took the better part of the Industrial Revolution to settle in. GPS went from novelty to dependency in about a generation. Generative AI has shifted from experimental to the default in office suites, search engines and CDE platforms in about two years. Every previous shift gave societies time to build the habits, institutions and counterweights that kept the tool in its place: weather forecasts with error margins, labour laws limiting the working day (unless you’re a freelancer, but that’s a different kind of story). This time, the change is outrunning our ability to notice it, let alone to respond to it.

So yes, colleagues who say AI is just another tool are half right in the sense that it certainly isn’t a rhino. It is another instrument, and like every instrument it’ll reshape us, and that’s precisely why we shouldn’t shrug it off as more of the same: the pattern is ancient, but there are new aspects in every innovation and their impact can be different, from changing our polite conversations to altering our fucking biology. What’s new, this time, is that we’re offloading the very faculty we’d need to evaluate the offloading, and we’re doing it at a speed that leaves no time to learn from the experience.

The ironic bit is that instruments like the thermometer changed how we think by giving us a way to measure something we used to just feel. If there’s one thing I’m convinced of, it’s that we need exactly that for AI: instruments that measure what it’s doing to our work, instead of trusting the feeling.

7. New Animal, New Tools, Good Ol’ Me

Let’s put all the differences in one paragraph, for the colleagues who skipped straight to the end. I see you.

• BIM executed rules we made explicit; AI learns the patterns we never wrote down.
  One automated the routine checker; the other goes after the judgement itself.
• BIM is a tool for our sector; AI is a technology for everyone, adopted through every door at once, crossing boundaries our standards were never designed to reach.
• BIM is deterministic: same input, same output. AI’s errors are structural: they can be reduced but never eliminated.
• BIM’s limits are mappable; AI’s frontier is jagged and moving. And our own sense of whether it’s helping is unreliable.
• BIM made the juniors; AI hits them, and with them we risk losing the apprenticeship that turns juniors into the seniors who can tell when the machine is wrong.
• Every tool changes how we think, but this one promises to take over judgment in the very tasks it offers to streamline, and it’s doing it in two years instead of two centuries.

It’s a different animal than any other automation we faced before, and that’s what makes it so exciting, but I think we can all agree that you don’t handle a rhino with the instructions for a typewriter.

In other words, the BIM playbook doesn’t transfer as is: our execution plans assume we know in advance what the deliverables are and that our tools behave the same way every time; clash detection assumes the rules are geometric and explicit; our training programmes assume the skills we teach will still be the right ones later this year; our implementation methods assume one sector, rolling out one way of working, at its own pace. None of these assumptions holds for AI.

Some things do transfer, though, and they’re the most valuable ones. We know that tools without process are expensive and dangerous toys, for instance. We know that making tacit knowledge explicit is painful, slow, and it’s fucking worth it. We know that integrity lives at the gates, not in the software. And, if we’re honest, our sector already has a vocabulary for working with things it can’t fully trust: we just never used it for software. Anyone who’s worked on site knows what an inspection and test plan is, with its hold points and its witness points. We don’t trust concrete because the supplier says it’s good: we test cubes. We don’t trust a weld because it looks nice: we inspect it. That mindset is exactly what we need now, pointed at a different kind of material.

So here are the new instruments I’d put on the table, thermometers for a new kind of weather.

1. Declare the mode. As I argued last week, for every task or deliverable you should state whether your approach is a Marginal use of AI, AI-First, Human-First or Fusion mode, and who answers for it. Changing the mode is a change to the plan, not an impromptu thing.
2. Treat an AI output like a material, and not like information. Give it hold points and witness points. Decide in advance where a qualified human must check before work proceeds, and where sampling is enough.
3. Measure, don’t feel. Pilot tasks with and without the tool. Track rework, errors caught downstream and time actually spent, not the impression of how smoothly the work went. If METR’s developers couldn’t tell, neither can we.
4. Keep a dated map of the dragons. A shared log of where the tools failed, on which task, with which model version, re-checked at every update. Our toolboxes full of “reasons the schedule is wrong” were the BIM version of this. The AI version needs dates on it, because the frontier moves.
5. Protect the apprenticeship. Some tasks stay Human-First for juniors, not because the machine can’t do them, but because the person needs to learn to. Compare their work with the AI’s, line by line, with a senior in the room, and budget the hours for it.
6. Write AI into the appointment. Since our standards can’t reach every laptop, our contracts can at least ask every party to declare how AI is used in what they deliver to us, and on what terms.

This doesn’t mean I’m not getting old. Of course I am. Douglas Adams had a rule for this, more or less: anything invented before you’re born is just the way the world works; anything invented before you’re thirty-five is exciting and you can probably make a career out of it; anything invented after that is against the natural order of things. BIM arrived into my exciting window. AI arrived in the other one. I’d be a fool not to suspect myself.

But here’s the thing I’ve come to realise. If the jagged frontier demands people who can tell when a confident answer is wrong, if the juniors of today need someone to circle things in red, if the tools need someone who remembers how the work was done before so we can measure what’s changing, then getting old isn’t the bias in this argument: it’s the fucking instrument. The people who were there before the shift, who mapped BIM’s dragons the hard way and remember the J-curve from the inside, are precisely the thermometer this transition needs. The danger isn’t that we’re old: the danger is that we keep our experience to ourselves, or spend it pretending that nothing’s changed.

Plato wasn’t entirely wrong about writing, by the way: it did change our memory, and we did lose things like oral traditions and maybe we had a thousand Odysseys we lost along that way. What he couldn’t see was everything that writing would give back, and what we’d build with it. I’m still a technology enthusiast, and I still believe AI can change how people learn, grow and communicate for the better. I just want us to read the instruments while it happens.

Somewhere around Darth Vader’s age, you stop being Anakin and start being the one who has to tell the kids an uncomfortable truth. And speaking of misattributions: he never said “Luke, I am your father”. He said “No, I am your father.” Check your sources. Even the old ones.