The Real Cost of Speed: When Development Moves Faster Than Validation

Imagine two engineering teams developing a new vehicle. Both have the same target: reach the market before their competitors.

The first team shortens reviews, pushes decisions forward and brings the launch date closer.

The second changes how the work gets done. Design, simulation, manufacturing and suppliers work together earlier. Problems surface before they become expensive design changes or production delays.

Both teams may launch sooner. They have not achieved the same thing.

One has compressed the schedule. The other has changed the development process. On a programme chart those look identical, which is precisely why the distinction is so easy to lose.

The real question is not whether vehicle development can become faster. It is whether we can remove wasted time without removing the evidence that makes a vehicle safe.

The Development Race Has Changed

The pressure is not theoretical. An NDTV report in September, citing Bloomberg's reporting of late August, described new models being developed in around two years in one fast-moving market, against roughly three to five years for many established manufacturers. The same reporting cited a projection from IAT Automobile Technology and the China Association of Automobile Manufacturers that greater use of AI could bring some programmes down towards eighteen months.

The same reporting noted that regulators had launched a yearlong campaign including surprise inspections at carmakers, and that mandatory road testing for new-energy vehicles was proposed to double to thirty thousand kilometres.

Those are industry estimates and a projection, not a universal benchmark and not current practice everywhere. But the direction is unambiguous, and the reasons are familiar to anyone in the business. Portfolios are changing quickly, electrification is still moving, software content is rising, and customers now expect updates rather than a fixed product.

Waiting too long to bring a competitive product to market has a real cost, and it is paid by everyone in the company.

It is also worth noting, before this becomes a story about one market, that established manufacturers are already achieving similar numbers. The same reporting describes two European manufacturers bringing new electric models to market in twenty-four and twenty-one months, both using AI and virtual validation, and a Japanese manufacturer developing a new platform and the vehicles on it in parallel rather than one after the other. Compression is not a regional trait. It is an industry condition.

What Established Manufacturers Should Stop Defending

It would be comfortable to treat all of this as someone else's problem. It is not, and I want to be specific about that before going further.

Plenty of what makes traditional development slow has nothing to do with safety. Sequential gateways that exist because the governance calendar is built that way rather than because the engineering needs the sequence. Suppliers brought in after the design is effectively frozen, so their manufacturing knowledge arrives too late to use. Physical builds used to discover problems that earlier simulation or cross-functional review could have exposed. Reviews that assemble twenty people to approve something nineteen of them have no basis to judge.

None of that is validation. It is habit wearing validation's clothes, and it is expensive.

An established manufacturer that defends every familiar process because it is familiar will lose, and will deserve to. The work of going faster has to start inside our own programmes before it is credible to ask questions about anyone else's.

Where the Time Actually Goes

The total development timeline is not made up entirely of productive engineering work. A significant part is consumed by waiting for decisions, resolving interfaces between teams, correcting errors, repeating work, and discovering problems later than necessary.

Consider an ordinary example. A component is designed before its manufacturing constraints are fully understood. Tooling begins. During a later build, an interference or manufacturability issue emerges. The team revises the design, updates the tooling, repeats the checks and adjusts the schedule.

The problem looks like a tooling delay. Its origin was an earlier design decision, an unresolved interface, or a gap in cross-functional review. And the cost is not only the time spent correcting it — it includes everything that now has to wait for the correction.

This is where speed can improve without lowering engineering standards. Bring manufacturing into the discussion earlier. Involve suppliers before design decisions become difficult to change. Use simulation to find likely problems before physical builds. Make interfaces and requirements explicit. Resolve decisions while the cost of changing them is still manageable.

None of these measures removes engineering work that needs to be done. They reduce the amount of work that has to be done twice.

Three Kinds of Time

I find it useful to separate development time into three kinds, because each calls for a different response. This is not a formal industry standard — it is a practical way to tell the opportunities apart from the risks.

Waiting Time: Reduce It Aggressively

Delays between reviews, slow decisions, unclear ownership, sequential handovers that no longer serve a technical purpose.

If a design decision is waiting for a meeting rather than for missing technical evidence, the answer is better decision-making, not more testing. Clear accountability, timely escalation and integrated teams remove this kind of delay without touching a single requirement.

Rework Time: Prevent It Upstream

Rework usually comes from requirements that were unclear, interfaces that were never resolved, manufacturing constraints discovered late, or supplier issues found after the design had advanced too far.

The answer is not to ask engineers to work faster once the problem has appeared. It is to stop avoidable problems travelling downstream in the first place — earlier collaboration, honest design reviews, simulation, and configuration control that actually controls something.

Evidence Time: Make It Smarter, Not Disposable

This is the distinction that matters most.

Some activities exist to establish that the vehicle is safe, durable, reliable and fit for its intended use: appropriate physical testing, verification of safety-critical systems, durability assessment, validation under relevant operating conditions.

Not every test has to happen in the same sequence or by the same method as before. Simulation, automated checks, virtual validation and better reuse of proven designs can all make this more efficient, and should.

Yale Zhang of Automotive Foresight made the point crisply in the same reporting: AI can help manufacturers be faster and more accurate and reduce design errors, but there are baselines — he cited on-road testing distances — that cannot be replaced and should not be replaced.

But the evidence still has to support the engineering decision. A simulation is useful only within the limits of its assumptions, its models and its own validation. A design review does not replace every physical test. A software update after launch is not a general substitute for finding a safety problem before a customer does.

