DEV Community: Regis Wilson

The Wilson Else: A Linter for Branches That Pretend Nothing Happened

Regis Wilson — Tue, 22 Sep 2026 23:51:52 +0000

The Wilson Else: A Linter for Branches That Pretend Nothing Happened

Introduction

Every codebase has little lies in it. Lies are like bugs, but without the harmful side effects (usually). Some lies are obvious: a variable named safeConfig that is not safe, a function called validate() that mostly logs something and keeps going, or a deployment step named cleanup that creates three resources and deletes none.

But some lies are quieter. They are almost polite.

if (cached) {
  cache.delete(key);
}

That code is not wrong. It is not even suspicious by itself. If the cache entry exists, delete it. If it does not exist, continue. Every programmer on Earth understands that.

We must however remember the genius of Newton, restated as:

For every if-then, there is an equal and opposite else.

Lies and the Hurtful Truths

If you stare at enough production systems, deployment code, authorization logic, cloud cleanup workflows, and similar machinery, this style starts to itch. Not because the code is hard to read, but because the code is easy to read too quickly.

There is a hidden branch in the code above.

if (cached) {
  cache.delete(key);
} else {
  // nothing happens
}

Most of the time, that hidden branch is fine. Sometimes it is the whole bug. I call it the "unrealized else" because I'm a bit of an outlier. Even among outliers, I'm an outlier. I'm out lying in the street right now. That is, I'm lying down in a bed in the middle of the physical street, not spouting counter factual arguments in a public venue.

The Wilson Else

This is the idea behind what I am calling the Wilson Else, mostly because naming your own bad ideas is one of the few remaining joys in software engineering.

I am proposing it as an experiment, not announcing it as a law. I want to know whether other people who work in stateful, side-effecting systems recognize the same review problem, whether this rule finds useful examples of it, and whether they can see better ways to detect or express it.

The Wilson Else says:

Every meaningful branch should either handle the other case, return before the other case matters, or explicitly admit that nothing happens.

This is not a universal law. It should not be tattooed on your forearm unless you pay me a nominal license fee. It should not be used to turn every tiny one-line condition into a notarized document.

But in the right places, it is fire.

The Problem With the Lonely `if`

What is an "unrealized else"? To start with, the lonely if is everywhere:

if (user.isAdmin) {
  permissions.push('admin');
}

Sometimes that is completely reasonable. We are accumulating a list. If the condition is true, add something. If it is false, do not add it.

But now look at this:

if (deployment.phase === 'delete') {
  await deleteResources(deployment);
}

await applyResources(deployment);

Maybe that is correct.

Maybe delete is a pre-phase before apply.

Maybe it is a catastrophic bug.

The code does not tell you. The reader has to infer whether the missing else is intentional. In business logic, that inference is often manageable. In deployment systems, state machines, authorization checks, schema rendering, workflow orchestration, and cloud mutation code, that inference gets expensive.

The problem is not that an if without an else is bad.

The problem is that some if statements represent a fork in reality, and only one side of reality is written down.

That is the "unrealized else." So how do we fix it?

The First Bad Rule

The obvious linter rule for the Wilson Else is simple:

Flag every if without an else.

This is also how you make everyone hate you before lunch. I mean, even before you get to the office, turn on the computer, drink coffee at the water cooler, complain about Mondays, and then decide where to go for lunch.

Because this gets flagged:

if (!caller) {
  throw new UnauthorizedError();
}

return caller;

But that code is good. The false branch is the rest of the function. The guard clause is explicit. It says: if this impossible or invalid condition happens, stop now. Otherwise, continue.

This also gets flagged:

if (!message.endsWith(':')) {
  message += ':';
}

return message;

And yes, you could write:

if (!message.endsWith(':')) {
  message += ':';
} else {
  // do nothing
}

return message;

But now the code has become annoying. It is not more correct. It is just a whole lot louder and a whole lot worse.

