Cory Ondrejka

I'm the CTO of Onebrief.

So Onebrief — we build command-planning software for the US military. If you think about starting at the national objective and what happens around strategy and plan creation: if you're in the military, you talk about COAs — courses of action — and how you build that. Historically that was SharePoint, a bunch of cutting and pasting of information and documents. What Onebrief did is ask: how can you make that a process that doesn't have drift and cut-and-paste errors, so that when a particular commander says "I want it as a presentation" or "as a document," the data is correct and up to date at every level?

It's primarily at division, combatant-command, and theater level. If you think about the decision-making process, you go down and down and down until you get all the way to tactical and kinetic — that's where all the drones are, where a thousand companies are. That isn't where we are, because the problems up here are much higher-leverage, but they're much harder. When you think about what you could bring AI to help with, AI from the 2014 era could help down there — that was image recognition, the kind of AI that started appearing in the deep-learning era.

You actually want to help a team of humans make a better decision, and that's something AI from that era really couldn't help with. We're only seeing now, with the emergence of large language models, the capacity to really partner with a team of experts who are already the best in the world at solving these very complex problems. It's applying AI at that level.

Yeah, with even a little more complexity than that, because sometimes it's helping an individual planner see the most important information, or prioritize the information they're putting into a document or presentation. It might be helping them lay it out on a map, because visually the map is the better way to convey it. Or it's taking all of that information and putting it into a war game — because if you really want to understand something, turn it into an exercise.

Traditionally, going from a course of action into an exercise was a multi-week process, and then months to prepare for literal tabletop war-gaming, because that's historically the best way to test something. So if you're really lucky, in six months you could test one course of action. What if instead you could go nearly instantaneously from "here's a course of action" to putting it into a multiplayer, multi-agent simulation — and then play that game, explore it, war-game it, and feed that feedback into your plan, iteratively, before you bring it to someone?

Or maybe it's, let's go explore multiple variations, because we want to understand: what's the failure mode of this course of action? What's the floor — it can fail in different ways, so what are the worst failure modes? What's the ceiling? Depending on the objective, the floor or the ceiling might be the more important constraint. So it gives planners an opportunity to iterate, to explore, and to collaborate with subordinate commands — because by starting at that grotty document-integration step, you start with how to make this multiplayer around the world to begin with. If you need to talk to another command or another unit, you can bring in their planners and get their input too.

Yes — we're operating in multiple combatant commands, with different services. Onebrief's been going for about six years, and really the last year has been this move into what you can do with frontier models on top of the existing product.

Everywhere you can. And it starts — again, this is something uniquely possible with large language models — with the fact that the military is very doctrine-driven. The military has thousands of pages of doctrine for every conceivable activity, both in terms of what its plans are and how it plans, and also authorities. It turns out the military has been thinking about the authority to execute on a decision longer than most organizations. In some ways it's the best possible environment to start thinking about AI, because you already had to make decisions about who can authorize an operation. All of that factors into every layer of the planning process, because you can actually put it into context for an AI.

This isn't using LLMs the way we'd have discussed two years ago — even 18 months ago — when we'd all be talking about RAG and hallucination. Today we have such large context windows that you make sure you're putting the right information in the context window, and then you're largely using the LLM for tool-following and decision-making within that very constrained and prescribed set of inputs.

Oh, absolutely. Part of what drew me to this challenge is that if you look at the command-planning challenge — its scale, the fact that it's multiplayer from the beginning, the complexity — it actually looks a lot like software development. It's a very similar shape of problem: you have multiple users collaborating, and an ability to apply agentic approaches in many different ways. The difference, of course, is that in software development you have observability, test suites, conformance suites — lots of ways to move agents out of simply guessing and into the iterative loops that we've seen have such unreasonable capability. If you can put an agent into a situation where it's created something, you can measure the output, prove whether it was what you said you wanted, feed that back in, and continue — and you can decide what level of risk you're tolerating: can the agent just commit and check in, or does a human need to sign off?

Software development, the last six to eight months, has been a real step change in what's possible. If you change to something like command planning, it's tempting to try to solve that problem in an open-loop way — "I have these incredibly capable AIs, we'll just ask them for input and somehow magically this gets us to better results." That's actually not the way to do it. The question becomes: how do you create a closed loop in a planning situation? That's where war-gaming and simulation become your test framework. If you can go from a course of action into something you can test or simulate or play, you can very rapidly loop that back in — and now you've created that same iteration-improvement loop at a command-planning level.

And across government — think about disaster recovery: a very similar set of constraints, challenges, and resource contention. There are many use cases where, if you can combine strict inputs, multiple inputs, real-time inputs, doctrine — or whatever your process thinks of as doctrine — the constraints, the human expertise, and then create a loop around all of that, you can iterate faster than real time.

