DEV Community: Remo H. Jansen

When Code Gets Cheap, Verification Becomes Expensive: How AI changes the economics of software architecture

Remo H. Jansen — Mon, 28 Sep 2026 21:52:55 +0000

Recently, I was having a conversation at work about how we should implement a feature. I was advocating for one particular approach, and one of the reasons I preferred it was that I thought it would be easier for AI agents to work with. The structure was more explicit, the possible states were easier to reason about, and it would give us better opportunities to automate verification and put guardrails around future changes.

One of the stakeholders pushed back with a very reasonable point: we shouldn't design software a certain way simply because it is easier for AI agents. We should design it based on what is best for our users.

I agree completely.

But the conversation made me realise that there is an important part of my reasoning that I hadn't articulated well. I wasn't putting the AI agent ahead of the user. I was still trying to find the solution that gave us the best combination of user experience, reliability, simplicity, time to market, implementation cost, operational cost, and long-term maintainability. The fact that an agent could understand and verify the resulting system more easily was one of the variables in that equation, not the objective itself.

That distinction matters because I think AI is changing the economics of software architecture in a way that we haven't fully absorbed yet.

The cost of writing software is changing

For decades, one of the biggest constraints in software development was the cost of producing software. Developers had to understand the problem, design the solution, write the code, review it, test it, debug it, and maintain it. Engineering capacity was scarce, so reducing the amount of implementation work required was extremely valuable.

AI coding agents are changing this equation. They can generate implementations, write tests, refactor code, explore unfamiliar codebases, migrate APIs, and perform many other tasks at a speed that would have been difficult to achieve with humans alone.

But there is an important asymmetry here: generating code is not the same thing as establishing that the code is correct.

An agent can produce a thousand lines of code in minutes. That doesn't mean we can establish in minutes that those thousand lines correctly implement the desired behaviour, don't introduce regressions, preserve important invariants, and interact correctly with the rest of the system.

This means that as the marginal cost of producing code decreases, another cost becomes relatively more important: the cost of verification.

And verification isn't something we pay for once.

We verify software when we initially build it. We verify it when we change it. We verify it when we refactor it. We verify it when dependencies change. We verify it when another feature interacts with it. We verify it when an AI agent modifies it. We verify it when a bug is fixed. We verify it when we migrate data. We verify it when we upgrade infrastructure.

Implementation costs are often largely one-off. Verification costs are recurrent.

That changes the architectural equation.

Implementation cost is not the whole cost

Imagine that we have two possible implementations for the same feature.

Solution A costs $100,000 to implement, but because the architecture doesn't provide strong guarantees, every subsequent change requires significant testing, review, and regression checking.

Solution B costs $120,000 to implement, but the architecture makes many invalid states impossible and gives us strong automated guarantees about the behaviour of the system.

If we only look at implementation cost, Solution A appears cheaper.

But software doesn't stop costing money when the initial implementation is complete.

If Solution A requires an additional $20,000 every year in verification and regression work while Solution B requires only $5,000, then the initial $20,000 saving disappears very quickly. Over the lifetime of the system, the more expensive implementation can become the cheaper system.

The exact numbers aren't important. The important thing is that verification is recurrent.

This is why I think we need to start treating verifiability as an architectural concern.

When comparing two architectures, we shouldn't only ask how much they cost to build. We should also ask how cheaply and reliably we can establish that they are correct over the lifetime of the system.

Verification isn't just testing

When I talk about verification, I don't mean that we should simply write more tests.

Tests are extremely useful, but there is a more powerful form of verification: designing the system so that certain classes of incorrect behaviour cannot happen in the first place.

There is a huge difference between saying, "We have tests that check this invalid state doesn't happen" and saying, "This invalid state cannot be represented by the system."

The latter is an architectural property.

Strong types are a simple example. If a function accepts a UserId rather than an arbitrary string, the type system can eliminate an entire class of mistakes before the program runs. Database constraints can prevent invalid relationships. State machines can restrict which transitions are possible. Schemas can prevent malformed data from entering a system. Idempotency can eliminate entire classes of duplicate-operation bugs. Explicit boundaries can reduce the number of possible interactions between components.

In each case, we are moving some of the burden of verification away from humans and tests and into the structure of the system itself.

The system becomes easier to verify because the system itself provides guarantees.

A database can become part of the state machine

Consider a workflow where a piece of data moves through several states.

Perhaps it starts as Created, then becomes Validated, then Processed, and finally Completed.

One way to implement this is with a single event table:

WorkflowEvents

id
workflow_id
event_type
payload
created_at

The application then needs to determine whether a particular event is valid given the previous state. The code needs to understand which transitions are allowed, whether the previous event exists, whether the payload is valid for the event type, and whether the workflow has reached an impossible state.

We can write tests for all of this. We can write application-level validation. We can ask an AI agent to reason about the state machine. We can review the implementation.

Another approach is to model the workflow more explicitly in the persistence layer. We could have event-specific structures where each stage references the previous stage through a foreign key, with schemas specific to that event.

Conceptually:

Created
   ↓
Validated
   ↓
Processed
   ↓
Completed

Validated cannot exist without a corresponding Created. Processed cannot exist without the appropriate Validated record. Completed cannot exist without the preceding state.

Each event can also have a schema that expresses the data required for that particular stage.

Now the database isn't just storing the state of the workflow. It is helping enforce the workflow.

We have effectively moved part of the finite-state machine into the persistence model.

I'm not suggesting that this is always the right design. It introduces its own complexity and trade-offs, and there are many workflows where a simpler event table or a different state-machine implementation would be preferable. The important point is not that one particular architecture is universally superior.

The important point is that the architectural choice changes the cost of verification.

With the first design, we may need to repeatedly establish through application logic and tests that invalid transitions cannot occur.

With the second design, some invalid transitions simply cannot be persisted.

That is a very different property.

Make invalid states unrepresentable

This is an old idea in software engineering, but AI makes it increasingly valuable.

If we can make an invalid state unrepresentable, we don't need to repeatedly verify that nobody has accidentally created that state.

Consider the difference between these two statements:

"We have tests proving that this state should never happen."

and:

"The architecture makes this state impossible."

The second statement is much more powerful.

It means that a future developer doesn't need to remember the rule. A future refactor doesn't need to rediscover the rule. An AI agent doesn't need to infer the rule from a collection of tests and documentation. A code reviewer doesn't need to notice a subtle violation.

The constraint is part of the system.

This is what I mean when I talk about verification becoming an architectural concern. Architecture can determine not only what the system is capable of doing, but also what incorrect things the system is capable of doing.

AI makes these properties more valuable

This is where AI agents enter the picture, but I don't think the argument should be "design software for AI."

The better argument is that AI increases the rate at which software can change.

If the number of changes increases, the cost of verifying those changes becomes more important.

Imagine two systems. In the first, every change requires a human to reconstruct a complicated mental model of the system and determine whether a subtle invariant has been preserved. In the second, the architecture expresses many of those invariants through types, schemas, constraints, contracts, and automated checks.

The second system is not merely easier for an AI agent to work with. It is easier for everyone to work with.

The agent benefits because it has stronger boundaries and clearer feedback. Developers benefit because there is less implicit behaviour to remember. Code reviewers benefit because more correctness properties are mechanically enforced. Operations benefit because fewer invalid states can reach production.

AI simply makes the difference more visible because we are increasing the volume and speed of change.

If AI can produce changes faster than humans can safely verify them, then architectures that reduce the cost of verification become increasingly valuable.

Verification is a recurring cost

This is probably the most important economic point.

Suppose Architecture A costs 10% less to implement but requires significantly more effort to verify every time it changes.

Architecture B costs 10% more to implement but gives us strong structural guarantees that dramatically reduce the cost of verification.

If we only look at the initial project, Architecture A may look attractive.

But software is not a project that ends when the feature ships. It is a system that continues changing for years.

The implementation cost happens once. The verification cost happens again and again.

Every feature built on top of the system pays some of that verification cost. Every refactor pays it. Every migration pays it. Every AI-generated change pays it.

This creates a compounding effect.

A small amount of additional complexity that buys a strong, reusable verification guarantee can potentially pay for itself many times over.

This is why I think architecture discussions need to consider the lifetime economics of verification, rather than treating testing and verification as something that happens after architecture has already been decided.

Verification as a first-class quality attribute

We already talk about architecture in terms of qualities such as performance, scalability, reliability, security, availability, and maintainability.

I think we should increasingly ask another question:

How verifiable is this system?

Not simply:

"How easy is it to write tests?"

But:

"How cheaply and reliably can we establish that this system is behaving correctly?"

Those are different questions.

A system can have excellent test coverage and still be difficult to verify. It might have complicated state transitions, implicit dependencies, weak contracts, highly coupled components, or many possible invalid states.

Conversely, a system can be designed so that its structure itself provides useful guarantees.

That could mean strong types. It could mean database constraints. It could mean explicit state machines. It could mean narrow interfaces, deterministic components, schemas, transactional boundaries, idempotent operations, or other forms of architectural constraint.

The common property is that correctness becomes cheaper to establish.

This changes architecture trade-offs

I think this also changes how we should evaluate competing solutions.

Historically, we might ask:

Which solution is cheaper to build?
Which one is simpler?
Which one performs better?
Which one is easier to maintain?

Those questions still matter.

But I think we should add:

Which solution is cheaper to verify?
Which solution makes more invalid states impossible?
Which solution gives us stronger automated guarantees?
Which solution makes regressions easier to detect?
Which solution reduces the amount of behaviour that humans have to repeatedly reason about?
Which solution gives automated agents better boundaries and feedback?
Which solution reduces the blast radius of an incorrect change?

The interesting thing is that these questions can change the answer.

A solution that costs more to implement can be the economically better solution if it substantially reduces the recurring cost of verification.

And this doesn't mean the most constrained architecture always wins. Constraints have costs too. Excessive constraints can make a system unnecessarily rigid, difficult to evolve, or more complicated than the problem warrants.

The point is not to maximise constraints.

The point is to recognise that constraints have economic value when they reduce the cost of establishing correctness.

The question I now want to ask during architecture discussions

Coming back to that conversation at work, I still agree with the stakeholder's principle: the user should come first.

But I now think there is a missing dimension in how we reason about what is best for the user.

The question isn't:

"Which architecture is easiest for the AI?"

Nor is it simply:

"Which architecture is cheapest to implement?"

The question is closer to:

"Which architecture gives us the best overall outcome for the user, given the lifetime cost of building, operating, changing, and verifying the system?"

Sometimes the answer will be the simplest possible implementation.

Sometimes it will be the architecture that is easiest for an AI agent to modify.

Sometimes it will be an architecture with significantly more upfront complexity because that complexity gives us guarantees that would otherwise have to be repeatedly verified.

And sometimes the right answer will be something completely different.

The important thing is that verifiability is now part of the trade-off.

The architecture should help us prove that it is correct

AI-assisted development is often discussed in terms of how quickly we can produce software.

I think that is only half of the story.

If AI makes implementation dramatically cheaper, then our scarce resource increasingly becomes the ability to establish that what we produced is correct.

That means the architecture of a system is no longer just about making the desired behaviour possible. It is also about making incorrect behaviour difficult to express, easy to detect, and cheap to rule out.

The most interesting architectural decisions may therefore be the ones that turn verification from a recurring human activity into a property of the system itself.

Because the ultimate goal isn't to build software that AI can generate quickly.

It's to build software that we can continuously establish is correct.

And if we can design the architecture so that the system helps us do that, then verification stops being something we bolt onto the end of development.

It becomes part of the architecture.

Do We Still Need Code Reviews in the Age of Coding Agents?

Remo H. Jansen — Sun, 27 Sep 2026 08:25:14 +0000

For most of my career, code review has been a fairly simple idea.

One engineer writes some code, opens a pull request, and another engineer reviews it before it gets merged. The second engineer looks for bugs, questions design decisions, suggests improvements, and ultimately gives the team another level of confidence that the change is safe to ship.

It is such a normal part of software development that we rarely stop to question the assumptions behind it.

One of those assumptions is that another engineer wrote the code.

That assumption is becoming less reliable.

Today, a coding agent can implement an entire feature, run the tests, fix failures, refactor the implementation, and prepare a pull request. The engineer who opens that pull request may have spent most of their time reviewing and directing the agent rather than writing the code themselves.

This makes me wonder whether our traditional code review process still makes sense.

Not because I think code review is obsolete. I think the opposite is true: we need verification more than ever.

But I think we need to change how we think about code review.

What was code review actually for?

Before we decide what should happen to code review, it is worth asking what problem it was solving in the first place.

When one engineer writes a change and another engineer reviews it, we get a second set of eyes. The reviewer might catch a bug the author missed, notice that an abstraction is wrong, identify an edge case, question an architectural decision, or simply ask why something was implemented in a particular way.

There is also a social dimension to code review. It creates shared ownership and knowledge across a team. The code does not belong exclusively to the person who wrote it.

All of that remains valuable.

But not every part of the traditional process is equally valuable when the author is an AI agent.

I have started thinking about coding agents as something like flawed peers.

Imagine that you are a seasoned engineer and you have a very fast colleague who is capable of producing an enormous amount of code. They can work tirelessly, know an impressive amount about software development, and solve many problems very well. At the same time, they are inexperienced in your particular system and can occasionally make mistakes that seem obvious in hindsight.

You would not blindly merge their work.

You would review it.

You would give them clear constraints.

You would run automated checks.

You might ask another specialist to look at particularly important changes.

That sounds quite a lot like the agentic development workflow we are building now.

The engineer opening the PR is already a reviewer

This is where I think our traditional PR rules start to become interesting.

Suppose a team has historically required one human review for every pull request.

The traditional workflow looks something like this:

Engineer A writes the code → Engineer B reviews the code → merge.

Now consider an agentic workflow:

Agent writes the code → Engineer A reviews the code → Engineer A opens the PR → merge.