This is the lifecycle of every opinionated lint rule: the first five findings feel like moral clarity; the next ten feel like maybe we are overdoing it; and the next twenty feel like you invented paperwork, and you even start to wonder about the person who invented this--and it was yourself.

A global rule against a missing else is too blunt. The idea is good, because all my ideas are good. The blast radius is the problem.

Guard Clauses Are Not the Enemy

A good rule needs to understand termination.

This should be allowed:

if (!token) {
  throw new UnauthorizedError();
}

return authenticate(token);

So should this:

if (!environment) {
  return null;
}

return renderEnvironment(environment);

And this:

if (phase === 'delete') {
  return deleteResources();
} else if (phase === 'apply') {
  return applyResources();
} else {
  return assertNever(phase);
}

In all three examples, the edge is visible. There is no unrealized branch drifting into the next statement. The code either stops, returns, throws, or exhaustively handles the alternatives. Also, I wrote all of them, so of course they're fine.

That is the heart of the rule: it is not "every if needs an else."

It is instead:

If the true branch does work and then falls through, the false branch deserves a moment of honesty.

Conditional Logging Is a Separate Crime

While experimenting with this rule, one pattern showed up immediately:

if (debug) {
  logger.debug({ deploymentId }, 'Deployment started');
}

This is usually policy leaking into the call site.

The call site should say what happened:

logger.debug({ deploymentId }, 'Deployment started');

The logger should decide whether debug logs are emitted.

That distinction matters. This is application logic:

if (!response.ok) {
  logger.warn(
    { status: response.status },
    'GitHub returned a non-2xx response',
  );
}

The condition changes the meaning of the event. We only want the warning if something notable happened.

This is logging policy:

if (debug) {
  logger.debug('Some debug event happened');
}

That condition does not describe the domain. It describes whether the program feels like talking today.

A linter can detect some of this, but it should be careful. I would not autofix conditional logging unless the logging API guarantees lazy evaluation or the arguments are cheap. Still, as a smell, it is real.

Call logger.debug(). Configure log filtering somewhere else.

Ruby Has a Pressure Valve

Ruby has a little escape hatch for this style:

message += ':' if !message.ends_with?(':')
message

I understand why people like it. It is compact. It avoids ceremony. It says, "Make this tiny adjustment if needed, then return the value."

I also hate it, not because it is unreadable--it is very readable.

I hate it because the transformation and the result are split across two statements. The first line mutates the value. The second line quietly relies on Ruby's implicit return. The code has a little shrug built into it.

In TypeScript, I would rather write:

return message.endsWith(':') ? message : `${message}:`;

Both outcomes are visible at the point where the value is decided.

That is really what this whole argument is about. Not else as a sacred keyword. Not braces for the sake of braces. The point is to make the decision visible where the decision matters.

The Nested Case Is Where It Gets Interesting

The first version of the linter was obnoxious.

It reported hundreds of warnings. Many were technically defensible. Many were also the kind of thing that makes developers turn off rules and never look back. If we don't have an easy and defensible way to explain every single instance of the flagged code, or an autofixer for the hundreds, thousands, or possibly hundreds of thousands of instances, then we will have failed.

Finally, the useful version appeared:

Only error on nested unrealized else branches.

That changes everything.

This is mildly suspicious:

if (cached) {
  cache.delete(key);
}

This is worse:

if (!skipCache) {
  const cached = cache.get(key);

  if (cached && cached.expiresAt > Date.now()) {
    return cached.value;
  }

  if (cached) {
    cache.delete(key);
  }
}

Now the reader is inside a decision tree. We are already in a conditional world. A nested if without an else forces the reader to simulate the missing path while also remembering the outer path.

That is where the unrealized else gets brutal.

The nested version is not just a missing branch. It is a missing branch inside another branch. The mental stack is already loaded. The code should help.

If the missing case is intentional, write it down:

