Hello Domonkos, great to see you, and thank you for joining us.
Domonkos: Hi Jakob, glad to be here. I will do my best to explain what we do without hiding behind jargon.
Tell us in one sentence what DiffuseDrive does.
Domonkos: DiffuseDrive helps computer-vision teams create the training data they cannot easily collect in the real world. We focus on rare, dangerous or expensive-to-capture scenarios and generate targeted synthetic data that matches the customer’s sensor environment closely enough to be useful for training and evaluating perception models.
What was your background before DiffuseDrive?
I studied physics at Eötvös Loránd University in Budapest, with a master’s specialization in data science, and worked in an AI research group on neural-network methods for scientific problems. Professionally, I worked on computer vision, language models and large-scale data systems, including as a lead data scientist at a major European retailer. That combination of research and applied work taught me that strong AI systems depend as much on data quality and evaluation as they do on model architecture.
You joined DiffuseDrive when the company was still more of a vision than a finished product. What convinced you to take that leap?
The timing felt right. By 2024, generative image models had become capable enough to move beyond demos and start solving very specific computer-vision data gaps. I had already experimented with synthetic training data earlier in my career, so I knew the problem was real. What interested me about DiffuseDrive was the focus on generating the exact scenarios a model is missing, rather than simply producing more images.
As one of the founding engineers, you’ve had responsibility for building the company’s core AI architecture. What is it like to build something when there isn’t an established playbook yet?
You learn by being wrong quickly. Early research code is great for proving an idea, but turning it into something reliable means creating structure around it: reproducible training, clear evaluation, modular components and guardrails for failure cases. A big part of my role has been turning fast-moving AI research into an architecture that other engineers can build on and customers can actually use.
What has been the biggest shift for you in moving from researcher and engineer to technical leader and architect?
The biggest shift was moving from being right to being effective. As an engineer, you can focus on finding the best technical answer. As an architect, the system has to make sense to the whole team, and the people around you need to understand and own the decisions. My definition of ‘done’ also changed: it is not enough that something works for the person who built it. It has to be reliable, understandable and safe for someone else to operate.
A lot of generative AI is judged by whether an image looks realistic. Your work uses a different definition of success. How do you measure it?
For us, realism is only the starting point. The real question is whether the generated data improves a model on real-world footage it has never seen. We compare performance with and without the synthetic data, especially on the rare scenario we are trying to fix, and we also check that performance on ordinary cases does not get worse. A beautiful image that teaches the model the wrong thing is not useful training data.
You argue that the future of synthetic data is not just about generating more data, but the exact data you are missing. Can you give an example?
Imagine a vision system that already has huge amounts of normal daytime footage but performs poorly in snow, heavy rain or with a partially blocked lens. Another hundred thousand ordinary images will not solve that problem. What matters is generating targeted examples of the missing condition in the same kind of sensor domain the model will encounter in practice. That is where synthetic data becomes valuable: it fills a specific gap instead of adding volume for its own sake.
What makes synthetic data for physical AI different from the data problem faced by large language models?
Large language models benefited from an enormous amount of text that already existed on the internet. Physical AI does not have an equivalent dataset waiting to be collected. The data is often sensor-specific, expensive to label, difficult to capture safely, or restricted to secure environments. That means the challenge is much more targeted: identify the exact failure mode, generate the missing data in the right sensor context and validate that it actually improves the perception system.
One challenge you describe is that a generated image can look convincing to a human while being harmful for training. What does that mean in practice?
A generated image can look completely believable while missing the rare object or condition the model is supposed to learn. It can also introduce subtle inconsistencies that a human would ignore but a detector may learn from. That is why we use several layers of quality checks and reject data that does not meet the requirements. The important idea is simple: visual quality alone is not enough; training utility has to be measured.
DiffuseDrive works across very different industries. How much domain knowledge does an AI engineer need to solve these problems well?
More than I expected. You do not need to become an expert in every customer’s industry, but you do need to understand what failure means in their environment. A false alarm, a missed object, a dirty camera or a changing seasonal condition can have very different consequences depending on the application. You cannot design the right training data until you understand which mistakes matter most to the people using the system.
Generative AI models are evolving incredibly quickly. How do you build a production architecture when the underlying models may look very different six months from now?
The key is to avoid building the product around one specific model. We design the AI stack so that new model families can be evaluated and integrated without rebuilding everything around them. The more difficult part is keeping the surrounding system stable: data handling, evaluation, validation and the safeguards that make the technology usable by people who did not build it. A production AI product has to survive the pace of research.
Synthetic data is increasingly discussed as a key technology for physical AI. Where is the industry overestimating it, and where might it be underestimating it?
It is overestimated when it is presented as ‘unlimited data’ or as a replacement for real-world data. Real data is still what anchors the system to reality. Synthetic data is most useful for filling the rare and expensive gaps around it. Where I think it is underestimated is speed: if a new failure mode appears, being able to create targeted training data quickly can shorten the response cycle dramatically. That is much more interesting than simply producing larger datasets.
Looking ahead, what has to change before AI systems can operate more reliably in the messy physical world?
The feedback loop has to become much faster. When a deployed system fails, teams should be able to identify the scenario, create targeted data, retrain and validate the model in days rather than months. Evaluation also needs to become more rigorous, especially for rare cases, and labeling needs to become far more automated. The strongest physical-AI systems will be the ones that can keep learning from the real world without losing control over quality.
Thank you for joining us. We wish you the best of luck!
Thank you, Jakob. It was a pleasure.