If Engineer A has genuinely reviewed the implementation, understands the change, and is willing to take ownership of it, what exactly are we gaining from requiring another human to perform a second generic review?

The PR being opened does not magically make the code more trustworthy.

The meaningful event happened before that: an engineer examined the work and decided that they were prepared to own it.

This is why I think we should be careful about treating approval counts as a proxy for quality.

If your previous process required one review, I think there is a reasonable argument that an agent-generated change which has been thoroughly reviewed by the engineer opening the PR may not need another generic human approval.

If your process required two human reviews, then perhaps the agent-generated change gets one human review by the owner and one additional human review after the PR is opened.

The exact policy will depend on the risk of the system and the kind of change being made.

The important part is the principle:

The number of approval buttons pressed is not the same thing as the amount of verification performed.

Trust the engineer, get ownership in return

There is also a cultural issue here.

If an experienced engineer reviews an agent-generated change, opens the PR, and says "I am happy to own this", I think we should take that statement seriously.

We often say that we want engineers to have ownership.

But ownership without trust is difficult to achieve.

If we tell engineers that they are responsible for the code but then require another person to validate every decision they make, we are creating a system where responsibility and authority do not quite match.

I would rather move toward a model where we say:

You reviewed it. You understand it. You own it.

In return, we should expect engineers to take that responsibility seriously.

This does not mean trusting every change equally. A production database migration, authentication change, or financial transaction workflow deserves a different verification strategy from a small UI change.

It means that our process should respond to risk and uncertainty, rather than blindly applying the same number of reviewers to every pull request.

The bigger problem is code volume

There is another problem that I think is even more important.

Coding agents make producing code dramatically cheaper.

That is fantastic.

It also creates a problem.

If generating code becomes cheap enough, the amount of code produced can increase much faster than the amount of human attention available to review it.

We cannot solve that problem simply by adding more reviewers.

If an agent produces ten times more code and our answer is to have humans manually inspect ten times more code, we have simply moved the bottleneck from writing software to verifying software.

Human attention is scarce.

So we need to become much more selective about where we spend it.

Don't review what you can make unrepresentable

This is where architecture becomes a much more important part of code review.

There are many classes of bugs where I would rather not depend on a reviewer noticing the problem.

I would rather design the system so that the incorrect implementation is difficult or impossible to represent.

Consider a database schema.

If the database requires a value to satisfy a particular constraint, we don't need to rely entirely on every application developer remembering to validate that constraint correctly. The database can enforce it.

Or consider a business workflow.

If a process can only move from Pending to Approved or Rejected, we can represent those states explicitly rather than allowing arbitrary strings and hoping that every piece of application code handles them correctly.

Finite state machines are a good example of this approach. The architecture itself describes which transitions are valid and which are not.

The same idea applies to types, contracts, API boundaries, validation, generated code, static analysis, automated tests, and many other forms of explicitness.

The goal is not to make developers more careful.

The goal is to make certain mistakes impossible.

That changes the economics of code review.

Instead of asking a human to inspect every line and think about every possible failure mode, we can move some classes of verification into the system itself.

The reviewer can then spend their limited cognitive capacity on the things that actually require human judgment.

Verification becomes a layered system

This suggests a different model for reviewing agent-generated code.

At the bottom, we have constraints and architecture that prevent entire classes of incorrect implementations.

Above that, we have automated verification: type checking, tests, static analysis, security scanners, contract tests, database constraints, CI checks, and whatever else is appropriate for the system.

Then we have the engineer who reviews the change and takes ownership.

And for changes where we want additional confidence, we can add another layer.

Adversarial agents.

What if the reviewers were agents too?

We don't necessarily have to choose between one human review and three human reviews.

We can introduce specialized agents whose job is not to approve the code, but to try to find reasons why we should not trust it.

Imagine an agent whose only responsibility is security.

It reviews the change and asks questions such as: "Can this input be manipulated? Did we introduce an authorization bypass? Are there new injection opportunities? Did this change expose something that should remain private?"

Another agent might specialize in performance.

It could look for expensive queries, unnecessary allocations, N+1 database access, contention, excessive network calls, or other performance problems.

We could have agents specializing in reliability, backwards compatibility, API design, testing, accessibility, architecture, or whatever concerns are particularly important to a given system.

The important part is that these agents have specialized responsibilities.

I don't want ten generic agents saying "LGTM."

I want adversarial agents trying to break my confidence in the implementation.

The security agent should be trying to find a security problem. The performance agent should be trying to find a performance problem. The architecture agent should be trying to find an architectural violation.

And, just like the coding agent, we should remember that these are flawed peers.

A security agent does not prove that our application is secure. A performance agent does not prove that the system is fast.

They provide another independent attempt to find problems.

That can still be extremely valuable.

More verification without a longer delivery cycle

This gives us an interesting alternative to the traditional approach.

Today, if a change is considered important, we might respond by adding more human reviewers.

That increases the amount of human attention required and can increase the time it takes to get the change through the development process.

In an agentic workflow, we have another option.

We can increase the amount of verification without necessarily increasing the number of humans involved.

For example:

Coding Agent
     |
     v
Engineer reviews and takes ownership
     |
     +------> Security Agent
     |
     +------> Performance Agent
     |
     +------> Architecture Agent
     |
     +------> Testing Agent
     |
     v
Automated verification
     |
     v
Merge

Not every change needs every agent.

A documentation change probably does not need a performance review. A database migration probably deserves more scrutiny than changing a button label.

The important thing is that verification can become composable.

We can assemble the verification pipeline according to the risk of the change.

Code review at scale

This leads me to a slightly different way of thinking about code review.

The answer to having more generated code is not necessarily to review more code.

It is to make less code require human review.

We can do that in several ways.

We can use architecture and constraints to make certain incorrect implementations unrepresentable.

We can use automation to verify things that machines are better at checking than humans.

We can use specialized adversarial agents to search for specific categories of problems.

And then we can use human engineers for the decisions where human judgment actually matters.

Does this solve the right problem?

Is this the right abstraction?

Does this fit the architecture?

Are the trade-offs appropriate?

Does this behavior make sense for the business?

Is this something we actually want to own and operate?

Those are difficult questions to reduce to a simple automated check.

Checking whether a database column is nullable is not.

Checking whether an API contract is backwards compatible is often automatable.

Checking whether every state transition is valid can be encoded into a state machine.

The more of these things we can move out of human cognition, the more effectively humans can review the things that remain.

The PR isn't dead

I don't think code reviews are going away.

I think the meaning of a code review is changing.

When humans wrote most of the code, the natural workflow was for another human to inspect the author's work.

When agents write most of the code, the engineer's role becomes less about being the person who typed the implementation and more about being the person who understands it, verifies it, and takes responsibility for it.

That doesn't mean we should blindly trust agents.

Quite the opposite.

It means we should build better verification systems around them.

Some verification should happen through architecture. Some through constraints. Some through automation. Some through specialized adversarial agents. And some through experienced engineers exercising judgment.

The goal shouldn't be to remove verification in order to move faster.

The goal should be to increase verification while reducing the amount of expensive human attention required for it.

Maybe the question for the agentic era isn't:

"How many engineers need to review this PR?"

Maybe it is:

"What is the cheapest reliable way to gain confidence in this change?"

Sometimes the answer will still be another human.

Sometimes it will be an agent.

Sometimes it will be a test, a type, a database constraint, or an architectural decision that makes the bug impossible.

And sometimes, if an experienced engineer has already reviewed the work and is willing to own it, perhaps the answer is simply to trust them.

Revisiting the Toyota Production System (TPS) in the Age of Coding Agents

Remo H. Jansen — Wed, 23 Sep 2026 23:36:43 +0000

Software has borrowed a surprising amount from manufacturing. Not from manufacturing in the sense of “let’s put programmers on an assembly line.” Thankfully, we’ve tried enough variations of that idea already.

I mean something more interesting.

Some of the most influential ideas in modern software development came from looking at how Toyota transformed manufacturing. Lean Software Development, Kanban, limiting work in progress, reducing waste, optimizing flow, continuous improvement, pull systems—many of these ideas have a lineage that leads back to manufacturing.

And at the center of that story is the Toyota Production System (TPS).

Toyota describes TPS around two pillars: Jidoka and Just-in-Time. Jidoka is roughly “automation with a human touch”: when an abnormality is detected, the process stops rather than continuing to produce defective products. Just-in-Time is about producing what is needed, when it is needed, and in the amount needed.

These ideas were developed for a world of physical products. But we are entering another period where software development is changing dramatically—and this time, the manufacturing analogy might be useful for a completely different reason.

I. The Software Bottleneck Is Moving

For most of the history of software development, producing software was expensive. Writing code took time. Understanding a codebase took time. Testing, debugging, and reviewing code all took time. Because developers are human, all of these activities were constrained by the number of humans available to perform them.

We built processes around this constraint:

IDEs to make writing code faster
Languages & Frameworks to make code easier to express
CI Systems to automate testing
Agile & Kanban to improve feedback loops and flow

Then coding agents arrived. Suddenly, the cost of producing code changed. An agent can read a codebase, modify dozens of files, run commands, inspect test results, make another change, and repeat the process without waiting for a human to type every line.

The production capacity of software development can increase dramatically. But if an agent can produce changes faster than we can establish that those changes are correct, we have created a new bottleneck: Verification.

TRADITIONAL SOFTWARE

┌──────────────┐
│ Human writes │
│    code      │
└──────┬───────┘
       │
       ▼
┌──────────────┐
│ Verification │
└──────────────┘

Production and verification are relatively balanced.

AI CODING AGENTS

┌──────────────────────────────┐
│                              │
│      CODE PRODUCTION         │
│                              │
│          ████████████        │
│          ████████████        │
│          ████████████        │
│                              │
└──────────────┬───────────────┘
               │
               ▼
        ┌──────────────┐
        │ VERIFICATION │
        │      █       │
        └──────────────┘

The factory produces faster than quality control can inspect.

That is a manufacturing problem, and manufacturing has spent a very long time thinking about it.

II. Looking at the Factory Floor Again

The answer is not to blindly copy Toyota. Software has no physical inventory, no physical assembly line, and no truck waiting for parts. But the underlying challenges are identical:

How do you prevent defects?
How do you detect problems as early as possible?
What should happen when an abnormality occurs?
How much unfinished work should be allowed to accumulate?
How do you improve the production process rather than merely inspecting its output?
How do you increase production speed without increasing the rate at which defects escape?

These are the exact questions that led to modern manufacturing quality practices.

III. Jidoka & The Software Andon Cord

Of all the Toyota concepts, Jidoka is the most interesting for AI coding agents. The basic idea is simple: if a machine detects an abnormality, it stops. The objective isn’t simply to detect defective products at the end of the line—it is to prevent the production of more defective products in the first place by building quality directly into the process.

A conventional automated system behaves like this:

Produce → Produce → Produce → Inspect → Discover Problem

Jidoka aims for something different:

Produce → Produce → Detect Abnormality → STOP

Imagine an agent working on a task. It modifies several files sequentially. Tests pass until an important invariant breaks. A naïve agent continues attempting fixes randomly:

Test failed. I’ll try another approach… and another… and another.

In doing so, it accumulates a massive amount of unverified state. A Jidoka-inspired agent behaves deliberately:

Agent Makes Change
       │
       ▼
  Verification
       │
       ▼
Abnormality Detected ──► STOP ──► Investigate ──► Fix ──► Verify ──► Continue

The agent should not merely be capable of stopping; it should be designed to stop.

The Andon Cord

Toyota uses an Andon signal to make abnormalities visible and draw immediate attention to the point of failure. While software already uses crude signals like failed CI builds or production alerts, AI agents allow us to make every invariant an Andon cord:

❌ Type safety violated
❌ API contract changed
❌ Security policy violated
❌ Migration is destructive
❌ Test coverage dropped
❌ Performance budget exceeded

The critical distinction is that the signal is not just a passive warning displayed on a dashboard; it is an active control mechanism. The agent loses permission to continue until the abnormality is resolved.

IV. Poka-yoke: Mistake-Proofing the Environment

Poka-yoke focuses on using fail-safe mechanisms to avoid simple mistakes entirely. We tend to frame software verification as:

“How can we detect whether the agent made a mistake?”

A far better question is:

“Can we make it impossible for the agent to make this particular mistake?”

If an agent needs to modify a database, giving it unrestricted access relies on post-hoc testing to catch dangerous operations. Designing a poka-yoke environment changes the interface:

┌───────┐      ┌──────────────┐      ┌──────────────┐      ┌──────────────────┐
│ Agent │ ───► │ Database Tool│ ───► │ Policy Layer │ ───► │ Allowed Operation│
└───────┘      └──────────────┘      └──────────────┘      └──────────────────┘

A destructive operation simply isn’t available through the interface. The agent cannot execute it because the capability does not exist in that context.

This applies equally to dependency installation, secret access, schema migrations, and permission changes.

Core Design Principle: Don’t teach the agent not to make a mistake when you can design the system so the mistake cannot be made.

V. Quality at the Source & WIP Limits for Uncertainty

An agent executing a dozen changes before running verification creates a massive search space when a failure inevitably occurs. Diagnosing which assumption failed becomes exponentially harder as unverified work accumulates.

AI coding agents require a concept similar to Work-in-Progress (WIP) limits. Instead of tracking open tickets, we should limit the amount of unverified change in the system.

    Make Small Change
            │
            ▼
         Verify
            │
            ▼
    Make Another Change
            │
            ▼
         Verify

Consider an agent operating with a Verification Debt budget:

Unchecked Invariant = +1
Unvalidated Dependency = +1
Unverified Integration = +1
Verification Debt = 0: Agent proceeds freely.
Verification Debt = 3: Agent must verify before taking further actions.
Verification Debt = 5: Agent is stopped completely.

VI. The Economics of Inspection

Not every verification step needs to carry the same execution cost. Cheap defects must be caught cheaply through a tiered inspection pipeline:

