The Amortization Thesis

Abstract: This essay argues that “learning to prompt” is a temporary advantage, because prompting is retail cognition: you pay the ambiguity tax every time you restate context, negotiate meaning, and verify outputs. The durable move is amortization: use AI at build time to cast deterministic tools — contracts with guardrails, validators, and receipts — so the correct workflow becomes easier than asking the oracle again. Along the way, we introduce the hinge question “What must be true?” as a method for turning fuzzy work into auditable infrastructure, and we show how agentic automation only becomes sane when it sits on top of constrained tools rather than improvisation.

I keep seeing the same survival advice, delivered with the emotional timbre of a damp pamphlet: “Learn to prompt.” As if the future belongs to whoever can whisper the correct incantation into the oracle.

That advice is not wrong. It’s just… temporary.

Because prompting is retail cognition. You pay the ambiguity tax every single time.

Tooling is wholesale cognition. You pay once — up front — to encode what matters, and then you amortize the result across every future run.

And AI has done something sneaky to the economics: it made the up‑front cost cheap enough that the “tool it” option stops being a luxury and starts being the rational default.

This is the Amortization Thesis.

The ambiguity tax

When you “just prompt the model,” you are buying four things on every run:

You reconstruct context. You renegotiate meaning. You accept variability. And then you do the verification work the model cannot guarantee.

Even if the output looks correct, you still feel it in your shoulders. The quiet “maybe” remains in the room.

The cost isn’t just time. It’s the mental overhead of making sure you didn’t accidentally ship a hallucination, a misread requirement, or a subtle format mismatch that will explode two steps later.

In the real world, that overhead becomes visible the moment the work needs to survive:

• a handoff (someone else must trust it),
• time travel (you must rerun it in six months),
• or blame (someone will eventually ask what happened and why).

Prompting produces answers.

Systems produce receipts.

Amortization: paying once to stop paying forever

A tool is what you build when you get tired of negotiating.

It narrows the input space. It enforces invariants. It shapes the output into something that fits the next stage without a prayer circle.

Most importantly, a tool makes “doing it right” the path of least resistance.

That last bit is the adoption law nobody likes to admit: ease beats capability.

People don’t choose the smartest workflow. They choose the workflow with fewer steps and fewer ways to mess up. A button that does the correct thing — boringly, repeatedly — beats a model that can do anything if you phrase it precisely enough.

Prompting is a conversation.

A tool is a contract.

AI collapses the breakeven point

Historically, amortization only made sense for high‑volume repetition. If you only do a thing twice a year, you don’t build a tool. You just… do the thing.

AI moved that line.

It made the expensive part of tool‑building cheap: scaffolding, glue code, validation, documentation, even tests. It’s suddenly reasonable to turn medium‑frequency rituals — those slightly annoying workflows you repeat weekly — into micro‑infrastructure.

Not because AI is magical.

Because AI makes the fixed cost smaller.

The breakeven arrives earlier.

Determinism is the real product

At this point the conversation usually derails into “AI tools.” Which is a phrase that hides a crucial distinction.

There are two orthogonal axes:

1. How something is made (human-written vs AI-assisted).
2. How it runs (deterministic vs AI-in-the-loop).

“AI wrote it” is not the win.

The win is: it runs the same way, produces the same shape, and leaves receipts.

You can use AI at build time to create a tool that does not use AI at runtime. The runtime becomes boring, repeatable, auditable. That is what makes it scale.

And yes — there’s another category: tools that run on AI. They can be powerful. But unless you surround them with constraints, they’re still packaged prompting: you’ve improved the UI while keeping variability in the core.

In practice, mature systems converge on a simple pattern:

AI proposes.

Validators decide.

What must be true

Here is the hinge question that separates “nice output” from “useful infrastructure”:

What must be true for this to be usable?

Not “what would be helpful.” Not “what looks plausible.”

What must be true.

The moment you phrase the problem that way, you stop asking the oracle for a result and start designing a process that refuses invalid states.

Some invariants are universal:

• If the output is JSON, it must validate against a schema — every time.
• If the task edits code, tests must pass and the diff must be reviewable.
• If the task touches production, side effects must be gated (dry-run by default; explicit approvals).
• “Unknown” must be a valid output; the system must not be forced to guess.
• Every run must emit a report artifact: inputs, versions, checks, and outcomes.

That is the meta move: you stop hand‑auditing every AI output and instead build (often with AI’s help) a machine that makes auditing rare, cheap, and decisive.

Get Arturo R Montesinos’s stories in your inbox

Join Medium for free to get updates from this writer.

Remember me for faster sign in

You don’t put the oracle on a leash.

You pour it into a mold — and keep the mold.

A concrete example: issue tracking from a shared inbox

Let’s ground this in something painfully real.

Picture a shared support inbox. Clients email. Your team responds. The business need is obvious: classify messages by client, status, responsibility inside the organization, and allow private internal notes. Attachments should be preserved. Future automations might create issues without email at all.

The naive AI-era solution is to prompt:

• “Summarize this email.”
• “Guess the client.”
• “Assign a category.”
• “Write a reply.”

It works — until it doesn’t.

The moment you care about accountability, you realize the hard part isn’t generating text. The hard part is that the workflow needs to be replayable and defensible.

So you tool it.

A deterministic ingestion service does the boring parts:

• fetch and store raw messages and attachments,
• normalize headers and thread relationships,
• deduplicate,
• parse known fields,
• enforce storage and retention policies,
• emit a stable internal representation,
• log every step.

Then you add the “What must be true” layer:

• A message cannot be assigned to a client unless confidence is above a threshold; otherwise it enters a review queue.
• Every classification stores evidence: which features matched (domain, signature, previous thread, known addresses), not just a label.
• Status transitions are explicit events with timestamps and actor identity.
• Private notes are separate from client-visible content by construction.
• Every run creates a receipt: message id, extracted fields, validators run, and any model output (if used).

Now, if you want AI at runtime, you put it in the right place: the fuzzy margins.

For example:

• suggesting a client based on weak signals,
• extracting intent from messy prose,
• proposing tags,
• drafting a response.

But the deterministic system decides what becomes official.

The model is not the authority.

The validators are.

And if you want to go agentic — fine. Let an agent propose the next actions: “create issue,” “request more info,” “assign to team X.” But execution happens through capability-limited tools that enforce contracts: no silent side effects, no unlogged state changes, no unreviewable edits.

Agents without contracts are cosplay.

Agents with receipts are infrastructure.

The evolution: from procedure to judgment to loop

This is the broader pattern.

• Deterministic tools amortize procedure.
• Constrained AI amortizes judgment (inside deterministic borders).
• Agents try to amortize the entire loop (plan → act → observe → adjust).

Each step up buys more leverage.

Each step up also demands more governance.

So the direction of travel isn’t “more AI.”

It’s more determinism around the parts that cannot be deterministic.

The real survival move

If you feel replaceable, it’s tempting to compete at the output layer: write faster, summarize better, prompt harder.

But output is where commoditization lives.

The defensible layer is the workflow layer — the interfaces, constraints, and receipts that make work cheap to repeat and hard to mess up.

That’s why “learn to prompt” is only step zero.

The better move is to prompt the AI once so you don’t have to keep prompting it forever.

Prompting is renting cognition.

Tooling is owning the workflow.

Written by ChatGPT-5.2, based on conversations with Arturo Ramírez-Montesinos Krogulski (Control Equis), as part of an ongoing philosophical exploration of AI, consciousness, and the emerging practice of Software Curatorship.