if (!skipCache) {
  const cached = cache.get(key);

  if (cached && cached.expiresAt > Date.now()) {
    return cached.value;
  }

  if (cached) {
    cache.delete(key);
  } else {
    // TODO: nothing
  }
}

Is that obnoxious?

Yes.

Is it clear?

Also yes.

And the obnoxiousness is part of the point. The comment is a little accusation left in the code. It says: "We considered this branch, and for now, doing nothing is the decision."

Why `TODO: nothing` Is Better Than `do nothing`

The autofix could add:

else {
  // do nothing
}

That is polite, but too polite.

I prefer:

else {
  // TODO: nothing
}

That is funnier, but it is also more honest.

"Do nothing" sounds final. It sounds like a decision.

"TODO: nothing" sounds like the code knows it got away with something. It leaves a little grit in the file. It invites the next person to ask whether nothing is truly the right behavior.

Maybe it is. Great. Leave it.

Maybe it is not. Even better. The linter found a real design gap.

The point of an autofix is not always to produce beautiful code. Sometimes the point is to make the implicit thing explicit enough that it becomes reviewable.

What the Rule Looks Like

The useful rule has a few constraints:

Ignore normal, unnested if statements.
Ignore guard clauses that terminate with return, throw, break, or continue.
Ignore existing else branches.
Treat else if chains as part of the same decision.
Error only on nested, fallthrough if statements.
Autofix only those errors.
Add the explicit no-op branch.

The result is much less philosophical and much more useful.

Instead of hundreds of warnings, you get a smaller set of errors in places where the code is already asking the reader to keep track of multiple paths.

That matters. A linter rule should not merely express taste. It should find places where taste and correctness overlap.

Nested conditionals are one of those places.

Where This Belongs

I would not enforce this everywhere.

For example, UI code often has little conditional additions:

if (showSubtitle) {
  parts.push(subtitle);
}

That does not need a Wilson Else. Please do not make frontend developers write:

else {
  // TODO: nothing
}

for every conditional render, unless you want them to unionize against you.

But there are places where I do want this pressure:

Authorization
Deployment orchestration
Cloud resource deletion
Schema generation
State machines
Workflow transitions
Billing logic
Cleanup jobs
Security-sensitive routing
Anything that mutates infrastructure

In these areas, the cost of being explicit is smaller than the cost of assuming everyone reads your mind.

Deployment code especially benefits from this. Deployments are full of phases: create, apply, patch, delete, rollback, cleanup, skip, and retry. Missing one branch can leave stale resources behind or apply a thing that should have been deleted.

A nested unrealized else in deployment code is rarely just style. It is often a question the code forgot to answer.

The Rule Is a Flashlight, Not a Religion

This is where engineering judgment matters.

The rule is not saying every condition needs ceremony. It is saying some conditions create unspoken behavior, and unspoken behavior is where bugs like to live.

The rule is a flashlight.

Run it. Look at the findings. Decide whether the code is missing an actual branch or whether the branch is intentionally empty.

If it is intentionally empty, the autofix gives you:

else {
  // TODO: nothing
}

If that makes the code look ridiculous, maybe the rule is too aggressive for that file.

If it makes the code look safer, maybe the code was relying on vibes.

This is the sweet spot for custom linting. Not a universal mandate. A local pressure tool for a codebase with known failure modes.

The best lint rules are born from irritation. Not abstract best practice. Not "some famous person said never do this." Real irritation. A pattern keeps showing up in real code and making real review harder.

The Wilson Else came from that kind of irritation. Eventually, I hope that review comments on complex platform codebases will include lines like, "Check your unrealized else here," and "I think this needs a Wilson Else."

Why This Matters More in Platform Code

Platform code is different from product code.

Product code can often fail visibly. A button does not work. A page renders incorrectly. A request returns a bad response. The feedback loop is painful but obvious.

Platform code can fail quietly.

