Canopy Inside Track: moving faster with generative and agentic AI
August 6, 2026
by The Canopy Team
At Canopy Simulations, AI is a tool that empowers engineers but does not replace them. LLMs are carefully deployed in different areas such as accelerating code development and review, or enhancing customer support.
Just as importantly, Canopy is transparent about where AI has no place: our physics models are built entirely from first principles, our lap time optimisation is mathematically rigorous, and customer data is never used to train models.
This approach ensures that cutting-edge AI productivity gains never come at the cost of accuracy, reliability, or client confidentiality.
Code Development and Review: AI at Canopy
Canopy was founded in 2015 as a small, natively remote, highly flexible organisation providing lap time simulation software as a service to a select group of motorsport teams. While we have now grown, our core ethos of a natively remote, flexible, agile team culture has been retained.
The scale of our team and the complexity of our vehicle models, along with our commitment to respecting client confidentiality and protecting IP, mean that using large language models such as Claude, Codex, Gemini, and Copilot for software development in a responsible way presents some interesting challenges.
The world of software development has evolved rapidly in the last 12 months, and we have worked hard to ensure that we are following industry trends without exposing ourselves to risk. We are also steadfast in our commitment that this is a disruptive technology that improves each of our individual engineers’ productivity and value – it will not be used to automate human functions or replace our engineers.
Agentic coding enhances our ability to deliver race-winning and championship-winning simulation tools, but we must not accept a reduction in our standards of reliability and accuracy in exchange.
Our code exists at the intersection of mathematics, software development, and vehicle science. Although LLMs are reasonably good at software development, they are still lacking compared to experienced engineers at the understanding of vehicle dynamics. Over many years, we have developed a knowledge base that can’t be adequately captured by current language models.
Instead, we have found applications for agentic coding in three key areas: prototyping, debugging, and code review. We’ve been able to build and test new features rapidly, very quickly determining whether they add value and are worth pursuing. This has helped us to prioritise and implement features from our feature requests – thank you for continuing to actively contribute to this!
We’ve been able to build significantly better in-house tools to help us build and validate each new simulation version, contributing to a continuous improvement in simulation convergence and reliability, and a reduction in unintentional breaking changes.
Finally, we’ve deployed carefully configured agents to perform code analysis and review, contributing to large performance and robustness improvements without sacrificing reliability. This includes the recent reduction in solve time by 20-30%, and has also been critical in validating the migration to the more modern and industry-standard parquet file format.
Support and AI
Canopy Simulations is a cutting edge technology with a unique approach to simulation. When we began to think about AI and how it could be used to improve our services, one obvious area was customer support. The Canopy simulation engine and its support infrastructure are complex. Our engineers are very knowledgeable about the areas they work in, but it would be unreasonable to expect any one team member to understand the entirety of our software stack.
To this end, we have provisioned a local LLM and given it access to a number of local resources. It can read our support pages and has access to some of our code repos. It can read tickets and craft responses for us to send. It can read some of our technical Slack channels to search for discussions that relate to the problem area.
We are very mindful of security so our LLM does not have access to the wider internet. This means that it is less likely to ‘hallucinate' or get things wrong. It doesn't have Reddit threads about gluing cheese to a pizza to contend with!
The LLM is a useful tool for triaging support tickets. If a ticket arrives in an area that a support engineer is less familiar with, the LLM can give useful context to help them to understand the user’s problem. It can also look for documentation about specific features, highlight recent conversations in Slack that were pertinent to the issue, and gather the disparate sources of data into one concise report. This allows the support engineer to understand not just the underlying problem, but also whether or how it related to any other ongoing projects.
Feedback from across the team has been positive — the information the LLM surfaces for each ticket is relevant, up to date, and accurate. It has proved particularly useful to newer team members, quickly giving them context in areas they aren’t yet familiar with, and helping them communicate clearly with customers on cases that need to be escalated.
We are very mindful of the potential pitfalls of using an LLM as part of our support process. We take care to treat its output with suspicion, and we always verify with real engineers before taking action to resolve a ticket. It can be an efficient and relatively quick way of searching Canopy data sources, allowing support engineers to make informed decisions when dealing with customer issues.
How we DON’T use AI
One of our core development practices at Canopy is that we build our physics models from first principles and established engineering theory. We don't use machine learning or AI to approximate vehicle behaviour. The vehicle dynamics, tyre behaviour, powertrain, and aerodynamics are all described by governing equations derived from established engineering theory, not fitted or inferred by a black-box model trained on datasets. This matters because first-principles physics is interpretable, reproducible, and verifiable. When simulations and models become as complex and sophisticated as Canopy’s, we feel it’s important to be able to trace the results back to the actual equations. This means that the behaviour of the model or odd-looking results can be verified and understood from the fundamentals, allowing our customers to apply their engineering knowledge and make defensible decisions to improve their vehicle’s performance.
Another common use of AI in vehicle dynamics and simulation would be in developing driver models. Control models can be developed which “learn” to drive around a track, trained on existing datasets or through some sort of reinforcement learning strategy. We don’t do this at Canopy. In fact, as experienced Canopy users will know all-too-well, we don’t have a “driver” model at all! Our Dynamic Lap simulation is a mathematical optimisation, not a learned or heuristic controller. It solves for the control strategy that is mathematically optimal for the given car, track, and constraints, and the solution satisfies the Karush-Kuhn-Tucker (KKT) conditions. In other words, the “driver” in a Dynamic Lap simulation is optimal in a rigorous mathematical sense rather than being an approximation trained to imitate example laps. This gives our customers a repeatable benchmark of what the car is genuinely capable of, free from the variability and opacity that a trained driver model would introduce.
Finally, we don’t use AI to develop our default car configurations (though we have experimented with AI driven simulation workflows! https://simulation.michelin.com/canopy/technical-articles/vibe-coding-with-canopy ), and we do not train on customer data in any way. Car setups and configurations are produced through deterministic, physics-based workflows under the engineer's control, and customer data stays strictly within the control of each customer on the Canopy portal. It is never harvested to train models or shared across customers. This ensures the confidentiality of our customers' intellectual property, and protects the competitive advantages they achieve using Canopy’s simulations.