Tests Were Always the First Thing Cut. Nobody Repriced Them.

A support fix went out on one of our builds with 31 automated tests attached to it. Nobody asked for 31 tests. They were not in the scope, not on the invoice, and not in any conversation with the client. The same day produced a rebuilt user management screen, a password reset flow that had not existed before, and two security gaps closed. The tests were the part of that day that would have been impossible to justify three years ago on a project that size.

That is worth sitting with, because on a fixed-scope MVP the automated test suite has always been the first thing to go.

The old math was honest

If you have ever run a small build, you know the trade. A founder is paying for a specific number of weeks. Every hour is visible, and every hour is competing against a feature the founder can see. Writing tests produced nothing clickable. It did not move a demo forward. It could not be shown to an investor. And it cost a meaningful slice of the engineering budget, because a human being had to sit down and write each one by hand.

So the test suite got traded. Every time. Not because anybody was lazy or careless, but because the trade was correct at the prices involved. "We will add coverage when there is traction" was a defensible answer, and any shop that told you otherwise was either charging you for it somewhere else or not telling you the truth about the schedule.

The result is a whole category of software that works and cannot be verified. It runs. It has always run. Nobody knows what happens if it stops.

What actually got cheaper

The interesting thing is not that AI writes code faster. That part is real but it is also everywhere, and most of it is oversold. The interesting thing is that AI did not lower the price of all engineering work by the same amount, and tests happen to sit at the far end of the curve.

Feature work has taste in it. Someone has to decide what the screen should do, what the edge cases mean for the business, which of four reasonable behaviors is the one this particular company needs. A model can produce a version of that quickly, but a person still has to sit with it and decide whether it is right, and that sitting is most of the cost.

A test is different. The specification already exists. It is in the code, in the schema, in the shape of the route. The work is mechanical, high volume, and self-verifying: you run it and it either passes or it does not. There is no debate about whether the assertion has good taste. This is the exact shape of work that models are good at, which means the price of a test suite fell further and faster than the price of the feature it covers.

Almost nobody has rerun the trade since. Founders are still being handed estimates where testing is a line item that got struck through, and the reason it was struck through has quietly stopped being true.

The way this goes wrong

Here is the honest half, because a post that only says "AI writes your tests now" is selling something.

When a model reads your code and writes assertions against it, the default output is a set of tests that prove the code does what it does. That is a photograph, not a check. If the function calculates the total wrong, you now have a test that confirms it calculates the total wrong, and it will turn green forever while the number stays wrong. Tautological tests are worse than no tests, because no tests make you nervous and green tests make you confident.

So the part that stayed expensive is deciding what the tests are about. Our own list is short and it is not about coverage percentage. It is about the things that are expensive to get wrong quietly: who can see what, who can do what, anything that touches money, and anything that writes to a record somebody else owns. In the support week above, the tests that mattered were the ones covering the invitation path and the two gaps we had just closed, not the ones covering the layout of a settings screen.

A person picks that list. A model writes the 31 tests underneath it in an afternoon. That division is the whole trick, and it is why "we use AI" is a weaker claim than it sounds.

The reason this matters more than quality

Quality is the obvious argument and it is not the best one.

We build first versions. Part of our pitch is that we are a clean starting point, not a permanent vendor, and that when a client outgrows us there should be a real handoff to a real engineering team. Which means we think a lot about what a codebase communicates to the people who inherit it.

Documentation does not communicate. A README rots silently. A Notion page describing how the permissions work is accurate on the day it is written and slowly stops being accurate, and nothing anywhere announces the moment it becomes a lie. Every engineer who has joined a company has been handed a document that was confidently wrong.

A test suite is the only documentation that fails loudly. A test that describes behavior the software no longer has goes red on the next commit. It cannot quietly become false. So a cheap test suite buys something beyond confidence in today's build: it buys the next team a description of what this software is supposed to do, written in a form that maintains itself.

For a founder, that is the difference between a handoff and a salvage operation. It is also the difference between a product that grows and a product somebody rebuilds in eighteen months because nobody could work out what was safe to change.

What to do with this

Two things, and neither of them requires you to become technical.

First, if a development partner tells you there is no room in the budget for automated testing, that is not automatically wrong, but it is an answer that was priced in a different era. Ask them when they last checked. A shop that has actually rerun the numbers can tell you what changed and where they still write tests by hand. A shop repeating a line from 2023 is telling you something about how closely they are watching their own craft.

Second, replace the question. "Do you write tests?" invites a yes and a coverage number, and coverage is a measure of volume, not judgment. Ask instead what their tests are about. If the answer is a percentage, you have learned nothing. If the answer is a list of the things that would be expensive to get wrong without anyone noticing, you have learned that somebody there is thinking.

The broader point is not that AI made your build better. It is that AI made one specific line item cheap, and that line item happened to be the one every small build has sacrificed for a decade. The sacrifice is no longer required. Most estimates have not caught up.

Go look at yours.