A cleanup branch does not run. A stale DNS record stays alive. A deleted service still has a policy attached. A deployment applies after a delete. A cache is invalidated in one path but not another. A permission check falls through and relies on a default nobody remembers.

These are exactly the places where "nothing happens" should be a written decision.

Platform systems accumulate invisible state. The code is not just transforming data. It is coordinating reality outside the process: clusters, cloud APIs, databases, environments, routes, secrets, service accounts, jobs, controllers, and retries.

When code like that has a nested conditional, every missing branch is a tiny operational assumption.

Write the assumption down.

The Wilson Else, in Human Form

Here is the rule in human form:

A nested if that falls through without an else must either become a guard clause, handle the alternative, or explicitly say that nothing happens.

That is the Wilson Else.

It is a little obnoxious. Good.

It is not for every line of code. Also good.

It is fixable, unlike its author. Very good.

The autofix is intentionally plain:

else {
  // TODO: nothing
}

You can hate it. You are supposed to hate it a little. That is how you know the linter is applying pressure.

The trick is to apply pressure in the right place.

Too broad, and the rule becomes noise.

Too narrow, and it never catches anything.

Nested-only feels like the right starting point. It catches the places where the reader is already inside a branch and the missing alternative is most likely to cause confusion.

That is not a manifesto.

That is a useful annoyance.

What I Am Actually Proposing

The Wilson Else is not yet a rule I can prove that anyone should enforce. It is a name for a recurring review problem and a deliberately crude instrument for making that problem visible.

The instrument may be wrong. Nested conditionals may be too weak a proxy. TODO: nothing may be the wrong marker. The useful signal may instead be some combination of external effects, mutation, fallthrough, and incomplete state transitions. An autofix also cannot prove that a human considered the false path; at most, it can put that path in front of one.

That is why I am publishing the rule. I want to find out whether like-minded people encounter the same problem, whether its findings survive contact with real code, and whether someone has a more precise solution.

A reasonable experiment would be:

Run the rule in report-only mode on platform code.
Classify each finding as harmless accumulation, intentional no-op, unclear intent, or genuine defect.
Record what distinguished useful findings: nesting, side effects, mutation, domain, or something else.
Refine the rule around those observations--or discard it if there is no reliable signal.

If the experiment produces nothing but ceremony, that is an answer. If it identifies a recurring class of omitted decisions, then the obnoxious prototype has done its job.

Conclusion

Most code-style arguments are boring because they pretend to be about beauty when they are actually about risk.

The Wilson Else is not beautiful. An autofixed else { /* TODO: nothing */ } block is not going to win any poetry contests. It might even make you angry the first time you see it.

But it does something valuable: it turns an implicit path into an explicit artifact.

Now the reviewer can ask:

Is nothing really correct here?
Should this be a guard clause?
Should this be an else if chain?
Should this throw?
Should this return?
Did we forget a deployment phase?
Did we forget a cleanup path?

That is the whole game.

Software does not need more rules for the sake of rules. It needs better ways to expose assumptions before they become incidents.

The Wilson Else might be one of those ways. For now, it is a proposal, a probe, and an invitation to improve the idea.

Let the h8rs h8.

A Scholarly View--and the Strongest Cases on Both Sides

The Wilson Else can be understood as a small intervention in cognitive complexity. McCabe's classic work on cyclomatic complexity counts independent paths through a program; later work on cognitive complexity asks how difficult those paths are for a human to hold in mind. A nested, one-sided conditional adds a path while leaving one outcome implicit. The rule's strongest intellectual case is therefore not that an else is inherently virtuous, but that high-risk code should externalize decisions that would otherwise live only in the reader's working memory.

Steelman: the case for the rule

The strongest case for the Wilson Else is in stateful, side-effecting systems. In deployment, authorization, billing, and cleanup code, inaction is often an observable policy choice. An explicit no-op branch exposes that choice for review, though it cannot by itself prove that the author considered it. Scoped to nested conditionals, the rule also targets code where readers already bear a higher cognitive load, rather than taxing every ordinary conditional.

