A conversation with Dr. Luc Julia

Rewiring today’s factories to code tomorrow’s cars

Dr. Luc Julia, Chief Scientific Officer, Renault Group

Dr. Luc Julia is Chief Scientific Officer at Renault Group, where he leads the organization’s efforts in AI, data, and software-driven transformation. With a background in computer science and a career spanning roles at Apple, Samsung, and the Centre national de la recherche scientifique (CNRS, French National Center for Scientific Research), Dr. Julia is recognized as a pioneer in voice recognition and AI and is the co-creator of Siri technology. Since 2020 he has been a member of l’Académie des technologies (the French Academy of Technologies). On October 2020, he was awarded the Légion d’Honneur (the highest French order of merit) by the Secretary of State for the Digital Economy, in recognition of his work in the fields of AI, human-computer interaction, digital media, and other advanced technologies.

---

Code on the shop floor

What does the chief scientific officer of an automotive manufacturer do?

My mandate isn’t fixed. I have the freedom to inject software ideas and practices into any department. For the past four years, we’ve been working on putting AI in the factories and in the cars themselves. We’re introducing practices that would be beneficial for a full software-defined vehicle (SDV) and pushing for modularity – the kind of modular design that SDVs can provide.

I actually have one tongue-in-cheek KPI: I aim for a 90% failure rate in our projects. Of course, I never actually achieve that – I only get to around 70% failure. But there’s a philosophy behind this: if we’re failing a lot, it means we’re trying to do very advanced, difficult things. We’re pushing boundaries. So to me, a high failure rate is a sign that we’re taking risks and innovating. In practice, I end up killing around 70% of the projects we start within a year. And that’s okay. It means we learn and move on to the next challenging idea. For my function, performance is measured by whether we’re attempting bold innovations, not whether they succeed or not (and naturally, many will fail).

---

What are the reasons behind project failures?

Usually, it’s because we discover we can’t successfully deploy it in the real world. It’s rarely due to the core technology not working; it’s more about the context. For example, say we develop a new AI tool for a factory floor. If we then realize that the workers will find it too complicated or just don’t like it, then there’s no point in continuing. The technology might have been cool, but if it can’t be applied due to practical barriers, that’s when I call it quits.

---

How do you select the projects or topics you work on?

We prioritize projects that we can execute quickly and that can make a short-term impact – especially projects that improve day-to-day operations. Some initiatives can change how a team or a factory operates in a matter of months. Of course, we do have longer projects. Anything involving changes to a car’s hardware or core systems can take 18–24 months. But we balance those with quick wins.

Another key criterion is reusability. Modularity is huge for us. We ask, if we build this, can we reuse the components elsewhere? We’ve developed certain software modules that can be plugged into different projects. If a new idea comes along, and we realize we already have 60% of the pieces from previous work, we’re more likely to pursue it. It saves time and avoids reinventing the wheel.

So, in summary, we select projects that 1) can be delivered fast for short-term impact, and 2) reuse existing building blocks or contribute new ones that we can reuse in future. If a project concept meets those criteria, it’s a go. If it’s something that would require starting from scratch that wouldn’t have an immediate big impact, we might set it aside for later.

---

Becoming software-ready

What leadership or governance changes do you think are needed for the organization to become more software-oriented?

First and foremost, education and mindset. Automotive manufacturers are dominated by people with hardware backgrounds: mechanical engineers, experts in building cars. That expertise is great and necessary, but we need leadership to truly understand software development practices. It can be challenging to implement real Agile in our environment because of the way car programs run.

Think about it. A manufacturer defines a car’s hardware four to five years in advance, step by step, with long lead times and freeze points. Software should be continuously updated and iterated on, not frozen years before launch. But in the current setup, even our software development is forced to follow that rigid timeline to align with the car’s production. By the time the software actually gets into the vehicle, it might already be outdated.

For decades, the mindset at the top has been “hardware-first.” Changing that means training and convincing people to think in terms of software cycles, over-the-air (OTA) updates, rapid improvements, etc., which is new territory for many. There’s a lot of internal resistance simply because “this is how we’ve always done it.”

Another major issue is organizational structure. Automotive manufacturers have too many layers of hierarchy. In engineering divisions, there can be seven layers of management between the CTO (or head of engineering) and the engineer who is actually writing code or designing a component. This dilutes or even blocks transformation.

To be more software-driven, we need to educate our people (especially leadership) about modern software practices, adopt an agile mindset, and flatten the organization or at least streamline decision-making. Otherwise, even the best ideas will get lost in the bureaucracy.

---

When using Agile and DevOps for continuous software updates, how do you ensure functional safety and cybersecurity are properly integrated?

