When Software Ships Faster Than Anyone Can Check It

Let's start with the good news, because it is real and it deserves to be said plainly. Work that used to take a software team an entire quarter can now take days. Not a demo. Not a mockup. A working feature, wired to real data, with tests around it and notes explaining how it works.

We wrote earlier about how AI is changing software development in general. This is the part that comes next, and it is the part most owners are not being told: when building gets this fast, the risk in your software moves. It does not disappear. It moves. It used to live in “we could not build it in time.” Now it lives in “we built it, and nobody noticed what was wrong.”

What genuinely got faster

It helps to be specific, because the hype is vague on purpose. Here is what actually collapsed in cost:

• First drafts. A screen, a form, a report, a settings page. The first complete version of almost anything now arrives in an hour or two rather than a week.
• Plumbing. The unglamorous connective work between the database, the server, and the screen. It is repetitive, it is most of a codebase by volume, and it is now close to free.
• Tests and documentation. The two things every team skipped under deadline pressure. They got cheap enough that skipping them is now a choice rather than an excuse.
• Database changes. Adding a field, reshaping a table, moving old records into a new format. Careful, fiddly work that used to eat days.

And here is what did not get faster at all, not by a single minute:

• Deciding what to build. Knowing what your customers actually need, as opposed to what they said in a meeting, is still a human conversation.
• Judging whether it is correct. Someone still has to look at the result and know, from experience, that it behaves right for everyone and not just for the person looking at it.
• Owning the consequences. When something breaks in front of a customer, the explanation is never “the tool wrote it.” A person with a name still answers for it.

The bottleneck that never moved

Here is the idea the whole article rests on. Writing code was never the bottleneck that mattered most. Checking it was.

Think about a kitchen. Speeding up the chopping does not let you serve more meals if one person still has to taste every dish before it leaves. AI made the chopping close to instant. The tasting takes exactly as long as it always did, because tasting is attention, and attention does not scale.

When code is produced faster than any human can read it, the gap between “written” and “verified” becomes the place where problems live.

That gap is why a fast team can accumulate what we think of as invisible debt. Not messy code, which at least announces itself. Something quieter: things that look finished, sit in the menu, appear in the demo, and do not work. Nobody wrote them badly on purpose. Nobody checked them either.

Five ways fast software fails quietly

These are patterns, not accusations. They show up across the industry, in products built by careful people, because they all share one trait: nothing crashes. Nothing turns red. The software behaves as though everything is fine.

1. Doors that look locked

A screen checks that you are signed in. It never checks whether you are allowed to see that. So anyone with an account can reach information meant for a few people: salaries, other customers' records, internal notes.

Picture an office building where your badge opens the front door. That part works, and it feels like security. What nobody tested is that the same badge also opens every office inside, including the ones with the filing cabinets.

How you catch it: log in as your most restricted user, then try to open a page or a record that belongs to someone senior. If it opens, the lock is decorative.

2. Features that never worked at all

Not a feature that broke. A feature that has never once worked. A form that has always failed to save. A list that has always come back empty. Usually because a rule was added later somewhere else, and nothing went back to recheck the screens that depended on the old rule.

These survive for months because of a very human reflex: the people who needed the feature assumed they were using it wrong. They found a workaround, a spreadsheet, a phone call, and stopped mentioning it.

How you catch it: pick the features nobody ever talks about and try to complete each one end to end, all the way to seeing the saved result come back.

3. Screens that show pretend data

During the design phase, someone fills a dashboard with plausible sample numbers so the layout can be reviewed. That is normal and useful. What happens next is the problem: the screen is approved, the project moves on, and the page is never connected to real data. Months later it is still in the live menu, showing the same authoritative-looking numbers to everyone who opens it.

It is a speedometer glued at sixty. The needle is steady, the dial is convincing, and it is not attached to the wheels.

How you catch it: change something real in the system, then check whether the number on the screen moves. If it does not move, it was never listening.

4. Things that work for you and fail for everyone else

