DEV Community: Regis Wilson

The Neo Fermi/Wilson AI Paradox

Regis Wilson — Fri, 28 Aug 2026 23:25:17 +0000

The original Fermi paradox asks:

If intelligent alien civilizations should be abundant, where is everybody?

The Neo-Fermi/Wilson paradox asks:

If AI is producing enormous quantities of excellent software, where is all the excellent software?

We are told that implementation has been transformed: agents write code, discover defects, review changes, operate continuously, preserve memory, evaluate one another, and improve the factories that produce still more agents and software.

Yet the visible world remains curiously familiar. We use largely the same products, through largely the same interfaces, to perform largely the same tasks—now surrounded by more code, automation, observability, governance, tickets, and electricity consumption.

This does not prove that AI produces no value. It asks where the claimed abundance becomes observable as outcomes rather than activity.

Steelmen and Straw Retorts

The steelmen are serious arguments. The retorts are deliberately unfair, compressed, and argumentative.

1. Invisible improvement
Steelman:
The new software is everywhere, but most of its value is invisible. Existing systems are becoming more reliable, secure, maintainable, performant, and efficient. Users do not notice successful infrastructure; they notice only failures.

Straw retort:
Is it, though?

2. Tools before products
Steelman:
We are building the tools that will enable the next wave of software. Foundational technologies arrive before their most important applications. Better agents, evals, memory, orchestration, and software factories are necessary infrastructure, even if their eventual products are not yet visible.

Straw retort:
We have been building the tools that will build the tools that will build the next wave since 2022. It is now at least 2026. At what point does a wave have to contain water?

3. Silent compounding
Steelman:
AI is making everything incrementally better: development is faster, incidents are diagnosed sooner, systems are optimized more aggressively, and small usability improvements accumulate across the economy. No single change looks revolutionary because the benefits are distributed and continuous.

Straw retort:
That must be why GitHub keeps crashing.

4. The growing iceberg
Steelman:
The visible product is only the tip of the iceberg. Beneath an unchanged interface is a rapidly expanding industrial base: generators, agents, tests, deployment systems, security controls, observability, and automated remediation. The visible tip can remain stable while the supporting capability grows enormously.

Straw retort:
We rebuilt it in Rust. The product is exactly the same; the iceberg is ten times larger and will now grow a thousand times faster. With type and memory safety and more AI.

5. The automobile analogy
Steelman:
Early cars were slow, inefficient, unreliable, and lethal. Modern cars may look conceptually similar: four wheels, seats, and a steering wheel; but they travel comfortably at highway speed, achieve far better fuel economy, and protect their occupants. Transformative progress can become invisible once people normalize it. Software may be improving in the same way.

Straw retort:
So we still watch cat videos, but now the data centre uses ten times as much electricity to recommend the next one.

6. Product, not implementation, is the bottleneck
Steelman:
AI may have substantially reduced the cost of implementation without solving product discovery. Humans and institutions cannot instantly invent, understand, adopt, regulate, or monetize entirely new software categories. Users prefer familiar interfaces and workflows, while businesses must compete within markets already shaped by incumbents. The bottleneck has moved from writing software to deciding what should exist.

Straw retort:
So implementation is solved, but civilization failed to provide a sufficiently imaginative backlog.

7. Organizational absorption takes time
Steelman:
Even when the technology works, organizations need years to change processes, incentives, staffing, architecture, procurement, and regulation. Electricity and computers also took decades to reorganize industry. Measuring AI’s effect before institutions have adapted will understate its eventual importance.

Straw retort:
The revolution is complete except for all the places where reality would reveal it.

8. Output is being consumed internally
Steelman:
Much of the new software is not a public product. It handles migrations, compliance, testing, support, fraud, analytics, internal operations, and countless organization-specific tasks. These systems create real economic value without appearing in an app store or changing a consumer interface.

Straw retort:
The missing great software became paperwork about the great software. And the documentation about the paperwork is being read and reviewed by AI documentation preparers who write the paperwork.

9. Factory administration is legitimate production
Steelman:
Automating the software factory is not empty recursion. Better monitoring, evaluation, cost control, and remediation make every later product cheaper and safer. Industrial revolutions require machine tools, standards, logistics, and quality control—not merely finished consumer goods.