┌───────────────────────────────────────────┐
│              Syntax / Parsing             │  ◄── Fast / Cheap
├───────────────────────────────────────────┤
│               Type Checking               │
├───────────────────────────────────────────┤
│              Static Analysis              │
├───────────────────────────────────────────┤
│                Unit Tests                 │
├───────────────────────────────────────────┤
│               Contract Tests              │
├───────────────────────────────────────────┤
│             Integration Tests             │
├───────────────────────────────────────────┤
│              E2E / Behavioral             │
├───────────────────────────────────────────┤
│          Adversarial Verification         │  ◄── Slow / Expensive
└───────────────────────────────────────────┘

If an agent references a non-existent function, it should not require a 45-minute integration suite to catch it. In a high-throughput environment where an agent generates dozens of candidate changes an hour, optimizing the verification loop itself is critical to preventing systemic bottlenecks.

VII. Process Control and Root-Cause Analysis

Statistical Process Control

In traditional manufacturing, quality control monitors the process, not just individual outputs. If an agent’s defect rate suddenly spikes, focusing only on single test failures misses system-level shifts (e.g., context window truncation, degraded model weights, altered tool behavior, or stale API specs).

Tracking process-level metrics provides visibility into the health of the system:

Metric	Target Baseline	Out-of-Control State
Compile Failures / 1,000 Changes	0.7%	4.8%
Test Failures / 1,000 Changes	3.1%	8.2%
Reverted Changes	0.9%	5.7%
Security Findings	0.03%	0.11%

When metrics breach baseline thresholds, the relevant question isn’t “Is this code change bad?” but “Has the production process itself gone out of control?”

Human Review Shifts Upward

When an engineer oversees dozens of autonomous agents, manual line-by-line code review becomes impossible. The human role shifts from reviewing individual diffs to evaluating the integrity of the generation process: verification coverage, failure patterns, architectural invariants, and root causes.

Kaizen (Continuous Improvement)

When a failure occurs, the agentic loop should produce process knowledge rather than simply retrying:

Test Fails ──► Containment ──► Identify Abnormality ──► Root-Cause Hypothesis ──► Fix & Regression Protection

Every failure should permanently update the system constraints:

Agent Task Fails (Stale API Docs)
              │
              ▼
    Add Contract Test
              │
              ▼
   Update Agent Constraint
              │
              ▼
  Improved Production System

VIII. End-to-End Traceability

When a defect manifests in production months after deployment, tracing its origin in an agent-generated codebase requires a complete provenance chain:

Requirement → Agent Session → Model/Version → Context & Tools → Verification Logs → Human Approval → Commit

Understanding defect origin shifts our diagnosis from “Who wrote this code?” to “What production process generated this code, and where did that process fail?”

IX. Conclusion: The Quality System Is the Deliverable

The conversation around AI coding agents focuses heavily on the agent itself: which model, which benchmark, which context window, which reasoning capabilities.

These factors matter, but the system surrounding the agent will ultimately matter more. A mediocre agent operating inside an exceptional verification environment will consistently outperform a brilliant agent operating inside a weak one.

The future of autonomous software engineering is less about building an AI that never makes mistakes, and more about building a production system in which mistakes are cheap, contained, visible, and quickly corrected.

The first wave of Lean software development optimized for flow, reduced batch sizes, and shorter feedback loops. The next evolution will focus on verification. As production costs drop toward zero, quality engineering becomes the primary constraint.

The most important question in modern software development is no longer “How do we build software faster?”

It is: “How do we build a system that produces software extremely fast without letting defects escape just as fast?”

Why the Best Software Advice Is the Hardest to Follow

Remo H. Jansen — Tue, 22 Sep 2026 13:19:12 +0000

Not all software advice is created equal. Some advice is practical. It tells you exactly what to do:

Write small functions.
Keep functions focused.
Use constants instead of magic numbers.
Give variables meaningful names.
Keep your classes small.

This kind of advice is useful because it is easy to understand, easy to teach, and easy to verify. You can look at a piece of code and ask: Is this function too large? Is this a magic number? Is this constant named correctly?

There is usually a relatively clear answer. And because this advice is so easy to follow, it tends to spread. Teams put it into coding standards. Linters enforce it. Code reviews check it. Developers learn it early in their careers. But there is another kind of advice. It is much harder to follow. And, in my experience, it is often much more valuable.

Two kinds of advice

I think about software advice as belonging roughly to two categories. The first is practical advice. It is close to black and white:

Do this.
Don't do that.

The second is judgment-based advice.

It doesn't give you a recipe. Instead, it gives you a principle that you have to interpret depending on the situation. It might even contradict another principle you have learned. This kind of advice is closer to a balance between two opposing forces. There isn't always a universally correct answer. And that's what makes it difficult.

Practical advice is easy to scale

Take a piece of advice like:

Write small functions.

That's generally useful advice. A junior developer can understand it. A senior developer can teach it. A code reviewer can point at a 200-line function and say, "This should probably be split up."

The same is true for advice such as:

Don't use magic numbers.

Or:

Use meaningful names.

Or:

Keep your classes focused.

These are great pieces of advice because they reduce the number of decisions you need to make.

You don't need years of experience to understand what they mean. You can learn them from a book, apply them tomorrow, and see an immediate improvement. This is one of the reasons books like Clean Code became so influential. A large part of the advice is actionable.

You can take a principle and immediately translate it into something you do while writing code. And that's valuable. But there is a danger. We can start confusing following good practices with becoming a good engineer.

When advice stops being black and white

Consider a different piece of advice:

The wrong abstraction is more costly than duplication.

This sounds simple, but try turning it into a rule. Should I duplicate this code? Sometimes yes. Sometimes no.

How much duplication is acceptable?

How similar do two pieces of code need to be before they should be abstracted? What if they look similar today but are likely to evolve differently?

What if the abstraction makes the current code more complicated but might save us from duplication later? There is no simple checklist that answers these questions. You need judgment. And judgment comes from experience. You have to have seen abstractions that worked well. You also have to have seen abstractions that turned into monsters.

You need to experience the cost of changing an abstraction that was designed too early. You need to see duplication that was completely harmless. And you need to see duplication eventually become a maintenance nightmare. Only then does the advice start to become useful at a deeper level. It stops being a rule and becomes a way of thinking.

Experience changes the meaning of advice

This is something I find fascinating about software engineering. You can hear exactly the same advice at different stages of your career and understand something completely different each time. Early in your career, someone tells you: "Don't repeat yourself".

You learn DRY. So you start looking for duplication everywhere. Two pieces of code look similar? Abstract them. A few parameters are repeated? Create a common object. Several classes have similar behavior? Create a base class. You are following the advice. Then, years later, you encounter another principle:

Prefer duplication over the wrong abstraction.

And suddenly DRY doesn't look so simple anymore. You realize that duplication isn't necessarily the problem.

Sometimes duplication is the price you pay for keeping two concepts independent. Sometimes an abstraction creates more coupling than the duplication ever would have. Sometimes the best thing you can do is repeat yourself and wait until the domain tells you what the abstraction should actually be.

The advice didn't change. Your ability to interpret it changed. That's what experience gives you.

From rules to intuition

There is a point in your career where you accumulate enough examples that you start recognizing patterns before you can fully articulate them. You look at an abstraction and something feels wrong. You can't immediately explain it. You might say:

"I don't think we should abstract this yet."

Why? Maybe you've seen this exact situation before. Maybe you've experienced how these abstractions evolve. Maybe you recognize that two things that currently look identical are likely to change for completely different reasons.

This is where intuition starts becoming important. Intuition in software engineering isn't magic. It isn't a replacement for thinking. It is often the result of accumulated experience.

You've seen enough situations, failures, trade-offs, and consequences that your brain starts recognizing patterns automatically. The problem is that intuition is much harder to teach than a rule. I can teach you "Use small functions." in five minutes.

I can't give you five minutes of advice that will make you understand when a function is too large, why it is too large, and when splitting it would actually make the code worse. That requires experience.

The uncomfortable part of judgment-based advice

There is another reason this kind of advice is difficult. Sometimes two pieces of good advice conflict. You might hear:

Keep things simple.

And:

Don't duplicate code.

And:

Avoid premature abstraction.

And:

Encapsulate things that change.

All of these can be good advice. But what happens when following one makes it harder to follow another?

There is no compiler warning for this. There is no linter that can tell you which principle should win. You have to make a decision. And that decision depends on context.

This is why experienced engineers can sometimes disagree about a piece of code while both having perfectly reasonable arguments. The disagreement isn't necessarily because one person knows the rules and the other doesn't.

It may be because they're making different judgments about the future, the domain, the cost of change, or the risks involved. That's the gray area of software engineering.

Scrum is another interesting example

I think the same distinction can be seen outside of code. Consider Scrum and the Agile Manifesto. Scrum gives you something concrete. Roles, Events, Artifacts and Rules.

A team can learn Scrum and start implementing it relatively quickly. That makes it attractive to organizations. There is something reassuring about being able to say:

"We are doing Scrum."

There is a framework. There are defined practices. There are ceremonies you can schedule. There are artifacts you can create. There are things you can point to and say, "We're doing it."

The Agile Manifesto is different. It gives you four values and twelve principles, but it doesn't give you a complete operating manual for running a software organization.

It tells you things like valuing individuals and interactions over processes and tools, and responding to change over following a plan. Those statements require interpretation. They require judgment.

For example, valuing individuals and interactions over processes doesn't mean processes are useless. Responding to change doesn't mean planning is useless.

The interesting question is not:

"Which one do I follow?"

The interesting question is:

"How do I apply these principles in this particular situation?"

And that is much harder. You can implement Scrum without necessarily developing the judgment behind Agile.

You can have all the ceremonies, all the boards, all the roles, and all the terminology and still miss the underlying principles.

That's the difference between following a framework and understanding the principles behind it.

Why the easy advice wins

There is a natural reason practical advice dominates.

It is measurable.
It is teachable.
It is reviewable.
It is scalable.

A company can create a coding standard that says:

Functions should be small.

It is much harder to create a standard that says:

Use your accumulated experience and judgment to determine the appropriate level of abstraction for the current domain and its likely future changes.

The first can become a rule. The second requires a person who knows what they're doing. Organizations naturally prefer things that can be turned into rules. And this isn't necessarily bad. Practical advice is extremely useful. The problem starts when we believe that collecting enough practical rules will eventually give us good judgment.

It doesn't work that way. Knowing more rules doesn't automatically make you better at making trade-offs. At some point, you need to develop the ability to decide which rule matters in this situation.

The hardest advice may be the most valuable

This is why I think some of the most valuable software advice is also the hardest to follow.

It doesn't tell you exactly what to do.

It makes you think. It gives you a lens through which you can look at a problem. It might even force you to balance two competing ideas. And initially, that can be frustrating. We want software engineering to have recipes.

Tell me the right architecture.
Tell me when to abstract.
Tell me how big a function should be.
Tell me exactly when to introduce a design pattern.
Tell me the correct process for building software.

But software is built in contexts.

Different teams.
Different domains.
Different constraints.
Different people.
Different levels of uncertainty.

The more experience you gain, the more you realize that many of the most important engineering decisions don't have a universally correct answer. They require judgment. And judgment is difficult because you have to own the decision. There is no checklist to hide behind.

Maybe that's the real progression

Perhaps becoming a better software engineer isn't about replacing bad rules with better rules. Maybe it's about gradually moving from rules toward principles.

From:

"I was told to do this."

to:

"I understand why this is usually useful."

and eventually to:

"I understand the trade-off, and I can decide whether it applies here."

That's a much harder skill to develop. But once you develop it, practical advice becomes even more useful. You don't stop using the rules. You understand them better. You know when to follow them. You know when two rules conflict. And, perhaps most importantly, you know when not to follow them. That is where experience turns advice into wisdom.

What do you think?

I'm curious about your experience. What is the most pointless practical software advice you've encountered in your career? And on the other side: What is the most valuable piece of judgment-based advice you've learned? The kind of advice that didn't give you a rule to follow, but changed the way you think about software engineering.

I'd love to hear your examples in the comments.

Scrum is finally dead 🎉 and we have to thank Coding Agents for that

Remo H. Jansen — Wed, 16 Sep 2026 10:55:21 +0000

The funeral nobody is sad about

Let's be honest about something we've all been pretending not to notice.

Scrum is dead.

And almost nobody is sad about it.

We've spent twenty years standing in a circle every morning, moving tickets across a board, arguing about whether something is a 3 or a 5, and calling it "agility." We built an entire industry on top of it — certifications, coaches, tooling, dashboards. We turned a lightweight idea into a bureaucracy with a mascot.

And deep down, most of us hated it.

Here's the twist: the thing finally killing Scrum isn't a better methodology. It isn't a smarter framework with cleaner ceremonies. It's a capability shift. Coding agents have made the original promise of the Agile Manifesto — the actual promise, not the ritual we replaced it with — physically possible for the first time.

Scrum won because it was followable, not because it was right. And now something has come along that makes the right thing followable too.

So this is a eulogy. But bring confetti.

The Manifesto was correct — and that's exactly why it failed

Here's the part people get wrong.

The Agile Manifesto wasn't wrong. It was right. Read it again today and it still reads like common sense written by people who had suffered.

So why did it fail?

It failed because it was right in the wrong format. It gave us principles. And principles are the single hardest thing in the world to get an organisation to actually follow.

Think about the difference between a principle and a piece of practical advice.

Practical advice can be followed by anyone. "Stand up for fifteen minutes every morning." "Estimate your work in story points." "Work in two-week sprints." No judgment required. No experience required. Just compliance. You can teach it in an afternoon and audit it with a spreadsheet.

Principles are different. "Deliver value continuously." "Trust motivated individuals to get the job done." "Reflect regularly and adjust." You cannot checklist your way to those. They require intuition, gut feeling, and accumulated experience. You have to earn the judgment to apply them, and that judgment doesn't arrive on a training course.

