James Washbourne, digital engineering lead, Perega, discusses how the role of BIM technicians has changed in recent years and why human judgement will always be important
Most conversations about BIM often still start with the model: geometry, coordination, drawing outputs. But BIM has evolved well beyond these foundations. Today, its scope extends across information management, data governance and digital workflows. Geometry provides the visual representation; it’s the information behind the model that enables informed decision-making and value throughout the project lifecycle.
That shift has been driven largely by automation. Visual programming tools like Dynamo and Grasshopper have transformed what a BIM technician spends their day doing. We can now strip out manual data entry, reduce double-handling and redirect saved time into developing standards and upskilling junior staff. The logic is straightforward: faster delivery, lower cost per drawing, leaner project economics.
But that picture has a complication most firms don’t talk about. I think of it as ‘disposable design’.
When design becomes disposable
When changing a model becomes frictionless, clients notice. Revisions that once required meaningful effort can now happen quickly, which encourages more of them. The brief evolves more freely, the design cycle stays open longer, and the time saved through automation gets steadily absorbed by the additional iterations that same automation makes possible.
Even where we’ve reclaimed hours through scripting, those hours can disappear into revision loops that weren’t there before. As I’ve said to colleagues, semi-automation helps you to keep delivery afloat. Full automation, removing engineering decision-making from the chain entirely, usually creates work that has to be redone later.
That’s the commercial reality. It’s not that automation doesn’t work; it does. It’s more about what you’re optimising for.
Why engineering judgement must stay in the loop
The answer to disposable design is to scope it more carefully and keep qualified engineers in the decision chain, alongside the automation. A workflow that runs without engineering involvement will produce outputs that need revisiting. The rework costs more than the efficiency saved.
One approach is to introduce automation in two stages where the task warrants it. First, use advanced scripts to handle the repetitive, data-heavy work, generating spreadsheets, identifying elements, and pushing structured data to an intermediary system. An engineer then reviews that data, applies their judgement and signs off on the outputs. Scripts then take the validated decisions and push them back into the model. The repetitive work is automated, while the thinking is not.
Industry conversations often cast automation and human expertise as competing approaches. In practise, semi-automation is what often keeps many projects commercially viable.
Luton and Dunstable Hospital: a late-stage change
Recent work on the new Acute Services and Ward building at Luton and Dunstable Hospital gives a concrete illustration of this. Late in the programme, the contractor opted to change the ground-to-first-floor RC columns to precast. On paper, this looked like a simple change. In practice, it meant managing over 600 columns, each carrying around ten data points, loading requirements, detailing specifications, material assignments, all of which needed updating across the model and the drawings.
Done manually, that’s days of work and a real risk of inconsistency. Instead, it made sense to write a two-stage Dynamo script. The first stage identified each column and pushed it to an Excel sheet, where engineers specified the precast designation, loads and detailing requirements for each one. The second script read those validated decisions back into Revit, updated the material assignments and changed the visual representation in the model. One button click per stage.
The automation eradicated all those potential human errors, and the engineering decisions stayed with the engineers. The script did the heavy lifting on repetitive data management. The team’s judgement shaped the outcome.
What this means for BIM technicians
The skills picture is also shifting. Building technology and technical drawing remain foundational; that doesn’t change. But visual scripting is becoming something closer to a baseline expectation. Within five years, I can’t see there being a job post for a technician without the need for visual scripting. There’s clearly a need to prioritise engineering knowledge over pure coding ability, but it makes sense to actively encourage a team to write one-off scripts where they solve a specific project problem.
AI will play a part, particularly in code production, testing and supporting scripting ecosystems. The integration of AI into tools like Grasshopper already offers some genuinely useful capability. But most of what mainstream construction AI currently does, APIs and dashboards already handle.
The real opportunity – agentic workflows, optioneering, reporting – sits further out. For now, the practical answer is semi-automation: careful scoping, disciplined delivery timing and keeping engineering judgement right where it belongs.
The post Why chasing full automation is the wrong target for BIM technicians appeared first on Planning, Building & Construction Today.
