Hannah Brecht

Walk me through what a week looked like before you brought AI into it.

A lot of my week went to lookup and cross-checking rather than design. A concrete or steel member starts with load takeoffs under ASCE 7, then sizing against ACI 318 or AISC 360, then a second pass to confirm I applied the right clause and the right code edition for the jurisdiction. The codes run to hundreds of pages, and a single detail can send me flipping between three chapters.

On top of that, every drawing set needed a manual coordination review against the architectural and mechanical sheets, checking that a beam did not sit where a duct had to run. It was necessary, careful work, but it was slow, and it was the part most likely to eat an evening. It also pulled hours away from the actual engineering decisions I was being paid to make.

What was the first thing you tried, and how did it go?

The first thing I tried was code lookup. I asked a general assistant about a seismic detailing provision, and the answer sounded authoritative and cited a clause number that did not exist in my edition. That taught me the ground rule early: these tools can invent a reference that reads perfectly.

So I changed how I used it. Instead of trusting a free-floating answer, I started giving the tool the actual code text I was working from and asking it to point me to the relevant section and summarize it, which I then opened and read myself. Used that way, it was genuinely fast. It turned a twenty-minute hunt through an index into a thirty-second pointer to the right page, and I still confirmed every clause against the book before it touched a calculation.

How do you actually use it now, day to day?

Three ways, mostly. First, calculation checks: after I run a member design, I have the tool re-derive the check against the governing equation and flag where my number and its number diverge, which catches a transposed value or a wrong load combination. Second, code cross-referencing: I feed it the provisions I am citing and ask where they interact, because a change in one chapter often triggers a requirement in another. Third, drawing QA. Before a set goes out, I run the structural sheets against the architectural and mechanical drawings to surface coordination conflicts, missing callouts, and load-path gaps. It reads flat 2D PDFs, so I do not need a full model to get value. In each case the tool produces a list of things to look at, and I do the looking. It sets the agenda for my review; it does not close the review.

Where do you not trust it, and where do you keep control?

I keep control at the point of judgment, and for me that is non-negotiable, because I am the engineer of record. When I stamp a drawing, I am personally attesting that the design is sound and code-compliant, and that responsibility cannot be delegated to a model. So AI never sizes a member that goes out unchecked, and it never has the final word on whether a detail satisfies the code.

I treat everything it produces as a prompt for my attention, not a conclusion. The failure mode I watch for is a confident, wrong citation, so any clause it surfaces I verify against the adopted code for that jurisdiction and edition. The tool does the consistent, repetitive checking well. The load-path reasoning, the judgment calls, and the signature stay with me, and the client is paying for exactly that.

Was there a specific moment it earned its place?

One project stands out. We were a day from issuing a set on a mixed-use building, and the drawing QA pass flagged a transfer beam on the second level that conflicted with a large supply duct routed by the mechanical engineer. On the sheets alone, in a rushed final review, it was the kind of clash that is easy to miss and expensive to catch in the field.

Because we found it at the desk, I could resize and reroute in coordination with the architect before the set left the office, instead of answering an RFI weeks later with steel already fabricated. That single catch paid for the tool many times over. It did not solve the problem; it pointed me at the right two sheets fast enough that I had time to solve it properly.

What would you tell a structural engineer who is skeptical?

I would tell them their skepticism is correct, and to keep it. This is not a tool you trust; it is a tool you supervise. Start with the low-risk, high-drudgery work: code lookup where you still open the book, and drawing coordination where the output is a checklist you verify. Do not let it size anything you would not re-check by hand, and never issue a citation you have not read yourself.

The value is not that it replaces your engineering. It is that it clears the mechanical parts of the day, the flipping and cross-referencing and sheet-by-sheet comparison, so more of your hours go to the design decisions that actually require a licensed engineer. Used with discipline, it makes you a more careful reviewer, not a lazier one.

How has it changed your work, or your clients' experience?

The most visible change is where my hours go. On a typical week I spend less time on lookup and coordination checking and more on the design itself, which is the part I am actually good at and the part the client is paying for. Fewer coordination conflicts survive to construction, so there are fewer field RFIs and fewer change orders, which clients feel directly as a smoother, cheaper build.

Turnaround on code questions has gone from a slow hunt to a quick, verified answer. None of this changed my standard of care or who is accountable. The stamp still means what it always meant. What changed is that I reach the engineering faster, catch more before it leaves the office, and hand over a set I have had more time to actually think through.