I Attended the AFCEA San Diego Mission Systems Symposium. I Learned What Vibe Coding Was.

I Attended the AFCEA San Diego Mission Systems Symposium. I Learned What Vibe Coding Was.

TL;DR — At the AFCEA San Diego Mission Systems Symposium, Gene Kim described how
sailors had built eleven mission-critical applications themselves, and were using
them — work that once took “millions of dollars and two years” and now takes “tens of
dollars in tokens and a couple of hours.” He was describing, almost line for line,
what I’d been doing in my homelab all year, and he finally gave me the word for it:
vibe coding. So after the session I showed a colleague what that looks like, by
building one. Twenty-three minutes later there was a live website with its own
address, a real certificate, a public hostname, documentation and a change ledger.
The AI wrote the code. The harness delivered it. Without both, that’s a month of
evenings.

The number I wrote down

I spent 15 September at the AFCEA San Diego Mission Systems Symposium, among people who
buy, build, and run mission systems — program offices, portfolio acquisition
executives, the C4ISR community. The guest speaker was Gene Kim, who wrote The Phoenix
Project and The Visible Ops Handbook and has spent twenty years arguing that the way
an organization delivers software is a strategic capability, not a back-office detail.

He had a number. Sailors — not contractors, not a program of record — had built and
were using eleven mission-critical applications. The line I wrote down was that
what once took millions of dollars and two years now takes tens of dollars in tokens
and a couple of hours. He talked about modernizing a workflow he called “NATICK 98” —
a paper-and-mail process from 1998 — and having a high-fidelity digital replacement
prototyped within hours.

If you sit on the acquisition side of the table, sit with that for a second. The
interesting part isn’t that it’s cheaper. It’s that the unit of work changed. A
thing that had to be a program with a budget line can now be an afternoon.

The word I didn’t have

There’s a slide in Gene’s deck titled “What I’ll Talk About,” and the first bullet is
how vibe coding will reshape technology organizations (as DevSecOps did). I had to
look up the term. It was coined by Andrej Karpathy in early 2025, and it means building
by describing what you want in ordinary language and letting the machine produce it.

That was the moment the talk stopped being interesting and started being personal,
because he was describing what I already do. I wrote a post a few weeks ago about
spending months solving homelab annoyances one at a time and accidentally rebuilding
most of platform engineering — GitOps, an IPAM, a CMDB, runbooks — without ever
learning the words for any of it. This was the same experience twice: a man on a stage
in San Diego handing me the vocabulary for something I’d been doing all year and just
calling “asking the AI to do the thing.”

So I showed someone

After the session I got talking with a colleague about what Gene had laid out, and
realized the easiest way to explain it was not to explain it. It’s how I already work.
So I showed them — live, from the conference.

Here is the actual command I typed, in full, typo and all:

Follow kb_guide("start_container_project"). I want to deploy: {show wind direction hourlu over the last 24 hours}.

It has two halves, and the seam between them is the entire argument of this post.

The braces are the specification. Show wind direction hourlu over the last 24
hours — what I wanted, in plain English, misspelled, thought about for roughly four
seconds. No architecture, no ticket, no design document, no meeting. A weather station
in my back garden already reported the readings; I wanted a page that made sense of
them. That half is the vibe coding.

The first half is the harness. kb_guide("start_container_project") tells the AI to
go and fetch my own written standard for deploying a container here — before it writes
anything. Which server to ask me about. Which registry to take an address from. What a
finished service looks like on this network. It is a pointer to a document I wrote
months earlier, for exactly this moment.

One is a wish. The other is the institution that turns a wish into a running thing.

Gene’s talk finished at 2pm Eastern. According to the session transcript, that command
went out at 14:04:25.

What came back, twenty-three minutes later

This is the part I’d put in front of a program office, and it isn’t the code.

• An IP address — allocated out of the network’s actual system of record and
  reserved against it, with an owner and a description. Not guessed, not “probably
  free.”
• A running service — built from source into a container image and deployed to a
  named server, through the same pipeline everything else here goes through.
• A public hostname — wind.cossaboon.net, with a real Let’s Encrypt certificate
  issued and installed, and automatic renewal.
• Four pages of documentation, including a verbatim copy of its own configuration —
  deliberately duplicated, because the day you need that file is a day the code
  repository may be the thing that’s down.
• Seven entries in an append-only change ledger: what changed, why, what it might
  break, and how to reverse each one.

Now read that list again as an organization would.

The address is a ticket to the network team. The certificate is a request to whoever
owns certificates, and a renewal reminder nobody sets. The hostname is a DNS change
request with an approval on it. The documentation is the thing everyone agrees is
important and no one writes. The change record is the thing you reconstruct from memory
during the post-incident review.