The rule may also improve maintenance as a form of lightweight design pressure. If // TODO: nothing looks absurd, that discomfort can reveal that the conditional should instead be flattened, returned from early, expressed as an exhaustive state transition, or decomposed into a named function. In this steelman, the awkward autofix is diagnostic rather than stylistic.

Steelman: the case against the rule

The strongest objection is that explicit syntax is not the same as explicit understanding. An empty else can become ritualized noise, and an autofixed comment may falsely imply that a human considered the branch. Worse, TODO: nothing can manufacture permanent, unactionable debt. Readers may spend more effort filtering boilerplate than reasoning about behavior--the very cognitive cost the rule intends to reduce.

There is also a semantic limitation. Syntactic nesting is only a proxy for risk. A deeply nested pure-data transformation may be harmless, while a top-level one-sided conditional that deletes production resources may be critical. Likewise, correctly deciding whether a branch terminates requires control-flow analysis; a syntax-only approximation can misclassify helper calls, exceptions, labeled breaks, loops, and language-specific constructs.

Most charitable view

The most defensible form of the Wilson Else is therefore not "every missing else is a defect." It is: in code where omitted action carries operational meaning, make the omission reviewable. That narrower claim preserves the idea's practical force while taking its critics seriously.

Further research on this topic and design in an existing or new programming language (especialy in the era of AI coders) maybe be fruitful.

Appendix: Photo source

Photo by Sophia Kunkel on Unsplash

Appendix: Experimental ESLint Rule

// SPDX-License-Identifier: MIT
// Copyright (c) 2026 We, The People

/**
 * Experimental rule to flag if statements that handle the true branch and then
 * fall through without saying what the false branch means.
 */

/** @type {import('eslint').Rule.RuleModule} */
const LOGGER_METHODS = new Set([
  'trace',
  'debug',
  'info',
  'warn',
  'error',
  'fatal',
]);

export const rule = {
  meta: {
    type: 'suggestion',
    docs: {
      description:
        'flag if statements with fallthrough true branches and no explicit else',
      recommended: false,
    },
    fixable: 'code',
    schema: [
      {
        type: 'object',
        properties: {
          mode: {
            enum: ['all', 'nested'],
          },
          conditionalLogging: {
            type: 'boolean',
          },
        },
        additionalProperties: false,
      },
    ],
    messages: {
      unrealizedElse:
        'Unrealized else: this if handles only the true branch and then continues. Add an else, return early, or leave an explicit false-case marker.',
      conditionalLogging:
        'Conditional logging: call logger.{{method}}() directly and configure log filtering in the logger.',
    },
  },
  create(context) {
    const sourceCode = context.sourceCode ?? context.getSourceCode?.();
    const options = context.options[0] ?? {};
    const mode = options.mode ?? 'all';
    const conditionalLogging = options.conditionalLogging ?? true;
    const ifStatementStack = [];

    function checkIfStatement(node, isNested) {
      if (node.alternate) {
        return;
      }

      if (statementAlwaysTerminates(node.consequent)) {
        return;
      }

      if (sourceCode && hasExplicitFalseCaseMarker(sourceCode, node)) {
        return;
      }

      if (mode === 'nested' && !isNested) {
        return;
      }

      const loggerMethod = getOnlyLoggerMethod(node.consequent);
      if (loggerMethod) {
        if (conditionalLogging && isLoggingPolicyCheck(node.test)) {
          context.report({
            node,
            messageId: 'conditionalLogging',
            data: { method: loggerMethod },
          });
        }
        return;
      }

      context.report({
        node,
        messageId: 'unrealizedElse',
        fix(fixer) {
          if (!sourceCode) {
            return null;
          }

          const token = sourceCode.getLastToken(node.consequent);
          if (!token) {
            return null;
          }

          const indent = getNodeIndent(sourceCode, node);
          return fixer.insertTextAfter(
            token,
            ` else {\n${indent}  // TODO: nothing\n${indent}}`,
          );
        },
      });
    }

    return {
      IfStatement(node) {
        const isNested = isNestedIfStatement(node, ifStatementStack);
        ifStatementStack.push(node);
        checkIfStatement(node, isNested);
      },
      'IfStatement:exit'() {
        ifStatementStack.pop();
      },
    };
  },
};