And here is the uncomfortable truth about human beings:

We are biased toward the practical over the principled.

Give a large organisation a choice between a principle it has to internalise and a practice it can copy-paste, and it will pick the practice every single time. Not because people are stupid — because practices are legible, teachable, auditable, and certifiable. Principles are none of those things. You can't put "developed good judgment" on a Jira board.

So the market did what the market always does. It converted the principles into practices — and lost the soul in translation.

Scrum was that conversion.

It took a set of values that required wisdom and repackaged them as ceremonies that required only attendance. That's the whole reason Scrum won and "being agile" lost: Scrum was followable. It asked nothing of your judgment. It just asked you to show up to the standup.

This is exactly how Agile transformations fail. The gap between principles and practices is where every one of them goes to die. Leadership never commits to the principle; they adopt the artefact, misread it — the burndown chart becomes an obsession with output instead of a tool for reflection — and they end up with the precise opposite of what the Manifesto intended. A principle demands a missionary. A practice only needs a mercenary. And most organisations are staffed to hire mercenaries.

So the real question was never "were the Agile values correct?" They were.

The real question was: how do you get an organisation to honour principles it doesn't have the collective experience to internalise?

For twenty years, the honest answer was: you can't. So here's Scrum instead.

The Manifesto didn't fail because it was too idealistic. It failed because it trusted us to have judgment — and judgment doesn't scale by memo. Scrum scaled by memo. That's the whole tragedy.

Until now.

The principle that just became literally true

Look at one line from the Manifesto:

"Business people and developers must work together daily throughout the project."

This is the principle everyone paid lip service to and absolutely nobody achieved.

"Daily"? Come on. We got a fifteen-minute standup where a business stakeholder occasionally lurked, and a Slack channel where they dropped requirements like ransom notes. We put "collaboration" on the wall and then reintroduced every silo the Manifesto told us to tear down.

Working together daily was a principle. So of course we replaced it with a practice — a recurring meeting — and pretended that counted.

Now watch what agents do to that sentence.

For the first time in the history of this industry, business people and end users are the ones building. Not describing. Not requesting. Building. A domain expert who has never written a line of production code can now sit down with a coding agent and vibe-code the thing they actually want.

So "work together daily" stops being a meeting you have to schedule and start resenting. It collapses into a single artefact: a working prototype, produced by the person who understands the problem best.

You don't need business and engineering in the same room every day if the business already handed you running software.

The principle didn't get easier to follow. It stopped needing to be followed at all — because the technology now executes it by default.

Prototypes are the new requirements — and they're better than any ticket

Think about the old chain of custody for an idea.

Idea → Jira epic → refinement session → user story → acceptance criteria → estimate → sprint commitment → build → demo → "...that's not what I meant."

Every arrow in that chain is a place where value leaks out. Every handoff is a game of telephone played by people with different incentives and different vocabularies. By the time an idea reaches an engineer, it has been flattened into a ticket — a lossy proxy for a conversation that a business person had with themselves weeks ago.

The new chain is almost insultingly short.

The end user vibe-codes the thing they actually want → they hand engineering a working form of requirements.

That's it.

And a working prototype is a better requirement than any document we've ever produced. A spec describes. A prototype demonstrates. A spec says "the user should be able to filter the list." A prototype shows you exactly which filters, in what order, with what defaults, behaving in the specific way the person imagined but could never have written down.

I've always believed we should listen to our customers' problems, not their solutions. That's still true — but a prototype reveals the real problem far better than a feature request ever could, because you get to see what they reached for when nobody was translating for them.

This is executable discovery. It is the highest-fidelity requirement artefact we have ever had.

Now — an important caveat, because I don't want to sell you snake oil. The prototype is not the product. It's validated intent. It's a running, clickable, arguable statement of "this is what I mean." Engineering's job doesn't disappear. It changes — from "figure out what they meant" to "make this real, safe, scalable, and correct."

Which is a much better job than the one we had.

Jira is dead too 🪦

So let me ask the obvious question.

If the requirement is a running prototype, what exactly is the backlog for?

The ticket was always a lossy proxy for a conversation and an intent. Agents let us skip the proxy entirely. And once you remove the proxy, an enormous amount of ceremony has nothing left to justify it.

Here lies:

Sprint planning.
Story points.
Estimates.
Burndown charts.
Three-hour refinement marathons.
Velocity dashboards nobody trusted anyway.

Story points and Jira tickets were the ultimate practice-over-principle crutch. They were legible, auditable, and certifiable — which is exactly why they metastasised across every engineering org on earth. They gave managers something to point at. They never gave customers anything.

I've argued for years for no estimates, no time boxes, pull-based flow, and cost tracking over velocity tracking. Agents don't just make estimation undesirable — they make it absurd. Agent velocity is wildly unpredictable; a task that looks trivial takes six iterations, and a task that looks huge falls out in one prompt. Estimating that is superstition with a Fibonacci sequence attached.

And let's say the quiet part out loud: a large chunk of the agile-industrial complex exists to manage a scarcity — human coding throughput — that is actively evaporating. When the bottleneck moves, the machinery built around the old bottleneck becomes theatre.

So what actually replaces Scrum?

Not another framework with new ceremonies. Please, not that.

What replaces it is a capability-driven loop:

Business people and end users turn intent into a prototype. Discovery becomes executable.
Engineering steers, hardens, verifies, and integrates. The role shifts from typing to judgment.
Everything is continuous, pull-based, and measured by outcomes rather than by sprints completed.

Notice what happened to the silo wall. It didn't get a door. It dissolved. Developers get pulled into discovery — because when implementation is cheap, understanding what to build matters more than how. And business people get pulled into building — because the tools finally let them.

And look at what got deleted in the process. Not automated — deleted. The whole tower of intermediaries that used to sit between the person with the problem and the person solving it. The business analyst who translated the need into a document. The scrum master who defended the ceremony. The project manager who maintained the Gantt chart. The proxy product owner who spoke for a user they'd never met. Layer after layer, each one added to compensate for the fact that the end user and the developer couldn't talk to each other directly.

Now they can. So the layers have no reason to exist.

This is where it gets interesting, because of Conway's law. Any system you build ends up mirroring the communication structure of the organisation that builds it. Stack up six layers of handoffs between the user and the code, and your software inherits all six — the seams, the misunderstandings, the compromises baked in at every translation. Conway's law never stops operating; you just get to choose how ugly the org chart it's copying is.

When you collapse the distance to a single hop — end user to developer, mediated by an agent instead of a committee — Conway's law is still true, but its blast radius shrinks to almost nothing. There are barely any communication seams left for the software to inherit. The negative version of Conway's law fades not because we repealed it, but because we finally stopped feeding it layers.

That's the Manifesto's cross-functional dream, except this time it isn't an aspiration you have to be disciplined enough to honour. It's just how the work flows.

The honest part: what could still go wrong

I'm celebrating, but I'm not naïve. I have one rule about AI that I'll never let go of: it's an amplifier, not a corrector. It accelerates whatever trajectory you're already on.

So here's the sober bit.

Verification is the new bottleneck. Anyone can now generate software that works-ish. Proving that it's correct, secure, performant, and maintainable is the scarce skill — and it's a skill agents cannot be fully trusted to perform on themselves. Prototypes-as-requirements only works if engineering owns the hardening layer with total seriousness.

Beware "good bad code" — code that is technically impressive but delivers no value, and its evil twin, code that looks fine and quietly ships a vulnerability. The vibe coders who ship without any verification will fail, and they'll fail fast. The winners are the ones who start with value and invest enough in verification to sustain it.

Killing Scrum removes a fake safety net. Sprints and story points never made your software correct; they just made your Gantt chart feel manageable. The real safety net — automated testing, security review, human judgment at the gate — now has to be built for real. The new failure mode isn't shipping slowly. It's shipping the wrong, unsafe thing faster.

Which brings us to the developer identity shift I keep banging on about. Our profession has lived by "talk is cheap, show me the code." Code is our identity. Letting go of it is painful. But the job was never the typing. The job was the judgment. Agents don't take the judgment away — they make it the only thing that matters.

Who wins and who's in denial

The winners are the teams that let end users prototype, treat those prototypes as requirements, and reinvest all the capacity they just freed up into the two things that actually matter now: discovery and verification.

The ones in denial are the organisations bolting agents onto Scrum. Asking an agent to produce story-point estimates. Running AI-assisted standups. Generating Jira tickets that no human will ever read, to feed a process whose only job was to ration a scarcity that no longer exists.

They will amplify their dysfunction — faster.

You cannot AI-transform your way out of a methodology whose entire purpose was to ration something that isn't scarce anymore.

The Manifesto wasn't wrong, just early

The Agile Manifesto's promise was never a lie. It was early. The values were correct; we just never had the technology to honour principles that demanded more judgment than an organisation could reliably muster. So we swapped the principles for practices, called the practices "agile," and spent two decades cosplaying the thing instead of living it.

Coding agents change that — not by giving us a new set of rules to follow, but by letting a principle finally be executed as a working artefact instead of admired as a poster on the wall.

Scrum served its purpose. It taught a whole generation to work in small increments and to at least look at their users. We can thank it for that. And then we can let it go.

Because Scrum didn't lose an argument.

It lost a job — now that business people and developers can, finally and literally, build together every day. 🎉

Turbocharge Coding Agents with Your Test Coverage

Remo H. Jansen — Wed, 16 Sep 2026 10:02:00 +0000

The original title of this post was ~~Turbocharge Your Test Coverage with Coding Agents~~ but then I changed it because the real competitive advantage isn’t using AI to write tests. It’s using high test coverage to let coding agents move at maximum speed without breaking your system.

The traditional view of testing

Most organisations still treat testing the old way. Tests ensure code quality. Tests catch bugs. Tests are a cost centre. We’ll add them when we have time.

The result is painfully familiar. Low coverage creates fear of change. Fear of change produces slow delivery. Slow delivery frustrates teams. Frustrated teams feed a downward spiral of doom where everyone knows the codebase is brittle, yet nobody wants to touch it.

The paradigm shift

There’s a better way to think about this. Tests are not primarily about quality. They’re about speed.

High test coverage is your licence to move fast. With low coverage the dominant question is always “Will this break something?” With high coverage it becomes “Let’s ship it.” Manual regression testing gives way to automated confidence. Fear of refactoring turns into fearless improvement. Slow, careful changes become fast, bold iterations.

When the suite is solid, changing code stops feeling dangerous. That psychological shift is more valuable than any individual bug the tests happen to catch.

The AI speed paradox

Without tests, coding agents create a new kind of bottleneck.

You ask the agent to refactor a service. Seconds later it hands you the new code. Then the real work begins: hours spent manually verifying that nothing broke. The agent was fast. The human became the bottleneck again.

AI generates code in seconds. You spend hours verifying it. Net productivity gain is often minimal, sometimes negative. Tests are the trust layer that unlocks the speed AI actually promises.

The competitive advantage

Organisations that already have high test coverage and then add coding agents experience something different. They ship features three to five times faster. They refactor without anxiety. New developers onboard more quickly because the tests act as living documentation. Agents can carry the heavy lifting while humans stay focused on intent.

Organisations that adopt AI without solid tests get the opposite outcome. The agents generate code that no one fully trusts. Everything still requires manual verification. Delivery barely accelerates. The AI investment is largely wasted.

The difference isn’t the model. It’s the feedback loop.

Spec-driven development

This is where tests become more than verification. They become documentation of intent.

describe('RiskService', () => {
  describe('calculatePremium', () => {
    it('should apply 15% surcharge for high-risk categories', () => {
      // This IS the specification
    });

    it('should throw ValidationError when coverage exceeds $10M', () => {
      // This documents the business rule
    });
  });
});

When tests are written this way, three quiet but powerful things happen.

They become living documentation. The suite is always up to date—or the tests fail. It is executable, not just readable. It shows actual behaviour rather than intended behaviour.

They create shared understanding. Developers who write the tests develop a deeper grasp of the requirements. Edge cases surface during design instead of in production.

And they form a reliable refactoring safety net. The implementation can change freely as long as the behaviour remains correct. The specs keep the system honest.

What coding agents actually need

For an autonomous coding agent to be useful, it needs four things.

Clear goals—the specs (tests) define what success looks like.

A feedback mechanism—test results show progress.

Verification—passing tests prove the work is done.

Guardrails—existing tests prevent regressions.

Without those elements the agent is flying blind. There is no reliable way to verify correctness, and the human has to step back in as the slow, expensive verification layer.

The virtuous cycle

When the feedback loop exists, a different cycle emerges.

The agent receives instructions. It makes the code changes. The tests run. The agent fixes whatever fails. It loops until the suite is green.

Humans stay focused on the intent and on the edge cases the tests don’t yet cover. The agent iterates rapidly because the tests tell it whether it is getting closer to the goal.

A practical example

I built a custom Copilot agent specifically for coverage improvement. It analyses coverage reports, prioritises files by impact, writes tests incrementally, verifies after each change, and loops until the target coverage is reached.

The agent works because the existing suite already provides the feedback loop and the guardrails. Without that foundation it would simply generate more untrusted code.

The AI test pitfall

One warning is important.

AI is very good at writing tests that pass. It is much less reliable at writing tests that are correct.

// You write a buggy function
function add(a, b) {
  return a + b + 1; // Bug: adds an extra 1
}

// AI generates a test based on the current implementation
it('should add two numbers', () => {
  expect(add(1, 1)).toBe(3); // Passes. Wrong.
});

// The test you actually want
it('should add two numbers', () => {
  expect(add(1, 1)).toBe(2); // Fails. Correct expectation.
});

If you let the agent write the tests from the implementation, you risk locking the bugs in place. Intent must come first. Specs must precede code.

Key takeaways

Tests enable speed, not just quality. High coverage gives you the confidence to move fast. Low coverage produces fear-driven slowness.

