Ship Fast With Tools, Not Shortcuts

"We ship fast." That sentence describes two opposite practices, which is exactly what makes it dangerous.

In the first case, a team has built its tooling. It generates what can be generated, automatically checks what can be checked, and has time left for the work that genuinely requires a brain. It moves fast because it paid up front.

In the second, a team skips steps. It moves fast today and will borrow tomorrow — without ever having signed the loan agreement, or read the rate.

The two look alike for roughly three months. After that, they diverge permanently.

The test that separates a tool from a shortcut

The distinction doesn't need to be complicated. One question is enough:

Will this make the next time cheaper, or more expensive?

A tool makes the next action cheaper. A test generator, a deploy script, a project template, an automated check that runs before every commit: each costs something once, then pays back on every use.

A shortcut makes the next action more expensive. A validation disabled "for now," a value hard-coded to move faster, a layer skipped because it "isn't needed here." It works. It works remarkably well — until someone has to change that code without knowing what was skipped.

This is what makes shortcuts so hard to fight: they deliver on every short-term promise. They ship. They close the ticket. They feel good. The bill arrives in a different sprint, often on someone else's desk.

What "technical debt" actually meant

The term comes from Ward Cunningham, and his original metaphor is sharper than the way we use it today.

Debt is not a mistake. It is a deliberate loan: you ship with an imperfect understanding of the problem, you capture the value now, and you repay by refactoring once you've learned. Cunningham was insistent on this point: debt is only healthy if you repay it.

What most people call technical debt today isn't that. It's code nobody understood while writing it, and nobody intends to revisit. That isn't a loan — it's an undeclared overdraft.

The practical difference is simple: acknowledged debt has a repayment date written down somewhere. If it doesn't, it isn't debt. It's a defect you've decided not to look at.

Leaky abstractions

Joel Spolsky wrote the single most useful law in this trade: all non-trivial abstractions leak. They hide complexity from you — until the day they hand it all back at once, at the worst possible moment, with no manual.

The pattern never changes. A tool solves 90% of the need in ten minutes. You adopt it. Six months later, the remaining 10% becomes the core of your product — and the tool doesn't do it. It never will. And since you never understood it, you can neither extend it nor replace it.

Authentication is the canonical example. Trivial to plug in, brutal to remove: it touches sessions, permissions, billing, personal data, compliance. What took ten minutes to install takes two months to dismantle.

Two questions before adopting anything:

Do I understand what this tool is doing for me?
Could I replace it if I had to?

Two "no" answers? That isn't a tool, it's a dependency whose exit price you don't know. That's not a reason to refuse it — it's a reason to know before, rather than during the incident.

AI-generated code didn't change the equation

An assistant now writes in seconds what used to take an hour. That shifts a lot of things. It doesn't shift one: someone remains accountable for what ships to production.

Generated code is a formidable accelerator for what you can review. It becomes a machine for producing debt by the kilometre for what you cannot — because it is plausible, well-formed, and wrong in ways a rushed human won't catch.

The rule that holds: don't merge what you couldn't debug at three in the morning. There is nothing anti-AI about it. It was already true for code pasted from a forum. Generation only raised the throughput — and therefore the stakes of review.

Tests aren't a cost, they're an alarm system

The "we don't have time to write tests" argument assumes tests exist to prove the code works. That isn't their main function.

Their function is to tell you when it stops working — six months later, in a module you weren't looking at, because of an apparently unrelated change. Without them, nobody tells you. Your users do, later, and less kindly.

One thing that's easy to forget: a test that cannot fail tests nothing. High coverage measures lines executed, not defects caught. The right question isn't "what percentage is covered?" but "if I deliberately break this function, does anything turn red?" If the answer is no, that test is lulling you to sleep rather than guarding you — and a verifier that lulls you is worse than no verifier at all.

The scout rule, applied to tooling

"Leave the campsite cleaner than you found it." Applied to code, that rule has a more demanding and more profitable version:

The second time a manual step repeats, it becomes a tool.

Not the first — the first time, you don't yet know the need is real. Not the fifth — by then the pain has become normal and nobody sees it any more. The second. That's the moment you know it will come back, and when automating it is still cheap.

This is where the two teams from the opening diverge. It isn't a question of talent, or moral discipline. It's an investment decision, repeated hundreds of times, each one taking about thirty seconds.

What this looks like in practice

At OmniRealm, this doctrine isn't a poster on the wall — it's wired in.

Tests aren't written by hand when a machine can generate their structure. Checks don't depend on the vigilance of whoever is committing: they run on their own, before code goes anywhere. Structural decisions don't live in one person's memory but in documents that a tool reads back and enforces.

And above all: when something goes wrong, the question is never "who forgot?" but "which mechanism should have caught this, and why didn't it exist?" A rule you merely write down is a wish. A rule a mechanism enforces is a guarantee. The gap between the two is exactly the gap between the two teams.

None of this is free. It gets paid in time, up front, across weeks where it feels like you're shipping nothing. That is precisely the investment a shortcut refuses to make — and precisely why it always ends up costing more.

Do this within 24 hours

Find one tool you use without knowing what it does for you. Just one.

Then decide: learn it, or replace it.

Don't let the third option happen by default — the one where you find out on a Friday night, in production, when the abstraction finally leaks.

This topic is also available as an audio episode: Ship Fast With Tools, Not Shortcuts.