Well, I think the stakes are different — absolutely. This gets back to where the human is in the loop, where the human is on the loop, where you can go fully autonomous. It's pretty different if you're debating which shade of blue to make a button versus something with larger-scale financial or human impact — that changes where you'd consider allowing autonomy versus a human in the loop. But from the standpoint of: can you define the problem, define success, define that you actually achieved the outcome you said you were trying to? In software development a lot of this moves into observability — even more than QA or acceptance or end-to-end testing, it's: can this actually be the system operating, delivered to 1% or 2%? In the real world you might not have that testing available, so instead you move into synthesis, simulation, modeling, and other tooling — where can you credibly generate a signal you can feed back into the process? Can you iterate quickly on the synthetic version, because there's no real cost and no real impact, and still explore the design space rapidly and present the synthesis of that much broader set of explorations to the planners and decision-makers?

I think these are the hardest questions, and definitionally, unintended consequences are unintended. There's an advantage for all of us in being students of history — really looking at what happened as we adopted different technologies, and where the incentives were.

One of the opportunities is to focus on — for example, in the planning process — if we're able to iterate more quickly, synthesize across multiple explorations, and present that to human planners who carry it to actual decision-makers, that's a place where we're providing more information to somebody whose job it is to explore the question and come in with the best possible inputs and recommendations. Can we deliver better information to them? And can we do it while being really aware that, in large language models, we have a technology that was built to be helpful, kind of friendly, and kind of credible — and the challenge with that combination is that none of those is equal to accuracy. There's a temptation, when you're building with LLMs, to just uncritically take a result and put it in front of a decision-maker.

The risk is that you have technology that was literally built to be credible, not technology built from the beginning to be accurate. If you recognize that, you actually bias away from the credibility and focus on the non-LLM tools and techniques for measuring accuracy — so you don't just fall into an LLM telling you something that seems really believable when the stakes are so high.

Well, I can't speak to how Google's going to navigate this. I think Google has been in an arms race on that particular topic for a lot longer than LLMs.

Which points to an advantage Google probably has here. And there's something illustrative there: recognizing that if your technological underpinnings generate a bunch of biases, what else can you add into the mix — and just not pretending they're not there. Going back to the planning example, thinking about what it means to explore verification and validation around LLMs — that's a really unsolved problem right now, and very challenging. But there are domains where that is the most important thing you're doing.

In my space, the DOD — on the secure networks the military uses — one of the decisions the government has made is to start more rapidly bringing frontier models onto those networks. Overall I think that's a good thing: the US models are advancing very quickly, and on any given week a different one of them is better for software development, for reasoning, for tool use. So it's good to have them available. But it also means that, very rapidly, I have to answer the question: do I want to use a different model this week to best serve my customer's needs? That's an incredibly complex verification-and-validation question, and you can't just rely on the models themselves — you can't rely, frankly, on any one model. One of the fascinating quirks about models is that they tend to agree with themselves, so if you want to set up effective counterweights, you actually have to use multiple models. All of that stems from a starting position that these are incredibly powerful reasoning and tool-use tools — but they're not necessarily correct.

You obviously can't cover everything — the surface area of a model is not infinite — but what you can do is: here is an exercise. Run it, evaluate it, report on it. How many tokens were used? Did it complete successfully? How many loops were there? Because one of the things that happens when you watch models is they have lots of errors in their loops, and part of what they manage to do is self-correct.

How aggressive were the self-corrections? How far-wandering were the errors in the loops? None of this gets you to 100% coverage or certainty — and that's an important reality. But like most forms of testing and validation, if you can articulate "here is what we believe we're setting out to do with this step," then: here's our past performance of multiple models and many runs; here are multiple runs of the new models; what are the differences, and can we explain them? That's the starting point — the version available to us today.

What we're fortunate about is that all the model providers are also moving forward on how to expose more information about the internal state of the model. Something that seems likely to be true is that wild changes in the internal state likely indicate some drift from your prior expectations. Right now most models don't expose that publicly; I suspect that's coming — that if you want to use a model in a more verifiable state, rather than just returning the answer or the thinking tokens, they'd also return some information about the internal state, which would give you insight into whether the model is solving the problem radically differently than you'd expect.

Well, but observability — we have versions of this already. If you're running a really large distributed system, as so many of us end up doing, and some subset of users is having a bad day, the miracle of observability was that you could start interrogating it: what's different about these users? What's different about the systems they're hitting, the subsystems, the network links? What you end up finding is something that, if you tried to boil it down to a single number or metric, you'd have no insight into — but it very much is the health of a massively complex system.

