Where the time actually goes
Ask a design engineer what they spent the week doing and the answer is rarely "engineering". It is more often re-entering the same information in four places: a calculation, a drawing, a schedule and a specification, each of which has to agree with the other three and none of which shares a source.
That transcription work is real, necessary under current tooling, and almost entirely free of engineering judgement. It is also where a large share of errors originate, because manual re-entry across four artefacts is exactly the process most likely to leave one of them out of date.
The carbon argument is indirect
The obvious environmental claim for automation — that it reduces the energy consumed by the design process — is trivially small and not worth making.
The real argument runs through option appraisal. The decisions with the greatest influence over a building's lifecycle carbon are taken early, when the design still has freedom: system selection, plant sizing philosophy, the balance of fabric against services. Appraising those options properly takes time, and it is the first thing compressed when fee and programme are tight.
If automation removes transcription work from the same fee, the time released goes somewhere. Directed at option appraisal, it has a carbon effect several orders of magnitude larger than any saving in the design process itself.
The competence problem
This is the part that cannot be waved through.
A chartered engineer carries professional responsibility for the designs they issue. That responsibility does not diminish because a calculation was produced by a tool rather than by hand, and the engineer cannot discharge it by pointing at the software.
What follows is a requirement on the tool rather than on the engineer: the output has to be interrogable. An engineer must be able to see the inputs, follow the method, identify the assumptions and form an independent view on whether the answer is right. A tool that returns a number with no accessible reasoning has not made the engineer faster; it has made them liable for something they cannot examine.
The test worth applying
For any automated design tool, the useful question is not how much time it saves. It is whether a competent engineer can take its output, reconstruct how it got there, and defend it to a peer.
Where that is possible, automation is straightforwardly good: the same judgement, applied to more options, in less time. Where it is not, the tool has concentrated risk rather than reduced work — and it has done so at exactly the point in the process where an error is least likely to be caught.