Select clients, firms, research partners, and industry events
I started as a structural engineer who wrote code. Then I spent a decade building the AI that changes how engineers work. This is the through-line.
Most AI keynotes are, underneath, about text. Summarize this, draft that, save an hour. That framing falls apart in front of a room whose output has to survive contact with the physical world.
Engineering is one method wearing different clothes. You take an intent, express it as goals and constraints, search a space of possible answers, and accept only what physics, cost, and code will allow. A structural engineer sizing a frame and a mechanical engineer designing a bracket are doing the same thing to different materials.
AI does not replace that method. It moves where the engineer stands inside it. The old loop was propose, then check: draw a candidate, analyze it, adjust, repeat, and run out of time after three or four options. The new loop is declare, then judge: state what you want and what you will not accept, let the system search far more of the space than a person can, and spend your expertise on evaluating what comes back and deciding what is actually buildable.
That shift is identical whether the artifact is a bracket or a building. The industries differ enormously. The method does not. Which is why this page exists as the front door, and why the talk can be aimed at a room of structural engineers or a room of mechanical engineers without being rewritten from scratch.
And it explains the part engineers usually care about most: the risk. A language model can be confidently wrong and nothing happens. An engineering decision that is confidently wrong shows up as a field failure. So the real question is never can AI generate this. It is what has to be true before I rely on it, and what verification looks like when the thing producing the answer cannot explain itself.
I did not arrive at AI from the outside and pick engineering as a market. I started in the profession, and then spent a decade building the technology that changes it.
Independently documented, so you do not have to take my word for any of it. The tags say exactly what was mine and what was the team's.
The Primordial research project, run with Bandito Brothers. A bare prototype was driven hard across the Mojave while sensors captured how the chassis and the driver actually behaved under load. That data drove a generative process that produced a chassis Fast Company reported as the first designed by an artificially intelligent system, one that “could never have been designed by humans.” I designed the algorithm behind that chassis.
Fast Company, 2015 →Autodesk and NASA's Jet Propulsion Laboratory used generative design to develop an aluminum lander chassis that had to survive launch loads and the environment at Jupiter's moon. It required new manufacturing constraints for casting, machining, and metal 3D printing, and Fast Company called the result the most complex generative design ever made. I was on the team that built the platform it was designed on, not on this project.
Project record →Starck set the goals and worked with the system across iterations until, in his words, it became a collaborative partner. Kartell put the result into commercial production in fully recycled material, unveiled at Salone del Mobile in 2019. It is the first mass-market product to come out of generative design, and it is still sold today. Same attribution: platform team, not this project.
Project record →Select clients, firms, research partners, and industry events
The fastest way to know whether he is right for your room.
The talk is built around your audience. Most engineering rooms sit on one side of this line or the other.
Buildings and infrastructure. Structural and civil engineering at building scale, design workflow, the liability question on a stamped deliverable, and what AI does to a fee-based business.
See the AEC keynote page →Products, components, assemblies, and the plants that make them. Generative design and lightweighting, production and quality, and the road from an R&D result to something on a line.
See the manufacturing keynote page →Each talk is rebuilt around your audience and calibrated to how technical the room is.
The method is shared. The examples are not. These are the audiences the talk gets built for most often.
Analysis, sizing, early system selection, and the professional liability question that follows every AI-assisted deliverable. Where I started.
Generative design, topology optimization, lightweighting, and design exploration. The research my patents come from.
Systems design, load and demand modeling, and reliability as complexity and constraints both increase.
Production planning, quality and inspection, maintenance, and what plant-floor data actually supports.
Choosing problems worth the effort, and moving a promising result past the pilot stage into something people use.
Capital allocation, workforce, verification and liability, and the case a VP has to make internally.
“His keynote sparked meaningful conversations and gave our leadership clear direction for the future.”
“A perfect balance of depth and clarity. Dr. Mehdi kept our senior leadership fully engaged and inspired.”
“Dr. Mehdi made AI not just approachable, but directly actionable for our teams across the globe.”
I trained as a civil engineer specializing in structural, and entered the profession as a structural engineer while teaching myself computer science on the side. I later took a master's in construction management and managed the construction of commercial and industrial buildings. My PhD, at Georgia Tech, was in building construction inside the School of Architecture, in design computation, alongside a master's in computer science. I then spent years at Autodesk as a research scientist developing generative design algorithms, and led a team on AI for structural engineering and architectural design. My 8 U.S. patents come out of that work and are public.
It can be either, and the version is chosen before the event rather than assumed. The technical version goes into how these methods are actually applied to engineering problems and where they break. The leadership version is about capital allocation, workforce, risk, and how an organization gets from pilot to production. Both assume an audience that can handle detail.
Skeptical engineers are the best audience for this talk, because the skepticism is usually correct. Most AI claims aimed at engineering overstate what a model can do with the data an organization actually has. I spend real time on the failure modes and on what has to be true before any of it works, which is what earns the room's attention for the part that is genuinely useful.
Yes, and in more depth than most audiences expect, because that research is where my patents come from. The talk covers what generative design actually does to an engineering workflow, why constraint handling and problem framing matter more than the algorithm itself, what it changes about the engineer's role, and where the approach genuinely does not apply. It scales from a general-session overview to a session for a room already using these tools.
This page is the front door. If your audience designs and delivers buildings and infrastructure, the AEC page goes deeper on that world. If they design products, components, and the plants that make them, see manufacturing and automotive. If you are programming a conference for a professional society, see trade and professional associations.
Yes, and that mixed room is common at engineering leadership summits. The approach is to keep the technical claims precise enough that engineers trust them and the consequences framed clearly enough that executives can act on them, rather than pitching to the middle and losing both.
Yes, and it is often the better use of the trip. A common pairing is a keynote in the general session and a working half-day with the engineering, R&D, or operations leadership on what to actually do next.
Yes. Virtual and hybrid keynotes are available and are built differently from the in-person version, with shorter segments and more interaction, because a remote audience behaves differently from an auditorium.
Three to six months is typical for a conference keynote, and longer for society annual meetings that plan a year out. Fees vary by format, location, travel, and whether a workshop or advisory day is included, and are available on request through the booking page.
Tell me which discipline is in the room and how deep you want it to go. I reply personally, usually within two business days.
Check Availability View the Speaker Kit