I'd suggest steering clear of saying it's a mental-health question. I don't think anthropomorphizing LLMs is that helpful, and it can sometimes be actively misleading. These are very large, very complex systems — unimaginably large and complex to us — but they still are large complex systems, and they have internal state, and that internal state is what predicts how they answer your question and execute your task. If it were a decade ago and we were talking about what LLMs give us today, we'd say we've achieved science fiction. But we can also look at the mathematical advances that took us here, and we have a set of tools. The great thing is all the model companies have been applying these tools themselves and publishing on it. What they haven't done yet is figure out how to publish that information and make it available to somebody using the tools, so they can get more insight into how the tools are operating.

It's just going to be demand pressure.

That's such a good question. The great thing is all the models are moving into highly regulated spaces — HIPAA-regulated, defense, all of these spaces — where you have customers who, independent of their technological savvy, have great regulatory savvy. They are very up on what they believe they need to know in order to be paying these providers of large language models to bring that technology into these new spaces.

Having spent a bunch of time on the Hill recently, I'd say our representatives are highly engaged on this topic, and their staffs are highly engaged — to a degree that, having been there for other technological-transformation periods, is incredibly exciting. To see that level of engagement, and a desire to get educated, to learn, to explore — because there's a recognition of how important this moment is — it gives you a lot of comfort that these are the most serious folks they can bring to bear on these questions. Obviously none of us are as expert on LLMs as the researchers building them. But if you approach it seriously, if you ask the right questions — back to your earlier point about incentives, what we've learned from prior transformations, what stresses these are already putting on the economy and on people — at least be asking really good questions. That's what you want to see.

That's upstream in many ways — getting it to the point where the regulation can actually be regulated. It seems like the industry is moving in that direction because it has to: medical, defense tech, all of that. So it's good the government is stepping in that way, and that should hopefully give people some theoretical peace of mind, depending on how they feel.

First of all, we're hiring — and we're right in that size you were talking about. Look, I'm just figuring this out: I've been paid to write code for nearly 40 years at this point. My life's work has been building products — coding, being a software engineer.

And the reality is, what my profession is, what my vocation is, is changing irrevocably. What it's going to be — not 10 years from now, but six months from now — is fundamentally different. I think this became clear to most people in software engineering really by the holidays, after that November of '25: agentic software development got good. It was such a dramatic change from earlier moments of the preceding year, where you could see the hints — but suddenly, nope, this is working now. What does this mean?

As someone who hires software engineers, who has an amazing team of them, my biggest concern was: how do we navigate this if we're afraid? Because nobody makes good decisions when they're scared. And this threatens your identity — because if my identity is "I'm a software engineer," agentic coding feels like a threat to that.

So how do we navigate it? For me, I looked at it as a thought experiment: how could you reframe what my profession does, and is there a way through this that is changed by AI and agentic but isn't destroyed by it? Part of why I've been a product engineer most of my life is that I love solving interesting problems — that's part of what makes coding so much fun. But what's even more fun is solving interesting problems you then get to deliver to somebody and see how they react — which is how I got into building video games. From the first time I touched a computer, I was writing games. Through that lens, software engineering is not about typing, and it's barely even about the code — it's about the outcomes. That turned into a thought experiment: could I articulate what outcome engineering is? The more I pushed on it, the more it felt like a way to reframe my profession. So, as one does, I wrote a manifesto — and I used it, frankly, to redefine how we hire. Because if I'm hiring people to do software engineering in an agentic future, there's a mix of people I might hire for those roles. It's obviously still software engineers, still AI researchers. But maybe it's that PM or designer who on the side is shipping their hustle on a Claude Code, vibe-coded thing — but they did it with observability, it's in production, and people depend on it. Well, that's interesting — let's talk to them. To me, that's the future to explore.

What does it become if you give us additional superpowers — the ability to collaborate with what software-development agents and design agents can do, and, as they improve, agents that help other aspects of product development, shipping, delivery, and learning? Because it's really easy to think of AI as just these slop-generating machines: you say "give me a piece of slop," it creates something, and it's often kind of interesting.

But it's not better than what you could create if you really go deep with the AI — or go deep with the AI in partnership with somebody else. That's the level that starts getting interesting, when AI lets us actually do more with computer technology, with design, with product development, with everything about how we learn and communicate.

First of all, there will always be people who write code — just like there are still people who paint after the camera came along. If hand-written, artisanal code is your thing — farm-to-market code — great; there will hopefully be plenty of opportunities to do that.

For a lot of product development, though — and system development, software development — the question becomes: what is the objective, the goal, the outcome you're attempting to achieve? And what are you able to do if you also add in superpowers and collaboration? Along the way, let's be clear, people are still responsible for the code. Which means you'd better — whether it's you staring at the code, or you plus an AI — be documenting it, explaining what it's doing, adding observability and testing and performance suites. You are still responsible for knowing what that code does, because if you ship a bug — if you ship a defect that the agents out there trying to hack you exploit — that's still your fault. That part has not changed. There is still a profession here; it's just a profession that's changing because of the addition of technology. Understanding responsibility, risk, and outcomes continues to be your responsibility.