Tests are specs. They are living documentation, executable requirements, and the single source of truth.

Tests enable AI. A reliable suite becomes the feedback loop and the trust layer for generated code. That is what finally unlocks the full potential of coding agents.

The organisations that understand this will not just write tests faster. They will move faster, refactor more freely, and let their agents do the heavy lifting while the system stays stable.

That is the real competitive advantage.

Maybe Enterprise Software Doesn’t Have to Suck Anymore

Remo H. Jansen — Mon, 14 Sep 2026 21:37:04 +0000

There is an uncomfortable truth about most non-tech enterprises: a lot of their software is insanely shit.

I don't mean that the engineers are shit. In many cases, the opposite is true. I've worked with plenty of smart engineers who were perfectly capable of building good software. The problem is that good software is expensive, and for a long time the economics of building it simply didn't make sense.

Think about the incentives inside a large enterprise. You have an internal system that employees have to use every day. The interface is confusing, the workflows are clunky, the codebase is a mess, and everyone knows it needs a serious refactor. Maybe there are thousands of lines of code that should be deleted. Maybe the architecture was designed ten years ago around assumptions that haven't been true for years. Maybe adding a simple feature now takes three weeks because nobody really understands how the thing works anymore.

The engineers know this. The users know this. Everyone complains about it.

And then someone proposes spending three months fixing it.

Why?

What exactly does the business get at the end of those three months?

There probably isn't a new customer. There isn't a new revenue stream. There isn't a shiny feature that can go into a quarterly presentation. Nobody in sales can put the refactor into a demo. The business has simply spent three months making something that already worked—technically speaking—less shit.

From the perspective of an executive looking at a roadmap, that's a difficult proposition to approve.

And in many enterprises, the incentives are even worse than that. The users aren't going anywhere. If you work for a bank, an airline, a government department, an insurance company, or some giant industrial company, you don't get to decide that you're going to use a competitor's internal software instead. You're using whatever system your employer gives you.

So why obsess over UX?

If your customers can leave, product quality matters enormously. If your customers are employees who have no choice, the incentive is very different.

This is one of the reasons I think a lot of terrible enterprise software actually makes sense.

Not to me, necessarily. But within the incentive structure of the organization, it can make perfect sense.

The company needs feature X by September. The team has four engineers. The existing system technically works. There is a giant backlog. Nobody has allocated time for a rewrite. The person responsible for the budget doesn't personally use the software. The person who understands the architecture is worried about hitting the deadline. And the consequences of making the code slightly worse won't show up on anyone's quarterly report.

So you ship it.

Then you ship the next thing.

Then the next thing.

And eventually you have a system that everyone hates.

The hidden cost of software everyone hates

The problem is that "the software technically works" is an incredibly low bar.

A piece of software can work perfectly well and still make thousands of people's lives slightly worse every single day.

A workflow that should take two minutes takes ten. A page that should load instantly takes thirty seconds. An employee has to enter the same information into three different systems. An error message tells them absolutely nothing. A form resets itself for no apparent reason. A button is hidden behind some bizarre legacy navigation. Nobody knows why the process works this way, but changing it feels too risky.

Each individual annoyance is tiny.

The problem is that these tiny annoyances compound.

If 5,000 employees waste ten minutes a day fighting with internal software, that's more than 200,000 hours of human time every year. And even that calculation misses something important: the psychological cost.

People don't just lose ten minutes.

They become frustrated.

They lose momentum. They have to remember workarounds. They start distrusting the systems around them. They learn that doing their job means fighting with the tools provided to them.

And eventually, they start hating the job itself.

We talk endlessly about employee engagement and morale. Companies spend fortunes on offsites, leadership programmes, wellness initiatives and motivational speakers. But there is something deeply absurd about trying to improve employee morale while forcing people to spend eight hours a day using software they hate.

Everyone knows that teams with low morale don't win championships.

We understand this intuitively in sports. Nobody looks at a dysfunctional football team and says, "It's fine, the players are still technically capable of running around."

We care about the environment in which people perform.

Software is part of that environment.

And yet, in many companies, the quality of the software employees use every day is treated as an engineering concern rather than a business concern.

The dinosaur problem

There is also a generational problem here.

A lot of people making technology decisions in large organizations didn't grow up thinking of software as a product. They grew up thinking of it as infrastructure: something the IT department provides so that the business can function.

You don't ask whether the electricity in the office has a delightful user experience.

You don't care whether the database has beautiful onboarding.

You just need it to work.

That mentality made a lot more sense when software was something employees occasionally interacted with. It makes considerably less sense when software is effectively the workplace itself.

But organizational thinking moves slowly.

Companies are enormous machines with long memories. The incentives, processes and mental models that made sense twenty years ago can survive long after the world that created them has disappeared.

And this is where I think something genuinely exciting is happening.

Coding agents are changing the economics of software quality.

The three-month refactor

Imagine that you have a horrible codebase.

For years, the engineering team has known that it should be cleaned up. Everyone has a list of things they would change if they had the time. But the time never comes.

The reason is not necessarily that management doesn't care. The reason is that the opportunity cost is enormous.

A traditional refactor might require one or two engineers to spend weeks or months understanding the existing system, designing the changes, implementing them, testing everything, fixing regressions and gradually migrating the code.

Three months is a long time.

And three months of engineering time is expensive.

Now imagine that instead of taking three months, an extremely capable coding agent can do a large part of the work in a day.

Not every refactor, obviously. Not every codebase. And certainly not without human oversight, testing and engineering judgement.

But the economic threshold has changed.

Something that previously required a three-month business case might now require an afternoon.

That is a completely different proposition.

AI makes quality economically viable

This is the part of AI-assisted programming that excites me much more than the promise of simply writing code faster.

I don't think the most interesting consequence of coding agents is that developers can produce more lines of code.

Frankly, the world already has enough lines of code.

The interesting consequence is that code quality itself can become economically viable in places where it wasn't before.

For a long time, software engineering involved an uncomfortable tradeoff. You could build the right thing, properly, but it would take longer. Or you could ship something that was good enough and move on.

There were always engineers arguing for the former, and there were always business pressures pushing toward the latter.

Sometimes the business won for perfectly rational reasons.

But what happens when the cost of doing the right thing falls by an order of magnitude?

Suddenly, the argument changes.

The refactor doesn't have to compete with the feature roadmap in the same way. The cleanup doesn't necessarily require taking a team off delivery for a quarter. The ugly piece of legacy code doesn't have to remain ugly simply because nobody can justify spending six weeks fixing it.

And perhaps most importantly, engineers don't have to spend as much time convincing people that quality matters.

This is a subtle but profound shift.

In the old world, if I wanted to spend three months improving a codebase, I had to convince someone that three months of engineering time was worth spending on something that users might not immediately notice.

I needed a business case.

I needed projections about future productivity.

I needed to explain how technical debt compounds.

I needed to convince someone to spend money today to avoid costs that might appear six months or two years from now.

That's hard.

But if the same improvement can be done in eight hours with an agent, the conversation becomes very different.

Maybe I don't need a business case.

Maybe I can just do it.

The software we already have

This is why I think the biggest impact of coding agents might not be that they allow us to build more software.

We already build an enormous amount of software.

It might be that they finally allow us to make the software we already have good.

There are millions of applications sitting inside organizations that are not fundamentally broken. They are just mediocre. They are slow, awkward, overcomplicated, badly structured and unpleasant to maintain.

And for years, that was the equilibrium.

The software was bad, but fixing it was too expensive.

So everyone learned to live with it.

Engineers learned the workarounds. Employees learned the weird workflows. Managers learned to accept the complaints. Executives learned that the system "worked."

The organization adapted itself around the limitations of its software.

That is a very strange thing when you step back and look at it.

We built computers to make people more productive, and then spent decades making people adapt their behaviour to accommodate the computers.

Coding agents could start reversing that relationship.

If an engineer can take a horrible codebase and dramatically improve it without blowing up the delivery schedule, the default assumption no longer has to be that technical debt is permanent.

Maybe the ugly code doesn't have to stay.

Maybe the terrible internal tool can actually become pleasant.

Maybe the three-month refactor becomes an afternoon.

And if that happens at scale, the consequences aren't just technical.

They are organizational.

Because when the software gets better, the people using it get better tools. When people have better tools, they waste less time. They get less frustrated. They can move faster. They spend less mental energy fighting the system and more energy doing the thing the system was supposed to help them do.

Good software isn't just a technical luxury.

It is part of the working environment.

And for the first time, we may be entering a world where making it good is cheap enough that even enterprises have less of an excuse not to.

Maybe the future of coding agents isn't that we'll write ten times as much code.

Maybe it's that we finally get to stop writing quite so much shit code.

Career safety in the Age of AI Layoffs

Remo H. Jansen — Sat, 05 Sep 2026 06:39:57 +0000

There is a strange contradiction happening in software engineering right now. A lot of developers are worried that AI is going to make them obsolete.

At the same time, the people building the most capable AI coding tools are demonstrating something that should probably make us rethink what being a software engineer actually means. I don't think the future is one where nobody understands software anymore. I think it is one where writing the software becomes dramatically cheaper.

And if that happens, the thing that makes an engineer valuable has to move. That is what I mean by career safety. Career safety isn't about making yourself impossible to replace. It is about making your value portable.

We've always resisted giving up the code

Developers have a long history of being suspicious of abstractions that take work away from us. We went from machine code to assembly, from assembly to higher-level languages, from manually managing memory to garbage collection, from building everything ourselves to libraries and frameworks, and from text editors to IDEs.

We even had entire categories of tools, such as CASE tools, designed to automate parts of software development. And every time, there was resistance. Because programmers don't just use code. We build our identities around it. John Carmack captured this unusually well when he wrote:

“Coding” was never the source of value, and people shouldn’t get overly attached to it. — John Carmack

He followed that with the more important point:

Problem solving is the core skill. — John Carmack

That is a difficult idea for developers to internalize because coding is tangible. You can point at the repository. You can point at the pull request. You can count the commits. You can say, "I wrote this."

But the business doesn't ultimately pay you for the number of lines you wrote. It pays you for what those lines accomplish.

The business never really bought the code

A company doesn't wake up in the morning thinking: "We need 14,000 more lines of TypeScript." It thinks:

"We need to reduce the cost of this process."
"We need to launch this product."
"We need to increase conversion."
"We need to satisfy this regulatory requirement."
"We need to reduce operational risk."
"We need to make our customers happier."

The code is the mechanism. The outcome is the value. That distinction matters enormously when the cost of producing code starts approaching zero.

And I think this is where the current AI discussion often goes wrong. The argument becomes: "AI can't write perfect code." Maybe. "AI still makes mistakes." Absolutely. "I had to spend an hour fixing what the AI generated." I've done that too.

But those observations don't answer the important question. How quickly is the capability improving? The code AI generated a year ago was often laughably bad. Today's systems are substantially better.

And the direction of travel matters more than whether today's models can replace every engineer. You don't need AI to become perfect for the economics of software development to change. You only need the cost of producing implementation to keep falling.

Linus Torvalds recently made essentially this pragmatic argument about AI in the Linux kernel:

“AI is a tool, just like other tools we use. And it’s clearly a useful one.”— Linus Torvalds

He went further, saying that decisions in the kernel should be based on:

“technical merit. Not fear of new tools.”— Linus Torvalds

That distinction is incredibly important. The question isn't whether AI is morally good or bad. The question is: Does the tool help us produce better technology?

If the answer increasingly becomes yes, then refusing to use it isn't protecting the profession. It is simply refusing a tool.

Understanding code isn't the same as typing it

This is where I think we need to separate two things that have become conflated. Understanding software and manually producing software are not the same skill.

A compiler already transforms the code we write into something else. Libraries allow us to avoid implementing primitives ourselves. Frameworks give us enormous amounts of functionality without us writing the underlying infrastructure. Garbage collectors manage memory we previously had to manage ourselves. IDEs autocomplete, refactor and navigate code for us.

Nobody seriously argues that using these tools means we aren't software engineers. AI is another step in the same direction. The difference is that this step is much larger.

Instead of automating one small part of implementation, AI can potentially automate substantial portions of the implementation itself. That doesn't make understanding less important. It makes understanding more important.

If I ask an AI system to build a payment workflow, I need to understand payments. If I ask it to design an insurance pricing system, I need to understand insurance. If I ask it to modify a distributed system, I need to understand distributed systems.

The machine can increasingly help with the implementation. It cannot magically give me the context that determines whether the implementation is the right thing to build. And that leads to what I think will become one of the biggest career advantages of the next decade.

Domain expertise becomes a moat

Imagine two engineers. The first is: Senior Full Stack TypeScript Engineer. The second is: London Specialty Insurance Product Engineer.

The first might be excellent at React, Node.js, TypeScript, databases and cloud infrastructure. The second understands specialty insurance. They understand brokers. They understand underwriting. They understand policies. They understand claims. They understand regulatory constraints. They understand how the business actually makes money. They understand which workflows are painful. They understand which problems are worth solving.

If AI makes software implementation dramatically cheaper, which of those profiles becomes more differentiated? Probably the second.

Because technology knowledge is increasingly becoming something AI can augment. Deep knowledge of a particular business domain is much harder to manufacture on demand.

This doesn't mean you should abandon technical expertise. Quite the opposite. It means you should combine technical expertise with domain expertise.

If you're working in finance, learn finance. If you're working in healthcare, learn healthcare. If you're working in insurance, learn insurance. Read the books. Understand the regulations. Talk to customers. Understand the economics. Learn how the industry actually works.

I increasingly think engineers should be reading as many books about their industry as they read about technology.

The engineer becomes a product person

This also changes the relationship between engineering and product management. For a long time, organizations could afford a relatively clean separation. Product people decide what to build. Engineers decide how to build it.

But what happens when the cost of implementation falls dramatically? The bottleneck moves. The scarce resource becomes knowing what should be built.