Straw retort:
“What does your software factory produce?”
“Software factories.”

10. Demand expands with supply
Steelman:
Cheaper software does not necessarily reduce spending or complexity. Jevons-style effects mean that when implementation becomes cheaper, organizations attempt more projects, add more features, and automate previously neglected work. The result can be much more software without a proportionate reduction in cost or headcount.

Straw retort:
Everything is more. Victory has been declared over the absence of less.

11. Quality is improving faster than expectations
Steelman:
Users continually raise their expectations. Yesterday’s impressive speed, availability, personalization, and polish become today’s baseline. AI-generated improvements may be real but hidden by an expanding definition of acceptable software.

Straw retort:
The software is getting better at exactly the rate required to remain disappointing.

12. We are looking in the wrong place
Steelman:
The important applications may not resemble traditional software products. AI could be transforming scientific research, logistics, chip design, medicine, finance, and operations while public attention remains fixed on websites and chat interfaces.

Straw retort:
The aliens are definitely here; they just work in internal tooling and cannot be shown because of an NDA.

13. The one that will get me fired
Steelman:
With fewer people, we can still perform the same valuable work. That frees human time and creativity for family, art, community, and the American ideals of life, liberty, and the pursuit of happiness.

Straw retort:
Everything except the life, liberty, dignity, income, structure, community, and occasional joy of having a job.

The Cosmic Version

The strongest product-bottleneck defense creates a pleasing extension of the original Fermi paradox:

Perhaps every alien civilization develops interstellar travel, looks around, sees nobody at home, and leaves to search for everyone else. Each civilization eventually arrives at another civilization’s planet only to discover that its inhabitants also departed to look for aliens.

The galaxy is not empty. Everyone is out at Marks and Sparks.

Likewise, perhaps the great AI-generated software exists, but all of it is busy building tools, factories, evals, agents, and observability for the next generation of great software. Every factory is operational. Every loop is closed. Every agent is improving another agent.

Nobody stayed home to make a chair.

Summary

Notice that none of these steelmen can simply say: “Here: here is one piece of genuinely great software produced by AI. You can see it, use it, and judge the result for yourself.” Every defense instead relocates the evidence: beneath the interface, inside the organization, somewhere in the infrastructure, still compounding, awaiting adoption, or building the factory that will eventually produce it. Perhaps those explanations are true. But their necessity is the paradox.

The paradox is not answered by code volume, agent activity, token consumption, pull-request throughput, or the number of autonomous loops. It is answered by observable outcomes:

capabilities that did not previously exist;
products that small teams could not previously build;
substantial reductions in cost, latency, or failure rates;
materially better user experiences;
scientific or operational results achieved faster;
and software that people voluntarily adopt because it improves their lives.

Until those outcomes become commensurate with the claims, the question remains:

If the software factory is producing so much excellent software, where is it all?

Human note: AI wrote this after several rounds of steelman arguments and strawman retorts, most of which I conceived and answered myself. This is not an ironic disclaimer; irony would require it to mean the opposite. It is simply the mundane truth of how the piece was produced. So the first clearly visible product of great AI software is persuasive copy explaining why its other products remain invisible.

Photo by Vadim Bogulov on Unsplash

AWS Outpost and RDS: Reslotting Checklist

Regis Wilson — Fri, 26 Jul 2024 00:35:48 +0000

Overview

At Underdog, we use Amazon Web Services’ (AWS) Relational Database Service (RDS) and Elastic Kubernetes Service (EKS) (among many other services) to power our sports betting applications. Most readers will be readily familiar with these services and if you aren’t, I will explain most of the terms and technologies briefly as we go. What will be different about this post is a recent AWS service we’ve been using in conjunction with these two (RDS and EKS) called AWS Outpost.

In order to meet United States state gaming regulations and requirements, we use Outpost to meet data and application security residency requirements in particular states where we operate. Outpost is great for delivering compute and storage services close to a region where we operate that might be outside of Amazon’s many regional centers.

This post will detail some of the challenging aspects of running and operating these services that we had recently and hope that the experience will enlighten you, the dear reader, if you ever need to venture down this road in the future. If you are already familiar with configuring and operating these services together, you might also enjoy reading it with the pleasure and satisfaction of schadenfreude.

