A financial services firm adopted Cursor AI and watched their coding output increase tenfold. The result wasn't a tenfold improvement. It was a million-line backlog that nobody could review. StackHawk CEO Joni Klippert told Futurism that companies "can't keep up" with the volume of code and the vulnerabilities it introduces. Joe Sullivan, advising at Costanoa Ventures, put it plainly: "There are not enough application security engineers on the planet to satisfy what just American companies need."

The article — "The Effects of AI-Generated Code Tearing Through Corporations Is Actually Kind of Funny" by Frank Landymore — paints a picture that isn't actually funny at all. Companies lay off developers, hand the work to AI, then discover the AI output needs developers to review it. The developers who remain, face what the article calls "brain fry" from constantly supervising code they didn't write, structured in ways they didn't choose, following patterns that change from file to file.

This is the part that doesn't get enough attention. The problem isn't that AI writes bad code. The problem is that AI writes inconsistent code. Every file is a new set of assumptions. Every function is a new naming convention. Every module structures itself differently. When a human writes inconsistent code, at least the team can ask them what they meant. When AI generates a million lines of it, there's no one to ask.

The Pattern Problem

Most codebases are a geology of decisions. Framework A was popular when the project started, framework B replaced it two years later, and now there are three ways to do the same thing. Add AI to that environment and it learns all three patterns — and invents a fourth.

This is what makes review so expensive. A reviewer isn't just checking logic. They're reverse-engineering which pattern the AI chose, whether it matches the surrounding code, whether the naming is consistent, whether the error handling follows the project's approach or the AI's default training, and whether the imports point to the right version of the right abstraction. Multiply that by a million lines and you understand why a "tenfold increase in output" creates a tenfold increase in confusion, not productivity.

Conventions Constrain Spagetti Code

CEOToolSuite relies upon a somewhat unorthodox set of conventions to solve the backlog problem. We run many micro-service workers on Cloudflare's Developer Platform all of which follow the same patterns in order to make reading the code easy for both man and machine.

See: https://blogs.ceots.io/ceotoolsuite-ecmascript-style-conventions

These aren't style preferences. They're a constraint system. When the rules are this specific, AI doesn't have to guess which pattern to follow. It reads the surrounding code, sees the same pattern repeated in every file it's ever seen in this codebase, and produces output that matches. The convention becomes self-reinforcing: every new file teaches the pattern, and every AI-generated file either follows it or is immediately, obviously wrong.

Named Failure Modes

We took this further by naming the ways AI goes wrong and wiring those names into automated detection. Instead of vague code review feedback, our system uses coded failure modes — each one mapped to a regex-based detection rule that runs against every file:

• P-02 CONST_LET_USAGE — detected by rule E001: the AI used const or let instead of var
• P-06 THEN_CHAIN — detected by rule E002: the AI used .then() instead of async/await
• B-03 CONVENTION_BREAK — detected by rules E003–E008: forbidden DOM APIs, data-* attributes, unauthorized comments, missing trailing commas, or unnecessary blank lines
• P-03 HYPHEN_IDENTIFIER — detected by rule W001: camelCase instead of snake_case

The convention engine (ceots__conventions) scans any JavaScript file and outputs violations tagged with both the rule ID and the failure mode code:

ERR  L42   [E001 P-02] Use `var` instead of `const`/`let`
ERR  L87   [E002 P-06] Use async/await instead of `.then()`/`.catch()`
WRN  L103  [W001 P-03] camelCase variable — use snake_case

When an AI agent recognizes it's about to commit a named failure, it can say "that's CONVENTION_BREAK" and self-correct before the code is written. When it doesn't self-correct, the engine catches it. Naming the failure makes it concrete. An AI can't reliably follow "write good code," but it can follow "never use const" — and if it slips, the linter catches it with a code that maps back to a documented anti-pattern.

Why the Industry Solution Won't Work

The article describes three approaches companies are taking: mandatory human code review, AI code-review agents, and acquiring code-review platforms. All three assume the code itself is uncontrollable and the answer is better filters after the fact.

