Good morning, everyone, and welcome to the Hudson Institute. I'm Brigham McCown, senior fellow here. You might notice that Emil Michael is not standing here yet. We have a distinguished expert panel. We've had to flip the expert panel and Secretary Michael's address. He will be here shortly due to a scheduling conflict, so I apologize for that. We're honored to have such a distinguished group on stage now, and thank you for joining us for winning the info competition. Innovation is critically important, as many of you have seen. Introducing the panel, we have our moderator, Dave Byrd, fellow for the Center for Defense Concepts here at Hudson. Next to him is Nick Bucci, Vice President of Systems and Technologies at General Atomics Electromagnetic Systems. We have Sean Vendetti, Lockheed Martin, Rotary and Mission Advanced Concepts; followed by Joe Coochin, Executive Director of the National Spectrum Consortium; and last but not least, Sam Lisburn, Vice President of Products at Saronic. The floor is yours.
Thank you, Brigham. I'd like to thank everybody for coming today. I appreciate you all meeting us on this very warm morning, and to all of our panelists. I'd also like to note that this event is one of the several lead-up events to the APEX conference that will be held in January of 2027. So it is a large defense conference about this exact topic, and we'll be hosting several workshops, panels, and moderation events leading up to it, exploring all of these topics in more detail. So check it out. I'd like to start off with giving everybody a chance to both introduce themselves and just to level-set the conversation. This whole discussion is about adaptability and innovation, but I'd like to start off with saying: what does adaptability mean to you and your organization, and how do you define it in this military context?
I guess for me, the quote from Mike Tyson kind of resonates with me when it comes to adaptability, and that is: everybody has a plan until they get punched in the face. What that means from an adaptability, from a defense systems perspective, is being able to take a weapon or a system that is geared toward a particular environment or mission and figuring out how to use it when it's in a different battle environment or in a different use case. And that is what always happens. You know, the old plan or saying in the military is, you know, any plan doesn't survive first contact with the enemy. I prefer the Mike Tyson version, though.
Yeah, no, I love that definition. I really got into this about 12 years ago with the DARPA Adaptive Radar Countermeasures program, DARPA ARC, and "adaptive" was right there in the title. For about two years, it was a program about algorithms, and then we kind of realized it had to be about: how do you tell what happens when you get punched in the mouth? What does it mean to get punched in the mouth? What are the different ways in which EW can punch you in the mouth, or a different system can punch you in the mouth? So we really drove home this idea that that evaluation environment and evaluation mechanism really was one of the core tenets to develop and to assess cognitive or adaptive systems. This is obviously before LLMs, but now that it's in vogue and it's all in our collective consciousness, right, we're at the point that it's just like humans, right? You have to be able to assess the adaptation of the system. You have to be able to drive the adaptation of the system. You need the sensing capabilities within the system, you need the cognitive flexibility of the system, you need the resilience. And so it's still a DARPA-hard problem. It's just the technology has evolved this to a different point where we're not talking about beating chess masters, we're talking about beating StarCraft or we're talking about beating real operational environments.
Great. Thank you, and glad to be here this morning. Very briefly, the National Spectrum Consortium is a 300-something member OTA consortium that's focused on innovation, broadly speaking, in the spectrum space—anything wireless, so anything that radiates or receives. Matter of fact, I think all three of the organizations here on stage are actually members of the consortium. I can talk about adaptability in two main thrusts. My main focus, I come from the telecom space, so from the communications space. But none of the technologies we talk about today or the systems that need to be adaptable don't, at their core, have a comms, sensing, EW problem to solve there. So it is a technology that is central to almost everything else within the DoD space. And these systems, there is a huge push for these systems to use and mesh with commercially available systems, which have now gotten extremely complex, right? Used to be that DoD comms systems were by far and away better than anything civilians had. Now we have something in our pockets, especially when you add an LLM over the top that you can access there, that rivals anything that military technology can put out there. Not only that, but these systems, because they've proliferated, now also cause tremendous issues if we leave the United States and go elsewhere because everyone else has them and they can use them, and there's no way to control or find them. So it's obvious what has come up just even recently in the recent conflicts from there.
The other sort of adaptability angle I'll put on it is that I focus a lot of my time on DoD procurement and innovation. Like, how do you get new innovation from smaller, more nimble commercial partners in through to the warfighter? The purpose of our OTA is prototype development in this space. So how do you form new partnerships? How do you solve new problems? How do you get solutions that go across DoD in the spectrum space, which, as Sean and I were just talking about earlier, is a very difficult problem—tons and tons of different systems, tons of different programs, tons of different missions and goals, and not all coordinated. So there's a sort of a government coordination problem in the spectrum and wireless space. There is a coordinate-with-industry problem. And then there is the: how do you rapidly get that through the innovation pipeline? And that is all a question of adapting the existing technology in the world, which has raced very far out ahead in some cases and can cause real problems in the defense space. How do you use that, adapt it, and quickly modify it, and do so in a way that meets the mission of all of the various different agencies and units across DoD? So I kind of think about that in two different places, a little more upstream even: how do you get that innovation going, and the policies correct, and then the acquisition framework and the innovation correct so that it goes from one end to the other more seamlessly?
Excellent. Good morning. Thank you for having me. Rather than converge on a single definition of adaptation, I'm going to add more definitions of adaptation just to make this more complicated. When I think about our work at Saronic, there's two additional places in which I think adaptation is relevant. My fellow panelists have described how adaptation is relevant in a short-term tactical environment, but there's two other places that our product work at Saronic views adaptation. One is that we're just a startup working in the defense space, and so adaptation is a cultural value and something that our organization is constantly facing. I joined the company three years ago as employee 25. We're at 1,700 people. You can believe that there's adaptation on a day-to-day basis inside our organization. So I think adaptation is something that's a resident cultural value or an organizational value in addition to a practice.
And then when I think about the products that we're building, we think about building autonomous surface platforms that meet a variety of needs across the joint force. Most people look at autonomous boats or ships and think that they're Navy-only products, but that's actually not the case. The responsibility of our team in product is to think about how we can build products that adapt to different needs across the services or across the joint force. So adaptation is also not just in response to an adversary, it's in response to divergent needs across DoD, and that's something that we place a high premium on.
And I think that's a great segue to jumping into sort of what actually enables this. So kind of continuing on with your point, in these recent conflicts, both Ukraine and Iran have proven remarkably resilient against getting punched quite hard in the mouth. How do we, as the US industrial base, enable that kind of adaptability, that kind of modularity, and flexible system composition at the industrial base level so that we can quickly find those new techniques, find those new innovations, and scale them quickly? So maybe start with you, Sam. If you could talk about Saronic's approach to industrial manufacturing and your modularity in boat design, especially since you guys have been in the news lately.
We have indeed. Yeah, I'll take that question a couple ways. The first thing I'll say is that there are two lessons from Ukraine: one is about adaptation, but the other is about mass. So there's a fine balance here between building systems at scale, which typically requires that they look exactly the same, and building systems that are adaptive and can continue to respond to threats. For us, the way we think about this is that we build common platforms. So our autonomous surface vessels are consistent, simple. In some ways, we liken these to pickup trucks, and then we allow operators to put whatever payloads or kits or modifications into those platforms. So for us, the adaptation in hardware is actually in the payloads, the sensors, and the integrations that we do on top of the base platform. That allows us to achieve scale in the base platform, but continue to meet discrete user needs and adapt to changing battlefield circumstances. And then we can also do the same thing in software, where the software can change on a recurring basis. Part of the advantage that we have as a business is that by bringing software, hardware, and production under one roof, we're able to sort of increase the velocity of that cycle.
And the other point I'd just make is that when we think about flexibility and adaptation in production, there's a distinction here between boat building and shipbuilding. We're trying to bridge that divide, but also recognize the inherent structural differences between those two disciplines. If you visit our production facilities in Austin, Texas, most of the workstations are set up on caster wheels so that we can continue to move around workstations and make that process more efficient. If all of a sudden we need to add a substation or a subsystem to the platform, we have the capacity to do that. Shipbuilding looks a little bit different. And so there, we're embracing robotics and software to sort of expedite the ability to adapt shipbuilding practices. But in both cases, we think about production as a necessary ingredient to adaptation in addition to technology development.
Nick, I'd like to hear your perspective on how this kind of works at GA, because GA does something similar working across domains—submarines, air-to-air missiles, vehicle bodies. You've tried to really find common approaches between these different domains and these different kinds of technologies.
Yeah, I'll take a step off of what was said, and that is: most people don't think about adaptability being enabled by manufacturing production. You kind of highlighted a lot of the different things, and the adaptability that we have in manufacturing across General Atomics Electromagnetic Systems starts with some of the commercial technologies that we leveraged into the defense world. We had a unique pressure vessel design that we needed to utilize for an electrostatic separation mechanism that we have that helped us figure out how to do all of the welding certifications, all the infrastructure, all of the machining technologies, all those kinds of things that we now use for things like Virginia payload tubes, for special parts for submarines, and things like that. So it's all about the ability—and our president says it very well: we go from technologies that support undersea to outer space. Being able to figure out how to adapt your manufacturing space to have that broad mix is an important thing to do to be able to do it efficiently.
We had some visitors about a year ago to our facility in Tupelo, Mississippi, and they said, "You could fit our entire production facility in this one building." That building is a couple hundred thousand square feet; we have over 700,000 square feet in Tupelo. And they said, "How is it possible that you can do things efficiently here?" I was telling them the story about the adaptability of being able to do the different products, and that's why we have large facilities so that one day we're making Virginia payload tubes and the next day we're making these containment vessels for our commercial electrostatic separator. They understood that and they appreciated it. I think that's a distinct piece of having the forethought of setting up: what are the personnel requirements that I need? What are the machines that I need? What are the welding techniques, all of the certifications for those people, the training, the buildings? Can I find enough land that's contiguous where I can do this all in one place and take advantage of both adaptability and scale?
And Sean, I know we've talked a lot about physical processes, but I know you care a lot about the digital infrastructure as well. Would you care to talk about some of the adaptable processes Lockheed has been doing for Aegis modification or C2?
Yeah, I mean, there's a few things happening at once here that Advanced Concepts within our group is helping to drive. Lockheed is obviously a large company. There's a lot of variation across the company and types of products we provide. We've just reorganized in a way that the largest concentration of software for the department is within one P&L center, and so with that comes the cultural change and having the brain adaptation, as well as we're within an environment where acquisition reform is happening with increasing velocity of policy and cultural changes that we have to adapt to. So we're helping to drive new business modeling and new interaction with how do we develop software while we're being squeezed on the other end that the whole software development community in the commercial world is learning that the toolset is switching underneath our feet, right? So it's an interesting challenge, and obviously we have to be adaptable to it. But it's also very exciting because we're being given the flexibility to try to change the business, to change how we do business while also changing the traditional methods of developing a product for a department that's buying it in a new way.
So it's not just Aegis, right? The current programs of record which are obviously involved in current affairs globally, there's public information about how we're being flexible and how we're working to update things quickly. But that just speaks to the prior investments we've had, right? So we're really trying to skate to where the puck is going to be, which is multi-domain conflicts, multi-domain challenges the customer has, and this is where we're embracing these new cultural and technology enablers. And half of it is this—oh, did you want to—
I was just going to pick up on you mentioned acquisition reform, which I think is a great example when you talk about adaptability because, again, there is a place in which the government is trying to adapt itself to the speed and the pace of the world, especially in acquisitions that had been, I think, pretty sclerotic, everybody would agree. And at the same time, you see some of those things—and by way of explanation, 70% of the membership of NSC is not represented by the companies either small, non-traditional, nimble, trying to figure out how to become DoD contractors, not necessarily in that spot 100% as established as these folks are. And so you see at the same time sort of a, "Oh, this whole method of acquisition, which you basically didn't understand anyway, is now changing also, and we want to buy commercial off-the-shelf things. Can't we just do things the way the Ukrainians are and buy a DJI drone and strap something into it and away we go, and isn't this innovative?" to CMMC Level 2 requirements that just got issued, which has literally made it more difficult for the government. We've gone backwards. The government now cannot email me documents because, in their way of being more compliant with cybersecurity requirements, they just put an LLM in place that is now stripping attachments out of their emails when they send them to me. And I'm not making that up. That just started happening last week where they're like, "Didn't you get that thing I sent?" It's like, "No, I didn't, because it's gone and you didn't realize it was gone."
So when we talk about adaptability, it happens in these fits and starts where this whole thing has changed and we're racing to meet this brand new world challenge. Some of that is good, but it doesn't happen at a pace where it all fits together well, so you have these big gaps. One of the things that we do as an organization is try to take a smaller company or a startup or somebody who can't possibly understand all of those pieces and help fill the gaps. "Hey, we can help you be more compliant. Hey, we can help you learn how to get a security clearance." Dumb things, but in order to be nimble and be more adaptable and get that technology—that new small company that might grow in to become a Saronic not so long from now or then eventually become a huge defense contractor.
No, no, yeah, there's plenty of innovative things. We love all of our children equally. I have a soft spot for the startups. But my point is, to get you up the chain in the direction of where all these companies want to go anyway, the notion of innovation and adaptability has to be more widespread and more evenly distributed. It happens in these weird fits and starts which cause very odd, like, "Hey, why can't we solve this problem quickly? Go get that thing off the shelf and whatever." And then I hear these stories of, like, such and such unit has figured out how to strap a Starlink to the top of their vehicle and accomplish their mission. Everybody freaks out because they're like, "Hey, you just bypassed all of our cybersecurity." Well, which did you want? Did you want them to solve the problem and be adaptable, or do you want them to follow all the rules? And I'm not saying don't follow the rules; I am saying the rules are going to need to figure out how we get to that place, and it's very unevenly distributed at the moment.
Yeah. So what you're hitting on is just like how, one, innovation is messy, right? Innovation is messy, but evolution goes faster if the ingredients for evolution are readily accessible, right? And one of the challenges in our work is, you know, classification has a purpose.
But classification has somewhat hindered innovation in the fact that you don't know who solved what in what pockets and who really needs what and what's a gap, right? And so this push to commercial, a lot of people have thought about it, especially within our organization, as, "Oh, the government wants to buy a done thing." Well, what's a commercial missile?
What's a commercial weapon system or a commercial Aegis? Right? We have a sister consortium that does ground mobility, and somebody put out a CSO for an autonomous howitzer, a CSO. And she was like, "I'm sorry, excuse me. Like, I really hope no one's finding that on a shelf anywhere, because if you are, we've got a way bigger problem."
So what's really needed is more of a consortium-like model on innovation, and that's where these consortiums like NSC have really helped. But we sort of need to broaden it to really covering accessibility of the environment, how we're solving the game. We made the joke in the green room that, you know, EW is hard, but that's because EW is one of those worst places where everybody's trying to solve a different game.
Right. But if you look at the kinetic side, whether it's Northrop, Raytheon, Lockheed, there is a lot of collaboration on kinetic effects, kill chains, orchestration, and that's why we're being successful in current conflicts. We need the same applied to a multi-domain battle.
And there's the flexibility of the industrial base, which you guys have talked about. There's the bureaucratic integration of these companies, and especially these small players, into the system so that they can talk to each other, actually legally share information. And then there's that last-mile part of: how do you actually get that innovation to the field and kind of make those updates and adjustments on the fly? You mentioned strapping a Starlink onto a truck because that's the solution that you need. What do you see as the opportunities for really accelerating that kind of operational-level and in-field modification of systems, be it hardware or software?
I'm happy to start here. I would say two things. The first is that, as a technology developer, there's no replacement for direct operator feedback and for direct access to operationally relevant intel. So for us, when we have the privilege of working extremely closely with the operational colleagues and those who are employing our systems, we see that the velocity of development is much higher, and we see that the output is much more successful. There have been a couple instances where we've been able to do that. I've never seen anything that is an equivalent substitute for that kind of input on behalf of the warfighter. So I think that's really critical for us.
And Sam, we were talking in the hall about how Saronic will go through and certify products, right, and help to do that. And it's like, do you have to do that kind of on your own? Do you have to wait for a government test facility to open up their time, which is limited? Or if there was sort of this commercial ecosystem of test houses that could be certified, accredited facilities, that might help, right? That's where Bryan Clark and you guys have talked about universal serial bus, USB, right, as an example. Test houses exist for that, test houses exist for 5G, which the NSC knows.
Right. How do we get that kind of independent certification cottage industry, I guess, to spring up and be supported to help expand what TRMC is able to do in organic test ranges?
And what is interesting to me is that this has come up recently quite a few times, and we are wholly supportive whatever way we can. You're seeing some of these things pop up, for instance, for unmanned drones and unmanned vehicles and things because it's a fairly easy thing—like, go find a big open space of land and let people come and play around. But what's not easy in the world that I live in is: how do you get access to DoD frequencies on this private—like, there's a huge coordination problem on the spectrum side. Not only is that coordination problem within DoD, which, please, if you could solve that problem, that's 75% of it, it's then you've got to go to the FCC, you've got to go to NTIA, there's often FAA issues. In another program not related to NSC, I've helped solve some of this a little bit, and it's coming up in a huge—hey, I think this idea of certification labs or private test ranges or partnering test ranges would be great. There are two or three things like this—spectrum being, I think, obviously first of mind.
Just to be clear, I wasn't saying physical ranges.
Even so, even some of those places, that's come up too is going out and testing some things. I think part of it goes back to adaptation in the acquisition process and the development process. We talk about adaptation that has been done in Ukraine and the Middle East. That is because they suffered a punch in the mouth, right? They had to adapt. Necessity is the mother of invention, all that kind of stuff, right? If they didn't adapt, they would have gotten more punches to the mouth and probably suffered a lot worse losses than they have already.
So part of this has to be: how do we adapt things like test ranges, and how do we immediately get, if not real-time, darn close to real-time insertion of new capabilities that we've adapted because we've got information? I used to work on the Aegis program, and Admiral Meyer always said, "The data is always talking to you, Nick. The data is always talking to you." So when you get that information back from the battlefield and you get that through intel channels or whatever the source is and you learn something, you immediately want to be able to react to that. And in many ways, we can as long as we're able to, right? We have to be able to figure out how to, if there are barriers, break those barriers down, whether it's physical ranges or cyber ranges, if you want to look at it that way when it comes to software development, to get through those approval gates so that we can field these things as quickly as possible. Because thank goodness we don't have to do it because we haven't gotten punched in the face, but we want to be able to do it before we get punched in the face so that we can react faster once we do.
Yeah. And whether it's the technical data that's coming off of these systems or the operator feedback, you need that way to encode and disseminate that information across this community of interest.
In some cases, all the way back to the manufacturing stage.
Because you may have to tweak something in your manufacturing process.
Yeah, there's some tolerance or some physical property that needs to change that drives the rest of the system to behave entirely differently. And the second half of your question was actually: how do operators also adapt this without necessarily coming back to a technology developer, which is important too? For us, we want to maintain a high development velocity, but we recognize there are going to be a number of instances in which we're not there. It's not our place to be there; the warfighter is making the change. So the way that we think about that from a system design perspective is that you need clean, good documentation and obvious commercial interfaces. We have APIs and ICDs for all of our technology. So if you want to interface with the hardware, if you want to interface with the software, it's easy to do. And that allows people that aren't just the technology developer—it's not gated or bottlenecked on us—operators can go make those changes. I think that's what you've also seen in Ukraine is that, yeah, you have companies developing technology at a higher rate, but you also have the actual operator making some of those changes. They're putting the Starlink on the vehicle.
I think that's a good segue also into where you see the best opportunities for commercial products and commercial technology to be injected into the system, because obviously you're probably not going to buy a howitzer at Walmart. Sounds like a great Christmas present, but maybe interfaces, maybe it's leveraging some of these network capabilities. What kind of pieces would you like to see most injected into this process? What would you be most excited to access from the commercial world?
I'm an outspoken change agent here, so I'll go first. We talk about getting commercial. We talk about how to evaluate commercial. And the thing that's most ironic to me is that we have so much in the department focused on making government-owned classified video games, right? And that's a quote actually from a COCOM commander. He's like, "I'm tired of talking to these people. I have these classified video games and they're telling me how it works." Somebody else talked about, as part of the Red Sea conflicts and trying to analyze faults that occurred in contact, the SETA organization used their classified video game to come up with one explanation. The two developers involved had their own simulations to try to assess the root cause. An independent auditor, FFRDC/UARC, came up with their own conclusion, and the COCOM's own operation cell came up with a different conclusion. Again, we can't solve the problem if we're all playing a different game, right? And we don't do that in kinetics, but for some reason, the rest of the ecosystem is different.
It's really good timing to be having this conversation because the commercial world is investing tons of money in physical AI. You've got a 1.5 trillion or whatever IPO today that's sort of wrapped up in this discussion with SpaceX, right? You've got a brand-new commercial standard unification, the Universal Scene Description, that just occurred last December. All of the modeling and sim organizations commercially are signing on to it. It's like now is the perfect time to unify the department and this community's ability to assess fit for purpose in these virtual environments and get more unified in what works and what doesn't work.
I like that a lot. I'll add, just in terms of where do you see good overlap, just for my own little part of the world, there's a lot of conversation about spectrum use and spectrum sharing or spectrum coexistence between DoD and the commercial world. But there are technologies that could be developed here that would even allow in many cases DoD to collapse some spectrum uses in a particular place or mission to be more effective and more efficient on its own, even without any other commercial—in other words, if you developed it for potential use in commercial.
Integrated sensing and communications is a perfect example. If we're able to figure that out—it's still a technology in development—you could imagine every single person, every single vehicle in a battlespace has multiple different radiating devices connected to it. If those things, instead of being single-purpose, were dual-purpose—so in the same way that integrated sensing and communications on the cell phone side is going to not only use your phone to communicate with you, but also to sense the world, you and all the phones, and figure out, not exactly like a radar, but maybe figure out what the world looks like a little bit from the cell tower looking out—you could imagine DoD adapting those technologies for its own use and ultimately making itself either more efficient on its spectrum use, less conflicted, or even just collapsing the number of vendors and the number of systems that any particular group of people has to manage, right? "Oh, you've got this sensor for this, and this sensor for this, and this sensor." In the same way that we at some point had seven different batteries strapped to a soldier and they figured out a way to sort of skinny that down a little bit so it wasn't—you could imagine doing the same thing and gathering more data with the same number of systems and becoming more efficient. That, I think, is a huge example of being able to adapt what is being developed for the commercial 5G world into the military world.
And just to pile on that, it's not that we need one radio or anything, right? In the commercial world, you have a variety of solutions.
The thing in your pocket has six radios in it already.
But you have a unified reference architecture. You have unified standards.
Yeah, we speak to MOSA, right?
But we don't always build in acquisition.
No, and it's not happening. It's still not happening right now. Agreed.
And some things are, to your point about you're not going to buy a howitzer at Walmart, some things are not going to be able to be commercialized. There are some things that maybe not off the top of your head if you think about, "Well, we could use this commercial product in a weapon system." There are ways to take a commercial-grade IMU and put it in an architecture that will allow it to perform as well as or better than an IMU that's 100 or 500 times more expensive. That IMU is not necessarily made to support an environment of 30,000 times the force of gravity shock events fired in a gunfire projectile, but there are ways to harden that IMU so that it can help your projectile go longer than any projectile ever. So we have to think about: how do we adapt the design and development process around commercial components sometimes to allow them to be used in an environment that they never would have been used for previously?
And from a requirements and specifications perspective, getting out of so specifically designing the tolerances and requirements of each individual component, and expanding out to more system-level: it needs to work this way.
And if you can find a commercial piece and harden it or adapt it, then great. You don't have to make it de novo.
And that gets to Sean's part about standards, right? If the standards are more universal and they bridge the commercial and the military, at least you know what this thing can do and you know what you need to harden it to. It's like, "Oh, well, if I buy one of these off the shelf and I add 20%, now I know I can use it," versus every single one of these things brand new has to come in and be like, "Exactly how robust is it?" I don't know because it's not.
I like Dave's point, though. It's very important to sometimes step away from the requirements and say, "I need something that does this. You figure out how to make it do that," right?
I was very disappointed to find out my master's degree in systems engineering lied to me when we started talking to Qualcomm. It's like, "What do you mean you don't have a 12,000 requirements database in DOORS? That's not how you develop product? That's wrong."
And I imagine this also plays into the operator feedback, because you probably build something, you test it out, it works to the nines, and operators say either, "It doesn't work," or, "All this work you did, I don't care and I don't need it." Having that flexibility to respond to those reactions is—
Yeah. At Saronic, we have a slightly different relationship to commercial products perhaps than a conventional defense contractor because we build products for both commercial and defense markets. So every one of our autonomous surface vessels is a commercial product at baseline. They're not available at Walmart, but you actually could buy it at Walmart. These are not military systems by
themselves. And we think about burdening the integration, payload integrations, and sensor integrations with handling all of the military-specific requirements rather than the host platform. So, of course, our vessels need to be able to perform and meet all of the broad mission needs, but those can actually sort of be collapsed to commercial requirements as well. If you want a vessel that can survive for 30 days and operate without humans on board, like our 150-foot Marauder will, that's a need that the oil and gas industry has just as much as the Navy has. And so we can take advantage of those commonalities to build commercial baseline products and then work with other system providers, technology providers to go integrate what's required that's specific to adapting to a military use case.
I think broadly what this kind of leads towards is you've got these developments of baseline standards, but you'll have lots of variation within or alongside them, and ultimately it produces a force that's very heterogeneous. It's not going to be built to any particular spec. There's going to be lots of new types of systems, new types of capabilities being introduced and retired all of the time. So, I'd like to hear all of your thoughts on what are ways that the US military can actually kind of manage and keep a hold on such a heterogeneously defined system without having to, without being tempted to go back to these kind of draconian standards in order just to simplify the process and ignore the problem.
I think some of it comes from the business environments that all of our companies—we're kind of four unique operations, right? Small, up-and-coming, large, well-established, medium-sized consortium, OTA management. Being in the middle is always interesting because companies like Lockheed Martin look at us and say, "You're small, you're nimble, you're fast, you're innovative, you can move like that." Smaller companies like Saronic look at us and say, "You're big. You've got all the processes and all those kinds of things." Being able to adapt to the different environments like the service members do sometimes requires a mindset that's adaptable. And I think all of our companies have that ability regardless of size.
But sometimes you're forced into a situation because of the circumstances in which you operate. And that's the way we have to think about it as we look to the different environments. Having a missile that can be air-launched from multiple services, but also put a booster on it and put it on a ship, or in a ground vehicle, or in a container launcher and have it be able to be launched—great idea. Have a projectile that utilizes all of the existing logistics chain, like our long-range maneuvering projectile that fits in a 155 launcher. Marine Corps, Army, doesn't matter, right? Autoloader already fits. Same propellant loads, everything. So, I think part of that is, in some ways, it's almost being a little bit of—with forethought and malice—thinking ahead so that you can play in those multiple environments.
I think we should quantify how different product development is possible right now in this world. It would be an interesting poll to see how many people have actually played beyond just using chat to verify something your doctor said or to use it as a better Google, but who's actually used Claude Code? Who has recognized the disruption that's happened there? I won't quote what our slot count per hour is that we use in standard quoting, but it's way lower than the 628,000 lines of code I was able to do with Claude Code in a week, right? And that's just one project. We're sort of democratizing the ability to quickly prototype a fully functional software element, but we're also going beyond coding agents at this point.
We're at the point where I can get a systems engineering agent. I can do full hardware development using agents because all it takes is to take that LLM-based peaky knowledge that's trained, take that model, and adapt it to new toolsets. So I think there's a lot of people that aren't recognizing the revolution in speed of development and adaptability and the real impact. If you're an engineering program manager, or if you're a contracts person, or you're somebody that's asked to budget a program and the gold standard on budgeting is actuals from prior performance—well, how do I do a program plan for an agent that can put out 628,000 lines of code in a week? How do I manage a team where I'm used to having 15 people coordinated in an agile scrum, but how do I have that one person manage a thousand virtual agents developing in a swarm? The disruption is more massive than the acquisition policy changes that are being considered right now.
I'll bring up something that is of interest to me. Sean mentioned MOSA. We had a project that recently got launched where it was in fact open-source software—Okudu is the name—open-source radio software wherein DoD actually asked for and paid for open-source software that is then going to become a part—it's now part of the Linux Foundation as an open-source project. To me, whether or not you necessarily believe and think it's going to get from here to there, there are a lot of opinions, but it is an interesting concept where you're talking about more decentralized, adaptable development.
Where now the idea is that this open-source Okudu software is going to be a requirement or a benefit. If you can write that into your next project, you'll get perhaps a second look at your proposal. And there's a case where you can have the community add features. It can be motoring along as an open-source project in the background, whereas then DoD can specify it. They know what's in there, they can pick it up, they can actually bring it in, harden it, and secure it as a part of an upcoming project. It's an interesting flip on the version of how do you become more adaptable. We will see. I think time will tell as to how well that works and whether or not it's more applicable and can be applied more broadly to the systems that are supposed to be a part of MOSA. But it was a very unique and innovative way of thinking about how to deal with the world where things are changing so rapidly.
I think a lot of these comments address the speed of development for technology. But part of the question is also: how do you go employ that technology? What's important to recognize here is that we're actually relatively early in the race with respect to how manned and unmanned systems are going to operate together, how a heterogeneous force is going to be employed. As a former government civilian, one of the things that surprised me was that the tolerance for experimentation with technology greatly exceeded the tolerance and experimentation for organizations. And in fact, people weren't necessarily willing to play with what organizational structures or definitions looked like in order to best employ the technology, which was changing quite quickly.
And so I've joked that for autonomous maritime systems, the Navy has only recently architected the transition from sort of the baking soda volcano science project to the Toyota Camry. And that's what we try to build: like the Toyota Camry of autonomous maritime systems. But we're earlier in that transition with respect to employment and with respect to organizational design that can best employ heterogeneous platforms. So my recommendation and sort of my thought here with respect to how DoD will do this is: be as willing to experiment with the organizations that are employing the technology as with the technology itself. There's not going to be an org design chart that is as flexible as Claude Code, but we can at least use that as some north star or some ambition.
And I think it speaks to the fact that there's heterogeneous technology, heterogeneous forces, heterogeneous organizational structures, and that also produces heterogeneous standards. There's not going to be one master standard that governs how quickly you're able to develop something, because it'll depend on what it goes on. I might not want to put my AI-engineered missile on a destroyer—that sounds dangerous—but I might put it on an autonomous speedboat and see how it works. So understanding that employment concept, you don't have to always manage the risk through standards and compliance; you can manage it through employment and organization as well.
I think Sam was spot on, though: the "build it and they will come" philosophy, there's an appetite for that.
There isn't an organizational structure that can support it, though. And I think, back to your point of it just needs to do this, sometimes when you do the "build it and they will come" approach, it works because you're showing them that your vehicle can do what it says or you're showing them that your missile can do what you said it can do. Then you've got to figure out how to get the organization within the department to figure out, "Verily, that's what we want to buy."
Yeah, I was going to say that that's actually the thing that we need to address head-on. It's in the public domain, so I don't think I'm calling anybody out, but there's a public discussion happening from one of the Shield AI executives where he posted a picture of all the CCA planes and then, I think it's the X-BAT, the vertical tail launch. It's like, one of these things is not like the other; why do they all look the same? Where's the innovation? And Colin Carroll, one of the guys that's come here before, he's like, "Because they all developed to a set of requirements from the government." Of course it's going to look similar, right? And so if we are in a monopsony where there's one buyer, of course we're going to develop to those rigid requirements, right? And so I think there's a real risk that we go off into a corner, create something we call innovative—who's going to buy it, right? And that's where we need a little bit more clarity on the acquisition roadmaps and what's actually in process. I think there's too many companies getting VC money right now that are putting together a good pitch deck and saying something's a gap without really clarity on what's actually in flight for acquisition and development.
We have a couple more minutes, so I'll be happy to turn it over for audience questions.
Okay. I have a question. I want to follow what you just said. How much of that—
Oh, were you speaking to Mike?
Hi. Chris Cerella with Provision Advisors. I want to follow up on the comment that you just made because I think that's important. Whether you're an organization like the NDIA or whether you're a new company or more established, you're all kind of judged by your peers' successes and failures. How much of that "fake it till you make it" charlatanism that is still very pervasive in this space—how disruptive is that to disruption efforts by those that have put in the work, that have done the push-ups, pick your metaphor, and are serious, but then you have these other folks that are out there as a distraction, either taking away bandwidth or money from those companies that actually have done the work?
So if I understand your question right, it's like: how distracting is all the VC movement, right? We've seen it go from—I think the statistic was about $20 billion of VC in the defense market to now this year it's about $75 billion, right? But in actuality, there's been a billion in acquisition that went to NTDCs and VC-backed companies. And so given the five-year timeline of VC and sovereign wealth wanting a return, somebody's getting upset right now between that curve. But at least for us, we don't look in the other lane when we're running a race, right? And the point is, at least as part of our culture, we know what the mission is. We know what the customer is.
I am personally in advanced concepts, who talks with a lot of startups and talks with a lot of technology companies that have value. I am concerned that they don't always have the perspective that we are lucky enough to get. And I know that's something—if anybody hasn't looked into it, the Mission Engineering and Integration Activity—that is core to what the department is trying to do is to make sure that they can share as much as possible to make sure people are informed and people are trying to solve the right issues. So I think if your premise is that there's some distraction or detractors on sovereign mission in some way, the only thing it's doing is pulling sovereign wealth money into the wrong directions, which doesn't impact me.
In many ways, it becomes noise in the system, and you just battle through it.
William Winker. Don't you think that especially the VC money that is in the military-industrial complex now is making companies like yours and General Atomics as well more innovative because you guys are competing now with Anduril Systems? Lockheed Martin is competing with Anduril Systems, a much smaller company, and with that, your company is being forced to rethink everything that you have been doing for the past decades. Isn't that the ultimate goal of market competition?
Yeah. So market competition is good. Again, I think it should be recognized that the US has the most competitive defense market. You go to another country in Europe, they have one defense company that's in the nation, right? UK has a few, Spain has one, right? But that's not to say that your premise is sound—competition is good. If the premise is that we're only changing because of Anduril, I take exception to that, right? We absolutely have been part of the push for the acquisition reforms that are happening. Anduril and the founders and The Kill Chain—one of the seminal books that kind of put a lot of this public—we agree with a lot of that and have been participating in it. The press around the company certainly causes pockets of our company to react to the press, as probably in the other companies as well.
It's competition. You innovate, you adapt. The old Marine Corps saying: improvise, adapt, overcome because of your environment. And bring it on.
Sorry, last question. Sydney Freedberg, Breaking Defense here.
Mr. Vendetti, you mentioned that you were very excited by Claude Code. You asked who's using it and nobody answered. So, I'd just like a quick take from each of the panel because you hear, on the one hand, "Oh my gosh, this is revolutionizing everything. It has a soul. It's my girlfriend," to "Well, actually, it's replacing all the low-level coders," to—especially for people who are not in the software business, although you kind of all are to some degree, or for applications outside software—a lot of companies saying, "We're spending a lot on tokens and a lot of time on integrating AI, but it's not really doing anything measurable. You spend as much time correcting the hallucinations and debugging the vibe code as you actually save on the other end." So, I'm just curious for the four of you what your experience is of how useful it is and where it maybe is less useful.
Yeah, I could start since I guess I kicked that off. There has been a dramatic change. I guess it started around 2022-2023 when the first ChatGPT agent model came out for chat use cases, but the AI exponential, as it's referred to, is real. There's a website, METR, that does independent assessment and they analyze it from the standpoint of for an equivalent human task that would take some amount of time, where is each model confidently getting to a 50% or 80% completion criteria? And you will see it is not a straight line like we're used to. It's not a Moore's law; it is a very heavily increasing exponential curve of agent capability.
And so this question of, "Well, it was doing hallucinations," or, "How useful is it, or do we spend more time fixing the vibe-coded nonsense?" Yes, but if you're not figuring out how to adapt your workflows and your processes to it now, you're going to miss what the next agent's going to be capable of doing. I'm only referencing Claude Code because Fable came out. To be clear, legally, we're not using Claude Code in any contracts for the government right now. We are evaluating and invest heavily in a lot of compliant agents, but nobody's figured it out. You go look at the filings from Meta or any of the other companies, they're trying to figure out how do you set up your workflows to use these increasingly capable co-pilots and developers.
So they're at the point—maybe to answer your question directly—you can absolutely develop production code today. I think the vibe coding thing has been a fun pejorative because of how many people on Reddit are like, "I go over this." But there are commercial companies—you are using code developed by an agent in your phone today. It's production quality; it's happening.
I view it as—and I've done a little bit of coding, but I don't code like Sean does—the way I would look at it is I think it lowers the barrier for an idea or a concept or a project to get out the door. There are things that a small organization, or a few people, or even a person might have done, but for that it would have taken a long time, but for I'd have to raise money, but for I would have to do this for a week. "I'm not exactly sure how to do it, so I could do half of it, but that'll get out the door." And if you do enough experiments, in my opinion, that's the heart of innovation. Take enough swings, something's going to hit, and something will get escape velocity that never would have gotten escape velocity before because someone using taste or judgment would have said, "Eh, that's not really worth it."
Well, now it's worth it because the cost of it is lower. It was kind of a silly thing to try or kind of a crazy idea, and that crazy idea reached escape velocity. And in my opinion, that's where you're going to really see it. Not that people are going to be voting missiles; it's that somebody's going to come into your office with a, "Hey, I tried this out, and you'll never believe it, but it worked." Somebody would not have greenlit $100,000 worth of experimental R&D on that, but it only cost $10,000 of tokens, and all of a sudden it's like, "Oh, actually, we may have to rethink this project." You're going to see that's going to happen more and more. In my opinion, that's how it's going to influence.
Two sessions with Fable, I burned $8,000 this week, so it definitely needs to be figured out quick.
I won't vouch at all for the economics—I think some of that's still crazy. But in terms of the value, you're going to see things reach escape velocity that never would have otherwise because it wasn't worth it, I wasn't going to try that. I think experimentation is, at least from my view, the perfect use for it for now.
Right. I also think on the back end of that, adaptation from battlefield data and things like that, that's where we will eventually see its implementation in the future.
