Engineers spend too much time in PDFs. Here's what AI is (and isn't) doing about it

The 600-page PDF is open on your second monitor. You've Ctrl-F'd "shear" four times. You've found three clauses that look relevant and you can't remember which one applies to your case. Your project review is Friday. It's Wednesday afternoon.

Every engineer knows this scene. Most of us live in it.

Reference work - looking up clauses, hunting for the right formula, cross-checking against the firm's design manual, finding the manufacturer's allowable in a datasheet - eats a real fraction of every engineering project. Industry surveys put it somewhere between 15% and 30% of an engineer's working week, depending on discipline and seniority. Junior engineers spend more. Anyone working across multiple codes spends more. Anyone designing anything novel spends a lot more.

This isn't a complaint about engineering being hard. It's a complaint about a specific tax: the time between knowing what you need to do and being able to do it. That tax is paid in PDFs.

For the last two years, AI has started to chip away at that tax. Imperfectly. This post is an honest look at where it's actually helping, where it's falling short, and what's still missing.

The shape of the problem

A typical engineering reference task looks like this:

1. You know the calculation you need to do (a beam capacity check, a load combination, a thermal expansion allowance).
2. The relevant code or reference contains the formula, but it's spread across several clauses, with definitions a few sections away and limits a few sections after that.
3. You need to find the clause, parse it, identify which variables apply, plug in your numbers, and produce a calculation that someone else can review.
4. The output isn't the answer. It's the calculation — the artifact that goes into the design report, gets reviewed, gets stamped, gets built from.

Steps 2 and 3 are pure friction. They produce nothing of value on their own. They just stand between you and step 4.

This is the gap AI tools are now trying to fill.

What current AI tools actually do for engineers

Let's be specific. There are roughly four categories of AI tool engineers are using today, and they each solve different parts of the problem (and miss different parts).

General-purpose chatbots (ChatGPT, Claude, Gemini)

These are great at explaining concepts in plain English. Ask "what's the difference between strength reduction factors in AS3600 and ACI 318" and you'll get a useful conversational answer.

They're terrible at being authoritative about specific clauses. Without the actual document in front of them, they hallucinate clause numbers, formula coefficients, and limits. They're good for understanding, not for citing.

For exploratory work and learning, they're excellent. For anything that ends up in a design report, you can't trust them.

Document chat tools (NotebookLM, Claude Projects, ChatGPT Custom GPTs)

These are the genuine breakthrough of the last 18 months. Upload your PDFs, ask questions, get answers grounded in the documents with citations. NotebookLM in particular has become the reference implementation of this format.

For engineering reference work, these tools genuinely help. You can upload AS3600 and actually have a conversation with it. The answers cite the clause. The hallucination rate drops dramatically.

But — and this is the gap nobody talks about — the output is still a paragraph. The artifact engineers need is a calculation. You can ask NotebookLM "what's the formula for shear capacity under clause 8.2," and it will tell you. Now you still have to copy that formula into Excel, type the variables, and build the calc.

The retrieval problem is largely solved. The "from answer to artifact" problem isn't.

Discipline-specific AI tools

A wave of vertical AI tools is emerging for specific engineering disciplines — AI co-pilots for structural analysis software, AI assistants for CAD packages, ML-based design optimisation. Some of these are genuinely good. Most are early.

The catch is they only help inside the specific software they're built into. The reference work — the PDF reading, the cross-code checking, the formula lookup — happens outside that software, in the tab where the PDF is open.

Spreadsheet AI

Excel and Google Sheets have added AI features for cell-level operations. Useful for cleaning data, less useful for the actual engineering question of "is the calculation in cells D3 to D17 the right one for this code provision."

Spreadsheets weren't designed to be document-aware, and bolting AI on top hasn't changed that.

The pattern in what's missing

If you stand back from these four categories, the gap is consistent. Current AI tools either:

• Help you understand something (chatbots), but can't be trusted for design output, or
• Help you find something in a document (document chat), but stop at the paragraph, or
• Help you inside a specific tool (vertical AI), but not across the reference work that surrounds it.

What none of them do is close the loop between "the standard says this" and "here is the calculation that does it." That gap is where engineers still spend their time. It's where mistakes hide. And it's the one part of the workflow that, for technical reasons, is genuinely hard to solve — because it requires both retrieval and computation, and most AI architectures are built for one or the other.

We go deeper on what it actually looks like to use today's AI tools with a real design code in [our next post →].

What "good" would look like

If we were designing the ideal AI-assisted reference workflow from scratch, it would probably look something like this:

• Upload your reference library once —  textbooks, your firm's design manual, manufacturer specs etc.
• Ask in plain English and get answers with citations to the exact clause.
• Generate the calculation from the conversation — not as a paragraph, but as a live, editable, reusable artifact.
• Stay scoped to your workspace. Your firm's IP doesn't leak into a model. The cited sources are sources you've licensed or own.
• Be reviewable. The output isn't a black box; another engineer can audit every step.

That's the shape of the thing engineers actually need. Some of it exists in pieces today. None of it exists end-to-end yet — though that's starting to change.

If this is the kind of workflow you've been waiting for, [join the list →]. We'll have more to say soon.

‍