That makes product judgment increasingly valuable for engineers. Can you understand a customer's problem? Can you translate it into a useful product? Can you understand the business case? Can you identify the constraints? Can you decide what not to build? Can you describe the desired outcome precisely enough that a machine can implement it?

That last question is particularly important. Because the next generation of software engineering may look less like: "Give me a ticket and I'll write the code." And more like: "Give me a business problem and I'll turn it into a system of coordinated machines that can safely solve it."

The compression of the middle

There is another consequence of AI that is worth considering: it may not only reduce the amount of implementation work required, but also compress some of the intermediate organizational layers around engineering.

As AI makes it easier to gather information, analyze requirements, synthesize feedback, produce specifications, and coordinate work, roles such as analysts, Scrum Masters, and some forms of project or product coordination may become leaner. This doesn't mean these functions disappear, but fewer people may be needed to translate information between customers, product teams, and engineers.

That makes communication an increasingly important engineering skill.

An engineer who can speak directly with users, understand their problems, gather and synthesize feedback, identify patterns across different customers, and translate those patterns into general-purpose solutions could become considerably more valuable. Instead of simply implementing a requirement handed down through several layers of an organization, that engineer can participate directly in discovering the requirement.

This also changes what it means to be good at product management. Product thinking isn't simply about writing requirements or managing a backlog; it involves understanding people and their problems, communicating effectively, distinguishing individual requests from broader patterns, and deciding which problems are worth solving.

In a leaner organization, the engineer who can bridge the gap between user problem → product insight → technical solution may have significantly more leverage than an engineer who only receives a specification and implements it.

The interesting consequence is that AI may therefore make communication skills more important for engineers, not less. As the number of intermediaries decreases, the ability to communicate directly with the people experiencing the problem becomes increasingly valuable.

The next engineering skill is operating agents

I don't think the most interesting future is one where an engineer has one AI assistant open in their IDE. I think it is one where an engineer can operate a fleet of agents.

One agent investigates the existing architecture. Another implements a feature. Another writes tests. Another reviews the implementation. Another performs security analysis. Another evaluates performance. Another updates documentation. Another runs experiments. And potentially dozens or hundreds of these processes can operate in parallel.

At that point, the scarce skill isn't typing. It's orchestration.

You need to know how to decompose a problem. How to specify work. How to establish boundaries. How to give agents the right context. How to structure systems so that work can happen safely in parallel. How to verify the results. How to detect when an agent has gone off course. How to roll back changes. How to evaluate whether the system actually achieved the intended outcome.

In other words, the engineer moves up another level of abstraction. From writing code to causing valuable software to be produced.

And I think this is where Linus's pragmatism becomes especially relevant. His position isn't "let the machines do whatever they want." It's essentially the opposite. Use the tool if it is useful. Judge the result on technical merit. Don't confuse opposition to the tool with engineering quality.

The standard doesn't disappear because AI produced the code. If anything, the standard has to become more explicit.

Verification becomes more important than generation

There is an uncomfortable implication here. If one engineer can produce ten times as much implementation with AI, we cannot simply review ten times as much code manually. The old process breaks.

Today we often have:

Human → code → human review

Tomorrow we may have:

Human → specification → many agents → automated verification → human judgment

That requires a different engineering discipline. We need better architectures. Better tests. Better specifications. Better observability. Better evaluation. Better security controls. Better deployment boundaries. Better rollback mechanisms. Better ways of proving that the generated system does what we intended.

This is why I don't think AI makes engineering less important. It makes engineering discipline more important.

The amount of generated code may explode. Our ability to trust that code cannot depend on reading every line. We need systems that make correctness easier to verify.

So what actually makes a career safe?

This is the question I care about most. Because if coding becomes increasingly commoditized, simply becoming a better coder may not be enough. The answer, I think, is to build career capital in layers:

Technical depth

You still need to understand how software works. You need architecture. You need systems thinking. You need to understand databases, networks, distributed systems, security, reliability and the fundamentals of computing. AI doesn't remove the need for this knowledge. It gives you more leverage if you have it.
Domain expertise

Become unusually knowledgeable about something that matters to a business. Don't just be "a TypeScript developer." Become the engineer who understands a particular industry, market or class of problems deeply.
Product judgment

Learn to identify valuable problems. Understand customers. Understand economics. Understand trade-offs. Understand why something should be built, not just how.
Specification

Learn to turn ambiguous goals into precise systems and constraints. This may become one of the defining engineering skills of the AI era. The better you can specify a problem, the more leverage you can get from machines.
Verification

Learn how to determine whether a system is actually correct. Testing. Evaluation. Observability. Security. Performance. Failure analysis. Rollback. These skills become more valuable as the amount of machine-generated output increases.
Reputation

Build proof that exists outside your current employer. Write. Build open source. Contribute. Speak. Teach. Publish. Create things people can see. Your employer can remove your job. They cannot remove the body of work you've built in public. That's what makes career capital portable.

Become replaceable at the task level

There is a strange career lesson hidden in all of this. I don't think you should try to make yourself irreplaceable. You should try to make yourself replaceable at the task level.

If an AI can write the CRUD endpoint you used to spend half a day implementing, great. Let it. If an agent can write the tests, great. Let it. If a tool can refactor 50 files in seconds, great. Let it.

Your goal shouldn't be to protect those tasks. Your goal should be to move upward.

From implementation to architecture. From architecture to product. From product to domain. From individual tasks to systems of work. From writing code to deciding what code should exist in the first place.

The safest engineer isn't necessarily the one who can write the most code. It is the engineer who can create the most value when the cost of writing code approaches zero.

Coding was never the destination

This is why I keep coming back to Carmack's observation. Coding was never the source of value. It was the mechanism through which we created value.

For decades, writing software was expensive enough that the ability to write it well was itself a significant competitive advantage. AI changes that equation. And that is scary. But it is also liberating.

Because it forces us to ask what we should have been asking all along: What are we actually here to do?

We're here to solve problems. We're here to create useful products. We're here to improve businesses. We're here to make systems more reliable. We're here to reduce costs. We're here to create new possibilities.

Code is one of the tools that allows us to do those things. It is not the thing itself.

Linus's attitude toward AI is useful here because it cuts through a lot of the noise: Use the tool. Judge it on technical merit. Keep the engineering standards. And if the tool becomes genuinely useful, don't confuse refusing to use it with preserving engineering.

The future engineer may write less code than today's engineer. They may spend more time understanding a business. More time talking to customers. More time designing systems. More time specifying problems. More time verifying results. More time coordinating machines. And potentially produce vastly more valuable software as a result.

That's the career shift I'm preparing for. Not how do I make sure AI never replaces what I do? But: How do I become the person who can use AI to create more value than I could ever create by myself?

Because career safety doesn't come from protecting the work that machines are learning to do. It comes from developing the judgment, expertise and reputation to remain valuable when the work itself changes.

Update 1: Technical depth is still relevant

Based on a comment by @routinekit, I think it is important to clarify one point: we can’t completely forget about technical expertise.

I still believe that the implementation details — specific tools, frameworks, syntax, and even some programming languages — will become less important as AI becomes increasingly capable of handling them. But that doesn't mean technical knowledge becomes irrelevant. In some ways, the opposite is true.

The fundamentals become more important. Understanding protocols, computer architecture, operating systems, networks, databases, distributed systems, security, and how software behaves at a deeper level gives you the context needed to judge whether an AI-generated solution is actually good.

And there is another kind of knowledge that is much harder to automate: the intuition you develop after years of being burned by bugs in production.

Knowing that a particular architecture looks fine is one thing. Having an instinct that something is going to fail under load, that a seemingly harmless change could introduce a race condition, or that a system is going to become impossible to operate six months from now is something you develop through experience.

AI can help us implement and investigate these problems, but someone still needs to recognize when something doesn't look right and know what questions to ask.

So I don't think the future is about choosing between technical expertise and domain expertise. I think the most valuable engineers will combine both, deep technical fundamentals, strong domain knowledge, and the experience to use AI effectively while knowing when not to trust it.

The syntax may change. The tools will certainly change. But understanding how computers and systems actually work. Having the scars to prove you've learned from production remains valuable.

Calling All Cloud Providers: Let’s Build a Sustainable Funding Model for Open Source

Remo H. Jansen — Mon, 31 Aug 2026 13:47:12 +0000

Calling All Cloud Providers: Let’s Build a Sustainable Funding Model for Open Source

Open source powers an enormous part of the modern internet. Apache HTTP Server, Linux, Kubernetes, PostgreSQL, Python, NGINX, and thousands of other projects form the foundation of the applications and infrastructure that run on cloud platforms.

Yet a clear economic disconnect remains: cloud providers generate billions from workloads built on open source, while many of the projects creating that value struggle to fund maintenance and development.

There is a straightforward mechanism that could help close the gap.

What if cloud providers shared a small percentage of cloud consumption attributable to open-source projects?

Not as a new fee, surcharge, or software license, and without charging the customer anything extra. An open-source project could simply add a button in its GitHub repository:

[ Deploy to AWS — Support this project ]
[ Deploy to Azure — Support this project ]
[ Deploy to Google Cloud — Support this project ]

The button deploys the project into the user’s own cloud account at the provider’s normal prices. The user pays exactly what they would otherwise pay. The cloud provider receives its normal revenue. The only difference is an attribution identifier that records:

“This workload originated from this open-source project.”

The provider could then voluntarily return, for example, 1% of eligible cloud consumption to the project.

From the user’s perspective nothing changes: they keep their own cloud account, pay normal prices, and need not understand the attribution details. The important part is transparency—the project can clearly tell users that choosing a particular option may help support it through ordinary cloud usage.

An example

A user clicks Deploy to Azure to support this project and later spends $10,000/month on Azure:

	Amount
Customer’s Azure bill	$10,000
Azure keeps	$9,900
OSS project receives	$100
Additional customer cost	$0

The project sells nothing. The user makes no donation. Azure charges nothing extra. The project simply receives a small share of the consumption it helped drive. If that deployment represents incremental revenue Azure might otherwise have lost, the provider has effectively spent $100 to acquire or retain $10,000 of monthly consumption—an attractive customer-acquisition cost.

This is different from a cloud marketplace

AWS, Azure, and Google Cloud Marketplaces already let companies sell software. That model is useful, but it does not address free and open-source projects that have no commercial license, subscription, paid listing, SaaS product, or software fee.

Apache HTTP Server is free. The customer simply needs somewhere to run it. If they choose Azure, Azure earns the infrastructure revenue. Why shouldn’t a tiny portion of that revenue flow back to the project that helped make the workload possible? This is not about turning open source into a paid product. It is about recognizing that open-source projects can influence where and how cloud infrastructure is consumed.

Think of it as an OSS affiliate program

Affiliate marketing is a familiar pattern: a site refers a customer to Amazon; the customer buys something; Amazon shares a percentage of the revenue. The affiliate did not manufacture the product—it simply helped generate the transaction.

Cloud revenue sharing for open source could work the same way, except the referral is:

“My open-source project helped generate or influence a cloud workload.”

Instead of a one-time payment, the project could receive a small percentage of resulting consumption for a defined period. The exact percentage and duration would be set by the provider. 1% is only an illustrative example of a sufficiently small share.

Cloud providers already have pieces of the technology

This is not purely hypothetical. Microsoft Azure’s Customer Usage Attribution (CUA), for example, associates Azure usage with partner solutions and deployments at the time of deployment. That capability is very close to the core technical requirement: knowing which project influenced a particular cloud deployment.

The missing piece is the economic incentive. Attribution already helps providers understand the origin of consumption. Why not use it to create a sustainability mechanism for open source?

Why would a cloud provider do this?

Giving away 1% of revenue looks like a cost at first glance. The better framing is:

Would spending $10 increase the probability of generating or retaining $1,000 of cloud consumption?

If the answer is yes, the program is an interesting customer-acquisition and retention tool. Open source already possesses a vast distribution network—GitHub, documentation, tutorials, Stack Overflow, package repositories, Docker images, Kubernetes manifests, Helm charts, Terraform modules, blog posts, conferences, and developer communities. Cloud providers compete to become the place where that software runs. Giving the software itself an economic incentive to make cloud deployment easier is a natural extension of that competition.

The flywheel

Maintainers currently rely on donations, GitHub Sponsors, corporate sponsorship, consulting, support contracts, foundations, grants, employment, dual licensing, or venture funding. Those channels remain valuable. Cloud revenue sharing would simply add another path that links real-world usage directly to sustainability.

This could change the economics of open source

One of the largest problems in open source is that usage and funding are poorly correlated. A project can have millions of users and still struggle financially. Cloud revenue sharing would create a tighter relationship:

usage → value → sustainability

instead of

usage → popularity → hope someone sponsors us

It would not replace existing models; it would complement them.

Attribution should favor the projects that need it most

The hardest practical question is attribution. When a user deploys an application that sits on top of Kubernetes, Ubuntu, PostgreSQL, Terraform, and a dozen other layers, who should receive credit?

In practice, the core infrastructure projects are often relatively well-funded. Foundations, corporate sponsors, and large user bases already support many of them. The projects that most often see zero support are the higher-level applications, libraries, tools, and domain-specific projects that actually put the “Deploy to Cloud” button in front of the user.

That observation points to a simple and intentional design choice:

Attribute the revenue share to the project that provided the explicit Deploy action.

The system does not try to split value across every layer of the stack. It does not attempt to decide whether Ubuntu, PostgreSQL, or Terraform “deserve” a cut. It only records a clear, measurable relationship: this deployment was initiated through this project’s channel.

That design has three advantages:

It directs funding toward the projects that are actively choosing to participate and that most often lack other funding.
It is technically straightforward—no complex dependency graph or value-allocation algorithm is required.
It remains transparent to the user: “If you choose this deployment option, your normal cloud usage may help support this project.”