AWS Regions and Outpost

If you are unfamiliar with Outpost (as I was initially), you may wonder what the service is and why Underdog chose to use it. In simple terms, you may already know that AWS regions are spread across the globe in various countries to offer services that are close to major population centers so that AWS’ cloud services can be placed closest to the most consumers. Inside each country, as in the United States, there are several regions located inside several states, for example Virginia (us-east-1), Ohio (us-east-2), and Oregon (us-west-2), among others.

What happens if Underdog wants to operate services inside a state that is not listed as an AWS region but, never-the-less, wants to collocate cloud services within the borders of a particular state? There are many options to independently host our own hardware and networking gear, but we wanted to continue to enjoy the automation and speed of deploying Infrastructure as a Service (IAAS) via Application Programming Interfaces (APIs) and so-called Infrastructure as Code (IAC). This is where the promise of AWS Outpost comes into play.

With AWS Outpost, customers like us can order capacity from AWS and deploy it into the hosting facility of our choice, along with connectivity from AWS Direct Connect or VPN services to provide a regionally-located service in a particular location that we need to operate in. While the capacity for Outpost is inherently limited, and also is not “instantly” deployable or provisioned like other services, at least we do not need to directly manage infrastructure, networking, security, or software ourselves. Also, any services that are provisioned inside the Outpost will be managed by the same AWS APIs and dashboards that we are already using. Most importantly, the resources inside the Outpost can be shared by our staging and production AWS accounts and Virtual Private Clouds (VPCs) in a relatively seamless and integrated way to operate from a location outside an established AWS region.

Getting Familiar With Outpost

As with all AWS services, it is important to know what the services’ strengths, weaknesses and limitations are. It is also important to understand how one or more services may (or may not) interoperate together! This is where the majority of our problems originated as we went into provisioning our applications in a remote environment. In terms of provisioning Elastic Cloud Compute (EC2) services that we can use as nodegroups in EKS, this is a relatively understood solution and works well with Outpost configurations. What isn’t as directly easy to understand or configure was the RDS integration with Outpost and we ran into issues with some basics like choosing instance sizes and using instances in Outpost with RDS.

The first issue we encountered initially was choosing the correct capacity and sizing of instances for both compute and RDS instances. If you are spoiled by AWS’ amazing depth and breadth of instance sizes, architectures, and variety, you will need to reorganize your thinking around a fixed set of capacity and architecture limitations for your Outpost racks and/or servers. As an example, let’s say that you have one rack with 4 each m5.24xlarge “raw” capacity. You could subdivide that capacity as you saw fit, let’s say that you started conservatively (as we did) with way too large of instance sizes as 8 each m5.12xlarge instances, spread across staging, production, RDS, and EKS as follows (please note all drawings are for illustrative purposes only and should not be relied upon for factual reference):

This seemed like a reasonable starting point for us and would allow us plenty of capacity and resources to operate without worrying about needing more vertical scaling capacity. With this setup, we were able to successfully launch services relatively quickly and simply, all options considered.

Right Size Scaling

If you are familiar with AWS services, you may now be thinking to yourself, as we later did, “Whoah, this seems like a lot of capacity to use for RDS and EKS!” The truth is that if we had more time, insight, and experience, we might have been able to come up with a much better provisioning scheme to right-size the capacity for each use case. The engineering issue isn’t so much the large over-allocation of capacity (which is a concern), but rather the operational downstream issues such as having spare capacity, being able to migrate or upgrade services and versions, and being able to scale horizontally (instead of vertically) as needed to meet demands.

After some post-launch issues were settled, we analyzed the data and came up with a much more reasonable allocation scheme that would suit our needs now and in the future. We settled on something that looked more like the following drawing.

You will notice that we have much more reasonably-sized (but still beefy) m5.8xlarge RDS databases. We also have enough capacity to add more RDS replicas (or new primaries even), and plenty of application-worthy EKS worker nodes for redundancy and failover. Not only that, but we now have way more free “spare” capacity for future needs as either smaller RDS databases or as beefier EKS workloads emerge.

Armed with this new information we let our AWS representatives know about our plans and future configuration. We had a pretty good idea of the plan of operations and had laid out a strategy for performing the changes “in place” with a reasonable amount of downtime during a maintenance window.