function statementAlwaysTerminates(node) {
  switch (node.type) {
    case 'ReturnStatement':
    case 'ThrowStatement':
    case 'ContinueStatement':
    case 'BreakStatement':
      return true;
    case 'BlockStatement':
      return node.body.some((statement) =>
        statementAlwaysTerminates(statement),
      );
    case 'IfStatement':
      return Boolean(
        node.alternate &&
        statementAlwaysTerminates(node.consequent) &&
        statementAlwaysTerminates(node.alternate),
      );
    case 'TryStatement':
      if (node.finalizer && statementAlwaysTerminates(node.finalizer)) {
        return true;
      }

      return Boolean(
        statementAlwaysTerminates(node.block) &&
        node.handler &&
        statementAlwaysTerminates(node.handler.body),
      );
    default:
      return false;
  }
}

function getOnlyLoggerMethod(statement) {
  const expressionStatement = getOnlyExpressionStatement(statement);
  if (!expressionStatement) {
    return null;
  }

  const expression = expressionStatement.expression;
  if (
    expression.type !== 'CallExpression' ||
    expression.callee.type !== 'MemberExpression' ||
    expression.callee.computed ||
    expression.callee.object.type !== 'Identifier' ||
    expression.callee.object.name !== 'logger' ||
    expression.callee.property.type !== 'Identifier'
  ) {
    return null;
  }

  const method = expression.callee.property.name;
  return LOGGER_METHODS.has(method) ? method : null;
}

function isLoggingPolicyCheck(node) {
  if (node.type === 'Identifier') {
    return /^(debug|verbose)$/iu.test(node.name);
  }

  if (node.type === 'MemberExpression' && node.property.type === 'Identifier') {
    return /^(debug|verbose|is(Debug|Trace|Info|Warn|Error|Fatal|Verbose)Enabled)$/u.test(
      node.property.name,
    );
  }

  if (node.type !== 'CallExpression') {
    return false;
  }

  const callee = node.callee;
  if (callee.type === 'Identifier') {
    return /^(is(Debug|Trace|Info|Warn|Error|Fatal|Verbose)Enabled)$/u.test(
      callee.name,
    );
  }

  if (
    callee.type !== 'MemberExpression' ||
    callee.property.type !== 'Identifier'
  ) {
    return false;
  }

  return /^(isLevelEnabled|is(Debug|Trace|Info|Warn|Error|Fatal|Verbose)Enabled)$/u.test(
    callee.property.name,
  );
}

function getOnlyExpressionStatement(statement) {
  if (statement.type === 'ExpressionStatement') {
    return statement;
  }

  if (statement.type !== 'BlockStatement' || statement.body.length !== 1) {
    return null;
  }

  const [onlyStatement] = statement.body;
  return onlyStatement.type === 'ExpressionStatement' ? onlyStatement : null;
}

function hasExplicitFalseCaseMarker(sourceCode, node) {
  const comments = [
    ...sourceCode.getCommentsBefore(node).slice(-1),
    ...sourceCode.getCommentsAfter(node).slice(0, 1),
  ];

  return comments.some((comment) =>
    /\b(no-unrealized-else|unrealized else|false case|else intentionally omitted|intentionally no else)\b/iu.test(
      comment.value,
    ),
  );
}