I was glad to find that framing echoed from outside my own industry corner. Bill Russo of the Shanghai consultancy Automobility, quoted in the same reporting, put the regulatory signal this way: companies can keep moving quickly in software, digital features and anything that can be thoroughly validated through simulation, but safety-critical hardware and new technologies need stronger validation before reaching customers.

That is the same line drawn from a different direction. Compress where evidence can be generated another way. Do not compress where it cannot.

The principle is simple enough to hold in your head during a difficult programme meeting: attack waiting and rework first, and make validation smarter rather than treating it as disposable time.

What the Proposed Rules Actually Say

The debate is no longer only about how quickly manufacturers can develop vehicles. It is also about how they demonstrate those vehicles are ready.

The September reporting described a joint regulatory directive, involving bodies including the Ministry of Industry and Information Technology and the State Administration for Market Regulation, focusing inspections on durability, production consistency, and driver-assistance and AI features.

On 10 October 2026, Reuters reported a draft from the industry ministry proposing stricter requirements for vehicle design and development testing. Under the draft, applications for new-model approval would need to supply more technical information about innovative designs and how they were tested, and models judged inadequately tested, or supported by falsified data, could be rejected. Reliability and durability validation would have to cover no less than thirty thousand kilometres.

The draft also addresses specific features: fully concealed door handles, with a requirement for mechanical releases both inside and outside the vehicle; foldable and flexible displays; zero-gravity and swivel seats while the vehicle is in motion; and physical controls retained for functions such as lights and wipers. The reported timeline applies the rules to newly declared models from 1 January 2027, with supplementary filings for previously approved models by 1 July 2027.

These are proposed measures rather than settled requirements, and I want to be careful about what they do and do not show. This article takes no position on the safety of any manufacturer's products. A programme can be fast and thoroughly validated. A long development cycle guarantees nothing by itself — I have seen slow programmes produce poor evidence.

It is also worth saying that this argument is being had inside the fast-moving market, not imposed on it. Executives quoted in the same reporting have warned publicly that compressed timelines risk turning customers into the people who discover durability problems. Others have argued the opposite with equal force — that a vehicle developed quickly which has completed all required testing is simply a demonstration of efficiency, and that asking anyone to slow down is unrealistic when consumers expect constant renewal.

Both positions are reasonable, and the second one is the better test of the first. Speed is not the variable that matters. Evidence is.

What the proposals signal is a principle worth stating plainly: innovation and speed do not transfer the responsibility to demonstrate safety. The question is whether a development process generates sufficient, traceable evidence before the vehicle reaches customers — and that question applies to every manufacturer in every market, including ours.

What AI Can and Cannot Change

AI adds another dimension. It can help engineers explore design alternatives, automate routine checks, analyse large volumes of engineering information and surface conflicts earlier. Combined with simulation and integrated toolchains, it may reduce the time some tasks take by a great deal.

But generating a design, flagging a possible issue, and proving a complete vehicle is safe are three different activities. I wrote about the limits of the first two in Frontier Agents Were Asked to Design Real Parts. None Passed. — where capable models produced geometry readily and still failed to hold many stated constraints true at once.

An AI system may propose something that looks entirely plausible. Engineers still have to establish that it meets the requirements, works within the system, can be manufactured consistently, and performs under the conditions the vehicle will actually meet. The more complex the system, the more it matters that requirements are testable and evidence is traceable.

AI should help teams reach sound decisions sooner. It should not convert an unverified output into an approved engineering result because the programme is under schedule pressure. The advantage will come not from using AI, but from redesigning the process around better information, faster feedback and verifiable decisions.

Five Things I Would Watch in a Faster Programme

A launch date on its own tells you very little about the quality of the development that produced it. Alongside the timeline, I would look at five things.

Design maturity at key milestones. How many major requirements and interfaces remain unresolved when the programme is allowed to move forward?

Late engineering changes. How much significant redesign is happening after tooling, validation or production preparation has begun?

Validation coverage. Have safety-critical requirements been verified by appropriate methods, with results that can be traced back to the requirement?

Issue closure quality. Are problems genuinely resolved and retested, or moved to another team and another milestone?

Early field performance. What do warranty data, customer complaints and in-service issues say once the vehicle is out?

These have to be read together. A programme with few late changes may be benefiting from better upfront engineering. A programme hitting every milestone while carrying unresolved safety-critical issues has a completely different problem, and the schedule will not reveal it.

The objective is not another dashboard. It is to make sure schedule performance does not conceal engineering risk.

The Lesson for Engineering Leaders

The pressure to develop faster will not go away, and should not. Established manufacturers have to challenge unnecessary process, improve collaboration, and adopt technology that allows better decisions earlier.

But leaders also have to distinguish between a delay caused by an inefficient process and the time required to establish that a product is fit for purpose. That distinction takes discipline, because the two feel identical when you are behind.

When a programme slips, the easiest response is to demand acceleration from every function. Reviews get shorter. Open issues move forward. Teams are asked to recover the schedule. Sometimes that focus is exactly what the programme needs.

Sometimes the apparent delay is a signal that the engineering has not yet resolved an important question. Treating both situations identically makes a programme look faster while transferring risk to manufacturing, to service teams, or to customers.

Which is a different version of a question I have written about before, in Who Can Say No to AI? Automotive Answered That Long Ago. — separating the people who check from the people who decide exists precisely so that schedule pressure cannot quietly become an engineering judgement.

The better question for a development leader is not how many months can be removed. It is which months are being lost to waiting and rework, and which activities produce evidence we cannot responsibly do without.

The goal is not to make engineering take less time at any cost. It is to make less time necessary to do engineering properly.