This is a follow-up blog post:
The Wild West of Coding: Why We’re Still Burning Digital Cities
Lars Moelleken ・ Jan 31 '25
The year 2050 is closer than 2000. And yet, software development is entering a phase where writing code is no longer the bottleneck.
For the first time, code generation is virtually free.
Large Language Models (LLMs) can generate thousands of lines of syntactically valid, locally plausible code in seconds. The bottleneck is no longer how fast we can implement features - it's how reliably we can absorb what has been produced.
This shift is not theoretical. It's already showing up in real-world codebases.
OpenClaw: Code Without Memory
Take the OpenClaw repository. At first glance, it looks like boring TypeScript. No red flags. The kind of code that would sail through a shallow pull request review.
But zoom out, and the deeper you go, the more disturbing it becomes.
- Redundant checks live next to reckless type assertions.
- Standard APIs are quietly reinvented.
- Near-identical helpers exist side by side, none reused. One even comes with a completely unnecessary comment.
Example:
https://github.com/openclaw/openclaw/commit/d1ecb46076145deb188abcba8f0699709ea17198
In this commit, the same escape-handling rule
if (ch === "\\" && isDoubleQuoteEscape(next)) {
appears three times, implemented independently in three different parsing loops. It works, but it is duplicated logic, not a shared rule.
The newly introduced constant
const DOUBLE_QUOTE_ESCAPES = new Set(["\\", '"', "$", "`", "\n", "\r"]);
makes the same problem visible at the naming level.
DOUBLE_QUOTE_ESCAPES sounds like “things that happen in double quotes”. What the code actually enforces is much narrower: a whitelist of characters that are allowed after a backslash while inside a double-quoted string.
That distinction matters, because this is not a general shell grammar. It is a parser rule with intentionally restricted semantics. A name that encodes the mechanism is therefore clearer and harder to misread:
const DOUBLE_QUOTE_BACKSLASH_FOLLOWERS = new Set(["\\", '"', "$", "`", "\n", "\r"]);
This is not a one-off mistake. It is a pattern: rules are re-expressed locally instead of being named once and reused. The code still works. But it doesn’t remember what it already knows.
1. From Coder to Inspector
For decades, software was naturally throttled by human speed... typing, thinking, debugging. That friction caught many errors before they reached production.
LLMs remove that friction. They don't understand systems. They don't remember outages, postmortems, or audit logs. They see the end result of code and predict patterns based on surface-level plausibility.
As a result:
- Defensive logic gets "simplified" away.
- Ugly but necessary patches get erased.
- Implicit architectural contracts get violated.
And yet, CI passes. Tests are green. The code looks fine.
But the foundation quietly erodes.
This is where the role of the Senior Engineer shifts. Their value is no longer in writing code, it's in knowing when not to and where to stop Claude from adding even more markdown files and not needed feature lists.
2. The Dangerous Gap Between Commit and Reality
Today's pipelines can take code from prompt to production in minutes. What's missing isn't automation, as in the last decade, it's human verification:
- Did we actually mean to solve the problem this way?
- Did we just break a hidden assumption?
- Will the next dev understand what this does?
The most dangerous bugs aren't crashes. They're subtle degradations:
- Re-emergent race conditions
- Broken security invariants
- Unnecessary abstractions that raise cognitive load
Tests won't catch all of this. Reviews barely scratch the surface when volume explodes.
And in this new regime, the cost of errors doesn't hit one dev, but it's paid by the organization in the long run.
3. Enter the System Inspector
In the 19th century, societies learned that bridges shouldn't be approved by the people who built them. Structural collapses birthed the role of inspectors.
Software is hitting that same phase.
The System Inspector is not a title. It's a responsibility: Someone whose job is to approve code, not write it. Not just another Code-Review between the next features. Not based on aesthetics, but on integrity.
Their responsibilities:
- Define and protect non-negotiable system rules
- Preserve organizational and historical knowledge
- Manage cognitive load
- Reject syntactically correct but structurally harmful code
This is not about blocking progress. It's about preventing scale-induced disasters.
4. Regulation Is a Prerequisite for Scaling
Guidelines don't scale. Style guides don't survive contact with LLMs. Comments get reworded, ignored, or helpfully "improved" into something else entirely.
Advice is optional. Code generation is not.
What actually works are machine-enforceable constraints: e.g.
- Linting, tests, static analysis, contract checks.
-
AGENTS.mdfiles that define rules, not suggestions. - Unchanging values that must apply regardless of how the code was created.
- ...
This isn't bureaucracy. This is infrastructure.
These constraints are the building codes of software systems that want to grow without collapsing. Every familiar argument against them sounds exactly like the arguments once made against fire codes or electrical standards. They were wrong then. They're wrong now.
Scaling requires automation. Automation requires limits. And limits still require humans in the loop, just not humans doing the policing by hand.
5. Blind Spots: The Parts We Prefer to Ignore
Even good systems carry risk. Here are some overlooked failure points:
🧱 Lack of Organizational Support
System Inspectors need mandates and time. Without this, their role collapses into unpaid heroism or burnout.
🧠 Concentrated Psychological Load
Decision bottlenecks are unsustainable. Approval authority needs to be distributed via frameworks, heuristics, or shared ownership... in the team.
🌍 One Size Doesn't Fit All
Not every team need this. These principles apply broadly but must be contextually adapted.
6. IKEA Was Never the Problem
This isn't a moral panic about LLMs.
Pandora’s box is open. Code generation is here: fast, cheap, and inescapable. Some teams will choose velocity over resilience. That's a valid economic tradeoff.
The problem begins when these systems are sold as something they are not.
IKEA furniture is not marketed as handmade oak. Software should follow the same principle of honesty. If we build with particle board, we should say so, and we should not pretend that it can bear the same load.
7. The Industrial Phase of Software
Software is leaving its artisanal phase, not because we matured, but because scale made failure expensive.
Code will be abundant. Responsibility will be scarce.
We are no longer writing code line by line. We are approving systems that outlast individuals and define entire orgs.
That's why we need System Inspectors.
Not to halt innovation, but to ensure our digital cities don't collapse like their wooden ancestors.
Let's build like we know what we're doing. :P
Top comments (2)
I understand the message, but I think that seniority has nothing to do with it. Even junior developers should know when not to write code.
The main difference seniority gives us is assurance that the point you stop writing code is the right one. A junior has had less confirmation about that cut off point.
With the examples in the post a junior that knows the DRY principle would have not wrote that code.
github.com/openclaw/openclaw/pull/...