Best Laid Plans of Mice and Men

Experts in RDS and Outpost may already see the issue we were going to find ourselves faced with and will be chuckling to themselves, but this was the original plan we were going to follow to migrate from the original configuration to the new capacity configuration. We had consciously chosen the shortest amount of time that the maintenance window would occur to re-slot the entire Outpost rack in one window without causing undue issues affecting both staging and production. We did not have multiple Outpost racks available to work with; but this is something we definitely will consider in the future.

See if you can spot the issue:

Initiate downtime maintenance window in the application by shutting down all application services and issuing maintenance page notifications
Temporarily stop staging RDS instances and EKS worker nodes
Take snapshots for disaster recovery purposes
Temporarily stop production RDS instances and EKS worker nodes
Take snapshots for disaster recovery purposes
AWS support will apply new Outpost reslotting configuration
Restart staging and production RDS instances with new sizes
Restart staging and production EKS worker nodes and join to clusters
Test and validate the applications
End the maintenance window and allow normal operations

If you spotted the issue in step 7 labeled “restart staging and production RDS instances”, congratulations! For everyone else, you can follow along and learn from our experience when you attempt to do this yourself.

You Can't Modify a Stopped DB Instance.

This statement from the AWS documentation should be tattooed on the forehead of any AWS RDS practitioner – in reverse so that they can read it in the mirror. Or, perhaps, both forward and reverse for people who look at the tattoo and for themselves looking at it in the mirror. The issue we immediately faced as we tried to start the new instances was that the previous db.m5.12xlarge instances were not available any more in our Outpost configuration, so we could not start the RDS instances. We also could not convert the instances into the new db.m5.8xlarge instances sizes that did exist in the new configuration since the databases were shut down!!

I’m not exaggerating too much when I say that I briefly considered the fact that we had made a fatal mistake and were going to be down in production for hours doing a disaster recovery at this point. It is very important in these situations not to panic but to stay calm, talk through your options, and decide on a safe course of corrective actions.

Fortunately, we had the following in our favor, which you should also have at your disposal if you attempt anything like this. We made sure we had an AWS representative and AWS support people on the call while our maintenance window was active and the team on our side were engaged. This enabled us to get real time feedback on the reslotting process, get answers to RDS and Outpost answers from AWS, and also (critically) allowed us to reconfigure the capacity online while we were in the midst of trying to salvage our operations. If you do not have enterprise support, then you will most likely not be able to resolve a situation like this. Nor should you even attempt to do something like this without enterprise support obviously.

Failure is Not an Option

We quickly broke out our calculators, slide rulers, and pocket pens to come up with an emergency configuration that would enable us to start both db.m5.12xlarge and db.m5.8xlarge target instance capacity at the same time. It was like that scene in Apollo 13 where Ed Harris says that we’ve never lost a database in the cloud and we were going to use everything at our disposal to figure out a solution. We were able to come up with the following configuration to solve our issue.

Fortunately, we had enough of the “spare” capacity to configure as RDS interim instances. Later on, AWS could then reslot the unused capacity back into our spare capacity as needed. There was a huge sigh of relief as the configuration was reslotted and the databases were started, modified to new instance sizes, then rebooted as the correct target instance size!

Summary

In summary, we learned quite a bit and hope that you have too, if you have any plans for Outpost capacity in your future. In no particular order these lessons are:

Always plan, check your plan, recheck your plan, and have a backup plan
Always work closely with your AWS support and representatives to avoid problems like this if you can, and have them available when you need them in advance
Always stay calm and consider your options. Stick to the plan but react appropriately when circumstances change
Read your documentation and pay close attention to every detail as it impacts your planned path
When migrating capacity, ensure enough spare capacity is available both before, during, and after your migration plans
Use multiple phases of the migration plan where possible; consider initial phases, interim phases, and final phases
Please, please, please give your AWS support people and representatives a big show of appreciation for their hard work, dedication, and help!

About the Author

Regis is a staff platform engineer at Underdog. He has designed, built, and operated cloud-native architectures since 2015.

We're Hiring!

If you want to work on exciting projects like these with exciting people like me, please check out our hiring page

Image Credit

Photo by Torsten Dederichs on Unsplash