By Igor Kulatov
An engineer’s argument for treating LLMs like interfaces, not colleagues
1. Framing
Most of the current discourse on prompt engineering treats large language models as a new kind of receiver requiring a new kind of communication discipline. They are not — LLMs are the newest instance of a very old engineering problem: a receiver with high inference capacity, an uncertain relationship between input and output, and no shared context with the sender.
Claude Shannon formalised a related problem in 1948, in the paper that founded information theory. He showed that the quality of a communication does not rest on the receiver’s sophistication — it rests on how precisely the sender encodes the message and how much noise the channel carries. A more capable receiver reduces the noise a little; it does not rescue an imprecise sender.
Engineers keep re-encountering that lesson every time a new class of receiver appears — early operating systems, networked APIs, distributed databases, machine-to-machine messaging in the Internet of Things, multi-protocol trading gateways, autonomous business-to-business commerce. Each generation initially treats its receiver as sophisticated enough to forgive sloppy input, and each generation eventually returns to the same rule: precision at the interface pays off more than sophistication in the receiver.
LLMs are receiver number N in that sequence, and the rule has not changed.
2. Where the pattern shows up
I have spent fifteen years working on the interface side of that problem, and it is the reason I keep noticing the same discipline appearing under different names.
Consider three examples from my own career.
My first was at 2lemetry, a startup building device connectivity infrastructure for the Internet of Things before that phrase had settled into common use. The question there was: how do you let millions of low-powered devices — thermostats, agricultural sensors, industrial monitors — communicate with servers over unreliable networks, without a person to translate misunderstandings? The engineering answer was not to make the server smarter; it was to make the message contract tighter. A device sending a temperature reading and a server interpreting it as an alarm code is a failure of the interface, not of either endpoint.
My second was the broker gateway at NAGA Group, where I served as Co-Founder and CTO from 2015 through 2022. Retail trading is a Tower of Babel: brokers and exchanges speak different protocols — FIX, FAST, ITCH, OUCH, and dozens of custom broker APIs — and none of them agree on how to represent an order, an execution, or a fill. The gateway I designed normalised those dialects into a single clean interface. Once it worked, direct competitors — FXCM, ThinkMarkets, OneFinancial and others — chose to license the technology and route their own client flow through it rather than build their own. That decision is not typical in retail brokerage; it happens only when the interface contract is precise enough that another firm’s due-diligence process will bet its client experience on it.
My third is Aurora Borealis, the autonomous business-to-business commerce infrastructure I have been running since 2020, where one company’s software strikes and settles trades directly with another company’s software, with no human at the decision points. In that setting, the interface is not a nice-to-have — it is the entire product. Two parties who cannot see each other’s internals must nevertheless agree, cryptographically, on the state of every trade. If the interface is loose, no amount of receiver sophistication rescues it.
Different receivers, same recurring lesson: in each generation, when the industry treats the receiver as forgiving, it hits a class of failures that only precision at the interface avoids. The engineering literature has been noting that pattern in different vocabularies since Shannon.
Now the same pattern has arrived at LLMs.
3. Why LLMs are unusually easy to underspecify
Here is what makes LLMs so tempting to underspecify. Every prior receiver in that pattern — a networked device, a broker system, an autonomous trading counterparty — looked mechanical enough that engineers knew they had to be precise. Nobody sends a vague message to a Bitcoin node and expects the node to interpret the intent. LLMs, by contrast, speak in fluent English; they sound like a colleague who understands you. The interface is dressed in the surface of a human conversation, and that surface is the trap. Whatever context you leave out, the LLM will fill in — silently, plausibly, and often wrong. Treating it as a colleague is the load-bearing mistake, and the four rules below address the failure modes that follow from it.
4. Four rules that carry across receivers
The engineering discipline for interfaces of this kind comes down to four operating rules. They are not specific to LLMs — they generalise. When applied to LLM prompting, they replace most of the current “prompt engineering” advice with something older and more portable.
1. Specify state, not intent
Intent is the sender’s problem; state is the interface’s problem. A good API does not accept “please make the code maintainable”. It accepts “no function longer than fifty lines, no cyclomatic complexity above ten, docstring on every public function”. State is verifiable. Intent is not. When you tell an LLM your intent, it invents a definition from its training distribution — usually the statistically common one, and usually not what you had in mind. When you tell it a state, it executes toward that state.
2. Same request, same result
A well-designed interface produces predictably equivalent results when the same request is sent twice. In distributed systems this property has a technical name — idempotency — and it prevents drift when the network retries. In LLM prompting, the equivalent discipline is that two reasonable rewordings of the same request should not produce categorically different outputs. If they do, your prompt is not specifying the request — it is being interpreted through minor accidents of wording. Test your prompt by rewording it before you rely on it.
3. Declare the boundary of what you don’t know
Precise interfaces mark unknown territory explicitly. Protocol specifications say “unknown fields are ignored” or “unrecognised opcodes must return an error”. Trading systems specify which market data feeds are authoritative and which are opportunistic. The equivalent in an LLM prompt is telling the model, in words, what it does not have access to: “If you do not have data on X, say so; do not infer from adjacent facts”. Without that clause, the model will fill the gap silently — and gaps filled silently are the most expensive bugs at any interface.
4. Ask what, not why
The “why” question invites the receiver to construct a narrative. Narratives are cheap to produce and hard to verify. The “what” question forces the receiver to describe a state that either exists or does not. When you ask an LLM “why is my query slow”, it produces a list of plausible-sounding causes, most of which will not apply to your specific query. When you ask “what operations does this query execute, and which ones scan more than ten thousand rows, given a Postgres 16 execution plan”, it has no room to narrate — it has to look.
Systems engineers spent decades learning that when you diagnose a black-box system by asking “why did this fail”, you get a plausible fiction. When you ask “what was the state at time T”, you get a fact. Blameless post-mortem culture, which is now standard practice in serious operational engineering, is built on exactly this substitution. The same shift is available in prompting.
Those four rules cover most of what makes a prompt work. They are not new — what is new is only that they now need to be applied by many people who never had to think about interfaces before, because LLMs put a receiver on every desk.
5. Why I trust those four rules
There is a second observation I have collected over the years, and it is why I trust these four rules rather than treating them as engineering-specific. The same rules keep appearing, in slightly different vocabularies, in every field where a communication has to be precise because the receiver will infer from what is given and the stakes will not tolerate wrong inference.
Emergency medical handoffs use structured protocols such as SBAR — Situation, Background, Assessment, Recommendation — first introduced at Kaiser Permanente in 2003 and originally developed for submarine watch handoffs by the US Navy. A rushed nurse describing “the patient in bed four is worrying me” produces catastrophically different outcomes than one describing state first and intent second. Cross-examination technique in law warns attorneys away from open-ended “why” questions that give a witness room to justify, and toward tightly-scoped “what happened” questions that force a factual answer. Clinical interviewing developed for trauma work discovered decades ago that any question beginning with “why” puts the patient on the defensive and stops the exploration, while questions beginning with “what” or “where” open it. Executive coaching for senior teams teaches the same substitution — “what was the reason” instead of “why” — because “why” interrogates, and “what” explores.
None of these fields borrowed from each other, and none of them thought they were doing engineering. They arrived at similar rules because they were solving similar problems — a receiver who will fill in whatever you leave out, and a downstream cost when the fill-in goes wrong. The underlying problem is the one Shannon named in 1948: a receiver will infer from what you give it, and the sender’s control ends at the interface. What differs across these domains is the receiver — a distressed patient, a witness on the stand, a nurse under time pressure, a client in a coaching session, an LLM at a keyboard. What does not differ is the discipline.
6. What to do on Monday morning
The takeaway is one habit change, wherever you sit.
Before you send your next prompt, ask yourself: could I write this same instruction as a change ticket to a colleague who does not share my context? Would they know the exact shape of the output I want, the boundary of what is out of scope, and the criteria by which the result is right? If the answer is no, the prompt is not precise enough. Rewrite it as if you were writing to a stranger who will bill for their time.
Consider three ordinary examples — the same request from the same person, first as usually written, then as it looks under the four rules.
Instead of “Review this code” use the four rules to ask for it: “Review this code for security issues and error-handling gaps. Return a bulleted list, most severe first, with a one-line explanation and a suggested fix per item. If you cannot judge a section for lack of context, say so; do not infer intent from surrounding code.”
Instead of “Write me an email to my boss” try “Write a five-sentence email to my boss requesting a two-week delay on the Q3 report. Include the reason (a data dependency slipped), a specific new date, and one clear ask (approval or objection by Friday).”
Instead of “Why is my query slow?” use “What operations does this query execute, and which ones scan more than ten thousand rows, assuming a Postgres 16 execution plan? Do not speculate about causes outside what the plan shows.”
Each first version asks the model to invent shared context; each second version tells the model what shape the answer must have, and what it is not allowed to fill in silently. Same task, different interface contract — and the second version produces answers you can use.
The discipline is not new — what is new is only that it has migrated onto every desk with an LLM on it. Recognising that you already know how, from every other high-stakes handoff you have ever done, is most of the work.
