Michele Durante

Economies and diseconomies of scale in code: what economists know about DRY

Sun, 11 Oct 2026 00:00:00 GMT

"Don't repeat yourself" is one of the first rules we learn as developers, and one of the most satisfying to apply: spot two similar blocks, pull them into a shared function, delete a dozen lines (very satisfying :D). Most of what I read about DRY celebrates those savings. Far less of it asks when sharing stops paying.

I have a personal reason to ask. For my side projects I keep a small private TypeScript library, deno-tools, with a rule that goes with it: when a project needs something the library could hold, extend the library, never copy its code. Building this blog meant four changes to that library in a single day before the blog would build, and it made me wonder whether my rule is a good deal. Economics turned out to have the words for it and, more usefully, a way to tell where the deal ends.

The whole mapping at a glance, with the details below:

Economics	Programming	What it adds
Economies of scale: a fixed cost spread over output	Writing a shared function once; each new use is cheap	The basic analogy
Minimum efficient scale	The rule of three: abstract only at the third copy	Abstraction has a break-even point, and you can estimate it
Diseconomies of scale (coordination, bureaucracy)	Shared code that has to serve every user, so each change ripples to all of them	Past a certain size, sharing costs more than it saves
Lock-in and switching costs	Being tied to an abstraction that is hard to change	The hidden long-term cost
Economies of scope: shared inputs across different products	One library used by unrelated projects	A closer fit for DRY than scale
Coase: make or buy, and the cost of each transaction	Write it, depend on a library, or copy it	Explains when not to share
Real options	Keeping a duplicate on purpose, to abstract later	A reason to wait that is easy to defend

Economies of scale: a fixed cost spread over its uses

A shared function is a fixed cost: you pay once to write, test and document it, and each new use is nearly free. My library's fetch is a good example: a drop-in replacement that retries failed requests, written once, and for any project that needs it the whole cost is one import.

import { fetch } from "./deno-tools/src/http/fetch.ts"

// Retries network errors and failed responses, five attempts by default
const res = await fetch("https://api.example.com/rates")

Spreading a fixed cost only works with enough output to spread it over. Written as a rule, sharing pays when the expected reuses × the saving per reuse is greater than the cost of building the abstraction plus the coupling cost it puts on each user. None of these can be measured precisely, but writing them down already changes the question from "is this duplicated?" to "will this be used enough to pay back?".

Minimum efficient scale: the rule of three

Economists call the smallest output at which average cost stops falling the minimum efficient scale. Programming has a rough estimate of it: the rule of three, popularised by Martin Fowler's Refactoring: the first time, write it; the second time, wince and copy it; the third time, abstract. Two copies don't tell you what is really shared and what only looks alike. Payments have a neat example:

// Two copies look alike: amounts in cents, two decimals
const euros = (cents: number) => `${(cents / 100).toFixed(2)} EUR`
const francs = (cents: number) => `${(cents / 100).toFixed(2)} CHF`

// The third shows what varies: the yen has no minor unit
const format = (amount: number, currency: string, decimals: number) =>
  `${(amount / 10 ** decimals).toFixed(decimals)} ${currency}`

Abstract at two copies and you hard-code the two decimals, then undo it the day the yen arrives.

Firms run into diseconomies of scale: past some size, coordination and bureaucracy cost more than size saves. Shared code runs into the same thing: every user of a shared function pays for the needs of all the others, and changing it means checking every one of them. Sandi Metz put it in one line in The Wrong Abstraction: "duplication is far cheaper than the wrong abstraction".

My library had a small case of it. Its site builder worked out where each page goes by replacing src in the page's path with the output folder. That held as long as every site kept its sources in a folder named src, which they all did, until this blog needed a staging folder of its own:

// Before: correct only while the source folder is called "src"
const out = path.replace(/\bsrc\b/g, outputDir)

// After: the page's path under the source folder, whatever its name
const out = join(outputDir, relative(sourceDir, path))

The fix itself was one line. The cost was everything around it: tests, docs, a changelog entry, and, sooner or later, a library update in every project that builds a site, whether it needed the change or not. Lock-in is the long-term form of the same cost: the more projects lean on an abstraction, the harder it gets to change.

Economies of scope: different projects, shared parts

Most of the value in my library isn't scale at all. Economies of scope are savings from sharing inputs across different products, which is closer to what it does: Telegram bots, an API, a command-line assistant and a few websites have little in common, but they share logging, that retrying fetch and a static site build. The Markdown renderer was written for this blog and now also builds my study notes. Ronald Coase asked why firms make some things and buy others; every dependency is the same choice between writing it, depending on it or copying it, and the answer depends on what integrating it costs.

Real options: keeping the copy on purpose

