There is a reason so many DI articles feel unconvincing.
They try to sell dependency injection with edge cases:
- “One day you might switch databases.”
- “One day you might write lots of unit tests.”
Most readers have never switched a database. Many teams do not have a serious testing culture. So the pitch lands as theory.
A better way to understand DI is to stop treating it as a clever technique and start treating it as an evolutionary step.
Not an upgrade in taste.
An upgrade in how a system scales.
From a peasant economy to a modern market economy
Economic development has a recurring pattern.
In a peasant economy, the dominant strategy is self-sufficiency.
You keep everything inside the household because coordination is expensive, trust is limited, and the market around you is unreliable. It is not a moral failure. It is simply the most natural equilibrium.
As commerce grows, the winners are the ones who embrace specialization and markets.
They stop building everything themselves. They standardize. They outsource. They trade through contracts. That is how societies unlock scale.
Codebases evolve the same way.
Early on, the most natural approach is “one file does everything.” One place, fewer decisions, less coordination, faster shipping.
But once a system enters the multi-person, multi-module phase, self-sufficiency turns into a tax.
Convenience compounds into coupling.
The hidden bill: when convenience stops compounding
When a component creates everything it needs inside itself, it looks productive. It also quietly removes the seams that teams need to collaborate. Most people do this for a completely rational reason: convenience.
One file.
One mental model.
Fewer decisions.
The problem is that the team ends up paying for that convenience later, in ways that feel boring but expensive:
- Code review becomes political. Changes touch too much, so reviews argue about side effects instead of intent.
- Onboarding becomes archaeology. New teammates learn by trial, not by reading clear boundaries.
- Refactors become all-or-nothing. You cannot improve one corner without breaking another, so cleanup becomes a rewrite.
- Debugging becomes guesswork. Failures propagate across implicit globals and “who created this” chains.
- Parallel work becomes merge hell. No stable seam means multiple changes collide on the same concrete dependencies.
A self-sufficient codebase can ship. It just struggles to compound.
Interfaces are not abstractions. They are market standards.
When markets scale, society does not run on heroic individuals.
It runs on standard parts.
Think of electricity, shipping containers, USB, HTTP. The magic is not the technology itself. The magic is that a shared spec creates an ecosystem:
- You can swap suppliers.
- You can split work across organizations.
- You can innovate behind the boundary without renegotiating everything.
An interface plays the same role in a codebase.
It is not “extra indirection.” It is a standard that allows specialization.
A good interface makes three things explicit:
- What you can ask for (inputs)
- What you will get back (outputs)
- Where the boundary is (constraints and failure modes)
// Not just code: a spec.
interface PaymentGateway {
// Right: I give you a command
// Obligation: you return a result
// Boundary: Result explicitly models both “success” and “expected failures”
pay(cmd: PayCommand): Result<Receipt, PaymentError>;
}Good interfaces feel boring because good standards are boring.
They reduce negotiation.
They reduce surprises.
They make collaboration cheap.
DI is how you operate in a market economy
Once you adopt standards, the next step is obvious.
A component should not decide which supplier it buys from.
It should declare what it needs, and let the environment provide it.
That is dependency injection.
I declare what I need. You provide it. Then I do my job.
This is not about future-proofing for “maybe we switch databases.”
It is about separating responsibilities today:
- Components focus on business logic.
- Wiring happens at the edges.
- Different parts of the system can evolve independently.
class OrderService {
constructor(
private readonly repo: OrderRepository,
private readonly risk: RiskControl,
) {}
createOrder(order: Order) {
if (this.risk.check(order)) {
this.repo.save(order);
}
}
}Now there is a seam:
- The team can change infrastructure without rewriting the service.
- Multiple people can work in parallel without stepping on each other.
- Experiments can happen behind the interface.
Yes, tests and swapping databases become easier.
But those are downstream benefits.
The primary benefit is that your system becomes specializable.
Type systems are the enforcement mechanism
Standards only work if violations are visible.
In society, contracts are enforced in court.
In code, we get a cheaper enforcement mechanism: types.
- A signature is the spec.
- The compiler is the judge.
If you break the agreement, you get immediate feedback.
That is why explicit signatures and explicit boundaries feel so powerful in large systems.
They turn “tribal knowledge” into something that can be checked.
Conclusion: DI is not a trick. It is an economic upgrade.
If you are writing a small script or a tiny product, “one file does everything” can be the right move. In 2025, AI agents should write this code anyway.
That is why DI feels like an evolution: it is the architecture you adopt when you are no longer optimizing for local convenience, but for long-term compounding.
Interfaces create standards.
DI creates markets around those standards.
In a world of agents, you won’t hand-write the wiring. But you’ll still need the seams. DI is how you draw them.