How to tell if your software was built too fast.
Rushed software runs and demos well, then breaks in a handful of recognizable ways. The tells, each one a real shape we found cleaning up our own code.
Builds production software, and cleans up the AI-generated code that breaks it. pdflokal, his open-source PDF toolkit, is one of the repos these notes come from.
Software built too fast has a fingerprint. It runs, it demos well, and then it fails in a small number of recognizable ways. You do not usually need to read the code to spot them. You need to know the tells, and the tells are consistent, because fast building fails for consistent reasons: the code was optimized to look done, not to be done.
We spend a lot of time inside software other people built quickly, and inside our own. The tells below are not guesses. Each one is a real shape we found and fixed in the open, with a public commit behind it. If you inherited a build, commissioned one, or shipped one at speed, this is what to look for.
The tells
A green test suite next to a bug you can reproduce. The clearest tell. If the tests all pass and a user can still show you the thing that is broken, the tests are proving the wrong thing. In our own editor a blank-page bug survived for weeks behind a full green suite, because the tests checked that the parts existed, not that the right thing rendered. Green is a fact about the test, not the product.
It is janky or slow for no reason anyone can name. Fast builds are full of config that runs and runs wrong. A single line made our PDF engine render on the main thread for two months. No error, no failed test, just quiet jank nobody could explain. Unexplained slowness is usually not the framework. It is a setting that looks right and defeats itself.
The same crash keeps coming back in new clothes. If a bug gets patched, goes away, and returns a week later near where it was, the patches are at the wrong layer. We fixed three crashes with three guards that all held, while the real cause, unnamed, kept producing new ones. A recurring crash is a structural tell, not bad luck.
One file does everything. Open the repository and look for the biggest file. Fast AI building appends every new feature to the file already open, so one file grows to thousands of lines with no seams. Ours reached 3,634 lines. A file that large cannot be changed safely, and its size is the bill for the speed that built it.
The dangerous bug is in a boring place. The security and correctness holes in rushed software are rarely in the obvious, well-reviewed surfaces. Ours was a cross-site scripting hole in a toast message. Fast building means the small helpers ship unread, and unread is exactly where an unsafe default survives. When you audit a rushed build, start with the parts that look too small to matter.
What the tells have in common
Every tell points at the same thing. The speed came from making the software look finished: the passing test, the running config, the patched crash, the growing file, the helper that just shows a message. Each is the visible edge of the same trade, correctness deferred so the demo could ship today. That trade is not always wrong; sometimes shipping today is the right call. But it is a loan, and the tells are how you find out how large the balance is before it comes due.
None of this requires reading the source. If two or three of these are present, the build was fast and the bill is still outstanding. Finding out exactly how large it is, safely, is roughly what a teardown does.
How can you tell if software was built too fast?
By the fingerprint, not the code. Rushed software runs and demos well, then fails in a small set of recognizable ways: it passes tests but breaks on the real path, it runs but runs wrong, it crashes in the same place repeatedly, one file has grown to thousands of lines, and the risky bug hides in a helper nobody reviewed. You can spot most of these without reading the source.
What are the signs of rushed or low-quality AI-generated code?
A green test suite next to a bug users can reproduce; performance that is janky for no clear reason; the same crash patched again and again; a single enormous file with no seams; and correctness or security holes in the boring, unreviewed corners. Each is a symptom of the same cause: the code was optimized to look done, not to be done.
Does software that was built too fast cost more later?
Usually, yes. The speed is borrowed, and the interest is paid in refactors. In our own product one AI-grown file reached 3,634 lines and a single cleanup pass removed over two thousand lines of dead code. Adding it was fast; proving it was safe to remove was slow. The bill comes due for whoever holds the code, which is rarely the person who typed it.