Well, I think you teach by doing. For the first time in human history you have a technology that can partner with us — a better shovel. It's a shovel that itself can be more than a shovel, and help us understand how a shovel works. We've never had technology like that before. The closest, in a lot of ways, was code — was HTML. Remember, "view source" was the magical part of the web: how did somebody make this website? Let me go to view source and poke around.

It was a fundamental decision all the way back in the Second Life days — when we were building Second Life, we wanted people to be able to create these 3D worlds, and we wanted them to be introspective, for the same reason: if you didn't understand how something got created, we wanted there to be a path to learn and discover it. What large language models and agents give you is that ability to be introspective on anything.

Going back to this whole junior/senior question — I find it baffling when somebody assumes "we don't need junior people." Because the path to a junior person being unbelievably impactful feels much shorter in an agentic era than before. If I'm bringing somebody in who is curious, hungry, interested, has a different set of life experiences because they're younger — and I can connect them into teams more quickly, get them integrated and learning, get them actually feeling, accurately, that they're a productive part of a team — that feels like winning all the way up and down. It would feel kind of dumb not to do that.

Other companies and people will make their own decisions on this. But from my perspective, we have a set of technology that makes it more exciting to hire up and down the levels of experience, and to give more ways for collaboration across and between teams. I come from a lifetime of building multiplayer games and services and systems, so I'm very biased in that direction. When I hear people say "what's great about AI is it lets the solo developer go do more solo things," to me that feels like a dystopian hellscape. I want more collaboration with amazing people, and more opportunities to ship and create and build things together. Why would we deprive ourselves of that joy? If LLMs give us more ways to do that, that's an incredible win. That's the moment we're in — and it's part of why it's important to define the future for this profession in a way that leverages LLMs instead of fighting them, and to be realistic that this is an amazing time to hire people, build new teams, and have them make more impact than ever before.

So I'm excited. I mean, I'm shattered for many friends in the game industry — and, much like friends in tech, there are certainly many businesses struggling right now. Whether they're struggling in spite of AI, I think there's a vibrant debate to be had there.

More importantly: right now there is no technology more generally hated in popular opinion than AI. To me, that's a very concerning trend. And let's be clear — if AI is used as an excuse to lay you off, if it's used as an excuse for your power costs to go up, if it's being used to make your life worse, of course you're going to hate AI.

And it's an incredible missed opportunity. Because if AI is actually delivering what those of us closest to it — actually using it, creating with it, giving teams full-power access to it — if it's working as well as we're seeing, that's why you keep hiring, that's why you say, "no, no, this is the moment." And it's incumbent upon the large model developers, who are sitting on massive war chests.

I think they really need to think carefully about — we know they want more compute. Okay, but you'd better be able to deploy more compute without driving up people's power bills. That's certainly within their capability; you just have to decide it's worth doing.

It's not a marketing problem. I mean, you've got Kevin O'Leary going into Utah and saying, "nobody from Utah is actually protesting my data center."

It's not a marketing problem, because we know from revealed preferences that people are using AI more than ever before. So people are using it and they're excited by it — but they're angry about it. Public polling gives you some insight. One: we have AI leaders loudly saying, "this is going to take your jobs."

They may very well believe that, but that's maybe not a good strategy if you don't want people super angry. While there's no doubt that technological transitions change jobs, the notion that this just eliminates jobs seems naive and short-sighted. Smarter folks than I have talked about radiology — the obvious example, where everybody argued radiologists would go away. It turns out, nope: reading the film is a tiny part of the job, and AI can actually make that part better, which means more people want to be radiologists. We're at the very beginning of that kind of transition in many fields. We can only continue to explore it if we keep advancing AI — which means producing chips, powering them, and doing it in a way that isn't hurtful to the communities where data centers go in. This is the United States; we have the capacity to build and deliver electricity. Deciding that that's a national imperative at this moment seems like a real opportunity — for the model developers and for government.

Anybody who claims to know five years out right now — let's be clear, I don't think we've ever had a moment of more uncertainty about what five years out looks like.

My hope is that all of us have more access to learn what we want to learn, and to create — in ways that could be very multi-layered: create a business, a product, something for your block, something just for your family. The ease of "wait, we need a particular app and none of them really work" — the speed with which you can solve that today is really remarkable. And these are the dumbest models we'll ever get to work with again; these are the models with the least design skills we'll ever work with again.

More of us being able to do what used to be the domain of a few software developers, a few product developers — instead saying, "nope, I want this capability, and I know how to think about it and explore it." More of us being able to do that, in a way that helps us have more fun, more learning, make more money, be healthier — that's the possibility. You can see the path to that, and that's where I hope we are five years from now.