Five queues. Each one a handoff, each handoff a wait, and the waits — not the
typing — are the schedule. Gene put it better than I will: when you can do something
within your group or by yourself, there’s no one you have to coordinate with.

The AI wrote the working code in the first few minutes. That part is what “vibe coding”
names. Everything after it — the address, the certificate, the hostname, the
documentation, the audit trail — is where software normally goes to die, and that part
isn’t vibe coding at all. That part is the harness.

And it isn’t a toy

Worth saying, because “AI built it in twenty-three minutes” invites the assumption that
what came out is a demo.

Wind direction is a genuinely awkward thing to summarize. Compass bearings wrap around,
so you can’t average them as numbers: if the wind blew from 350° for half an hour and
10° for the other half, it blew from the north the whole time — but add those and
divide by two and you get 180°, due south. Exactly backwards, and completely
plausible-looking on a chart.

So the page adds them as vectors, the way you’re supposed to. It also weights each
reading by the wind speed at that moment, because a vane barely moving in dead air
isn’t really measuring anything and shouldn’t get an equal vote. And when the wind
drops below the threshold where the instrument still tracks, the page declines to
report a confidence figure at all — it says nothing rather than something
unsupportable.

That screenshot was taken on a nearly windless day. “Steady hours: 0 of 24” is the page
being honest about a quiet night instead of dressing up a parked instrument as a
confident reading. For anything that feeds a decision, knowing when not to assert is
worth more than the assertion.

Not bad for a misspelled sentence in a pair of braces.

The part nobody puts on a slide

Here is the honest asterisk, and it’s the reason I’d argue with anyone who takes
“twenty-three minutes” as a procurement target.

Those twenty-three minutes were fast because the road was already paved. Before that
afternoon there was already an AI harness built in my homelab: a wiki the AI reads
at the start of every session, so it knows the servers, the subnets and the
conventions; a written standard it fetches for this exact task — the thing that first
half of the command points at — which is why it asked me which server before it
assigned anything and stopped for an answer; an address registry that is genuinely
authoritative; a deployment pipeline where the only way to change a service is to
change the repository; certificate automation; a documentation pipeline with a human
gate on it; and a ledger that makes every change reversible.

None of that was built that afternoon. It was built over months, one annoyance at a
time, and essentially none of it was glamorous.

To achieve the twenty-three minutes, you need to build the harness, the skills and
the tools. Then it’s twenty-three minutes every time, forever, for everything. That’s
the investment case, and it’s a much less exciting slide than the productivity number.

The limit Gene named in the same breath

He predicted a hundredfold expansion in the number of people building their own tools.
In the very next breath he said that systems touching personal data, real architecture
and compliance obligations still need professional developers, information security and
genuine gatekeeping.

Both of those are true at once, and the skill that matters now is telling which one
you’re holding.

Mine is a weather page. Nobody dies if it’s wrong; the worst case is I dress
inappropriately for the garden. The distance between that and a mission system isn’t
measured in lines of code — it’s measured in consequences, and the apparatus you need
scales with the consequences, not with the size of the program.

What I’d actually tell a program office

1. The speed is real, and it isn’t typing speed. It’s the collapse of coordination
   cost. If your process assumes five queues between an idea and a working service, the
   process is now the long pole — not the engineering.
2. You can’t procure the outcome without building the harness. A system of record,
   a deployment pipeline, automated certificates, documentation that writes itself —
   that’s what converts a fast model into a live service. Fund that, and the afternoons
   take care of themselves.
3. Expanded builders and professional rigor are not in competition. Let people
   build their own tools. Keep the gatekeeping where consequences live. Deciding which
   is which is now a core acquisition skill.

The thing I keep coming back to isn’t the productivity number. It’s that the hard part
had already been done, as I built the harness — the process — over the last few months,
by a series of decisions that each felt like housekeeping at the time.

The afternoon in San Diego just showed me what it had been for.

---

A footnote on how you’re reading this

Same disclosure as last time, because it would be absurd not to: this post was drafted
by an AI working from my knowledge base, using tools and skills developed by me for the
homelab, and my notes — then edited by me. The weather page it describes was built by
that same AI in twenty-three minutes while I was in San Diego, and it published this
post to WordPress through a control plane we built for exactly that purpose.

Quotes from Gene Kim’s talk are from my notes on the session, not a verbatim
transcript, and any roughness in them is mine rather than his. The timings and the
command are exact — they come from the session’s own transcript.

The full technical write-up lives on my knowledge base.