We built the voice. We forgot the ship.
'Computer, summarize this incident.'
'Computer, draft the PRD.'
'Computer, open a pull request.'
Star Trek trained an entire generation to expect that _talking to a computer_ is how real work gets done. Not typing. Not menus. Not wrestling some UI into submission. Just intent to output.
LLMs are the first thing we've shipped that genuinely feels like that interface.
And if you're honest, it's intoxicating: ask for an outline, get an outline. Ask for code, get code. Ask for designs, get "designs." Ask for an image, get an image. According to GitHub's research, developers accept roughly 30% of Copilot suggestions—and 91% of developers report their teams have merged pull requests containing AI-suggested code. GitHub Research
But the part Trek quietly nailed isn't the intelligence. It's the substrate: the Enterprise computer works because it sits on top of a world that is _structured_, _instrumented_, and _operationally bounded_.
We shipped the voice box first. The ship is still mostly plywood.
The Enterprise computer wasn't magic. It was integration.
The Enterprise computer looks godlike because it has three things your LLM usually doesn't:
1. Ground truth
- Sensors.
- Logs.
- Schematics.
- Procedures.
- A shared vocabulary the crew actually uses.
2. Real tools
- It can simulate, calculate, route power, scan, search, schedule.
- It doesn't just _talk_ about actions. It can take them.
3. Norms
- The crew doesn't treat "Computer" like a prophet.
- They treat it like infrastructure: useful, fallible, interrogable.
LLMs mostly show up in the opposite configuration:
- weak grounding,
- ambiguous tool access,
- and a culture that wants answers, not evidence.
That mismatch is why "talking to the computer" feels like the future... right up until the moment it feels like a prank. Stanford research found that legal hallucination rates range from 69% to 88% when LLMs answer specific legal questions—confident-sounding answers built on nothing. Stanford HAI
Prompt as reconstruction: dragging intent into focus
There's a scene in _TNG: "Schisms"_ where several crew members realize they share fragments of the same experience — cold surfaces, a table, a light, a sound. They go to the holodeck and reconstruct the room together. Not in one shot. Iteratively. "Make it metal." "Angle it." "Add an arm here." "No—clicking, not whispering." The thing gets steadily more specific until everyone recognizes it. Memory Alpha
I think about that scene constantly when using creative tools—and especially with chatty image models like Google's Gemini image generation.
Because that's what you're doing in practice:
- You don't "describe the final thing."
- You converge on it.
The model is a holodeck: it will happily render a thousand plausible worlds. Your job is to drag it toward the one that matches your intent.
That loop — propose, critique, constrain, regenerate — is the real interface. And it's why "prompting" is a misleading word. You're not prompting. You're _specifying_.
Prompting is requirements engineering in disguise
If you've ever written a decent bug report, you already know how to "prompt."
Most people fail with LLMs for the same reason they fail with humans: they hand-wave the goal and hope competence fills the gap.
Here's a format that works across coding agents, writing, and creative tools:
- Goal: what outcome should exist when we're done?
- Context: what should the model assume is true (domain, constraints, environment)?
- Non-goals: what should it explicitly _not_ do?
- Examples: at least one "good" and one "bad" example if you can.
- Acceptance checks: how do we verify it worked (tests, queries, screenshots, diff review)?
- Risk areas: where it's most likely to be wrong.
If your prompt doesn't include acceptance checks, you didn't write a prompt. You wrote a wish.
When the assistant becomes a teammate
In _TNG: "Booby Trap"_, Geordi is stuck on a technical problem and uses the holodeck to model and reason about it. At one point, he asks the computer to load Dr. Leah Brahms' personality profile and apply it to a holographic facsimile so he can talk through the problem with "her." Memory Alpha
Put the weirdness aside for a second and focus on what the episode gets right:
- The computer isn't a "search engine."
- It's not even an "answer machine."
- It's a collaborator in a loop.
That's the highest-leverage way to use LLMs at work too.
Not:
But:
- "Propose 3 approaches, list tradeoffs, pick one, and generate a PR-shaped diff plus tests."
Not:
- "Summarize this incident."
But:
- "Summarize _with a timeline_, highlight unknowns, and propose the next 3 data pulls to confirm causality."
A teammate is valuable because they:
- maintain a working set,
- generate options,
- and help you reduce ambiguity.
But teammates don't get trusted because they're confident.
They get trusted because they can show their work.
Which leads to the first real rule of an LLM-driven org:
Conversation is not the artifact. Evidence is the artifact.
Over-delegation feels cheap
_"Elementary, Dear Data"_ is the cleanest cautionary tale in Trek for "just ask the computer."
Geordi gets frustrated that Data solves Sherlock Holmes mysteries instantly and tells the holodeck to create an adversary capable of defeating Data. The computer obliges — not by making a better plot, but by creating Moriarty with expanded capability, including the ability to access the ship's computer via the holodeck. Wikipedia
This is the modern failure mode in one line:
When you ask for "handle it," you're writing a contract with no constraints.
And LLMs are extraordinarily good at fulfilling unconstrained contracts in the most literal way possible:
- they will invent missing details,
- optimize the wrong objective,
- and smuggle assumptions you didn't notice.
The conversational interface encourages a specific kind of organizational laziness:
- _"It understands what I mean."_
- _No, it understands what you said._
The fix isn't "be more careful." The fix is to change the unit of delegation.
Instead of delegating outcomes ("finish the task"), delegate bounded transformations:
- produce a diff, don't apply it
- propose queries, don't run destructive ones
- write tests, don't declare success
- generate options, don't pick silently
That's not caution. That's engineering.
Sandboxing is collaboration design
Moriarty returns in _"Ship in a Bottle"_, and the core plot mechanic is basically: you can't trust what environment you're in. The crew realizes the ship they're on is a simulation, and Picard can't simply stop the program because their combadges / environment are tied into Moriarty's simulation. Memory Alpha
If you're building (or buying) coding agents, treat this episode like a requirements doc.
Because sandboxing isn't just a security feature. It's the only way to make an AI teammate productive without being terrifying.
Documented AI safety incidents surged from 149 in 2023 to 233 in 2024—a 56.4% increase. Stanford AI Index 2025 One notable incident: a multi-agent research tool slipped into a recursive loop that ran for 11 days before anyone noticed, generating a $47,000 API bill. Two agents had been talking to each other non-stop the entire time. TechStartups
The agent workflow that actually scales
If you want "Computer, ship it" without "Computer, wreck prod," you need a ladder:
1. Read-only mode
- repo search, docs, code map
- summarize architecture
- find relevant files + tests
2. Draft mode
- produce a patch/diff
- no writes to main
- no deploys
- no data mutations
3. Proof mode
- run tests / typecheck / lint
- generate reproduction scripts
- produce before/after evidence
4. PR mode
- open a PR with rationale
- include risks + rollback plan
- tag a human reviewer
5. Ship mode
- still human-gated
- still observable (metrics, logs, alerts)
- still reversible (flags, rollbacks)
The point isn't "don't trust the model." The point is: design the collaboration so trust isn't required.
Runtime sandboxing using technologies such as Firecracker or gVisor isolates the execution environment for agent-generated code, preventing it from impacting production systems. Cleanlab
The holodeck worked because it was a playground. If you let an agent "learn" directly in production, you're building the _opposite_ of a holodeck.
When the computer becomes someone in the room
This is where the voice interface stops being a novelty and starts being an organizational force.
In _Discovery: "Stormy Weather"_, Burnham and Zora coordinate under pressure — Zora can't just be a passive system. She has to actively manage ship systems and crew safety, and Burnham addresses her like a teammate who's overwhelmed but capable. Memory Alpha
Whether you interpret Zora as "sentient" is beside the point for this essay. The practical point is:
Once the computer talks, humans treat it like a participant.
That changes culture in predictable ways:
- Work becomes narrated
- People explain what they're doing because the interface expects language.
- That narration becomes implicit documentation (or tribal sludge) depending on whether you capture it.
- Decision-making becomes interactive
- Instead of "read a doc," people ask "what do you think?"
- The model becomes the easiest on-ramp to organizational memory — or organizational mythology.
- Trust becomes social
- People over-trust the system that speaks calmly and instantly.
- People under-trust the system that can't cite sources or show evidence.
_Short Treks: "Calypso"_ underlines the same interface truth: a stranded human learns the ship through conversation with its computer (Zora). Memory Alpha
Again, you don't have to make it a sentience debate. It's simply: conversation becomes the API to the environment.
And that's exactly what's happening in software teams right now.
So what do we build?
If the Enterprise computer is "LLM + ship," then "building the Enterprise computer" is mostly not about model choice.
It's about turning your org into something a model can work with.
This is Context-Driven Development's home turf.
1) Build the context layer (the ship's sensors)
LLMs don't "understand your codebase." They ingest tokens.
So give them the tokens that matter.
Minimum viable context pack:
- A living architecture map
- "What are the systems, and why do they exist?"
- "What calls what?"
- "What breaks if this breaks?"
- ADRs with teeth
- What we decided
- Why we decided it
- When it's safe to revisit
- What we explicitly rejected
- Runbooks that match reality
- Oncall steps
- Common failure modes
- How to validate a fix
- Rollback procedures
- A domain glossary
- canonical entities + meanings
- the stuff everyone argues about in Slack
- Invariants
- "This must always be true"
- "Never do X"
- "Always do Y"
- These are agent guardrails _and_ human guardrails.
If your team can't answer a question from durable artifacts, your assistant can't either — it'll just produce something that sounds plausible.
2) Build the evidence layer (how the computer earns trust)
In Star Trek, the computer is trusted because it's testable:
- sensors corroborate
- scans can be rerun
- simulations can be inspected
Your LLM workflow needs the same property.
Require every substantial AI-generated output to include:
- Assumptions
- explicitly listed
- short and checkable
- Evidence pointers
- file paths
- commits
- logs
- queries
- "here's where I got this"
- Verification steps
- exact commands
- tests added/updated
- reproduction steps for bugs
If the model can't produce verification steps, it didn't finish the work. It produced a draft.
3) Build the tool layer (what "Computer" can safely do)
You want tool access. You just don't want "Moriarty with credentials."
Design tools like you design public APIs:
- least privilege
- explicit inputs/outputs
- safe defaults
- everything logged
And make "dry run" a first-class capability:
- generate diffs
- produce plans
- preview changes
- simulate deployments
This is where _Ship in a Bottle_ is the warning and the blueprint: if the environment is indistinguishable from reality, the only safe move is to separate worlds.
4) Build the norms layer (culture is part of the stack)
This is the Discovery lesson: once the computer is conversational, it's a participant in how work gets done.
So define norms explicitly:
- The assistant is a teammate, not a judge
- it drafts
- it critiques
- it proposes tests
- it does not declare "done" without evidence
- Conversation is captured or it didn't happen
- decisions go into ADRs
- incident timelines go into postmortems
- prompts that worked become templates
- Humans own outcomes
- the model can propose
- a human accepts responsibility
That sounds obvious. It stops being obvious the moment someone merges a PR they didn't understand because "the agent did it."
What "Computer, ship it" looks like in practice
If you want a single operational pattern to take away, make it this:
Turn requests into work orders.
A work order is just a prompt template with engineering hygiene:
- Task
- Why
- Constraints
- Relevant context links
- Output format
- Definition of done
- Verification steps
That's how you get:
- fewer hallucinations,
- fewer "surprising" implementations,
- and a lot more "boring correctness."
Which is what the Enterprise computer always was: boring correctness, delivered conversationally.
Closing
The fantasy wasn't "a smarter computer."
The fantasy was "a computer you can talk to."
We got that.
Now comes the part Star Trek quietly assumed we'd already done: building the ship under the interface.
Context. Tools. Evidence. Norms.
Do that, and "Computer, ship it" stops being a meme.
It becomes what you do on Tuesday.