Technical Enough

What software actually is

Chapter 2 of 7 in The Software Map · 6 min

You are running the roadmap review, and the slide on the screen is yours: an AI summary feature for the mobile app, promised to a logistics customer whose drivers spend half of every day out of cell coverage. An engineer looks at the row and says the feature cannot work offline because the model runs server-side. The customer success lead asks whether the commitment stands. You cannot picture what the sentence describes, so you promise to follow up, the review moves on, and the commitment goes out resting on words you could not translate. In Decode the technical questions that stop you you practiced slowing that moment down; this chapter builds the picture that makes the translation fast.

The smallest piece of software, printed in full

Before that sentence can be decoded, the word underneath it has to become concrete. Here is an entire piece of software, complete: a tip calculator written in Python, a programming language, and you do not need to read the punctuation to follow it.

bill = float(input("Bill amount: "))
tip = bill * 0.20
print("Total with tip:", bill + tip)

Point at what is actually there. The three lines are instructions: the first waits for the user to type a number, the second works out twenty percent of it, and the third puts the answer on the screen. On this page they do nothing; they become a working calculator only when a computer carries them out. And their whole job, once running, is to take one thing in, the bill amount, and hand one thing back, the total. That is everything the program contained: instructions, a place to run them, and an input that becomes an output.

A piece of software is a set of instructions, a place where those instructions run, and an input that becomes an output.

Everything you have ever shipped, bought, or churned from is those three parts at some scale, and nearly every technical question you will ever face is a question about one of them.

Every piece of software, in three partsThree cards left to right, joined by thin connectors. Card one, instructions: what to do. Card two, runs somewhere: local or remote. Card three, input to output: takes X, gives Y. Each card is tagged with the decision it stands for, what, where, and in and out. Caption: every piece of software, in three parts.WHATINSTRUCTIONSwhat to do(a page or a model)WHERERUNS SOMEWHERElocal or remote(your device or a host)IN AND OUTINPUT → OUTPUTtakes X, gives Y(tap in, answer out)Every piece of software, in three parts.

ChatGPT is the same three parts at giant scale

The frame has to hold for the software that feels least like a three-line calculator, so test it on ChatGPT, likely the AI product you know best. At its center is a model: a set of instructions that produces text, built by training on enormous amounts of writing rather than typed out by a programmer.

  • The instructions live in two places: an app on your phone that draws a text box and a send button, and the model itself on OpenAI's computers.
  • The running happens partly in your hand and mostly in a data center, a building full of computers that a company operates.
  • The input is the message you type plus the conversation so far, and the output is the reply that streams back.

Questions about the product now become precise: a privacy reviewer asking what the model receives is asking an input question with an exact answer, your message and the conversation so far.

A model is a set of instructions produced by training on data rather than typed by a programmer, and it still runs on specific computers and still turns an input into an output.

The engineer's sentence, decoded

Now go back to the sentence that ended the review with you silent.

The feature cannot work offline because the model runs server-side.

Read it against the frame. "The model" now has a picture behind it: trained instructions that would produce the summaries, the same kind that produce the replies in ChatGPT. "Server-side" is builder shorthand for where those instructions run: on the company's computers, reached over a connection, not on the phone in the driver's hand. The whole sentence is a statement about the second part of the frame; with no signal, the phone cannot reach the place where the summarizing instructions live, so no summary arrives until the connection returns.

And the reply you could not give in the room writes itself once the part has a name: do any pieces of the feature run on the phone, and could they capture notes locally and hold them until the connection returns? That is a real product option, recovered from a sentence that had felt like a wall. The three recurring questions from Decode the technical questions that stop you, where something runs, where something is kept, and who is allowed to do what, are this same frame in action.

The obvious objection: an AI chat can translate for you