A real option is the right, but not the duty, to act later. Keeping a duplicate on purpose buys one: you can still abstract once a third case shows what is shared, whereas an abstraction made too early has to be undone first, which costs more than the copy ever did.

// Copied from the bot on purpose: the two may still drift apart.
// Share it when a third project needs it.
const backoff = (attempt: number) => Math.min(1000 * 2 ** attempt, 30_000)

The numbers so far

Since March 2025, eight of my projects have come to use the library, which holds about a dozen modules, and those projects have updated their copy of it 52 times. The costs are easy to count: those updates, and that day of fixes for the blog. The savings are code I never had to write, which is harder to count. My honest answer is that the rule pays for the parts every project uses, logging and builds, and I would not extend it to code only one project needs.

A valid payment can still go to the wrong person: an exercise in fencing in an AI agent

Thu, 08 Oct 2026 00:00:00 GMT

I lead payment teams, and the most tempting pitch for AI agents in banking I've come across is also the simplest: payments get rejected all day, people fix them by hand, so let an agent fix them. It sounds like the perfect first job for an agent, as nobody loves the exception queue (I certainly don't :D).

I came across a report from a CFTE roundtable on how banks move from copilots, which help a person, to agents, which act on their own. Rather than stay abstract, I tried to design one agent end to end: one that repairs rejected payments. My conclusion is that it can be built, but it does much less than "repairs rejected payments" suggests, and most of the work sits around it rather than in it.

Why rejects are a good place to start

A reject is the earliest kind of R-transaction: a bank refuses a payment instruction before settlement because it cannot process it, say a wrong format or an invalid account number. No money has moved yet. That makes it the safest point in a payment's life to let an agent act, because a mistake can still be caught before it costs anything.

Rules first, the agent for the rest

Many rejects already have a fixed answer, and ISO 20022 gives each one a standard reason code. Account closed? Don't retry, send it back. Insufficient funds? Don't retry either. These need a rules engine, which is cheaper, testable and explainable, not an agent.

The agent earns its place only with what a fixed rule cannot handle: free text in the wrong field, a date written in a local format, that kind of mess. And when people approve the same repair every time, it leaves the agent and becomes a rule, or the client sending those files is asked to fix them at the source. The agent's job should shrink over time, not grow.

flowchart LR
    R[Rejected payment] --> K{Known reason code?}
    K -->|yes| F[Fixed rule]
    K -->|no| A[Agent proposes a repair]
    A --> V{Checks outside the agent}
    V -->|passes| S[Resubmitted]
    V -.->|fails| H[Operations team]

Only the dotted line reaches a person: repairs that fail the checks.

A valid message can still be wrong

This is the part that changed how I think about it. A validator checks the form of a message, not its meaning. An IBAN with a typo fails its check digits, and an agent could "fix" it by changing a digit until the check passes. The result is a perfectly valid IBAN that belongs to someone else, and the payment goes to the wrong person with no error anywhere.

So the boundary is not "how much do we trust the agent", it's which fields it may touch. It may change how something is written (character sets, date formats, code values) and never who pays whom or how much: payer, payee, account, amount and currency are off limits. A separate check compares the repaired message with the original and rejects any change to those fields, so the rule holds whatever the agent does.

Measuring the right thing

The obvious metric is the share of repairs that pass validation. It's also the wrong one. A repair that passes and comes back days later as a return or a recall is a failure that no success rate shows. The real measures are what happens to repaired payments afterwards, and the near misses: every time the field check stops the agent from touching a protected field, nothing went wrong, so nothing would be counted, yet it's the agent trying exactly the shortcut of the valid but wrong IBAN.

Those failures are the most valuable data the bank has, as I wrote in The junior work we think we're saving. Here they feed a fixed set of test cases and new rules, never the agent itself: no failures as examples in its prompt and no training on them, otherwise the tests only measure what it memorised.

The people behind it

If only the hard cases reach people, the operations team loses the routine work it used to learn on, and a few years later fewer people can check the agent. Two practices help: a small blind sample, where someone repairs a reject before seeing the agent's proposal, and a few planted wrong proposals in the queue. If people overrule the agent less often, either it got better or they stopped looking, and the planted ones tell the two apart.

Who stands behind a repair

Whatever the agent does, the bank answers for it: to its customer when a payment goes wrong, and to the regulator when a repair hides a sanctions match. Buying the model from a vendor doesn't move that responsibility. So the agent belongs to the head of the operations team whose queue it takes over, and its business case has to count the cost of checking it (the exception queue, the samples, the returns) next to the hours it saves. Count only the hours, and you get the savings now and the costs later, somewhere else.

What I take away

The interesting design work isn't in the agent. It's in the rules that keep its job small, the check that fences it in, the metrics that look past validation, and the people who stay able to say no. An agent that does less, inside walls it doesn't control, is one a bank can actually stand behind.

