Testing a brand-new air and missile defense setup in an active war zone sounds bold. It also sounds like the kind of decision you only make when you believe two things at once: that your system is ready, and that the normal pace of defense development is too slow for the world we’re in.
Based on what’s been shared publicly, Leonardo says it plans to start testing elements of its Michelangelo Dome in Ukraine by the end of 2026. Not a glossy demo on a quiet range. Not another controlled exercise with scripted targets. Ukraine.
From our side of the table—building radar and drone detection systems, and building AI fusion that pulls signals from different sensors into one picture—that choice lands with real weight. Because if you’re serious about air defense now, you’re not arguing about theory. You’re arguing about minutes, overload, confusion, and the fact that the next wave doesn’t wait for your integration plan.
The pitch of Michelangelo Dome is pretty clear: open, modular architecture that ties together radars, missiles, anti-aircraft guns, counter-drone tools, and other sensors and “effectors” into a single network. The core piece mentioned is an MC5 module—hardware plus software—that’s meant to connect different systems and move data quickly so detection-to-engagement is faster and more coordinated.
I like the direction. I also don’t trust it until it survives reality.
“Open and modular” is a great phrase. It’s also where projects go to die. Everyone says they’re interoperable until the first time two systems disagree about what they’re seeing, or the network gets jammed, or an operator is forced to choose which alert to believe while a drone is already diving. In a lab, you can make a clean story. In combat, your story gets interrupted.
The part that matters most to me isn’t the brand-new name for the dome. It’s the idea that you can fuse radars, electro-optical sensors, acoustic sensors, third-party feeds, and whatever else is available into one shared view fast enough that people can act. Our world lives or dies on that. Radar drone detection is only as useful as what you do with it next. If the radar sees it but the shooter doesn’t trust the track, you’ve basically paid for a warning light.
And Ukraine is the harshest feedback loop imaginable. That’s a compliment and a warning.
There’s a reason they’re involving a newly created Kyiv unit to tailor the solution based on battlefield experience. On paper, that sounds like humility: “We’re going to listen and iterate.” In practice, it’s also an admission that what you built at home won’t map neatly to what’s actually happening. Threats change, tactics change, and the enemy learns. The system you test in year one is not the system you need in year two.
So yes, building close to the operators makes sense. But there’s tension here that people should not wave away: adapting fast means pushing changes fast. Pushing changes fast inside a defense network that’s supposed to be trusted is risky.
Imagine a night with mixed threats: small drones meant to drain attention, then a larger raid, then something faster that forces a split-second decision. In that moment, “low-latency data exchange” is not a feature; it’s the difference between one coordinated response and five separate teams stepping on each other. If an AI fusion layer is wrong, it won’t just miss something—it can mislead multiple weapons at once. A single bad correlation can turn into wasted interceptors, friendly-fire risk, or a false sense of safety.
Now imagine a different scenario: a country has several old air defense assets from different eras and different suppliers. They can’t afford to replace everything. An open architecture that can integrate third-party systems could be the most realistic path to better coverage. In that world, the winners are the operators, not the vendors. You build a framework and let the best sensor and the best interceptor do their jobs, together. That’s the promise.
But there’s another side: “open” can become a political word. Some customers will love it because it avoids lock-in. Others will fear it because openness means dependency—on network design, on software updates, on who controls the configuration, on who can audit what the system is doing. Even if the intent is clean, the trust question doesn’t go away.
There’s also the uncomfortable ethics and optics. Testing in Ukraine means learning in a place where mistakes have a human cost. I’m not going to pretend that isn’t true. The argument for it is that Ukraine is already paying that cost, and systems that improve coordination and speed can save lives. The argument against it is that “operational validation” can slide into “we’re using a war to finish development.” Both can be partly true, which is exactly why people will argue about it.
And the 2026 timing is its own signal. It suggests this isn’t something that’s ready tomorrow. That’s honest, but it also means the system is being built for a war environment that may look different by the time it’s tested. Drones evolve fast. Electronic warfare evolves fast. Even the definition of “drone detection” changes when decoys and swarms show up. What does “validated” even mean when the target keeps shifting?
From where we sit, the direction is right: fuse more sensors, connect more shooters, reduce delay, and make the whole thing resilient under stress. But if Michelangelo Dome succeeds, it will be because it works on a bad day, not a good day—when the data is messy, when links drop, when operators are exhausted, and when the system has to choose what matters.
So here’s the real debate I want people to have: should new defense networks be tested in live combat to speed up learning, or should that line never be crossed even if it slows down getting better protection to the people who need it most?