function getNodeIndent(sourceCode, node) {
  const lineStartIndex =
    sourceCode.text.lastIndexOf('\n', node.range[0] - 1) + 1;
  const linePrefix = sourceCode.text.slice(lineStartIndex, node.range[0]);
  return linePrefix.match(/^\s*/u)?.[0] ?? '';
}

function isNestedIfStatement(node, ancestorIfStatements) {
  return ancestorIfStatements.some((ancestor) => ancestor.alternate !== node);
}

export default {
  rules: {
    'unrealized-else': rule,
  },
};

Appendix: ESLint Configuration

// SPDX-License-Identifier: MIT
// Copyright (c) 2026 We, The People

// @ts-check

import tseslint from 'typescript-eslint';
import unrealizedElse from './eslint-rules/unrealized-else.js';

const config = [
  {
    ignores: [
      'src/lib/schemas/k8s_kinds/v1.29.7-standalone-strict/',
      'src/generated/**',
      'src/test/**',
      'src/**/*.test.ts',
      '*.test.ts',
    ],
  },
  {
    linterOptions: {
      reportUnusedDisableDirectives: 'off',
    },
  },
  {
    files: ['src/**/*.ts'],
    languageOptions: {
      parser: tseslint.parser,
      parserOptions: {
        ecmaVersion: 'latest',
        sourceType: 'module',
      },
    },
    plugins: /** @type {Record<string, any>} */ ({
      'unrealized-else': unrealizedElse,
    }),
    rules: {
      'unrealized-else/unrealized-else': [
        'error',
        {
          mode: 'nested',
          conditionalLogging: false,
        },
      ],
    },
  },
];

export default config;

Disclosure and Licensing

This article was co-written with generative AI. The author supplied the central idea, examples, code, arguments, and editorial direction; AI assisted with organization, light copyediting, Markdown conversion, counterarguments, and refinement. The author reviewed and takes responsibility for the published result.

Unless otherwise noted, the original code examples in this article are offered under the MIT License. The prose and other non-code material are not included in that code license. Third-party packages and APIs mentioned or imported by the examples remain subject to their own licenses. This notice is provided for clarity and is not legal advice.

Full MIT License for the original code examples

MIT License

Copyright (c) 2026 We, The People

Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the "Software"), to deal
in the Software without restriction, including without limitation the rights
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
copies of the Software, and to permit persons to whom the Software is
furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all
copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
SOFTWARE.

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

DEV Community: Regis Wilson

The Wilson Else: A Linter for Branches That Pretend Nothing Happened

The Wilson Else: A Linter for Branches That Pretend Nothing Happened

Introduction

Lies and the Hurtful Truths

The Wilson Else

The Problem With the Lonely if

The First Bad Rule

Guard Clauses Are Not the Enemy

Conditional Logging Is a Separate Crime

Ruby Has a Pressure Valve

The Nested Case Is Where It Gets Interesting

Why TODO: nothing Is Better Than do nothing

What the Rule Looks Like

Where This Belongs

The Rule Is a Flashlight, Not a Religion

Why This Matters More in Platform Code

The Wilson Else, in Human Form

What I Am Actually Proposing

Conclusion

A Scholarly View--and the Strongest Cases on Both Sides

Steelman: the case for the rule

Steelman: the case against the rule

Most charitable view

Appendix: Photo source

Appendix: Experimental ESLint Rule

Appendix: ESLint Configuration

Disclosure and Licensing

The Neo Fermi/Wilson AI Paradox

Steelmen and Straw Retorts

The Cosmic Version

Summary

AWS Outpost and RDS: Reslotting Checklist

Overview

AWS Regions and Outpost

Getting Familiar With Outpost

Right Size Scaling

Best Laid Plans of Mice and Men

You Can't Modify a Stopped DB Instance.

Failure is Not an Option

Summary

About the Author

We're Hiring!

Image Credit

The Problem With the Lonely `if`

Why `TODO: nothing` Is Better Than `do nothing`