More sophisticated multi-project attribution could be explored later if the community wants it. But the first version should deliberately prioritize the project that put the button in front of the user. That is usually the project that needs the support.

It does not have to be 1%

1% is merely an example. The share could be 0.1%, 0.5%, 2%, or tiered. The essential principle is that it remains small relative to the consumption generated or influenced by the project.

Monthly cloud consumption	1% OSS share
$1,000	$10
$10,000	$100
$100,000	$1,000
$1 million	$10,000
$10 million	$100,000

For a successful project this can become meaningful funding. For the provider the percentage is tiny compared with the associated consumption. The precise economics can be tested experimentally.

Existing vs. incremental consumption

A distinction between attributed and incremental consumption is useful. If a customer already spending $10,000/month on Azure simply clicks the support button, the provider has not necessarily acquired new revenue. Different share rates (or time-limited payments) can therefore apply to new customers, new workloads, cloud switches, or true incremental consumption versus existing usage. A time-limited window—for example the first 12 months after deployment—would further position the program as a customer-acquisition and developer-ecosystem initiative rather than a permanent royalty.

Open-source neutrality matters

If a project offered “Deploy to us and we get 1%” buttons for AWS, Azure, and Google Cloud, it would have financial relationships with multiple providers. That can be healthy provided the project remains neutral. Provider neutrality should therefore be a core design principle: all participating clouds support the same public attribution standard and offer comparable participation mechanisms. The project can then present equal options without endorsing any single provider.

Separate attribution from payment

It is useful to establish an open attribution standard independently of any financial program—something along the lines of:

OSS Project ID + Repository ID + Deployment ID + Cloud Provider + Timestamp

Providers receive the metadata. Commercial agreements then decide whether and how much money is paid. This separation makes experimentation easier. Stakeholders need not agree immediately on a universal percentage; they can first agree on how to identify and measure open-source deployment influence. Once the data exists, different economic models can be tested.

What if open source became a cloud distribution channel?

Today cloud providers compete for developers. Open-source projects already have those developers. If major projects could say “Deploy this on Azure / AWS / Google Cloud to support our project,” the provider would no longer be merely hosting open source—it would be economically partnering with it. The project would have a direct incentive to make cloud deployment easier, more reliable, and more discoverable. The result is a powerful alignment: providers want workloads, developers want easy deployment, and projects want sustainable funding.

Let’s try it

I am not asking providers to make cloud computing cheaper, donate billions, or raise customer prices. I am proposing something much smaller:

Give open-source projects a way to participate in the cloud economics they help create.

Start with a limited experiment. Select a handful of major projects, give them a deployment attribution mechanism, allow transparent “Deploy to … to support this project” buttons, measure the resulting consumption, and return a small percentage of eligible usage. Then evaluate: Did the program drive incremental consumption? Influence cloud choice? Improve adoption or retention? Provide meaningful funding? If it works, expand it. If it does not, stop. Relative to the size of the cloud market, that is a modest experiment.

The bigger opportunity

The real opportunity may be larger than any particular percentage. Open-source projects form a major part of the developer distribution network. They influence what developers install, what technologies companies adopt, what infrastructure teams deploy, and ultimately where workloads run. Yet the economic value of that influence is largely invisible.

Cloud providers measure customers, workloads, and consumption. Open-source communities measure downloads, stars, contributors, and deployments. What is missing is a bridge between those two worlds. A standardized attribution mechanism—open-source project → deployment → cloud consumption—would create that bridge. Once the connection exists, many economic models become possible: 1%, 0.1%, fixed bounties for new customers, shares of incremental consumption, time-limited referral payments, and more. The exact model can evolve. The essential step is creating the connection.

A call to action

If you work at AWS, Azure, or Google Cloud on developer relations, partnerships, cloud economics, Marketplace, open source, or growth: I would like to hear your thoughts.

If you maintain an open-source project: Would you add a “Deploy to Cloud to support this project” button if it could generate recurring funding?

If you are a cloud customer: Would knowing that your normal usage could help fund an open-source project influence which cloud you choose?

Attribution may prove complicated. 1% may be too high or 0.1% may be sufficient. The economics may work only for new customers. Revenue sharing may not turn out to be the best model. But the underlying question is worth asking:

Can we turn a small fraction of cloud consumption into a sustainable funding mechanism for the open-source software that makes that consumption possible?

Cloud providers already have the customers. Open source already has the developers. The technology to attribute deployments is increasingly available. What is missing is the incentive model. Let’s build it.

I’m Looking for the Right Problem, Not the Right Job Title — Could It Be You?

Remo H. Jansen — Sat, 29 Aug 2026 23:37:13 +0000

This is a slightly unusual post.

After almost 20 years of writing software, creating and leading an open-source project, writing multiple books, spending several years as a Microsoft MVP, and generally spending far too much of my free time thinking about developer tools, I've reached a point where I think I know what I want to do next.

And I'm not entirely sure what the job title is.

So instead of starting with a job title, I'm going to describe the kind of work I'd love to do.

I'm looking for a role where I can combine technical depth, API design, developer experience, product thinking and technical leadership.

If that sounds like something your team needs, I'd love to hear from you.

Two decades of building software

I've been coding for almost 20 years now.

Over that time I've worked across quite a broad part of the software development landscape, but I've increasingly gravitated towards one particular problem:

How do we make software easier and more enjoyable for other developers to build?

I've written multiple books, spent several years as a Microsoft MVP, spoken and written about technology, and built open-source software used by developers around the world.

You can find some of my books on Amazon.

Looking back, these experiences all taught me different parts of the same thing.

Writing books taught me how to explain complex technical ideas.

Being a Microsoft MVP taught me how much I enjoy sharing knowledge and participating in a technical community.

And building open-source software taught me something I didn't expect: how much I enjoy designing and evolving developer tools as products and ecosystems.

The project that has shaped me the most is Inversify.

Inversify

I created Inversify and have developed it from the ground up.

It started as an experiment around dependency injection in TypeScript and Node.js, but over the years it became a much bigger education in both technology and developer experience.

Working on Inversify meant going very deep into things like:

TypeScript's type system
decorators
runtime metadata
reflection
compiler integration
JavaScript and Node.js runtime behaviour
module systems
API design
backwards compatibility
versioning
performance
documentation
developer experience

But that isn't actually the part of the experience I value most.

The other side of building Inversify was learning how to run and evolve an open-source developer ecosystem.

When thousands of developers are using an API, designing the API is only part of the job.

You have to learn how to listen to users without allowing the loudest user to define the roadmap.

You have to distinguish:

"I want this feature"

from:

"There is actually a deeper problem with the abstraction."

You have to make pragmatic decisions when there isn't a perfect technical solution.

You have to work with contributors.

You have to communicate breaking changes.

You have to think about migration paths.

You have to maintain compatibility.

You have to decide what not to build.

And you have to maintain trust with a community.

In hindsight, Inversify became an accidental education in developer-tooling product and program management.

Experimenting with developer experience

One of the things I've enjoyed most throughout this journey has been experimenting with new ways of making developers' lives easier.

For example, inversify-express-utils was one of my early experiments with decorator-based routing and controller APIs for Node.js.

The basic idea was to let developers express an HTTP API using TypeScript classes and decorators:

@controller("/users")
class UserController {
    @httpGet("/")
    public getUsers() {
        // ...
    }
}

At the time, decorator-driven routing and controller APIs were still relatively novel in the Node.js/TypeScript ecosystem.

Today, this style of API is completely mainstream.

That experience was incredibly interesting to me, not because of the particular implementation, but because of the process:

Identify a developer problem.
Imagine a better API.
Build a prototype.
Put it in front of real developers.
Listen to what they do with it.
Discover where the abstraction works and where it doesn't.
Iterate.

I've gone through versions of that cycle repeatedly over the years.

And I've realised that I really enjoy it.

From Inversify to RFLCT

More recently, I've started thinking about something much closer to the underlying language and tooling.

Inversify has historically relied heavily on decorators and runtime metadata.

After working with that model for years, I started wondering:

What if framework metadata could be expressed through TypeScript's type system instead?

That question led me to start experimenting with RFLCT.

The idea is still evolving, but imagine something like:

import { Reflect, resolve } from "rflct";

interface Shape { sides: number; }

class Polygon {
  public color: Reflect<string, { optional: true }>;

  constructor(
    public shape: Reflect<Shape>,
    public label: Reflect<string>
  ) {}
}

container.bind(resolve<Shape>()).to(Polygon);

Then the compiler generates metadata automatically:

const __RFLCT_Shape = Symbol.for("@acme/shapes@1|src/geo.ts|Shape");

class Polygon {
  constructor(shape, label) {}
}

Reflect.defineMetadata("design:paramtypes", [
  { type: __RFLCT_Shape, metadata: {} },
  { type: String, metadata: {} }
], Polygon, undefined);

Reflect.defineMetadata("design:properties", ["color"], Polygon);
Reflect.defineMetadata("design:paramtypes", [
  { type: String, metadata: { optional: true } }
], Polygon.prototype, "color");

container.bind(__RFLCT_Shape).to(Polygon);

Reflect.defineMetadata("design:symbols", Object.assign(
  Reflect.getMetadata("design:symbols", Reflect) ?? {}, {
    "@acme/shapes@1|src/geo.ts|Shape": __RFLCT_Shape,
    "@acme/shapes@1|src/geo.ts|Polygon": Polygon,
  }
), Reflect);

The interesting part isn't really the syntax.

It's the architectural question behind it:

Can a universal tooling layer understand relationships expressed through TypeScript's type system and turn them into runtime metadata, while leaving the meaning of that metadata entirely to the consuming framework?

Inversify could define what postConstruct, preDestroy, injectFromBase, injectFromHierarchy, etc. mean.

Another framework could define completely different metadata.

RFLCT doesn't need to understand either framework.

This is the kind of problem I've increasingly found myself drawn towards:

the boundary between programming languages, frameworks, APIs, tooling and developer experience.

What I think I'm actually good at

I've spent most of my career writing software, and I'm very comfortable doing it.

But looking back at everything I've worked on, I think my highest-leverage skill is increasingly somewhere else.

I really enjoy:

understanding difficult developer problems
designing APIs
designing abstractions
thinking about programming-language constraints
exploring new developer experiences
talking to users and contributors
collecting and interpreting feedback
turning conflicting feedback into a coherent direction
deciding what should and shouldn't be built
prototyping ideas
thinking about long-term API evolution
connecting technical possibilities with actual developer needs

I still enjoy implementation.

But increasingly, I think I can create more value by deciding what we should build and why, and by designing the abstraction that makes it possible.

I don't want to become a non-technical product manager who throws requirements over the wall to engineers.

Quite the opposite.

I want to remain deeply technical.

I want to be able to understand the compiler implications of an API, prototype something when necessary, discuss architecture with engineers, understand the constraints, and get into the code when that's the fastest way to answer a question.

But I would like my primary leverage to come increasingly from technical design, product thinking and direction rather than from implementing every feature myself.

So what am I looking for?

I'm honestly not completely sure what the job title should be.

It might be:

Technical Product Manager
Developer Experience Product Manager
Developer Platform Lead
Lead / Principal Engineer
Developer Tools Engineer
Developer Productivity Engineer
Technical Program Manager
Developer Ecosystem Lead
Architect
or something I haven't thought of yet

The title matters less to me than the actual work.

I'm looking for a role where I can sit at the intersection of:

developers × APIs × technology × product × developer experience

and help figure out what the next thing should look like.

I'm particularly interested in:

TypeScript / JavaScript
Node.js
developer tooling
compilers and language tooling
developer experience
APIs and SDKs
frameworks
developer platforms
programming-language-adjacent infrastructure
open-source ecosystems

I'd love to work somewhere where developer tooling itself is the product, rather than something that happens to be built internally.

What I'd love to do

My ideal day would probably involve some combination of:

"Developers are struggling with X. Why?"

followed by:

"What would the API look like if we solved this properly?"

followed by:

"Can we actually make TypeScript, the compiler or the runtime do that?"

followed by:

"Let's prototype it."

And then:

"Let's put it in front of developers and see what happens."

I love that loop.

I'd love to do it with a team of people who are much smarter than me in their respective areas, where I can contribute the combination of technical depth, API design, developer empathy and years of experience operating an open-source ecosystem.

What I bring

I think my background gives me an unusual combination of experiences.

I've spent more than 20 years writing software.

I've created and built a major open-source TypeScript project from the ground up.

I've spent years working directly with developers and contributors.

I've designed APIs that have been used in real-world applications.

I've experimented with new developer-experience patterns.

I've written multiple technical books.

I've been a Microsoft MVP.

And along the way, I've ended up going very deep into areas I originally had no particular intention of becoming an expert in:

decorators, metadata, reflection, type systems, compiler integration and the relationship between compile-time types and runtime JavaScript.

I didn't set out to become a TypeScript language/tooling expert.

I was trying to build useful developer tools.

The technical depth came from having to solve the problems those tools created.

And I think that's an important part of what I can offer.

I'm looking for the right problem, not just the right title

I could update my CV and start applying to jobs.

But I'm not sure that's the best way to find this particular kind of role.

I'm not looking for just any job.

I'm looking for a team where this rather unusual combination of experience is useful.

I've spent years building a developer tool from scratch, evolving its APIs, working with its community, dealing with real-world developer feedback and becoming deeply familiar with the technical machinery underneath TypeScript and Node.js.

I suspect there are teams out there where that experience would be extremely useful.

I just don't necessarily know where all of them are.

So I'm hoping that someone reading this will think:

"Wait, this sounds like something our team needs."

Maybe that's at a large company working on developer infrastructure.

Maybe it's a team working on TypeScript, JavaScript, Node.js, VS Code, developer productivity or developer platforms.

Maybe it's a company I've never heard of.

Maybe it's a role that doesn't exist yet.

Where?

I'm based in the Irish countryside, so I can only consider fully remote roles.

I'm absolutely fine with occasional travel for things like:

