The composition vs composable question has one test. A part is composable when you can lift it out and every other part keeps running with the same answers. The quote engine I built at AccuKnox fails that test, because removing one module changes the price of every other module.
Composition is how you build a system from parts. Composable is what each part is afterward. Most advice covers the building, and the cost sits in the seams between parts.
TLDR
Composition is the act of building from parts, and composable is a property of each part.
The lift-out test: remove one part, run the rest, and compare every answer with the full run.
Three tests decide it: a part must be self-contained, reusable and interoperable.
My quote engine passes the third test and fails the first two, because one quote-wide tier ties every module together.
A Unix pipe passes on every stage but one, and that one fails without any error.
A Part Is Composable Only If You Can Lift It Out
Run the same experiment on two systems. Remove one part, then watch what moves.
Quote engine: Remove one module and the total units fall. The quote-wide tier can change, so every other module reprices.
Unix pipe: Remove grep and the other stages still run. The error lines come out the same, with more lines around them.
Run the lift-out test on your own code in three steps:
Pick one part, then delete it or stub it with an empty return.
Run everything else.
Compare each remaining output with the full run. Any difference is a coupling.
Rule of thumb. If you cannot delete a part to see what breaks, you cannot reuse it in a second place either.
Composition Builds From Parts, Inheritance Builds a Tree
Composition is a design principle. You build a larger system from smaller parts, such as objects, functions and components. Inheritance builds a tree instead, and a subclass stays locked to its parent's shape.
Design Patterns by the Gang of Four, published in October 1994, tells you to "Favor object composition over class inheritance." The advice says favor, so inheritance stays legal.
My own post on this split sits below.
Three Tests Decide Whether a Part Composes
Composable describes a part, not the act of building with it. A composable part passes three tests.
Self-contained: It never reaches into a sibling's internals.
Reusable: The same part solves the same problem a second time without a rewrite.
Interoperable: It connects to other parts through a plain interface.
The third test is the cheapest to pass, because a plain interface is one value that crosses the seam. MCP (Model Context Protocol) is a standard plug that connects an outside tool to an agent.
A Pricing Engine Failed the Lift-Out Test
I replaced a quote spreadsheet with a pricing engine at AccuKnox. About a dozen security modules feed one quote. Each module turns a raw count into billable units, and the units from all selected modules add up to one total. That total sets the volume tier for the whole quote.
Score the engine against the three tests:
Self-contained fails: Step 4 reads the units of every module.
Reusable fails: The same module gets a different rate in every quote, because its rate depends on the other modules.
Interoperable passes: Steps 1 to 3 hand over one number, the unit count.
The billing entity dropdown shows the same cost. One choice switches the currency symbol, number format, address and legal footer together, because the spreadsheet kept those as separate manual steps and people got one right and missed another.
Tip. You cannot always remove a coupling. Put it in one named step and keep every other step blind to it.
Agent instruction files follow the same rule. Each rule gets one home, as the load order post explains. The same cost shows up at the edge of a product, and the integration strategy post covers when to build a native integration and when to publish one event feed.
A Unix Pipe Passes on Every Stage but One
A pipe's interface is lines of text in and lines of text out, so no stage knows its neighbors. The output below is real. I ran it on a sample log of 8 lines that I wrote for this post.
GET /a 200
error: disk full
GET /b 200
error: timeout
error: disk full
error: auth failed
error: timeout
error: disk fullThe full pipe, then the pipe with grep lifted out:
$ cat app.log | grep "error" | sort | uniq
error: auth failed
error: disk full
error: timeout
$ cat app.log | sort | uniq
GET /a 200
GET /b 200
error: auth failed
error: disk full
error: timeoutThe error lines match in both runs, so grep lifts out clean. Now lift out sort.
$ cat app.log | grep "error" | uniq
error: disk full
error: timeout
error: disk full
error: auth failed
error: timeout
error: disk fullWatch out. The pipe still ran and printed no error, yet the answer is wrong. uniq collapses only adjacent duplicates, so it quietly depends on sort. Running is not the same as right, so compare outputs in step 3.
A CLI can pass the test the same way. groundtruth is a tool I built that fails a build when a claim drifts from its source. It reports to the rest of the build through one signal, pass or fail.
PocketFlow Applies the Same Test to an LLM App
PocketFlow is a 100-line LLM framework with zero dependencies, so you can read all of it in one sitting. A node runs one task, and the action it returns picks the next node.
Zachary Huang explains the 100-line design in his essay.
review - "approved" >> payment
review - "needs_revision" >> revise
review - "rejected" >> finish
revise >> review
payment >> finish
flow = Flow(start=review)A flow is also a node, so a flow nests inside another flow. An order pipeline can run payment, inventory and shipping as three nested flows.
None of the three flows needs to know the other two exist. Each one passes the lift-out test.
Utkarsh Sharma shared a free 421-page guide to agentic design patterns. It covers prompt chaining and routing, which are two ways to compose parts.
Four Questions Developers Ask About Composable Code
Is composition the same as composable? No. Composition is the act of building from parts, and composable is a property of one part. You can compose parts that are not composable, and the cost then shows up in the seams.
Is inheritance always wrong? No. The Gang of Four says to favor composition, not to ban inheritance. A change to the parent's code reaches every subclass, so inherit only where you want that.
How do I run the lift-out test? Delete one part, run the rest, and compare each output with the full run. A crash or a changed answer marks a coupling.
Is every coupling a bug? No. A quote-wide pricing tier is a rule of the business. Keep the coupling in one named step and let every other step stay blind to it.
The UNIX and React examples make this tangible. This should be mandatory post-tutorial reading.
Here's the TL;DR version of this:
• Inheritance creates rigid coupling over time.
• Composition enables flexible system design.
• Reusable units reduce architectural fear.
• Modern systems favor assembly over hierarchy.
• This principle applies to LLM frameworks directly.