The obvious objection is that any AI chat would have translated the engineer's sentence in ten seconds, so why carry a frame in your head at all? Pasting fails in the moments that cost the most: the review, the vendor pitch, the incident call, where the response has to come from you on the spot. It also leaves you unable to judge what comes back, because a wrong explanation reads exactly like a right one. The frame is how you check: a real explanation lands on one of the three parts, and when it touches none of them, you do not have an answer yet, so keep asking.

Try it on a sentence harder than the engineer's:

We should move inference closer to the user to cut the latency.

Inference is a builder's word for the model running, producing an output from an input, and latency is the wait between sending the input and seeing the output. Closer to the user is geography, computers physically nearer the phone. So this is a where-it-runs proposal, move the place the model's instructions run so the answer travels a shorter distance, and it becomes a decision you are qualified to weigh: which users wait too long today, what the wait costs them, and what the move would cost.

This page is the same three parts

The page you are reading is software too, and its breakdown is short.

  • Instructions: a folder of plain text files holding the pages and the chapters, each readable in an ordinary text editor. We described every page in English to an AI coding agent, a tool that turns descriptions into code, then read the files it produced and corrected what came back.
  • Runs: on a computer we rent in someone else's building. We own no machine you could visit; when you opened this page, that rented computer ran our files and sent back the result.
  • Input and output: your tap on a link went in, and this chapter on your screen came out.

If the frame holds a three-line calculator, ChatGPT, and this page, it will hold whatever you build. The rest of the level takes the parts one at a time: the instructions in languages and frameworks and Git, the place they run in hosting and environments, and the inputs and outputs in the journey of a request, APIs, and data.

Try it now

This drill takes about ten minutes and spends nothing, or a few cents on the tooled path. You leave with two three-part breakdowns, one of them for the idea you want to build, added to the idea file you started in Decode the technical questions that stop you.

No setup: Pick an app you used in the last hour and write its three parts in three lines: what the instructions do, where they run, and what goes in and comes out. For a podcast app: instructions that fetch, store, and play audio; running partly on your phone, mostly on the company's computers; a tapped episode going in and sound coming out. Pick a boring app, because the boring ones prove the frame holds everywhere. Then write the same three lines for the tiny idea you keep circling, a bill splitter, a reading tracker, a feedback form, and add both breakdowns to your idea file.

With your tools: Open Claude Code and run the frame on that same idea before any build. Prompt it with: "Before writing any code, describe the three parts of this idea: what the instructions would do, where they would run, and what the input and output would be." It will reply with a short breakdown, a few sentences per part. Restate each part in your own words and save your restated version into your idea file, because the drill's product is your restatement, not the tool's answer. If Claude Code is not installed yet, the Setup Clinic gets you there in one sitting. In Codex or Cursor the move is the same: paste the same prompt into the chat sidebar before any code gets written.

Chapter Summary

  • A piece of software is three things: a set of instructions, a place where those instructions run, and an input that becomes an output.
  • The instructions can be three lines of arithmetic or a model trained on a large share of the written internet, and the three parts stay the same.
  • A model is instructions produced by training on data rather than typed by a programmer, so run it through the same three questions, starting with where it runs.
  • "The model runs server-side" is a statement about where instructions run: on the company's computers, reached over a connection, which is why no signal means no output.
  • An AI chat can translate any technical sentence after the meeting; the frame is what lets you respond during it, and it tells you what a real explanation has to contain.
  • When a technical sentence stops you, name which part it is about, the instructions, the place, or the input and output, and the question usually turns out smaller than it sounded.
  • Your idea file now holds a three-part breakdown of the idea you actually want to build, and later chapters will pick it up from there.
  • Next, Where software lives opens up the part this chapter kept pointing at, the place where instructions run.

Sources

  • OpenAI help documentation on the ChatGPT mobile and web apps (last verified July 2026).
  • Python language documentation, python.org (last verified July 2026).
Reaching the end does this for you.
Next upWhere software livesChapter 3 of 27 · 7 min
Read alongside
The Missing Layer (essay)· Essay
Glossary
Software