Automation Tools Start With the Engineer, Not the Script

Watch the work before you automate it

An engineer rarely asks for "a tool". They describe a task that takes too long, or one they have to redo every time a design changes. The useful first step is to sit with that task and understand which parts are judgement and which parts are repetition.

Judgement should stay with the engineer. Repetition is what a parametric model or a script does well. Mixing the two up gives you a tool that either does too little or quietly makes decisions it should not.

Small tools that people trust beat large tools that people avoid

It is tempting to build one tool that covers a whole workflow. In my experience a narrow tool that does one job reliably is adopted faster. Once people trust it, they come back with the next task, and the tools grow from real requests rather than guesses.

Make the inputs and outputs visible

Computational design tools can feel like a black box to someone who did not write them. I try to make clear what goes in, what rules are applied and what comes out. When an engineer can check the result against their own understanding, they are much more willing to rely on it for real project work.

A tool is a product

The tools we build inside a firm have users, a backlog and a support burden, just like any software product. Someone has to own feedback, fixes and the next version. Treating them as products, not one-off scripts, is what keeps them alive after the first project.

Where AI fits

Building AI products in the Curious PM cohort made me think about where language models could sit in this work. Much of an engineer's time goes into reading standards, briefs and past designs before any modelling starts. That reading is where AI can help, while the design decisions and the checks stay with people.