The Unix model composes small single-purpose programs over untyped byte streams. When you design the tooling around a platform your team owns, how would you decide between that model and a single integrated program producing structured output, and what does each choice cost?

## Frame the decision as a contract question Both models are answers to the same question — *where does the coupling live?* In the composed model the coupling lives in the stream format and is implicit. In the integrated model it lives inside one program and is explicit. Neither eliminates coupling; they relocate it, and the whole judgment is about which location you can afford to defend. ## What composition actually gives you **Independent evolution.** Each program has its own release cadence, its own owner and its own tests. Adding a capability means writing a new program, not modifying an existing one — the extension point is the stream, so nobody has to design a plugin interface, and nobody's change can destabilise an unrelated feature. **Discoverable, run-time assembly.** A human at a prompt can invent a combination the authors never imagined. This is genuinely valuable during incidents, when the useful query is by definition one nobody anticipated. **Low commitment.** A small tool that turns out to be wrong is cheap to throw away. A capability inside a large tool acquires users and becomes permanent. ## What composition costs you **Accidental APIs.** The most expensive failure mode: you ship a human-readable format, someone automates against it, and now the default output is a contract you never versioned. Every cosmetic improvement becomes a breaking change discovered in someone else's pipeline. **No types, no nesting.** Byte streams model flat records well. Nested or optional data has to be flattened, and flattening is lossy or ambiguous. Values containing the delimiter are a permanent hazard. **Impoverished failure semantics.** One integer of exit status cannot say "three of four hundred records failed, here is which and why". Partial failure — the normal case in real systems — is exactly what the model expresses worst, and the default pipeline status hides upstream failure entirely unless you opt into a shell option that changes it. **Per-stage overhead and no shared state.** Each stage is a process. For high-volume or latency-sensitive paths, the process boundaries and the repeated serialise-parse cycle are real cost. **Operational surface.** Five programs means five things to install, version, sign and keep compatible with each other. That is often the deciding factor for a tool that must land on many machines. ## What the integrated tool gives you and costs you It gives you a typed internal model, precise structured errors, one artefact to install and one place to instrument. It costs you extensibility and organisational scale: every new capability queues behind one codebase's review, its test matrix grows superlinearly, and a bug in one area can take out the rest. It also tends to accumulate a poorly designed configuration language as it absorbs the flexibility that composition used to provide for free. ## The decision procedure I would actually use 1. **Name the consumers.** Human-first, machine-first, or both? Machine consumers are the strongest argument for a declared structured format, whichever packaging you choose. 2. **Ask what the failure model needs to express.** If partial success is normal and must be actionable, a single exit status is disqualifying. 3. **Ask who will extend this.** Many teams adding capabilities favours composition; one team owning a coherent workflow favours integration. 4. **Look at the data shape.** Flat records stream well; deeply nested state does not. 5. **Check the deployment cost.** How many machines, and how hard is it to keep several artefacts in step? ## The synthesis worth stating out loud The modern resolution is not to pick a side. Keep programs small and single-purpose — that part of the Unix argument has aged extremely well — but stop pretending the human format is an interface. Give every tool an explicit machine-readable output mode, document it, version it, and change the pretty format freely. Emit diagnostics on the separate error channel so structured data on the output channel stays clean. Where a stage can partially fail, put the per-item outcome *in* the structured output rather than in the exit status, and reserve the status for "did the invocation run at all". That is the honest position at this level: the Unix insight was that a universal interface enables composition, and text was simply the only universal interface available in 1975. Keep the insight and upgrade the interface.