We mock AI slop while enormous human organizations have been shipping their own for decades.
There has been a lot of hand-wringing lately about “AI slop.”
AI-generated websites. AI-generated code. AI-generated content. Interfaces that look vaguely right until you actually try to use them. Features that technically exist but clearly were not thought through. Products that feel like somebody typed a prompt, glanced at the result, and shipped it.
A lot of that criticism is deserved. But humans have been producing garbage software for decades, and sometimes they do it with resources an AI startup could barely imagine.
I recently encountered a particularly beautiful example from Enbridge, a company whose market capitalization was roughly $110 billion when I checked.
Enbridge Inc. market capitalization, the day I tried to pay my gas bill.
Pause on that number for a moment.
One hundred and ten billion dollars.
Imagine what you could build if you had access to even a tiny fraction of the resources available to an organization of that scale. You could hire elite engineers from anywhere in the world. You could maintain dedicated product, design, security, accessibility, QA, infrastructure, and customer-experience teams. You could test every workflow against every major browser, device, payment network, and authentication method. You could run usability studies until you were sick of usability studies.
You could build an extraordinary website.
Instead, Enbridge built one that will not let me use a password longer than 13 characters.
That is HumanSlop.
My Gas Company “Upgraded” Its Website
I ended up on Enbridge’s new site because I received notice that my existing online bill payment through my bank had been canceled. I already had a perfectly functional way to pay my gas bill, but Enbridge changed something on its end and forced me to migrate.
Fine. Systems change.
I went to the new site, tried to create my account, and was greeted with this:
Password cannot be longer than 13 characters.
The answer my password manager got back.
Thirteen characters.
In 2026.
We have spent years telling people to use password managers, generate long random passwords, and stop reusing short memorable credentials. My password manager did exactly what it was supposed to do and generated a strong password. Enbridge’s shiny new system responded, essentially:
Whoa, whoa, whoa. Not that secure.
This is not some ancient green-screen application sitting behind a mainframe. This is the new customer-facing website of one of the largest energy infrastructure companies in North America.
Again, consider the resources involved. A company this size can afford sophisticated identity infrastructure, penetration testing, security consultants, automated test suites, dedicated security engineers, and whatever authentication vendor it wants.
Somewhere inside all of that machinery, the final answer was:
Maximum password length: 13. Ship it.
And Then There’s the Design
Before you even hit the bugs, the site looks like it was rescued from a SharePoint migration in 2003.
Look at it.
A giant gray header. Tiny form fields. Underlined blue links. A sidebar box with “Sign In” and “Contact us.” Dense blocks of instructions. Hard borders. Tiny buttons. Layout decisions that feel less like a modern customer portal and more like something you would use to register for benefits from a county government office in 1998.
And somehow the page proudly says:
“Welcome to your new online experience!”
That line might be the funniest part of the whole thing.
New compared to what? Telnet?
This is a company worth roughly $110 billion, and its “new online experience” looks like the kind of website where you expect to see a blinking <marquee> tag and a “Best viewed in Internet Explorer 6” badge at the bottom.
The problem is not that every corporate website needs to look like Apple. It does not. A utility billing portal should actually be boring. It should be clean, fast, obvious, accessible, and almost impossible to screw up.
But this is not boring in the good way. It looks old because the information architecture, typography, hierarchy, spacing, controls, and interaction patterns all feel ancient.
And again:
$110 billion.
Imagine having even one billion dollars to build software.
You could hire some of the best product designers in the world. You could build a design system that works across every customer touchpoint. You could test the portal with thousands of real customers. You could make the login flow effortless. You could make the billing interface work beautifully on desktop and mobile. You could obsess over accessibility, performance, and usability until there was basically nothing left to improve.
You would not need a billion dollars to do any of this, of course. You could build a dramatically better version of this page with a tiny fraction of that.
That is what makes it so funny.
This is not a story about a company lacking resources.
It is a story about what happens when resources stop being the limiting factor and organizational quality becomes the limiting factor instead.
Then the Website Stopped Working
After working around the password requirement, I started getting generic failures:
“There’s a problem on our end. Please wait a few minutes, and try again.”
The other thing the new online experience does.
That is irritating on any website, but the context makes it worse. I did not voluntarily sign up to beta test Enbridge’s exciting new digital experience. My old payment workflow worked. Enbridge removed it and directed me to the replacement.
If you are going to force customers through a migration, the replacement should work.
This should not be a controversial product-management philosophy, especially when the company doing the migration is worth eleven figures.
The $110 Billion Company That Forgot How American Express Works
Eventually I reached the credit-card form. Enbridge displayed American Express as a supported card, so I entered my Amex information.
Then I reached the CVV field.
American Express uses a four-digit security code.
The Enbridge form allowed three digits.
I entered three numbers and tried to type the fourth. Nothing happened. The field simply refused it.
This is my favorite bug because of how beautifully uncomplicated it is.
There is no sophisticated edge case to debug. There is no race condition hidden inside a distributed system. There is no obscure browser incompatibility that only appears on Tuesdays when Mercury is in retrograde.
American Express cards have four-digit security codes.
If you say you accept American Express, your form needs to accept four digits.
That is the whole requirement.
A junior developer could understand it. A QA tester could catch it. An automated integration test could catch it. A product manager paying for lunch with an Amex could catch it.
Yet somehow this bug traveled through whatever engineering, vendor, design, QA, security, deployment, and approval machinery exists inside a $110 billion corporation and emerged alive on the other side.
That takes effort.
Seriously, Imagine What You Could Build With a Billion Dollars
A billion dollars is such a large number that it becomes abstract, so forget Enbridge’s $110 billion valuation for a second.
Imagine someone handed you one billion dollars and said:
Build the best utility customer experience on Earth.
What could you build?
You could hire 500 exceptional engineers at $250,000 a year and employ them for eight years.
You could assemble dedicated teams for product design, frontend, backend, security, accessibility, reliability, mobile, payments, customer research, analytics, QA, and infrastructure.
You could build full-scale testing environments that mirrored production.
You could test every payment method. Every browser. Every phone. Every accessibility scenario. Every authentication flow.
You could pay real customers to sit in a room and try to break the site all day. You could run usability studies across every demographic you serve. You could hire experts specifically to make sure people with vision impairment, motor disabilities, or limited technical experience could pay their gas bill without frustration.
You could build an app. You could build a world-class web experience. You could build APIs. You could create real-time billing forecasts, energy-use analytics, outage information, autopay controls, account sharing, alerts, notifications, and integrations with every major digital wallet.
You could probably rebuild the entire platform several times.
And after doing all of that, you would still have hundreds of millions of dollars left.
Now remember: Enbridge is worth roughly 110 times that amount.
Obviously market capitalization is not cash in the bank. Enbridge does not have $110 billion sitting in a vault waiting for someone to spend it on password fields. That is not the point.
The point is scale.
We are not talking about a startup founder with $40,000 left in the bank trying to keep the servers running.
We are talking about an enormous corporation with effectively unlimited access to the kinds of expertise required to solve these problems.
And the result is a website that looks decades old, rejects modern password lengths, throws generic server errors, and claims to support American Express while refusing to accept an American Express CVV.
That is not a resource problem.
That is Human Slop.
More Process Does Not Necessarily Produce Better Software
One of the strangest assumptions in software development is that more organizational process naturally leads to higher quality.
A giant company presumably has product managers, project managers, engineers, designers, security teams, QA teams, outside vendors, consultants, compliance processes, staging environments, deployment procedures, ticketing systems, and approval chains. All of that should theoretically make something like a payment form more reliable.
But complexity can also dilute responsibility.
The authentication team owns one piece. The payment vendor owns another. A frontend team owns the form. A design system dictates the component. Security has requirements. Product wrote the acceptance criteria. QA tested the documented cases. A contractor built some portion of it.
Everyone can do their assigned job correctly while the final product is still bad.
That is the part I find interesting.
No individual person necessarily decided to build something stupid. The organization produced stupidity collectively.
A system can go through layers of human review, planning, meetings, testing, procurement, and approval and still arrive in production unable to accept the security code for one of the credit cards it says it supports.
Money can buy talent, but it cannot guarantee ownership.
Money can buy process, but it cannot guarantee judgment.
Money can buy QA teams, but it cannot guarantee that anyone tested the obvious thing.
Sometimes all that process just makes the slop more expensive.
AI Slop at Least Has an Excuse
This is also why I find some of the outrage around AI-generated software amusing. We are judging technology that has existed for only a few years against human software organizations that have had decades to figure this out.
Of course AI produces bad code sometimes. Of course an agent can misunderstand a requirement. Of course generated interfaces can contain weird assumptions. Those are legitimate problems, and AI-generated software should absolutely be tested before it reaches users.
But what exactly is the excuse when hundreds or thousands of humans, mature engineering practices, enormous budgets, and decades of institutional knowledge produce the same result?
If an AI coding agent produced an Amex form that only accepted three digits, I could probably tell it:
American Express uses a four-digit CVV. Fix this and add a regression test.
There is a decent chance the problem would be fixed a few minutes later.
The giant human organization somehow managed to get the bug all the way into production.
The Real Problem Is Incentives
There is another reason my Enbridge experience bothered me more than an ordinary bad website: what exactly am I going to do about it?
If an online retailer makes checkout miserable, I can buy somewhere else. If a SaaS product gets progressively worse, I can cancel it. If a restaurant consistently gives me terrible service, I stop going.
Competition creates a brutal but effective feedback loop:
Make customers miserable long enough and eventually you lose them.
Utilities operate differently.
I cannot exactly announce that I am disappointed with Enbridge’s UX and ask another company to connect its competing natural gas network to my house.
What is my leverage here?
“Fix your website or I am taking my underground gas pipes to a competitor”?
When customers cannot easily leave, one of the strongest mechanisms for punishing bad software disappears.
That does not mean anyone at Enbridge deliberately decided that customer experience does not matter. I am sure plenty of people there care very much about producing good work. But incentives matter even when nobody explicitly talks about them.
If you cannot lose the customer, the pressure to delight the customer is simply different.
And sometimes you can feel that absence in the product.
These Aren’t Hard Problems
That may be what bothers me most.
None of my complaints involve difficult engineering.
I am not asking Enbridge to solve nuclear fusion.
I am asking it to:
- Allow modern password lengths.
- Keep its website functioning.
- Accept four digits in a four-digit CVV field.
- Build a customer portal that does not look decades old.
- Test the billing system before forcing customers to migrate to it.
These are solved problems.
A competent developer could fix some of them before lunch. A competent design team could make the entire interface feel modern without reinventing anything. A competent QA process should catch the Amex bug immediately.
And yet all of it survived all the way to production at a company worth tens of billions of dollars.
That should make us reconsider the assumption that the primary threat to software quality is inexperienced developers armed with AI.
Sometimes the inexperienced developer with an AI agent might actually notice the four-digit CVV problem.
Humans Don’t Get a Quality Pass
I am excited about AI-assisted software development. I also think we should be extremely critical of the garbage it can produce. Those positions are completely compatible.
Generated code needs review. Agents need tests. AI-created interfaces need real users. Companies should not ship garbage merely because generating it became cheaper.
But the standard needs to work both ways.
Software should not get a quality exemption simply because a model helped build it.
And software should not get a quality exemption simply because humans built it.
If we are going to mock AI systems for generating broken forms, nonsensical UX, security mistakes, and features that clearly were not tested, we should apply exactly the same standard to traditional software organizations.
Maybe an even higher one.
AI slop is produced by a technology we are still figuring out.
Human slop is produced after decades of knowing better.
The next time somebody shows me some ridiculous AI-generated application as proof that machines cannot be trusted to build software, I am going to remember the company worth roughly $110 billion whose new billing site thought my secure password was too long, whose “new online experience” looked like it had survived Y2K, and whose payment form thought my four-digit American Express CVV should somehow fit into three digits.
Imagine what you could build with a billion dollars.
Then imagine having access to the resources of an organization worth 110 times that and shipping this.
