Engineering Intelligence: Practical Applications of AI in Structural Engineering Practice
Interview with Sergey Pigach – CORE studio | Thornton Tomasetti
As artificial intelligence continues to evolve beyond research labs and semi-delusional consumer hype cycles, the AEC industry is actively exploring how to integrate these tools into mission-critical workflows.
At CDFAM NYC, Sergey Pigach of CORE studio | Thornton Tomasetti will deliver a grounded and technical perspective on the realities of deploying AI in structural engineering practice where precision, risk, and professional accountability leave no room for black-box hallucinations.
In this interview ahead of his presentation in NYC, Sergey outlines the decade-long journey of CORE studio experimenting with machine learning, moving from early-stage R&D to building production-ready tools used by engineers today.
He shares insights into what it takes to develop trustworthy AI infrastructure, create purpose-built synthetic datasets, and navigate the tension between speed and accuracy in high-stakes environments.
Can you start by outlining what you’ll be presenting at CDFAM and how CORE studio is approaching AI integration in structural engineering practice?
CORE studio has been experimenting with machine learning and AI for almost 10 years now, and we have come a long way from doing pure R&D to building tools that we are comfortable handing to our engineers. So my presentation can be viewed as a case study of integrating AI into professional practice: how we started, what we learned, what mistakes we made along the way, and what questions and considerations we are still wrestling with.
With a technology as impactful and exciting as AI, it is often difficult to separate hype from real progress.
Every day, we hear about new benchmarks being defeated by the latest frontier models, new examples of PhD-level performance, and “sparks of AGI” demonstrated in a lab setting. And yet, true adoption in most industries, including AEC, is very much lagging behind. And there are many reasons for that. Reliability and interpretability are the two obvious ones.
If you are a structural engineering company, it is entirely possible for you to make a single mistake that irreparably damages your reputation, causes devastating harm to the public, and, potentially, costs you your business. So, it should come as no surprise that the “black box” nature of AI systems makes many engineers uneasy.
Therefore, our approach to using AI centers around an understanding that it is a powerful, but imperfect technology that can be extraordinarily helpful in some cases and completely unacceptable in others.
It is not a magic bullet. And finding practical applications where the use of AI is appropriate, safe, and genuinely productive is something we consider very carefully.
What kinds of models and workflows have proven most applicable within Thornton Tomasetti’s engineering practice, and how are they selected or developed?
I’d say we’ve gotten pretty far by building classical machine learning tools for our engineers. These tools solve specific problems, such as designing a truss, a column stack, a steel bay, a shear wall and so on. And the main advantage here is speed: relying on inference rather than classical solvers lets us get an answer in milliseconds as opposed to minutes or even hours, especially for iterative design problems.
This proved very effective for speeding up early stages of design. During Schematic Design and Design Development, engineers often have to use CD-level tools that are clunky, time-consuming to set up, and give you way more information than you need at that stage.
If the client only wants to know the approximate member sizes, which will likely change anyway, you are much better off using one of our AI apps that will give you a 95% accurate result in seconds. Rapid feedback, in turn, allows you to iterate quickly and try many different options early on.
That said, as a matter of company policy, anything that ends up on a construction document set, or anything directly communicated to the client, must be looked at by multiple people, then checked, and re-checked by conventional software.
Computer vision is another domain where we saw a lot of practical benefit. For instance, CORE has worked on a tool called T2D2.ai, which does automatic facade damage detection and classification from a series of photographs to help speed up inspections. Since then T2D2 became its own independent company and they are doing quite well.
And, of course, with the advent of generative AI, we have done a lot of experimentation with RAG, agents, and MCPs. Though, for reasons that I already described, we are still figuring out the best ways to integrate these systems into production workflows while navigating around the bugs. Hallucinations and in-context scheming are always a big concern.
With regards to how we select specific technologies or workflows, it really depends. Some of it comes from pure R&D: we test things out, see how they perform and if something looks promising, we commit to turning it into a product.
Sometimes we are directly approached by a practice, or a project team who need a solution to a specific problem. We also have a mechanism called CORE Lab, where anyone in the company can pitch an idea. A number of those ideas are then selected by a jury and provided with funding. CORE studio is often called upon to help with the technical implementation.
Where does the data for your engineering apps come from? Do you use your past projects to train machine learning models?
No, and trust me, we tried. The issue with using past project data is threefold.
First of all, no matter how many projects you have in your portfolio, you will never be able to find enough diversity in member sizes and structural loads to evenly cover the entire design space. Buildings with the same program and structural system are more alike than they are different, so you inevitably end up with a dataset where you have several clusters with tons of samples and then vast voids in between.
Secondly, not all design decisions in a real building are motivated by purely engineering considerations. For example, it might be more structurally efficient to have a unique column size for every level, but in the interest of simplifying the construction process, you will more likely pick one size for multiple floors. And these types of decisions that are not motivated by pure physics really impede a model’s ability to generalize.
Finally, extracting the data from past projects is a lot harder than it sounds, especially if you want to automate the process. There are tons of different files, some are in versions of Revit so old that they won’t even open properly, some are in other CAD formats and, if you go far enough back in time, you end up with PDFs of scanned drawing sets.
So instead we partner with domain experts within TT to produce our own synthetic data. For each ML app that we build, we write a custom solver that bruteforces the design space and gives us a clean, even dataset in a few hours or, sometimes, a few weeks. We then validate the results using industry-standard software. And if you are wondering why we are not using these solvers directly, it once again comes down to speed: inference is just a lot faster most of the time. And in the few cases where the speed advantage is not significant enough, we do opt for traditional calculations.
What does your software stack look like for deploying AI tools across the firm, and how is data managed to ensure consistency, security, and usability across disciplines?
A while back, when we started diving deeper into ML and AI, it quickly became apparent that we had to dedicate significant resources and time to building out a proper MLOps pipeline. So we developed CORE.Cortex, which is our in-house MLOps platform that supports the CORE AI team.
Cortex is a web app and a Python SDK that allows us to quickly log trained models to a tracking server alongside all of the essential metadata: hyperparameters, evaluation metrics, specific dataset versions, etc. This really helps us keep everything neatly organized and allows us to clearly see which models perform best for specific tasks.
Cortex is also directly linked to our deployment infrastructure in AWS. With just a few clicks, we can take a logged model and deploy it to Amazon Sagemaker. Our MLOps platform lets us generate a unique set of API keys for every project, which are easy to rotate in case of compromise. As a result, thanks to us taking MLOps very seriously, we can go from a locally trained model to an authenticated API endpoint in a matter of minutes. And this really helps with iterating quickly during R&D, as well as managing our fleet of available endpoints in production.
Now, API endpoints are great for developers, but not particularly useful for project engineers. Building bespoke web applications or desktop clients to wrap each of our AI models would have been a very time-consuming option requiring a lot of maintenance and likely leading to severe technical debt. Instead, we are using ShapeDiver.com, which is a compute platform that lets you solve Grasshopper definitions in the cloud with a web UI that can be deployed firmwide.
We’ve been partnering with them for many years, and they’ve been instrumental to our AI efforts. With ShapeDiver we can turn any Grasshopper definition into a web app that has a clean interface and a nice 3D viewer.
Because everything runs in the cloud, we do not have to worry about missing plugins, or version control, which is a common problem with sharing Grasshopper files. And then the Grasshopper definitions call our Cortex API endpoints and perform whatever geometric operations are necessary. This approach has been very popular with our engineers: CORE AI put together an entire library of ShapeDiver apps that folks routinely use for early design.
We’ve also been doing a lot of experimentation with agentic workflows, though we don’t have anything in production quite yet.
For example, Thornton Tomasetti uses Glean.com as our off-the-shelf RAG / enterprise search solution that is available to all employees.
Glean allows you to define custom “Actions” and build agents, so we immediately started connecting it to Cortex endpoints to see if an LLM can use the structural engineering tools we have already built. The results are very impressive, though we will need to do a lot more testing and implement much more robust guardrails to be comfortable releasing something like this company-wide.
We also converted many of our tools into MCPs and experimented with building fully custom agents using Strands SDK and AWS AgentCore – I’ll be showing some of that in my presentation. But again, we’re still trying to figure out how to best deal with things like hallucinations and scheming.
How have you approached evaluating where AI can offer practical value versus areas where conventional tools remain more effective in the design and engineering process?
For us, as an engineering company, it all comes down to evaluating reliability and risk. AI tools work best in situations where rapid feedback matters more than 100% accuracy, which is why we have been focusing on early stages of design.
In the later stages, this equation flips: no one expects frequent or major changes towards the end of the project, so accuracy becomes far more important and this is where conventional tools really shine.
As I mentioned before, we do not allow any type of AI output to make it into an official drawing set without it being thoroughly validated by traditional methods.
And, of course, at this stage, a human is always in the loop. The tools that we build are meant to augment, not replace.
For example, our existing AI infrastructure lets us search through the company’s knowledge base to find relevant sources and references in seconds. Our AI apps help teams zero in on the best course of action early in the project by trying out many solutions quickly.
We are very excited about the prospect of agentic AI that can help automate mundane engineering tasks. But it is ultimately up to the engineer to use their judgement, think critically about the problem and take full responsibility for the final design.
What do you hope to share with and learn from the CDFAM community regarding cross-disciplinary collaboration and building resilient AI-enabled design cultures?
It’s a brave new world out there and I think we are all excited to see what doors AI will open for us as professionals, while we also try to anticipate and mitigate the risks.
CORE studio and Thornton Tomasetti have been exploring machine learning and AI for almost a decade now and I am very excited to share what we have learned.
Structural engineering and construction do not naturally lend themselves to AI automation both due to high stakes, and because they are messy and complex disciplines. So I think we present an interesting case study of overcoming some major friction.
And, of course, I am very excited to see how other professionals tackle similar questions in related domains.
I think what it means to be a designer in any field will change significantly in the near future. What it is that we bring to the table in the world where Artificial Intelligence is no longer science fiction will have to be re-evaluated. We are already starting to notice the shift. And I would love to see how the rest of the design community is approaching this transformation.
To connect with Sergey and other leaders shaping the future of AI in design and engineering, join us at CDFAM NYC. This is where real-world expertise meets cutting-edge experimentation, don’t miss the opportunity on this unique opportunity to be part of the conversation.
