Why Florida’s AI-built software keeps looking finished before it is
There is a particular moment happening in conference rooms from Miami to the Space Coast right now. Someone opens a laptop, shows a working screen, clicks through three or four steps, and everything responds. The room reacts the way rooms always react to working software. Timelines get shortened. Headcount gets questioned. Someone says the word “shipped.”
Two weeks later, the support queue explains what actually happened.
This is the defining pattern of the current wave of AI-assisted development, and Florida’s technology sector — a mix of Tampa Bay SaaS shops, Orlando simulation and modeling firms, Jacksonville fintech, Miami startups, and a very large population of small businesses buying software built by two people and a subscription — is running straight into it. The problem is not that AI writes bad code. Much of it is clean, well-formatted, and properly commented. The problem is that AI-assisted development produces a sensation of progress that runs well ahead of measurable progress, and almost nothing in the normal workflow corrects for that.
The perception gap is real, and it has been measured
In July 2025, the nonprofit research group METR ran a randomized controlled trial with sixteen experienced open-source developers working on 246 real tasks in codebases they already knew well. The developers predicted AI tools would speed them up by roughly 24 percent. Afterward, they estimated they had been about 20 percent faster. The clock said they were 19 percent slower.
The headline number is not the interesting part. METR itself has since labeled the result historical, and a 2026 follow-up ran into selection effects that muddied the picture — developers who most benefited from AI were reluctant to participate in sessions where they might be forbidden from using it. Anyone quoting “19 percent slower” as settled science in 2026 is overreaching.
The finding that survived is the one that matters here: self-reported speed and measured speed pointed in opposite directions, and the developers could not tell. They had just finished the work. They still guessed wrong, in the wrong direction, by a wide margin.
METR’s proposed explanation is worth sitting with. Code generation is fast, visible, and memorable. Review, correction, integration, and debugging feel like ordinary engineering work rather than costs attributable to the tool. The fast part gets remembered as the tool’s contribution. The slow part gets remembered as just Tuesday.
That is the mechanism behind the demo that dazzles and the product that limps.
The power tool standard
Consider a cordless drill. It is a genuinely transformative tool — but only because it works every single time you pull the trigger. A drill that fires on 95 percent of pulls is not 95 percent of a drill. It is worse than useless, because now every hole requires a hesitation, a second attempt, a backup plan, and a mental note about which surfaces you cannot risk it on. The tool no longer removes work; it adds a category of work that did not exist before. You would take it back to the store.
Software carries the same threshold, and most teams evaluate it against a far more forgiving one. “It worked when I tried it” is the 95-percent drill. An intake form that fails on hyphenated last names, a scheduling tool that breaks the week Daylight Saving shifts, a payment flow that silently drops the transaction if the customer’s session expires mid-checkout — none of these show up in a demo. All of them convert a labor-saving tool into a labor-generating one, because now a human has to check every result, and checking every result is the job the software was bought to eliminate.
Partial reliability in software is not partial value. It is often negative value, because it also carries the cost of the trust it destroyed.
What’s actually underneath the failures
Dig into why an AI-assisted app breaks in production and you almost always find the same thing: the task was more complex than it looked at the moment someone typed the prompt.
A prompt describes the happy path — the sequence of events where everything goes right — because that is how humans naturally describe what they want. What the prompt does not describe, and what the requester frequently does not yet know, is everything else:
- Edge cases in the data. Real Florida customer data includes accented characters, apostrophes in surnames, PO boxes, seasonal-resident dual addresses, and phone numbers entered eleven different ways.
- State and concurrency. Two users editing the same record. A form submitted twice because the first tap seemed unresponsive. A job that runs while the previous one is still finishing.
- Failure paths. What happens when the third-party API times out, returns a 500, or returns success with an empty body?
- Scale. Code that is fine against 50 test rows and unusable against 500,000 production rows.
- Integration with what already exists. The legacy system, the accounting export format, the county’s file naming convention, the permissions model.
- Non-functional requirements. Authorization, audit trails, retention rules, accessibility, and — for anyone touching health data or insurance in this state — actual regulatory obligations.
Independent measurement suggests these gaps are compounding rather than shrinking. GitClear and GitKraken, analyzing hundreds of millions of real code changes from 2023 through 2026, found code duplication up sharply and refactoring — the act of reworking existing code rather than adding more alongside it — down dramatically. They also flagged a rise in code that catches errors without addressing their cause, which produces exactly the shallow, confusingly-behaved apps described above. Google’s DORA research has separately associated rising AI usage with reduced delivery stability.
The pattern is not “AI writes broken code.” It is “AI writes plausible code that adds volume faster than it adds structure, and volume without structure is where failures hide.”
Testing is the part that was skipped, not the part that comes later
The corrective is unglamorous and well understood: adversarial testing before declaring victory, not after complaints arrive.
That means testing what the app does with garbage input, not just correct input. Testing with production-scale data volumes. Deliberately breaking dependencies — kill the network, expire the token, return malformed JSON — and watching what the app does. Handing it to someone who was not in the room when it was built and did not read the prompt, then watching silently while they try to use it. Checking the error paths, which is where AI-generated code is weakest, because error paths are precisely what a happy-path prompt never mentioned.
And critically: treating “the code runs” as the start of evaluation rather than the end of it.
The Florida stakes
This is not an abstract quality-of-craft argument in a state where software failure has a physical dimension.
Hurricane season is underway. Emergency notification systems, shelter locators, and utility outage maps are load-tested by reality on the worst possible day, with no warning and no opportunity to patch. Property insurance technology processes claims for people whose roofs are gone. Health systems serving one of the country’s largest elderly populations run on scheduling and records software where a silent failure is a missed appointment for someone who cannot easily reschedule. Orlando’s defense and simulation cluster builds systems where “works most of the time” is not a category that exists. Tourism operators lose the booking, and the customer, permanently.
None of this argues against AI-assisted development. The tools are real and the leverage is real. It argues against the specific failure mode of mistaking generated code for finished software, and mistaking the feeling of speed for the fact of it.
The demo is evidence that the code compiles. The stress test is evidence that you have a product. Florida teams that keep those two things straight will ship things that hold. The ones that do not will keep shipping drills that fire 95 percent of the time — and keep wondering why customers stopped picking them up.
About the Author
