Select clients, research partners, and industry events
I designed the algorithm behind the chassis of the first car built by an artificially intelligent system, then helped take that research all the way into a shipping product.
Most speakers who talk to manufacturers about AI are describing something they read about. I was on the research team that built it.
In 2014 I joined the group that brought AI into Autodesk, on Project Dreamcatcher, as a research scientist writing the algorithms. The question we were given was not how to make CAD faster. It was how people would design at all in ten years. The answer we pursued was this: instead of drawing a candidate and checking whether it works, an engineer declares the goals and the constraints, and the system produces designs that satisfy them, including designs that can actually be manufactured.
My first project was the one that put it in front of an automotive audience. It became Hack Rod, and I designed the algorithm behind the chassis. A prototype was driven hard across the Mojave with sensors capturing how the structure and the driver actually behaved, and that data drove the generative process. Fast Company covered it in 2015 as the first car designed by an artificially intelligent system.
That is a much harder problem than it sounds, and the difficulty is not in the generation. It is in the constraints. Load paths, stress limits, material behavior, how the part will be made, what tooling exists, what the assembly around it demands. A system that produces a beautiful shape nobody can build has produced nothing. The engineering is in the constraint handling and in giving an engineer a set of options they can actually evaluate and defend to a design review.
Then came the half that matters commercially and gets talked about least. Research is not an achievement until it is a product someone relies on. I was part of the team that transferred that work to the product organization, where it shipped in the Autodesk Fusion portfolio. Most of my 8 U.S. patents come from that period.
I bring this up on stage for one reason, and it is not the credential. The hardest problem in your organization right now is almost certainly not whether AI can do something impressive in a demo. It is the distance between a promising result and a capability your engineers use, trust, and defend. That distance is where nearly every corporate AI program quietly dies. I have crossed it, in engineering, with real customers on the other side. So when the talk reaches pilot to production, it is not a framework assembled from case studies. It is the road, including the parts that did not work.
Three places, and they have almost nothing in common. Conflating them is why so many manufacturing AI strategies read as a list of unrelated pilots.
Exploring far more of the option space than a team can by hand. Lightweighting and part consolidation. Design for the process you actually have rather than the one in the textbook. This is the part I worked on directly, and the part where the engineer's role changes the most: from producing candidates to defining the problem well and judging what comes back.
Planning and scheduling, quality and inspection, maintenance, yield. The constraint here is rarely the model. It is that the data coming off the floor was collected for a different purpose, or was not collected at all, and nobody budgeted for fixing that.
Who is allowed to approve an AI-assisted design. What verification looks like when the system cannot explain itself. What happens to an engineering career path when the entry-level work is the first to be automated. These are the questions that decide whether the first two ever amount to anything, and they are leadership questions, not technical ones.
Three things designed on the platform I worked on. Independently documented, and 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 →The fastest way to know whether he is right for your room.
Select clients, research partners, and industry events
Each talk is rebuilt around your audience and calibrated to how technical the room is.
The talk changes depending on who is in the room. These are the audiences it gets built for most often.
Vehicle and component design, lightweighting, supplier engineering, and how value shifts along the chain as design gets automated.
Structures and assemblies under real load, long product lifecycles, and service and maintenance as a data problem.
Faster design exploration, cost and material pressure, and shortening the distance from concept to tooling.
Design for manufacturability as a service, quoting and estimating, and where AI changes what a customer expects you to absorb.
Scheduling, quality and inspection, maintenance, and an honest read on what your floor data will and will not support.
Choosing problems worth the effort, capital allocation, and moving a result past the pilot into production.
A PhD from Georgia Tech in design computation, 8 U.S. patents at the intersection of AI, physics, manufacturing, and design, and years as a research scientist developing generative design algorithms before that work was commercialized into a shipping product. The patent record is public if you want to see the actual work rather than take my word for it.
Before any of that I trained and practiced as a structural engineer, which is why the talk treats physical constraint as the starting point rather than an afterthought. The full arc is on the engineering page.
Today I run YegaTech, where we build AI strategy, governance, and execution plans, and host AI summits and the Disruptors Circle, a peer group in which executives from different organizations compare what is actually working. I wrote Augment It and Disrupt It, and the blog is the fastest way to see how I think before booking anything.
A general AI keynote is, underneath, about text. Summarize this, draft that, save an hour. That framing falls apart in front of people responsible for something that has to hold a load, come off a line within tolerance, and survive a warranty period. I worked on the research side of exactly this problem, developing generative design algorithms, so the talk starts from physical constraint rather than treating it as a footnote.
Skeptical engineers are the best audience for this talk, because the skepticism is usually correct. Most AI claims aimed at manufacturing 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.
Both, and I keep them clearly separated because they are different problems. Design is where I worked directly. Production, quality, and maintenance are where most organizations discover that their real constraint is data that was collected for another purpose, or not collected at all. Which end gets the most time depends on who is in the room.
Either, chosen before the event rather than assumed. The technical version goes into how these methods are applied and where they break. The leadership version is about capital allocation, workforce, approval and verification, and how an organization gets from pilot to production. Both assume an audience that can handle detail.
Yes, and that mixed room is common at industry conferences and supplier events. 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. Before the event I run a short discovery call, review your priorities, and where it helps speak with two or three of your engineers or leaders directly. Those conversations are where the examples come from, and they are the reason the room recognizes itself in the talk rather than watching a generic presentation.
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 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. 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 who is in the room, how technical you want it, and what they should leave ready to do. I reply personally, usually within two business days.
Check Availability View the Speaker Kit