Talking to the Machine

I spent thirty years learning that command runs one direction: you give the order, someone below you executes it, and if it's not done right, that's on you for how you gave it. That's the grammar of authority I lived inside for three decades—clear, hierarchical, unambiguous. So it still catches me, most days, that I now spend a good part of my mornings having a conversation with something that isn't a person, describing what I want in plain English, and watching it build the thing I described.

I don't mean using software. I mean talking to it—typing out an idea in ordinary sentences, the way I'd explain something to a junior NCO, and having a working piece of code, or a document, or a functioning app come back on the other end. Not a menu of options. Not a template I fill in. An actual conversation, with revisions, where I say "no, that's not quite right, make it feel more like this," and it adjusts.

That is the part that still feels, some mornings, like I've wandered into somebody else's future.

The Old Grammar of Building Things

For most of my life, if you wanted to build something—a system, a piece of software, a process—you needed a specialist. You needed someone who spoke the language of the machine, who'd spent years learning syntax the rest of us never touched. There was a wall between having an idea and making it real, and the wall was made of expertise you either had or didn't. I commanded soldiers, wrote doctrine, ran training programs across an entire division, and none of that gave me the first clue how to build software. That wasn't my trade. I had people for that, or I didn't have the thing at all.

What's changed—quietly, without much fanfare, in the space of what feels like a couple of years—is that the wall has a door in it now, and the door opens if you just describe, clearly and specifically, what you're trying to accomplish. I've built working prototypes of applications by describing them the way I'd brief an operations order: here's the objective, here's the constraint, here's what right looks like. And the machine executes. Not perfectly, not without back-and-forth, but close enough, fast enough, that the entire old relationship between having an idea and building the thing has been rewired.

That's not a small shift. That's a different category of tool than anything that came before it.

What Makes This Different From Other Tools

People say this about a lot of technology—"it feels like science fiction"—and mostly it's overstated. A smartphone is remarkable, but it's still fundamentally a tool you operate: you press things, it responds in predictable ways, and the intelligence is yours, applied through an interface. What's different about talking to an AI system is that the intelligence is now distributed. You're not the only mind in the loop anymore. The tool has a kind of judgment of its own—limited, occasionally wrong, entirely dependent on how well you've explained yourself, but judgment nonetheless. It can catch an ambiguity in what you asked for and ask you to clarify. It can suggest an approach you hadn't considered. It can, on a good day, understand your intent better than you'd stated it.

I've spent a career around command relationships, and I know what it means to work with someone who can think alongside you rather than just execute instructions. What's strange—science-fiction strange—is encountering that quality in something that isn't a person at all. There's no fatigue in it, no morale to manage, no career incentives shaping its judgment. It's a new kind of collaborator, and we don't yet have good instincts for how to work with one.

The Quiet Change: Who Gets to Build

Here's what I think is actually shifting, underneath the novelty of the experience itself: the population of people who can bring an idea into existence has just expanded enormously, and most of us haven't caught up to what that means yet.

For generations, the gap between "I have an idea" and "the idea exists in working form" was bridged by specialized labor. That gap filtered who got to build things. It filtered by education, by access, by which fields you'd trained in. A career soldier with three decades of experience in leadership, training design, and operational planning had exactly zero standing to build a piece of software, no matter how good the idea was, because the gap required a different vocabulary entirely—one I'd never had reason to learn.

That gap is narrowing, fast, for a specific and important reason: the bridge across it is now natural language. If you can describe what you want with the same clarity you'd use to brief a mission, you can build a surprising amount of what you're picturing. That means the filter on who gets to create things is shifting from "who learned to code" to "who can think clearly and communicate precisely about what they want built." That is a completely different filter, and it favors a completely different set of people than the last forty years of software development did.

I don't think that's a small cultural change. I think it's the kind of change that, twenty years from now, gets talked about the way we now talk about desktop publishing or the internet itself—not as a single dramatic event, but as a quiet redrawing of who has access to a kind of power that used to be gated behind years of specialized training.

What It's Costing Us, Quietly

I don't want to write this as pure enthusiasm, because every capability like this comes with a cost, and the costs are usually the ones nobody notices until they've already reshaped something important.

The first cost is patience. When you can describe an idea and see a rough version of it appear in minutes, you lose some of your tolerance for the slow, deliberate craft that used to be the only way anything got built. There's a discipline that comes from struggling through a problem by hand, from being forced to understand every layer of something because you had no choice but to build it yourself, one piece at a time. Some of that discipline is just friction, and good riddance to it. But some of it was teaching you something you didn't know you needed—the kind of deep, structural understanding that only comes from having built the hard way at least once. I worry, watching people (myself included) skip straight to the fast version, that we're trading depth of understanding for speed of output, and that trade doesn't always show its cost immediately.

The second cost is a subtler one, and it's the one that actually concerns me most, given the work I do now. When you can generate something that looks finished so quickly, it's tempting to mistake fluency for correctness. A document that reads well isn't necessarily a document that's right. Code that runs isn't necessarily code that's sound. I've had to develop a new discipline—verify against the source, check the actual behavior, don't trust the confident summary—because the tool's fluency is not the same thing as its accuracy, and the gap between those two things is exactly where mistakes hide. That's not a reason to distrust the tool. It's a reason to bring the same rigor to this collaboration that you'd bring to any other one where someone's confidence outpaces their certainty.

Command, Rewritten

What I keep coming back to, thinking about all this, is that the oldest lesson of command was never really about giving orders. It was about communicating intent clearly enough that someone else—someone who wasn't you, who couldn't read your mind, who had to act on their own judgment in the gap between your instruction and the situation on the ground—could still do the right thing. Good commanders weren't the ones who controlled every detail. They were the ones who communicated purpose so clearly that the people under them could improvise correctly when the plan inevitably broke down.

I didn't expect that lesson to be the one that transferred most directly into this new world of working alongside an AI system. But it has. The people getting the most out of these tools right now aren't the ones with the most technical background. They're the ones who can state intent with precision—who know the difference between what they actually want and what they've only vaguely gestured toward, and who can close that gap in language instead of code.

That's the quiet part of this that I think we'll look back on as the real change. Not that machines got smarter. That the skill of clear communication—the thing good leaders have always needed and most technical fields never demanded—just became one of the most valuable and least appreciated tools in the box. I spent thirty years training people to state their intent so clearly that it survived contact with chaos. I didn't know I was also training for this.