Software is usually tested by the person who built it, and that person almost always has the highest level of access in the system. Everything opens for them. So the version a regular employee sees, with fewer permissions and different data, is never actually looked at. It can be broken, or empty, or missing half its buttons, and nobody with the power to fix it ever sees that screen.

It is the restaurant owner tasting a meal in their own kitchen, at their own table, with the good cutlery, and concluding that dinner service is going well.

How you catch it: ask for a walkthrough performed in an account that has the least access, not the most. Watch that session, not the polished one.

5. Settings that are written but never take effect

A protection exists. It is written down, it reads correctly, anyone reviewing it would nod. And somewhere else in the system, a second instruction quietly cancels it out. The rule is present and does nothing. This is the hardest one to find, because reading the software tells you it is protected. Only running it tells you the truth.

Think of a smoke alarm that is mounted, wired, and labelled, with the battery compartment empty. Everything about it says “protected” except the part that matters.

How you catch it: do not ask whether the rule exists. Ask someone to demonstrate it stopping something. A rule you cannot watch fail is a rule you do not have.

And a sixth: work that never reaches anyone

Worth mentioning because it is so easy to miss. A feature is finished, approved, and correct, and it never reaches customers, because the process that pushes new versions live is broken on something unrelated. Everyone is watching the work. Nobody is watching the delivery. Weeks of finished software can sit one step short of the people it was built for, and the only symptom is a vague sense that the product is not changing much.

Ten records is not a hundred thousand

One more failure worth understanding, because it arrives late and all at once. Software built quickly is usually built against a handful of test records. With ten customers on file, almost any approach feels instant, including some genuinely wasteful ones: loading every record in the database to show the first twenty, searching without the equivalent of an index at the back of a book, never breaking a long list into pages.

None of that hurts at ten records. At a hundred thousand it is the difference between a page that opens now and a page that opens in forty seconds, or not at all. The fix is usually cheap when done early and expensive when done in a panic, so it is worth asking the question before launch rather than after: has anyone run this against a realistic amount of data?

What good looks like now

If building is fast and checking is not, then checking is the job. That is the whole adjustment. A team that has made it has these habits, and you can ask about every one of them without knowing anything technical.

• Review what was built, not just whether it runs.“It works” usually means “it did not crash.” Ask what was checked, not whether it loaded.
• Test as the least privileged user. Every demo should be given from the account with the fewest permissions. It is the fastest way to find both the locked-door problem and the works-for-me problem.
• Test from a cold start. Open the feature the way a new customer would, fresh, from the front page, on a device that has never used it. Not from the screen that is already open on the developer's second monitor.
• Have someone other than the author look. The author and the AI are, at this point, the same reviewer twice. A second person who did not write it is the cheapest quality tool that exists.
• Keep a real place to test. A separate copy of the system with realistic volumes of data, where things can be tried and broken safely before customers see them.
• Watch the release, not just the code. Someone should be able to tell you, today, when the last successful release went out and what is currently waiting.

Turned into questions you can put to your team or your vendor, on any project, at any stage: Who checked this besides the person who wrote it? Can you show me this working in an account with the lowest access? Is this screen reading real data, and can we watch a number change? Can you show me this rule blocking something? When did the last release actually reach customers? None of those require you to read a line of code, and all of them are hard to answer vaguely.

Speed is worth having

We want to be clear about where we land. The speed is real, we use it every day, and we would not go back. Ideas that were once too expensive to try are now cheap enough to test in an afternoon. Small teams genuinely ship what large ones used to. That is a good decade to be building software in.

But speed on its own is just motion. What turns it into something you can trust is the unglamorous half: someone looking carefully, from the outside, as the least powerful user, at the thing that was just built. That habit is now the difference between a product that moves fast and a product that moves fast in the right direction.

If you own software and any of the five patterns above sounded uncomfortably familiar, it is worth having someone look. If you are about to build something, it is worth deciding up front who does the checking. Either way, let's talk, or see what we've built.