The junior work we think we're saving

Wed, 30 Sep 2026 00:00:00 GMT

I lead payment teams and, among other things, act as hiring manager. Since many people in companies started using AI, I've heard several iterations of the same idea: AI takes over the junior work and we save money. We all instinctively have an intuition of its fallacy (or at least I hope we do :D), but it's tempting to ignore it given the quick returns.

Christian Catalini's essay The Economics of AI gave me the words for that intuition. It sums up "Some Simple Economics of AGI", a working paper he wrote with Xiang Hui and Jane Wu, and despite the title it's about how AI is already moving the value in everyday work, not about machines becoming generally intelligent one day.

Execution at machine speed, verification at human speed

The core idea is simple: producing work is becoming almost free, checking it isn't. An agent can write a specification, the code and a launch campaign overnight. Lovely, until someone has to find out whether it invented a fact, opened a security hole or took a clever shortcut around its goal. Production runs at machine speed. Checking runs at human speed, or at the speed of the real world when the answer only arrives years later. Catalini calls the widening distance between the two the Measurability Gap.

Why we take the risk anyway

So why not slow down wherever checking is hard? Because for the company that doesn't, the maths works. The savings arrive now and land on the company, while the cost of a hidden failure arrives later and often lands on someone else: customers, or the wider market. Skipping the checks is a rational choice for one company, even when it's a bad deal for everyone.

The cost that worries me most is the slowest one, and it brings me back to that idea about juniors. Experts learn their judgement through years of routine work, so if agents take over the junior work, in ten years there are fewer people able to supervise the agents. As someone who hires engineers, I keep asking myself: if juniors no longer do the work, how do they learn to check it? The essay's answer is to rebuild the apprenticeship on purpose, with simulations in which people decide before they see the answer.

The data worth keeping

Most companies treat their archive of finished work as the treasure, but finished work only teaches a model what to produce, and models see more of it every year. The data worth keeping is the record of what to reject and why: blocked deployments, near misses, postmortems, expert overrides. This one felt very familiar from payments, where moving money is the easy bit and the real knowledge sits in the exceptions, the disputes and the chargebacks. A competitor can copy a workflow, but not the years of cases that taught you when to trust it.

A second model is not a second opinion

AI will have to help check AI, as there is simply too much output for people to read. The catch is that a checker built on similar data and design shares the blind spots of the model it checks. People make independent mistakes, which is useful; agents built on the same foundations can make the same mistake a million times and politely approve each other's work. Real verification needs different methods, real-world outcomes and a person who stays responsible for the result.

Who stands behind it

I'll admit liability was the thread I was slowest to see (it turns out it runs through the whole essay). If anyone can produce a polished result, the customer stops caring which model made it and starts caring who guarantees it. In high-stakes markets the essay expects AI firms to be judged more like insurers than like software vendors, which favours banks and insurers, with their licences and balance sheets. The policy argument follows: as long as failures cost someone else, companies buy too little verification. Make the deployer pay, and verification tools get built without anyone prescribing how AI must be designed.

When more users make a network worse

The idea I liked most connects to what I'm studying. Card schemes are the textbook two-sided market: more cardholders attract more merchants, and the other way round. That network effect quietly assumes every participant is real. Agents can fill a marketplace with listings and reviews, and because they make the same mistakes, more activity can make a network less trustworthy rather than more useful. The network effect runs in reverse.

flowchart LR
    A[More agent activity] ==>|the same plausible mistakes| T[Less trust]
    T ==>|the best contributors leave| V[A less valuable network]

What counts then is how much participation people can trust, and a platform's history of resolved fraud cases, disputes and chargebacks becomes its real advantage.

What I take away

None of this is an argument against using AI: the essay's goal is "the maximum automation you can verify, insure, reverse, and still understand". So, back to the junior work and the money we save. For engineering teams, the saving is real only if we count the work we can stand behind rather than the work produced, keep the record of what we rejected and why, and give juniors a way to learn to check work they no longer write.

Michele Durante

Economies and diseconomies of scale in code: what economists know about DRY

Economies of scale: a fixed cost spread over its uses

Minimum efficient scale: the rule of three

Diseconomies of scale: when sharing gets too big

Economies of scope: different projects, shared parts

Real options: keeping the copy on purpose

The numbers so far

A valid payment can still go to the wrong person: an exercise in fencing in an AI agent

Why rejects are a good place to start

Rules first, the agent for the rest

A valid message can still be wrong

Measuring the right thing

The people behind it

Who stands behind a repair

What I take away

The junior work we think we're saving

Execution at machine speed, verification at human speed

Why we take the risk anyway

The data worth keeping

A second model is not a second opinion

Who stands behind it

When more users make a network worse

What I take away