That's backwards. If your codebase has 15 ways to structure a module and 4 naming conventions and 3 error handling patterns, no amount of review — human or AI — will make a million lines of that code coherent. You're paying reviewers to impose consistency that should have been baked in.

Conventions are cheaper than review. A set of rules that an AI can internalize costs nothing per line. A human reviewer costs everything per line. The companies facing million-line backlogs aren't suffering from too much AI output. They're suffering from too little structural discipline.

Fractal Consistency

The deeper principle is what we call fractal consistency. It starts with a single rule about underscores.

In CEOToolSuite, a single underscore (_) separates words within a name — the way you'd naturally combine two words into one concept. user_data is one thing: the user's data. form_input is one thing: a form input. content_type is one thing: the Content-Type header. These are compound words.

A double underscore (__) means something different. It separates a namespace from a descriptor — the thing being talked about from the specific instance of it. When you have multiple variables that all relate to the same concept, the concept becomes a namespace:

var session__id = select.value;
var session__saved = storage.get('session');
var session__found = false;

"Session" is the namespace. The descriptors tell you which aspect of it you're looking at. You can scan a function and immediately see "these three variables are all about the session" because they share a prefix separated by __. Compare that to the typical approach — savedSession, foundSession, sessionId — where you have to parse camelCase boundaries to find the grouping, and the shared concept ends up scattered across different positions in the name.

The same rule applies to functions. When multiple functions share a verb, the verb is the namespace:

async function handle__api(request, env) { }
async function handle__assets(request, env) { }
async function verify__session(request, env) { }
async function verify__token(request, env) { }

Search for handle__ and you find every request handler. Search for verify__ and you find every validation function. The double underscore makes the namespace boundary searchable and unambiguous.

Here's where it becomes fractal. That same __ convention isn't just a code style rule — it's the naming system for the entire platform:

• Repository names: ceots__crm, ceots__billing, ceots__calendar — the platform namespace separated from the service name
• Directory structure: projects/ceots/ceots__crm, projects/ceots/ceots__billing — the file system mirrors the naming convention
• Service URLs: crm.ceots.io, billing.ceots.io, calendar.ceots.io — the service name becomes the subdomain
• Configuration keys: CONFIG__API_KEY, CACHE__TIMEOUT — even key-value storage uses the same namespace separator
• Frontend modules: window.ceots__crm = { e: {}, f: {}, g: {} } — the JavaScript module object carries the same name as the repo, the URL, and the directory

At every level — variable, function, module, file path, service URL, configuration — the double underscore means "namespace boundary" and the single underscore means "words in a concept." A developer who learns this from reading one function in one service can navigate the entire platform's architecture because the pattern doesn't change. An AI agent that reads three files has internalized the naming system for forty services.

This is the opposite of how most codebases work. Most projects use camelCase in JavaScript, kebab-case in file names, SCREAMING_SNAKE in environment variables, PascalCase in class names, and whatever the framework dictates in configuration files. Every layer has its own convention. AI trained on that codebase has to learn five naming systems and figure out which one applies where. Ours has one system. It applies everywhere.

The 40th service makes the first 39 easier to understand because it reinforces the same structure. Most codebases degrade as they grow. Ours gets more legible.

That's not a technology advantage. It's a discipline advantage. And it's the one thing that actually scales when AI is writing the code.

The Real Lesson

The Futurism article quotes Sachin Kamdar of Elvix: "It's just going to break something, and they're not going to know why it broke." That's true when every file is a surprise. It's not true when every file follows the same pattern, names things the same way, structures itself the same way, and deviates in ways that are immediately visible.

The companies struggling with AI code backlogs don't need better review tools. They need conventions worth following. Rigid, specific, boring conventions that reduce every decision to a reflex — for the AI and for the humans who work alongside it.

AI didn't create the consistency problem. It exposed it. The million-line backlog is the natural consequence of codebases that never had structural discipline to begin with. The AI just made the mess faster.