This is one of the toughest challenges, and it’s something the entire software world grapples with. The truth is, despite our best intentions, “cybersecurity by design” or “safety by design” is easier to preach than practice. In theory, you’re supposed to consider security and safety from day one, build them into the architecture, and continuously verify them. In practice, when engineers are racing to develop a feature or fix a bug, they might not think of every potential hole in safety and security systems. Often, we find ourselves in a reactively securing posture: build the feature first, then test it, find vulnerabilities, and patch them.

Even though we have processes to mitigate risks, security is a continuous race. You can never say, “Alright, we’re 100% secure now. Done.” The moment you think that, someone will find a new exploit. Same with safety. So, our approach is continuous vigilance. We incorporate security into the DevOps pipeline (such as automated security scans, static code analysis, etc.), but we also monitor in the field. If we see anything suspicious in fleet data – anomalies that could hint at a hacking attempt or a software glitch, say – we investigate immediately. And owing to the connected car capabilities, if a serious vulnerability is found, we can issue an OTA patch. We integrate safety and security as much as we can from the start, we test like crazy, we follow regulations for baseline best practices, and then we remain on alert. Agile development doesn’t mean we compromise on safety. It just means we have to be extra rigorous.

---

Synthetic data and generative AI

How do you use the data from vehicles on the road, and what role does synthetic data play?

Synthetic data has become extremely important for us, mostly for simulation purposes. Take crash testing. Traditionally, you’d crash real cars to collect data but, obviously, that’s expensive and has limitations. Nowadays, we use simulated crash scenarios to generate synthetic sensor data to represent collisions. That way, we can virtually test how a car’s systems respond to countless crash situations without actually wrecking a car each time.

Another use is simulating driving scenarios. We do have proving grounds and test tracks, but we’ll never cover every possible scenario. So, when we hear about a new scenario or imagine something unusual (“What if a kangaroo jumps in front of the car?”), we can simulate that scenario using synthetic data.

We use AI in two domains: outside the car and inside the car. Outside means understanding the environment: recognizing pedestrians, other vehicles, signs, making driving decisions (all the ADAS and autonomous driving stuff). Inside the car means interacting with the driver via voice assistants, driver alertness monitoring, etc. For the outside part (which is where safety is critical), synthetic data is a godsend.

One reason we rely on synthetic data is the surprisingly limited real-world data available. There are two big obstacles to collecting this at scale:

Regulation (e.g., GDPR in Europe): Privacy laws are very strict about collecting and using data from customers’ vehicles. We need explicit consent, and even when people click “yes” on something, it might not cover everything we need.

Ownership and access: Sometimes, the data generated by a component isn’t directly accessible to us. For a long time, for example, we could not access the raw images from the front-facing cameras in our own cars because that camera module came from a supplier that treated them as its property.

So, between the legal privacy hurdles and some legacy supplier contracts, our actual usable fleet data is much smaller than it could be.

Synthetic data fills the gap. We create the data that we’re missing. We simulate scenarios that we suspect happen in the real world but aren’t yet represented in our datasets. It helps us cover our blind spots and train robust AI models without relying on real-world collection.

---

Are you already incorporating generative AI (Gen AI) or agentic AI?

Yes. For example, in our recently released Renault 5 electric model, we have a built-in intelligent assistant. This is a little avatar on the infotainment screen that you can talk to.  This is powered completely by Gen AI, specifically large language models (LLMs) under the hood. We started working on this before ChatGPT blew up in 2023, so we were slightly ahead of the hype curve. The idea is that you can ask this assistant anything, either general knowledge or specific to the car. It can tap into an LLM or its internal system, as required. The assistant can even have a bit of a personality. It’s a demo of how Gen AI can make a car’s interface more human-like.

For our context, agentic AI could be extremely useful. Think of the car as an ecosystem of AI agents: one agent is constantly watching the road lanes, another is monitoring the driver’s alertness, and so on. These agents can operate semi-independently and then an orchestrator or higher-level logic combines their outputs to decide overall actions.

This aligns with our modular approach and also fits our hardware constraints. We can’t, for example, run a giant cloud-sized AI model in the car in real time. We simply don’t have that computing power on board, for one thing. But we could run a set of smaller, efficient agents on the car’s computers. It’s a bit like having a team of specialists instead of one jack-of-all-trades.

So, yes, we are tapping into Gen AI for the user interface and experience side, and agent-based AI is influencing our thinking on the system architecture side. Agentic AI will become a bigger and bigger deal in automotive software. The industry might need a few years to fully embrace it, but it’s definitely on our radar.