team gatherings
conferences
planning sessions
customer or developer meetings
important face-to-face events

I'm just not looking for a role that requires regular commuting to an office.

Remote-first is therefore an important constraint for me.

If this sounds like you

If you work on developer tooling, TypeScript, Node.js, compilers, developer productivity, APIs, SDKs, frameworks or developer platforms, I'd genuinely love to hear from you.

Especially if you work somewhere that values people who can move between:

technical architecture ↔ API design ↔ developer experience ↔ product direction ↔ open-source/community

If you know of a team that might be a good fit, please reach out!

AI Code Is No Longer Slop

Remo H. Jansen — Sat, 29 Aug 2026 07:39:55 +0000

In December 2025 I wrote that Claude Opus 4.5 changed everything. I had been using AI coding tools since the beginning. They were useful, but they were also unreliable. The working pattern was defensive: stage every change, review every prompt, stay on feature branches, lean hard on CI, and be ready to roll back.

Then I spent serious time with Opus 4.5.

What shifted was not that the model suddenly produced perfect software. It still didn’t. What shifted was the economics of my own time. I could describe why I wanted something instead of spelling out every implementation detail. The agent could plan, write, test, and iterate. I spent more of my day reviewing results, thinking about architecture, and deciding what should be built next.

I wrote at the time:

“Suddenly, when you are running 6 AI agents in parallel, it is like freaking horizontally scaling yourself.”

That was my personal inflection point — the moment AI-assisted development stopped feeling like a productivity experiment and started feeling like a fundamental change in how software could be built.

It was still only my experience. I could have been unusually tolerant of AI-generated code. Then July 2026 happened.

The Linux moment

On July 14, 2026, Linus Torvalds replied to a discussion on the Linux kernel mailing list about LLM-based tooling for maintainers. The thread included familiar anti-LLM concerns and the question of whether such tools should simply be avoided.

Torvalds was direct:

“Linux is not one of those anti-AI projects”

and

“AI is a tool, just like other tools we use. And it’s clearly a useful one.”

This is not a random developer saying AI is handy. This is the person who created and still shepherds the Linux kernel.

That is why this matters more than my December experience. My moment was personal. This is a project-level signal from one of the most consequential figures in open-source software.

Read the original

I’m not going to paraphrase the email and pretend the surrounding context is irrelevant. Read the full message:

Subject: Re: Linking Patchwork with Sashiko?
Date: Tue, 14 Jul 2026 20:06:14 -0700 [thread overview]
Message-ID: (raw)
In-Reply-To: 4928C919-7999-4E76-ADCB-F8643FED105B@linux.dev
On Tue, 14 Jul 2026 at 19:01, Roman Gushchin roman.gushchin@linux.dev wrote:

I think it makes the point of sashiko - helping maintainers - unachievable. If the point to not use
LLMs in general, let’s discuss this, not how to make each use case more complex.

It seems like [1] expresses a very anti-LLM position in general
Yes.
And no, that's not the position of the Linux kernel.
I realize that some people really dislike AI, but this is an area
where I'm willing to absolutely put my foot down as the top-level
maintainer.
Linux is not one of those anti-AI projects, and if somebody has issues
with that, they can do the open-source thing and fork it.
Or just walk away.
AI is a tool, just like other tools we use. And it's clearly a useful one.
It may not have been that "clearly" even just a year ago, but it's no
longer in question today.
There are other questions around AI (like what the economy of it will
actually look like in the end), but "is it useful" is no longer one of
those questions. Anybody who doubts that clearly hasn't actually used
it.
Yes, it can also be a somewhat painful tool, both for maintainer
workloads and just from a "it keeps finding embarrassing bugs"
standpoint.
But the solution is not to put your head in the sand and sing "La La
La, I can't hear you" at the top of your voice like some people seem
to do.
The solution is to make sure those LLM tools help maintainers
instead of just causing them pain. There's no question on that side.
We're not forcing anybody to use it, but I will very loudly ignore
people who try to argue against other people from using it.
And no, AI isn't perfect. But Christ, anybody who points to the
problems at AI had better be looking in the mirror and pointing at
themselves at the same time.
Because it's not like natural intelligence is always all that great either.
The kernel project has been and will continue to be about the technology.
Sure, the social angle of working on open source is important and
often a very motivating part of the project, but in the end that's a
side benefit, not the point of the project.
This is NOT some kind of "social warrior" project, never has been,
and never will be.
In the kernel community we do open source because it results in better
technology, not because of religious reasons.
And so we make decisions primarily based on technical merit. Not fear
of new tools.
Linus

What struck me most is that Torvalds does not claim AI is perfect. He talks about the problems it creates — embarrassing bugs, extra workload for maintainers, the risk of noise. His conclusion is not “AI is dangerous, therefore ban it.” It is closer to “AI is useful, therefore figure out how to make it work.”

That is a meaningful distinction.

AI still produces bad code

The conversation around “AI slop” has gone sideways.

AI can still produce code that is:

unnecessarily complicated
subtly wrong
insecure
poorly structured
hard to maintain

I have seen all of those. I still review every change. I still rely on tests and CI. I still throw away AI-generated work when it is not good enough.

None of that contradicts the claim that AI has become an extremely useful engineering tool. In some ways it is why the tool is useful: we have gotten better at using it despite its failure modes.

The important fact is not that AI never makes mistakes. The important fact is that the cost of generating, evaluating, and discarding candidates has fallen far enough that the overall process is now productive.

“AI-generated” is not a quality metric

Imagine opening a pull request and saying: “This was written by AI, so it’s slop.”

That is not a technical review.

A technical review asks:

Is the implementation correct?
Does it meet the requirements?
Is the architecture appropriate?
Is it tested?
Is it secure?
Is it maintainable?
Does it add unnecessary complexity?
Does it fit the existing system?

“Was an LLM involved?” can be useful context. It is not a quality judgment.

Humans have produced terrible software for decades. We do not call it “human slop.” We call it bad code, review it, fix it, or delete it. The same standard should apply to AI-generated code.

The real change is the cost of another attempt

The biggest shift is not that AI can write code. We have known that for years. The shift is that the cost of producing another implementation has collapsed.

Want a different approach? Ask the agent.
Want to prototype an API? Ask the agent.
Want to migrate off a deprecated framework? Ask the agent.
Want to explore an unfamiliar codebase? Ask the agent.
Want tests for an edge case? Ask the agent.
Want to throw the whole thing away and try again? Do it.

This does not make engineering judgment less important. It makes it more important.

When implementation becomes cheap, deciding what to implement becomes more valuable. Architecture, requirements, code review, testing, domain knowledge, and the ability to recognize bad solutions all rise in relative value.

In December 2025 the story was capability: multiple agents, dramatically higher throughput, less time spent on repetitive implementation, more time spent on product thinking and review.

In July 2026 the story became acceptance: one of the world’s most important open-source projects is not going to reject the technology on ideological grounds.

Capability plus acceptance is a stronger signal than either alone.

Developers that brand AI as slop will be left behind

Remo H. Jansen — Fri, 28 Aug 2026 14:33:08 +0000

A few days ago I shared an architectural proposal for InversifyJS on Reddit. It outlined an IPC-based type server that could help Inversify move beyond the legacy TypeScript decorator metadata APIs toward something compatible with TC39 decorators and TypeScript’s next-generation compiler.

The first comment was:

AI slop

I ignored it and went back to work.

That night I built rflct.

It isn’t perfect. It’s an alpha with plenty of rough edges. But the fact that an architectural idea can become a working repository—with a runtime, compiler-side implementation, types, tests, examples, and a CLI—in a couple of hours is still mind-blowing to me.

I have a particular perspective on this because I built Inversify from the ground up. It’s been a roughly ten-year journey. Early feedback was often negative. Plenty of things weren’t right, and plenty of things I didn’t know yet. Today Inversify has around 500,000 daily downloads and is used by projects including Elastic and the Eclipse Foundation.

One of the things Inversify did well was listening to users. The best way to get that feedback is to put something real in their hands—not when it’s perfect, not when you’re completely proud of it, and not after months of polishing. Early. Sometimes so early it isn’t pretty yet.

That is where AI changes software development most.

AI makes experimentation cheap

Before AI, turning an architectural hypothesis into something executable carried a real cost: research the APIs, design the architecture, write the code, debug it, build tests, and work through the edge cases. When experimentation is expensive, developers become conservative. You pick one idea, spend days or weeks on it, and only then discover whether it works.

AI collapses that cost. It is no longer primarily about typing code faster. It is about making the loop from “I wonder if this would work?” to “Let’s build it and find out” dramatically cheaper.

That is the part many people are underestimating.

The Inversify problem is real

Inversify was built around TypeScript’s experimental decorator and metadata capabilities. Constructor injection could infer parameter types and deliver a pleasant developer experience. But the ecosystem has moved on. TC39 decorators do not provide the same parameter decorator mechanism, and the design:paramtypes metadata Inversify historically relied on belongs to the legacy decorator world. At the same time, TypeScript’s next-generation compiler (tsgo) is introducing an IPC-based extensibility model.

The RFC I shared explored whether a resident type server, queried over IPC, could recover the type information needed for dependency injection at build time. It was deliberately exploratory—open questions, things that needed prototyping, things that could be wrong. That’s the point of an RFC.

Someone looked at it and decided the most useful feedback was “AI slop.”

So I built something concrete instead.

rflct is an experiment in ahead-of-time reflection metadata for TypeScript 7. Instead of relying on runtime decorator metadata, it generates the metadata at build time. I didn’t need AI to identify the problem or decide the architectural questions were worth exploring. Those existed before the AI. What changed was the cost of turning the ideas into something I could run, test, and put in front of other developers.

The value moved up the stack

When writing code becomes cheaper, writing code is no longer the scarce resource. The valuable part of the job moves upward:

What problem are we solving?
Is this the right problem?
Is this architecture reasonable?
What are the constraints and assumptions?
What should be tested—and what should not be built?
How do we know the result is correct?
What happens in production, and what are the failure modes?

An LLM can generate a function, a module, or an entire repository. Generating a lot of code does not tell you whether you should have generated any of it. That judgment is still yours.

“But you didn’t write the code”

We have spent decades building abstractions that generate code for us: compilers, IDEs, code generators, frameworks, and libraries containing millions of lines we do not personally maintain. Nobody asks whether a developer typed every instruction the CPU executes. We care whether the software works, whether it is maintainable, whether the architecture is sound, whether it solves the problem, and whether the person responsible understands what they are shipping.

If you generate 20,000 lines with AI and understand none of it, you have a problem. If you use AI to explore an architecture, inspect the output, run it, test it, discard bad approaches, modify it, and ultimately understand the result, the provenance of individual keystrokes is not particularly interesting.

“AI slop” is not a technical critique

AI slop is real. Developers are generating applications they do not understand. People are opening pull requests with thousands of unreviewed lines. Documentation confidently describes APIs that do not exist. People are building things because an LLM suggested them rather than because they understood the problem.

None of that is controversial.

There is a large difference, however, between observing that a lot of low-quality AI-generated software exists and declaring that AI-generated software is slop. The first is an observation. The second is a prejudice.

I have seen far worse code on GitHub than rflct, and it was written entirely by humans. Unreviewed pull requests, copy-pasted Stack Overflow solutions, frameworks held together by wishful thinking, and entire applications whose authors clearly did not understand the systems they were shipping. Low quality is not a new invention of large language models. The difference is that AI makes it easier to produce more of it, faster. That is a real problem. It is not a reason to stop evaluating the actual architecture, the tests, or the trade-offs.

If you think an architecture is wrong, say why. If the assumptions about TypeScript are flawed, show the evidence. If there is a race condition, a bad API, a performance problem, or a failure case, demonstrate it. That is how software engineering works.

“AI slop” identifies none of those things. It tells you how the reviewer feels about the tool that was used. Feeling is not the same as review.

We have seen this movie before

Software developers have a long history of dismissing new approaches before eventually adopting them: new languages, frameworks, paradigms, static typing, functional programming, managed runtimes, garbage collection, WebAssembly, containers, serverless. Each transition produces a group that correctly identifies real limitations. There is a difference, though, between understanding the limitations of a technology and refusing to engage with it because you dislike the technology.

AI is going through the same process. The people who dismiss it completely are going to have a problem.

The productivity gap will compound

Imagine two developers.

Developer A decides AI-generated code is inherently bad and refuses to use it.

Developer B uses AI aggressively but reviews everything: generates prototypes, investigates unfamiliar APIs, writes tests, explores alternatives, throws away most of what is produced, keeps what works, and still understands the system.

After one day, B may have explored five ideas while A has explored one. After a week the gap is larger. After a month it is larger still.

The advantage compounds because the scarce resource is not typing speed. It is iteration speed. The faster you can move from idea to evidence, the more ideas you can evaluate, and the more likely you are to find something valuable.

AI amplifies the developer

This does not mean AI will make everyone a great developer. Quite the opposite. AI can make a bad developer dramatically more productive at producing bad software. If you do not understand architecture, AI can generate an architecture you do not understand even faster. If you cannot review code, AI simply gives you more code to fail to review.

AI amplifies the developer. That is why engineering judgment becomes more important, not less.

The future is not “AI writes the software and developers sit back.” It is closer to this: developers who know what they are doing can use AI to explore and execute at a speed that was not previously possible.

I would rather build and be wrong

Maybe rflct is a terrible idea. Maybe the architecture needs to change completely. Maybe TypeScript 7 will evolve in a direction that makes the experiment irrelevant. That is fine.

I now have something concrete that can be run, benchmarked, broken, changed, and inspected by others. That feedback loop is infinitely more useful than an argument on Reddit.

AI has lowered the cost of turning ideas into software. We can try more things, fail faster, learn faster, and build things that previously were not worth the investment. Developers who spend their energy dismissing all of this as “AI slop” are going to discover that the world moved on without them.

Developers that brand AI as slop will be left behind.