Why Discovery Matters More in Engineering Automation Than in Software

Most articles about the discovery phase say the same thing: talk to users, build personas, align stakeholders, avoid assumptions. That advice is fine for a consumer app. It’s close to useless for engineering automation – because the thing you’re discovering isn’t what users want. It’s how the work actually gets done, in detail no one has ever written down.

That distinction is the whole game. When you automate a formwork calculation or connect a CAD model to an ERP system, there’s no product vision to validate. The workflow already exists, runs every day, and lives almost entirely in the heads of a few senior engineers. Discovery here isn’t research. It’s reverse-engineering domain logic that no specification contains – and it’s precisely the step that off-the-shelf software and AI code generation skip, which is exactly why they break on this kind of problem.

The bottleneck is never where the client thinks it is

Ask an engineering team where their time goes and they’ll name a task. Watch the work and you’ll usually find the real cost somewhere else – in the rework loop, the manual re-entry, the calculation redone from scratch because the last version wasn’t reusable.

Formwork is a clean example. The obvious answer is “the calculation takes too long.” The discovery finding is more specific: the cost isn’t the calculation, it’s the lack of panel reuse across pour stages, and the fact that results depend on which engineer ran them. Automating the fast part would have saved nothing. Automating the reuse logic cut cost by 70% and turned weeks into hours. You only get there by measuring the actual workflow, not the reported one.

What you skip in discovery, you pay for in integration

The most expensive discovery failures show up at the seams between systems. On an oil & gas project, an engineering team’s AutoCAD Plant 3D didn’t talk to their SAP S/4HANA, and asset handover was taking six-plus weeks with a 15% error rate on Bills of Materials.

The instinct is to treat that as an integration coding problem. It wasn’t. The delay came from a workflow gap – how data was classified, named, and validated before it ever reached SAP – and that gap was invisible until it was mapped. Once discovery surfaced it, the build was straightforward: error rates dropped from 15% to under 2%, and handover compressed from six-plus weeks to one. The result was decided before a line of integration code was written. That’s the pattern: in engineering automation, the hard thinking happens in discovery, and the code just executes it.

Why AI code generation can’t do this part

AI is genuinely good at generating code from a clear specification. The problem is that in engineering automation, the specification is the deliverable you don’t have yet. The domain logic – how your team handles a non-standard section, which standard governs an edge case, why one classification maps to two SAP records – isn’t in any prompt. It has to be extracted from people and practice first. Skip that, and you get software that runs perfectly and solves the wrong problem. Discovery is the human-and-domain work that no code generator can shortcut.

What good engineering discovery actually produces

Not personas or wireframes. A mapped workflow – the real one, including the workarounds. The constraint set: applicable standards, edge cases, the non-negotiables. A clear read on where automation pays off first and where it doesn’t pay off at all. And an honest answer to whether the problem is worth automating, which is sometimes no. That output is what turns a risky custom-software bet into a predictable engineering project.

This is why we treat discovery as the first stage of every engagement, not a formality before the “real” work. It is the real work.