DEV Community: Remo H. Jansen

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.

RFLCT: Bringing Runtime Type Metadata to TypeScript 7

Remo H. Jansen — Thu, 27 Aug 2026 00:11:08 +0000

If you've built large-scale applications in TypeScript, chances are you've used a Dependency Injection (DI) container. As the creator of InversifyJS, I've spent years thinking deeply about inversion of control, decoupling, and how to make enterprise patterns feel natural in TypeScript.

But for all those years, there has been a glaring elephant in the room: our heavy reliance on experimentalDecorators and emitDecoratorMetadata.

These compiler flags have served us well, but they are exactly that—experimental. They tie us to legacy decorator implementations, require specific compiler configurations, and often feel like a magic black box that doesn't perfectly align with modern build pipelines. I've spent a lot of time recently thinking about how we could finally drop these flags entirely while keeping the developer experience pristine.

With the release of TypeScript 7, I'm thrilled to introduce the solution: 🪞 RFLCT.

What is RFLCT?

RFLCT is an ahead-of-time (AOT) reflect metadata injector for TypeScript 7. It injects design:symbols and design:arguments directly at build time.

Zero decorators. Zero emitDecoratorMetadata.

It integrates seamlessly with virtually any build tool (Vite, Rollup, webpack, esbuild) via unplugin, or you can use the built-in CLI using the TypeScript 7 API for standalone tsgo projects.

Let's look at how it actually feels to write code with RFLCT.

The Magic: Before and After

With RFLCT, you annotate the types you want to expose to your runtime metadata using a special Reflect<T> wrapper type.

What you write:

import { Reflect, resolve } from "rflct";

interface Shape { sides: number; }

class Polygon {
  constructor(
    public shape: Reflect<Shape>,
    public label: Reflect<string, { optional: true }>
  ) {}
}

// resolve<T>() → the runtime identity of T (Symbol for interfaces, class for classes)
container.bind(resolve<Shape>()).to(Polygon);

What RFLCT compiles it to:

Notice how the interfaces are safely converted into global Symbols, and metadata is explicitly registered without a single decorator in sight.

import "reflect-metadata";

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

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

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

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);

Broader Than Just InversifyJS

While my primary motivation for building RFLCT was to pave the way for the next generation of InversifyJS, this underlying primitive—a reliable, decorator-free way to emit runtime type metadata—unlocks so much more.

Because RFLCT standardizes how types are mapped to memory at build time, it has massive potential across the ecosystem:

Custom DI Engines: Build your own lightweight inversion of control containers without metadata boilerplate.
Object Mapping & Hydration: Easily map database or API JSON results directly back into instantiated classes.
RPC Frameworks: Guarantee type-safe network boundaries by validating incoming arguments against compile-time metadata.
Runtime Validation: Perform deep runtime validation by reading exactly what types a constructor or method expects.

How It Works: The Three Transformations

Under the hood, RFLCT performs three core transformations during your build step:

1. `design:symbols` — The Global Type Registry

Every class, interface, and type alias in a file is registered in a process-wide Map on the global Reflect object.

Interfaces & Types become universally unique Symbols (e.g., Symbol.for(qualifiedName)).
Classes map directly to their constructor.

2. `design:arguments` — Parameter Type Metadata

Any parameter annotated with Reflect<T> (or Reflect<T, Metadata>) tells the compiler to produce a Reflect.defineMetadata("design:arguments", [...], target, key) call:

Constructors: target = ClassName, key = undefined
Methods: target = ClassName.prototype, key = "methodName"

3. `resolve<T>()` — Compile-Time Type Resolution

Writing resolve<T>() acts as a macro. It is replaced at compile time with the actual runtime identity of T:

resolve<Shape>() compiles to Symbol.for("...Shape")
resolve<Triangle>(Triangle) compiles simply to Triangle

Smart Symbol Qualification

A massive headache with metadata in the past has been duplicate dependencies causing symbol collisions. Generated symbols use Symbol.for(qualifiedName) structured as packageName@majorVersion|packageRelativePath|TypeName. This prevents collisions, allows minor/patch versions to share symbols, and ensures that shared library types resolve to the exact same symbol reference in memory.

Getting Started (Alpha Preview)

⚠️ **Note:* RFLCT is currently in its early 0.0.1-alpha.0 stage and the npm module has not yet been published to the public registry.*

For now, to try it out, you will need to download the source directly from GitHub and build it locally.

1. Build from Source

git clone https://github.com/your-username/rflct.git
cd rflct
npm install
npm run build
npm link

2. Project Setup

Link the local package to your project:

npm link rflct
npm install reflect-metadata

You'll need to import reflect-metadata once at your application's entry point to polyfill the global Reflect.defineMetadata APIs:

// entry.ts
import "reflect-metadata";

3. Configure Your Build Tool

Because RFLCT is built on top of unplugin, it drops straight into your existing pipeline.

Vite:

// vite.config.js
import { vitePlugin } from "rflct/vite";

export default {
  plugins: [vitePlugin()],
};

(Plugins for Rollup, esbuild, and webpack are also available out of the box!)

If you are running a standalone tsgo project without a bundler, the CLI leverages the TS 7 API:

npx rflct -p tsconfig.json -o dist --check

Looking Forward & Next Steps

Dependency Injection in TypeScript is finally growing up. By moving metadata generation to a clean, predictable build step, we can leave experimental decorators in the past and write DI code that feels native to modern TypeScript.

So, what's next?
The immediate next step for me is to start experimenting with integrating RFLCT directly into InversifyJS. I'll be testing how seamlessly we can migrate existing IoC containers to this new AOT metadata approach.

I can't wait to see what you build with it! Clone the repo, try it in your projects, and let me know what you think.

23 TypeScript Tools for Making Software Explicit in the AI Era

Remo H. Jansen — Fri, 21 Aug 2026 08:53:59 +0000

In my previous articles, I argued that AI is changing the role of constraints in software development.

For a long time, we treated constraints as friction. Static types felt slower than dynamic code. Schemas felt restrictive compared to flexible data. Explicit workflows felt more cumbersome than letting an application decide what to do at runtime.

But AI changes the economics.

Writing code is becoming cheaper. Understanding what the code is supposed to do is not. And verifying that generated code actually does what we intended is becoming one of the most important parts of software development.

This leads to a simple principle:

The more important an assumption is, the more valuable it is to make that assumption explicit.

This is particularly important with TypeScript. TypeScript already makes some things explicit, but the type system cannot express everything. It cannot tell us what happens when an HTTP request fails, validate JSON received from an external service, tell us which application states are legal, describe database relationships, enforce module boundaries, or define how a distributed workflow should behave after a process crashes.

Those things are often left implicit.

That is exactly where AI-assisted development becomes difficult. If a constraint exists only in someone's head, a prompt, a convention, or an undocumented assumption, the AI has to infer it. And inference is exactly where we don't want critical business rules to live.

The interesting thing about the TypeScript ecosystem is that there are now tools for making almost every layer of a system more explicit.

Here are 23 of them.

Schemas and Side Effects

1. Effect

Effect makes effects, errors, dependencies, concurrency, resources, and schemas explicit.

Without Effect, we might write:

async function getUser(id: string) {
  const response = await fetch(`/users/${id}`);

  if (!response.ok) {
    throw new Error("Request failed");
  }

  return response.json();
}

There is a lot of implicit information here. The function performs I/O. It can fail. It returns unvalidated external data. It depends on fetch. The caller has to discover all of this by reading the implementation.

With Effect, those concerns become part of the program's structure:

const getUser = (id: string) =>
  Effect.gen(function* () {
    const response = yield* HttpClient.get(`/users/${id}`);
    return yield* decodeUser(response);
  });

The important difference is not syntax. It is information density. The code communicates what the operation does, what it can fail with, what it depends on, and how it composes with other effects.

Effect turns invisible operational behavior into explicit program structure.

2. Zod

Zod makes runtime data validation explicit.

Without it:

const user = await response.json();

sendEmail(user.email);

The programmer is implicitly assuming that the response contains an email property.

With Zod:

const User = z.object({
  id: z.string(),
  name: z.string(),
  email: z.string().email()
});

const user = User.parse(await response.json());

sendEmail(user.email);

Now the assumption is explicit. The schema can be read by a human, used by the application, tested automatically, and inspected by AI.

Types describe what we believe. Runtime schemas verify what we actually received.

3. io-ts

io-ts makes the boundary between unknown runtime data and typed data explicit.

Without a codec:

type Payment = {
  id: string;
  amount: number;
};

const payment: Payment = await getPayment();

The type says payment is valid, but the runtime data has not actually been checked.

With io-ts:

const Payment = t.type({
  id: t.string,
  amount: t.number
});

const result = Payment.decode(await getPayment());

Now there is an executable description of the boundary between unknown data and trusted data. The codec can also be tested against invalid inputs.

4. Valibot

Valibot makes runtime validation and schemas explicit with a lightweight API.

Without it:

function createAccount(input: any) {
  // Assume input is valid.
}

With Valibot:

const AccountInput = v.object({
  name: v.string(),
  email: v.pipe(v.string(), v.email()),
  age: v.pipe(v.number(), v.integer(), v.minValue(18))
});

function createAccount(input: unknown) {
  const account = v.parse(AccountInput, input);
}

The requirements are no longer hidden inside the implementation. They are represented as data that humans, tests, tools, and AI can inspect.

5. TypeBox

TypeBox makes JSON Schema and TypeScript type definitions explicit and connected.

Without it:

interface CreateOrder {
  productId: string;
  quantity: number;
}

The TypeScript type describes the application, but external validators and JSON Schema consumers need another representation.

With TypeBox:

const CreateOrder = Type.Object({
  productId: Type.String(),
  quantity: Type.Integer({ minimum: 1 })
});

The schema becomes a first-class artifact that can drive validation, tooling, documentation, and generation.

One explicit contract is better than five independently maintained descriptions of the same contract.

State and Behaviour

6. XState

XState makes states, events, transitions, and actors explicit.

Without a state machine:

if (loading) {
  // ...
}

if (error) {
  // ...
}

if (data) {
  // ...
}

As the application grows, combinations can appear that were never intended. The actual state model exists implicitly in conditionals.

With XState:

const machine = createMachine({
  initial: "idle",

  states: {
    idle: {
      on: { SUBMIT: "submitting" }
    },

    submitting: {
      on: {
        SUCCESS: "success",
        FAILURE: "failure"
      }
    },

    success: {},
    failure: {
      on: { RETRY: "submitting" }
    }
  }
});

Now the possible states and transitions are explicit. An AI does not need to infer which transitions are legal. Tests can enumerate them, tooling can visualize them, and invalid transitions can be rejected.

This is the same idea I explored in my article about AI agents and finite state machines: don't ask the AI to infer the workflow when you can give it the workflow.

Data and Persistence

7. Prisma

Prisma makes database models, relationships, migrations, and generated data access types explicit.

Without a schema-first ORM:

const users = await db.query(
  "SELECT * FROM users WHERE organisation_id = ?",
  [organisationId]
);

The relationship between users and organisations is hidden in the database.

With Prisma:

model User {
  id             String       @id
  email          String
  organisationId String
  organisation   Organisation @relation(fields: [organisationId], references: [id])
}

model Organisation {
  id    String @id
  users User[]
}

The model and relationship are explicit, and the schema can generate types and migrations.

8. Drizzle

Drizzle ORM makes database schemas, SQL relationships, and query types explicit in TypeScript.

Without it:

const result = await db.query(
  "SELECT id, name FROM users WHERE active = true"
);

The SQL is explicit, but the relationship between the query and its TypeScript result is not.

With Drizzle:

const users = await db
  .select({
    id: usersTable.id,
    name: usersTable.name
  })
  .from(usersTable)
  .where(eq(usersTable.active, true));

The schema, query, selected fields, and result type can all be connected.

9. Kysely

Kysely makes SQL queries and their result types compile-time checked.

Without it:

const result = await db.query(`
  SELECT id, email
  FROM users
  WHERE organisation_id = $1
`, [organisationId]);

The AI has to infer the result shape from the SQL.

With Kysely:

const result = await db
  .selectFrom("user")
  .select(["id", "email"])
  .where("organisation_id", "=", organisationId)
  .execute();

The query is constrained by the database type. Invalid tables or columns can become compile-time errors.

The best constraint is often the one that fails automatically.

Infrastructure

10. Pulumi

Pulumi makes infrastructure resources, dependencies, and configuration explicit as typed code.

Without infrastructure-as-code, the architecture might be a collection of console settings, scripts, environment variables, documentation, and tribal knowledge.

With Pulumi:

const bucket = new aws.s3.Bucket("uploads");

const policy = new aws.s3.BucketPolicy("uploads-policy", {
  bucket: bucket.id,
  policy: ...
});

Infrastructure relationships become part of the program. The AI can inspect them, deployment tooling can inspect them, and infrastructure can be previewed before it changes.

11. AWS CDK

AWS CDK makes cloud infrastructure and its relationships explicit as TypeScript constructs.

Without CDK, the relationship between an API and Lambda might exist only in cloud configuration.

With CDK:

const api = new apigateway.RestApi(this, "Api");

const handler = new lambda.Function(this, "Handler", {
  runtime: lambda.Runtime.NODEJS_22_X,
  handler: "index.handler",
  code: lambda.Code.fromAsset("lambda")
});

api.root.addMethod("GET", new apigateway.LambdaIntegration(handler));

The relationship is now explicit, reviewable, synthesizable, and testable.

Architecture

12. dependency-cruiser

dependency-cruiser makes module dependency rules explicit and enforceable.

Imagine:

UI
 ↓
Application
 ↓
Domain
 ↓
Infrastructure

But nothing prevents:

Domain
 ↓
Infrastructure

With dependency-cruiser, rules such as "domain must not depend on infrastructure" become executable.

An AI can read the rules, CI can enforce them, and generated imports that violate them can fail automatically.

Architectural decisions should be executable whenever possible.

13. Madge

Madge makes module dependency graphs and circular dependencies explicit.

Without tooling, a cycle such as this can be difficult to see:

A → B → C → D → A

With Madge:

madge --circular src/

the graph becomes inspectable and circular dependencies can be detected automatically.

14. eslint-plugin-boundaries

eslint-plugin-boundaries makes architectural layer and module boundaries explicit and enforceable.

Without it:

import { UserRepository } from "../../infrastructure/database";

might compile perfectly even when application code is not supposed to access infrastructure directly.

With boundaries configured, the rule can become:

application → domain
application → infrastructure ❌
domain → infrastructure ❌

ESLint can reject the violation. The AI does not need to remember the architectural rule because the tool enforces it.

APIs

15. tRPC

tRPC makes client/server procedure contracts explicit and type-safe.

Without a shared contract:

api.post("/users", {
  name,
  email
});

The server might expect completely different field names. The contract exists implicitly across two implementations.

With tRPC:

const createUser = publicProcedure
  .input(
    z.object({
      name: z.string(),
      email: z.string().email()
    })
  )
  .mutation(({ input }) => {
    // ...
  });

The procedure and its input contract become part of the program. The client can consume that contract directly, and the compiler provides feedback when it changes.

16. ts-rest

ts-rest makes HTTP endpoints, parameters, payloads, and responses explicit as shared contracts.

Without it:

fetch("/api/orders", {
  method: "POST",
  body: JSON.stringify(order)
});

The AI has to infer what the endpoint expects, what it returns, and which status codes are possible.

With a contract:

const contract = c.router({
  createOrder: {
    method: "POST",
    path: "/orders",
    body: CreateOrder,
    responses: {
      201: Order,
      400: ErrorResponse
    }
  }
});

The HTTP boundary becomes explicit and can drive server implementation, client usage, tests, and documentation.

17. oRPC

oRPC makes RPC procedures and their client/server contracts explicit and type-safe.

Without a contract:

client.createUser(...)

The implementation determines what arguments are accepted.

With an explicit procedure contract, inputs, outputs, errors, and procedure identity become machine-readable. The AI is no longer asked to figure out how the API probably works; it is asked to implement against a defined contract.

18. OpenAPI

OpenAPI Initiative makes network API contracts explicit independently of implementation language.

Without OpenAPI, an API might be described by a README:

POST /users

Probably takes:
{
  name,
  email
}

Returns a user.

With OpenAPI:

paths:
  /users:
    post:
      requestBody:
        content:
          application/json:
            schema:
              $ref: '#/components/schemas/CreateUser'
      responses:
        '201':
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/User'

The API becomes a formal artifact. Humans can read it, machines can validate it, tools can generate clients, and AI can consume it.

19. Orval

Orval makes OpenAPI contracts executable by generating strongly typed clients.

Without generation, an AI might repeatedly write:

fetch("/api/users/123")

and have to infer the method, parameters, request body, response type, and error handling.

With Orval, the OpenAPI specification becomes the source from which client code is generated. The AI can use generated code whose structure already reflects the contract.

Explicitness is even more powerful when it can be converted into automation.

Distributed Systems

20. Proto.Actor

Proto.Actor makes actors, messages, supervision, identity, and distributed communication explicit.

Without an actor model:

await sendMessage(node, message);

What happens when the node disappears? Who owns the state? Should the message be retried? Who supervises the failure? Can two messages be processed concurrently?

An actor model gives these concepts explicit names and structures:

Actor
  ↓
Message
  ↓
State
  ↓
Supervision
  ↓
Failure handling

The distributed system now has a vocabulary that both humans and AI can reason about.

21. Dapr

Dapr makes distributed-system capabilities explicit through abstractions such as actors, state, pub/sub, and service invocation.

Without a distributed abstraction:

await redis.set(key, value);
await kafka.publish(topic, message);
await fetch(serviceUrl);

The distributed semantics are scattered throughout the application.

With Dapr, concepts such as state, pub/sub, service invocation, and actors become explicit architectural capabilities. The AI can reason about intent instead of reconstructing architecture from arbitrary infrastructure calls.

22. Temporal

Temporal makes durable workflows, activities, retries, timers, failures, and long-running execution explicit.

Without Temporal:

await chargeCard();
await createOrder();
await sendEmail();

What happens if the process crashes after chargeCard()? Should it be retried? What if createOrder() fails? Should the email be sent twice?

With Temporal:

await chargeCard();

await proxyActivities<typeof activities>({
  startToCloseTimeout: "1 minute",
  retry: {
    maximumAttempts: 3
  }
}).createOrder();

await sleep("1 day");

The workflow, retries, timers, activities, and durability semantics become explicit.

This is especially important for AI agents.

Let AI decide what requires intelligence. Let the workflow engine handle what requires reliability.

Functional Programming

23. fp-ts

fp-ts makes functional effects, optionality, errors, and composition explicit through types.

Without it:

function findUser(id: string): User | undefined {
  // ...
}

The caller has to remember to handle the missing case.

With explicit functional structures:

const findUser = (id: string): Option<User> => {
  // ...
};

Or:

const createUser = (
  input: CreateUser
): Either<ValidationError, User> => {
  // ...
};

The possibility of failure is no longer an informal convention. It is part of the function's type.

If a function returns User, the AI may assume it always has a user. If it returns Either<ValidationError, User>, the failure path is visible and the compiler can help verify that it was handled.

The Common Pattern

These tools look very different. Effect is not Prisma. Prisma is not XState. XState is not OpenAPI. OpenAPI is not Temporal.

But they are all solving a similar problem.

They take something that would otherwise be implicit and give it a representation.

Implicit	Explicit
Errors	Effect / `Either`
External data assumptions	Zod / io-ts / Valibot
JSON Schema	TypeBox
Application state	XState
Database relationships	Prisma / Drizzle
SQL result types	Kysely
Infrastructure relationships	Pulumi / CDK
Module architecture	dependency-cruiser / Madge
Architectural boundaries	eslint-plugin-boundaries
API contracts	tRPC / ts-rest / oRPC / OpenAPI
Generated API clients	Orval
Actor semantics	Proto.Actor / Dapr
Durable workflows	Temporal
Optionality and errors	fp-ts

The important word here is representation.

If a rule only exists in a developer's head, there is very little an AI can do with it. If the rule exists only in a prompt, the AI can forget it. If it exists only in documentation, it can become stale.

But if the rule exists in code, a schema, a state machine, a contract, a dependency rule, or a workflow definition, it becomes part of the system.

And once it is part of the system, we can automate around it.

Explicitness Creates a Verification Surface

Consider an AI-generated change.

Without explicit constraints, verification might look like this:

AI generated code
        ↓
Human reads it
        ↓
Human tries to understand intent
        ↓
Human guesses whether assumptions are correct
        ↓
Tests

There is a lot of interpretation involved.

Now consider a system with explicit contracts:

AI generated code
        ↓
TypeScript compiler
        ↓
Schema validation
        ↓
API contract tests
        ↓
Architecture rules
        ↓
State-machine tests
        ↓
Database constraints
        ↓
Workflow verification

The AI still generates code, but it generates code inside a much smaller space of possibilities.

That is the real advantage.

We don't need AI to become perfectly reliable. We can make the environment around AI more verifiable.

Better Context Produces Better Code

These tools don't only prevent mistakes. They improve the context available to the AI.

Suppose I ask an AI:

Add a new payment provider.

In an implicit codebase, the AI has to discover how payments work, where providers live, which errors are possible, how payment state is represented, how retries work, which modules can depend on which, which API contract is expected, and how the database represents payments.

It has to reconstruct all of that.

Now imagine the same request in an explicit system. The AI can inspect the payment state machine, payment schema, payment API contract, dependency rules, database schema, and workflow definition.

The problem has become much smaller.

The AI isn't necessarily smarter. The system is simply giving it better information.

This is why I increasingly think about constraints as context compression.

An explicit model can communicate a large amount of intent in a small, machine-readable representation.

Explicitness Also Changes Testing

When something is implicit, testing often requires testing the implementation.

When something is explicit, we can often test the model.

With an FSM we can test:

Can Submitted → Purchased happen directly?

With an API contract:

Does POST /orders return 201 with an Order?

With a schema:

Does invalid email data get rejected?

With dependency rules:

Can domain import infrastructure?

It should not.

With a database schema:

Can an Order reference a non-existent User?

It should not.

With Temporal:

What happens when Activity #2 fails?

With OpenAPI:

Does the implementation conform to the published API?

The verification target moves from "Does this code look correct?" toward "Does this implementation satisfy these explicit constraints?"

That is a much better problem for automation.

This Does Not Mean Everything Should Be Explicit

There is an obvious danger here.

If explicitness is good, it is tempting to make everything explicit.

That would be a mistake.

Not every function needs an effect system. Not every application needs a state machine. Not every database needs an ORM. Not every project needs five architecture enforcement tools.

The goal is not maximum constraint. The goal is to make important assumptions explicit.

A useful question is:

If this assumption were wrong, would the resulting bug be expensive?

If the answer is yes, it is a good candidate for explicit representation.

If the answer is no, inference may be perfectly reasonable.

The objective is not rigidity. It is explicitness where explicitness creates value.

The TypeScript Ecosystem Is Becoming an Explicitness Ecosystem

This is what I find interesting about the current TypeScript ecosystem.

It is no longer just a language with a type checker. There are tools for making almost every important boundary explicit:

             Business process
                    │
                 XState
                    │
              Application
                    │
          ┌─────────┴─────────┐
          │                   │
       Effect              fp-ts
          │                   │
          └─────────┬─────────┘
                    │
                TypeScript
                    │
       ┌────────────┼────────────┐
       │            │            │
     Zod         tRPC        OpenAPI
       │            │            │
       └────────────┼────────────┘
                    │
              Database
                    │
       Prisma / Drizzle / Kysely
                    │
              Infrastructure
                    │
             Pulumi / CDK
                    │
          Distributed Systems
                    │
      Temporal / Dapr / Actors

And around all of it:

dependency-cruiser
Madge
eslint-plugin-boundaries

These tools are doing something bigger than adding features to TypeScript.

They are making assumptions observable.

AI Makes This More Important

Before AI-assisted development, a developer could often compensate for implicitness through experience.

A senior developer might know that you shouldn't import infrastructure from the domain, that a particular API actually returns 202 rather than 200, that an operation is not safe to retry, that a state can only transition after approval, or that a database field is nullable even though the TypeScript type says otherwise.

That knowledge existed in people's heads.

AI doesn't reliably have access to that knowledge. And even when we tell it, we have to trust that it will remember and apply it consistently.

This creates a new architectural pressure:

Move important knowledge out of people's heads and into artifacts that machines can inspect and verify.

Schemas. Types. Contracts. State machines. Dependency rules. Database models. Workflow definitions. Infrastructure definitions.

These become part of the AI's context. But more importantly, they become part of the system's verification surface.

From Code Generation to Code Verification

AI is making code generation increasingly cheap. That changes what we should optimize for.

We should spend less time asking:

How can I make writing this code faster?

and more time asking:

How can I make it obvious whether this code is correct?

The tools in this list answer that question in different ways. Some make data explicit. Some make behaviour explicit. Some make architecture explicit. Some make infrastructure explicit. Some make distributed execution explicit. Some make APIs explicit. And some make failure explicit.

They all reduce the amount of important information that exists only through inference.

That is valuable for humans. But I think it is becoming even more valuable for AI.

The Future Is Not More Constraints

I don't think the future of software is going to be about adding more and more constraints.

It is about putting constraints in the right places.

A good system might look like this:

AI
 │
 │ intelligence
 ▼
Explicit contracts
 │
 ├── Types
 ├── Schemas
 ├── APIs
 ├── State machines
 ├── Architecture rules
 ├── Database models
 └── Workflows
 │
 ▼
Automated verification

The AI remains probabilistic. The system around it becomes increasingly deterministic.

That is the architectural shift I find most interesting.

We don't need to make AI deterministic. We need to stop asking AI to infer things that software can already define.

The best TypeScript tools for the AI era may therefore not be the ones that help us write code faster. They may be the ones that make the intent behind the code impossible to misunderstand.

Because when code generation is cheap, explicitness becomes leverage.

And when verification is the bottleneck, every explicit constraint becomes another thing a human or a machine can check.

Don't make the AI remember your rules. Make your system represent them.

That is how we move from AI-generated software to AI-generated software that we can actually verify.

The Boundary Independence Principle (BIP)

Remo H. Jansen — Thu, 20 Aug 2026 08:20:05 +0000

I've been writing about the SOLID principles for over a decade. I built InversifyJS because of them, I wrote about implementing them with the onion architecture, and just recently I argued that they are universal design principles that appear far beyond object-oriented programming. Yet something has always felt missing, not from the principles themselves, but from the conversation around them.

SOLID tells you how to write good components. It does not tell you how to compose those components into a system whose shape can still change.

The gap

Imagine a perfectly SOLID codebase. Your UserRepository depends on an abstraction. Your EmailService has a single responsibility. Your OrderProcessor is open for extension and closed for modification. Everything is clean.

Then your CTO says: "We need to extract user management into its own microservice."

You begin ripping the system apart. New projects, moved files, rewritten imports, new entry points, new dependency wiring, shared interfaces extracted into packages. Weeks of work follow. The SOLID components themselves needed almost no change. The structure around them did. The boundaries of the system had been baked into import paths, project layout, entry points, and hard-coded module wiring.

SOLID gave you excellent bricks. Without a principle that keeps those bricks from being cemented into a fixed shape too early, you still end up with a rigid system.

A convergence of patterns

Software engineering literature is rich with architectural patterns: Hexagonal Architecture, Onion Architecture, Ports & Adapters, Composition Roots, Modular Monoliths, Microkernels, and plugin systems.

On the surface they address different concerns:

Composition Root , assemble the object graph in one place at startup.
Ports and Adapters / Hexagonal , isolate domain logic behind explicit interfaces.
Onion / Clean Architecture , enforce inward-pointing dependencies toward business rules.
Modular Monolith , keep a single deployable while enforcing strict module encapsulation.
Microkernels and plugins , keep a minimal core unaware of the extensions that run inside it.

Despite different origins, applying these patterns well repeatedly produces the same emergent property:

You can change the physical shape of a system without altering the code that performs the actual business logic.

When independent patterns converge on the same property, it is worth asking whether they are expressions of a deeper principle.

System shape

System shape is the physical layout, deployment targets, and runtime distribution of a system:

One process or many services?
In-memory calls or network messages?
Monolith container, shared library, or serverless functions?

Shape decisions are among the most expensive an organization can make. Teams that choose microservices too early often spend months consolidating. Teams that stay in a monolith too long often spend a year extracting services. These transitions hurt because business logic frequently carries implicit assumptions about where it runs, shared memory, instantaneous responses, or a single database.

The patterns above make system shape mutable. They allow teams to reconfigure the physical layout without rewriting domain rules.

What changes with the Composition Root

Consider the same codebase wired exclusively through an IoC container, with all wiring living in composition roots.

In a monolith:

// monolith/composition-root.ts
const container = new Container();
container.load(authModule);
container.load(userModule);
container.load(orderModule);
container.load(emailModule);
container.load(cmsModule);

When the organization decides to split services, new composition roots select different subsets:

// services/user-service/composition-root.ts
const container = new Container();
container.load(authModule);
container.load(userModule);

// services/order-service/composition-root.ts
const container = new Container();
container.load(authModule);
container.load(orderModule);
container.load(emailModule);

The components themselves do not change. Only the composition roots change. The boundaries of the system, what constitutes a deployable unit, were never encoded inside the components.

I documented a concrete case study of this approach: From Monolith to Microservices without changing one line of code. The same source produced either a monolith or a set of microservices depending on which composition roots and CI/CD configuration were used. We even swapped CosmosDB for PostgreSQL by replacing one IoC module.

This is not merely the Composition Root pattern

The Composition Root (Mark Seemann) tells you where to wire dependencies: in a single place close to the application’s entry point. Seemann correctly insists that each deployable artifact should have exactly one composition root.

The principle I am naming is different. It is not primarily about where wiring occurs. It is about what components are allowed to know about their own boundaries.

The Composition Root pattern is a mechanism.
Boundary Independence is the reason to keep components ignorant of shape so that new composition roots can redefine system shape without touching the components.

In large systems the ideal of a single pure composition root often becomes hierarchical or framework-assisted wiring. The principle still holds: the decision about which components belong together must remain outside the components themselves.

The core mechanism: ignorance of boundaries

The consistent mechanism across these patterns is simple:

Components that execute core business logic must remain ignorant of the boundaries that enclose them.

A domain service that processes a customer transaction should not know:

whether its storage dependency is an in-memory map, a local database, or a remote API;
whether it is running inside a Lambda, an Express process, or a CLI;
whether an event it emits is handled synchronously or placed on a distributed broker.

Because the component has no access to infrastructure details and no way to query its execution environment, it stays passive to shape changes. Relocate it from a monolith to a serverless worker and it continues to function.

This is the heart of the idea: components must not encode assumptions about the shape in which they happen to execute.

The Boundary Deferral Spectrum

A useful mental model is a spectrum of how late boundary decisions can be deferred:

Design time (worst)

Boundaries are baked into source structure, import paths, and project layout. Restructuring requires rewriting.

Composition time (good)

Boundaries are defined only in composition roots. Components are boundary-agnostic. Different roots produce different shapes from the same components.

Build time (better)

Composition roots (or equivalent configuration) read build arguments or environment variables. A single codebase yields different deployable artifacts. Restructuring becomes a change of build configuration.

Runtime (most deferred)

The system discovers and loads components dynamically. Plugin architectures (MEF, OSGi, VS Code extensions, browser extensions) do not know their final shape until they are running. The system’s boundaries are defined by what is present at runtime.

Plugin systems are the purest practical embodiment of this spectrum. They are also among the longest-lived and most adaptable software systems we have built, IDEs, browsers, operating systems. They defer boundary decisions until the last responsible moment.

Horizontal and vertical slicing

Boundary decisions come in two flavours; both should be deferrable.

Vertical slices concern technical layers: HTTP, domain logic, persistence. In a well-structured onion or hexagonal architecture these layers are already separated by abstractions. The composition root connects them. Swapping an entire persistence technology becomes a composition-root change.

Horizontal slices concern business capabilities: user management, order processing, content, authentication. In a modular monolith these appear as modules; in a microservices architecture each becomes its own deployable with its own composition root.

Both kinds of boundary should be defined outside the components. Components should not know whether two repositories live in the same process or across a network, or whether an email service is an in-process call or a remote API. Those are composition-time decisions.

When both vertical and horizontal boundaries are deferred, the system becomes a collection of Lego bricks. You can assemble a monolith, a set of services, or anything in between without modifying the bricks, only the instruction manual changes.

The same idea in functional programming

The principle is not limited to OOP or IoC containers.

In ML-family languages, module functors parameterise an entire module over its dependencies. The wiring occurs at the call site; the functor itself remains boundary-agnostic.

Effect systems such as ZIO declare dependencies as a type-level environment. Different layer configurations can be assembled for tests, a monolith, or distributed deployment. The program does not change, only the layer composition does.

Even simple higher-order functions achieve the same effect: a function that receives its collaborators as parameters does not know whether those collaborators are local, remote, or mocked.

The mechanisms differ; the principle is identical.

Boundary Independence and Dependency Inversion

A natural question is whether this is simply Dependency Inversion applied at larger scale.

There is a close relationship, but they are not the same.

Dependency Inversion makes a component independent of the concrete implementation of a dependency.
Boundary Independence makes a component independent of the shape in which that dependency is fulfilled.

DIP frees you from a particular database driver or HTTP client. BIP frees you from the assumption that the dependency lives in the same process, the same memory space, or the same failure domain. BIP builds on DIP and extends the reasoning from class and module boundaries to architectural and physical boundaries.

Architectural trade-offs and costs

Flexibility always has costs. Making components shape-independent introduces real challenges that must be managed deliberately.

1. Contract design for multiple topologies

Interfaces must express guarantees that remain valid whether the dependency is local or remote. Assumptions about shared memory, instantaneous response, or transactional consistency across components cannot be hidden inside domain logic if the boundary may later move across a network.

2. Translation and mapping overhead

Data crossing a boundary usually requires mapping between transport formats and domain models. This adds code and a modest performance cost compared with passing raw persistence entities through the application.

3. Latency and performance blindness

When code is unaware of boundaries, developers can write sequential chatty interactions that are acceptable in-process but catastrophic across a network. Boundary Independence does not remove the need for performance thinking; it requires that the costs of each shape be made explicit at the boundary (bulk APIs, async messaging, caching strategies, etc.).

4. Consistency, failure, and observability

Network boundaries introduce partial failure, different consistency models, and the need for distributed tracing, circuit breakers, and clear ownership of data. These concerns cannot be fully abstracted away. They must be addressed at the edges while the domain logic remains ignorant of them.

Boundary Independence does not claim that shape is irrelevant. It claims that shape should remain a replaceable architectural decision, while the semantics and costs of each shape are handled explicitly at the boundary.

Has this been said before?

Yes, but scattered across different communities and disciplines.

The practice is not new. Strong teams have been building boundary-agnostic components and deciding system shape at composition time for years. What has been missing is a concise, named principle that sits cleanly alongside SOLID and explicitly connects the dots.

The existing sources

These concepts and patterns already exist:

Robert C. Martin (Clean Micro-service Architecture): “The Deployment Model is a Detail,” “Forced Ignorance”
Mark Seemann (Dependency Injection pattern): The Composition Root mechanism; exactly one composition root per deployable artifact
The Lean community: “Decide as Late as Possible” — defer irreversible decisions until the last responsible moment
Domain-Driven Design & Hexagonal/Onion Architecture: Isolate domain logic behind abstraction boundaries
Plugin architectures (VS Code, browsers, operating systems): Runtime deferral of component identity and shape
Modular Monoliths & Modular Monolith Architecture: Treat internal boundaries as if they might become external later

These are not new ideas. This article is not inventing them.

What's missing: the synthesis

However, these sources treat the idea as separate concerns:

Uncle Bob writes about deployment models and clean architecture, but still largely assumes component boundaries are fixed in project or package structure.
The Composition Root pattern tells you where to wire, but not that components must be deliberately designed to be boundary-agnostic.
“Decide as Late as Possible” is a general heuristic, not a specific principle about system boundaries.
Plugin architectures demonstrate the idea perfectly, but are often treated as a specialist domain (browser extensions, IDEs) rather than a principle that applies to all systems.

None of these sources state the full, unified claim:

The boundaries of a system — which components are grouped together, what constitutes a vertical or horizontal slice, what constitutes a deployable unit — should be defined outside the components themselves (normally at composition-root level or later) and should be reconfigurable without modifying the components.

Why name it?

By naming the principle and showing its convergence across patterns, we can:

Make it teachable — rather than learning Composition Root, Hexagonal Architecture, and modular monoliths as separate ideas, teams can learn one unifying principle and recognize it in all of them.
Enable deliberate design — teams can ask “Are we applying BIP?” during architecture and code review, with a shared language.
Connect it to SOLID — BIP is the architectural answer to a question SOLID leaves open: “Once I have excellent components, how do I ensure the system's shape remains flexible?” Naming it makes that connection explicit.
Prevent accidental commitment — when teams see that plugin architectures, successful modular monoliths, and successful microservices migrations all rely on the same underlying principle, they can avoid encoding shape decisions inside domain logic by default, not by luck.

The principle

I am naming the existing, convergent practice:

The Boundary Independence Principle (BIP)

Components should declare what they require to operate, while remaining ignorant of how, where, or when those requirements are fulfilled across system boundaries. System boundaries, both vertical (technical layers) and horizontal (business capabilities), should be defined at the composition-root level (or later), never inside the components themselves. Boundary decisions should be deferred as late as practically possible.

More concisely: system boundaries are independent of the components themselves.

This extends the familiar framing — database is a detail, framework is a detail, deployment model is a detail — to its logical conclusion: the boundaries themselves are a detail too.

Intellectual lineage

This principle is built on decades of work by many practitioners:

Alistair Cockburn — Hexagonal Architecture / Ports & Adapters
Robert C. Martin — Clean Architecture, dependency inversion, deployment as a detail
Mark Seemann — Dependency Injection patterns and the Composition Root
Domain-Driven Design community — Entity, aggregate, and bounded context boundaries
Lean software development — Defer decisions until the last responsible moment
Plugin architecture patterns — Used successfully in OS kernels, browsers, IDEs, and application platforms for decades

The contribution of naming Boundary Independence is not inventing a new idea. It is making explicit what these patterns converge on, giving it a place alongside SOLID, and enabling teams to apply it deliberately rather than accidentally.

Practical application

Naming the principle gives teams a shared heuristic for design and review:

Architecture and code reviews

Ask: “Does this domain logic contain assumptions about its execution boundary?” Importing infrastructure SDKs, assuming shared transactions, or hard-wiring module relationships inside business logic are boundary leaks.
Deferring expensive decisions

Start with a modular monolith whose internal boundaries are already BIP-compliant. Extract services later only when metrics justify the operational cost. The extraction cost drops dramatically because the components were never entangled with the old shape.
Testing

Domain logic that is oblivious to its runtime environment can be tested with lightweight in-memory adapters. This simplifies unit and many integration tests. It does not eliminate the need for contract tests, end-to-end tests, or chaos experiments once real distribution appears; those remain necessary at the boundaries.

The goal is not to make every system ready to become a microservice architecture on day one. The goal is to avoid accidentally encoding shape decisions inside the components that should not have to care.

SOLID + BIP

SOLID without Boundary Independence has always felt incomplete. SOLID gives you high-quality components. Without a principle that keeps boundaries deferred and external to those components, teams still cement the bricks into a shape too early. When the shape must change, and it almost always must, the cost is far higher than it needed to be.

The teams that extract the most value from SOLID are the ones that, whether they name it or not, also practise Boundary Independence. Their systems behave like plugin architectures even when they are not formally plugins. Components do not know their own shape. Boundaries live in one place (or a small number of controlled places). Changing that place changes the shape of the system.

SOLID gives us the bricks. BIP keeps the mortar from setting too soon.

I would love to hear your thoughts.

Why Developer Experience (DevEx) Dies in the Backlog?

Remo H. Jansen — Mon, 03 Aug 2026 01:10:16 +0000

"Technical debt" might be one of the most successful terms ever coined in software engineering.

Not because it solved the problem. Technical debt is still everywhere. But it fundamentally changed the conversation. Before the term existed, engineers struggled to explain why seemingly harmless shortcuts eventually become expensive. Calling it technical debt gave business leaders a language they already understood. Debt accumulates interest. Debt carries risk. Debt demands attention.

It was a brilliant metaphor. The metaphor didn't eliminate technical debt, but it changed how organizations think about it. Today, no serious engineering organization questions whether technical debt exists. The conversation has shifted from Is this a real problem? to What should we do about it? That's the power of language. Today, our industry has another equally pervasive problem.

Developers spend their days fighting slow build systems, brittle internal frameworks, unreliable tooling, unnecessary processes, endless context switching and organizational friction. Every one of these things quietly reduces an organization's ability to build great software, yet we rarely talk about them as strategic business problems. We have a name for this.

Developer Experience.

And I believe we've chosen the wrong one. Not because the underlying idea is wrong, but because the name fails to communicate what is actually at stake.

The Wrong Conversation

At first glance, Developer Experience seems like a perfectly reasonable name. After all, nobody questions the importance of Customer Experience. Entire organizations are built around improving it.

So why hasn't Developer Experience had the same impact? I think the answer is surprisingly simple. The relationship between customer experience and business performance is obvious. Happy customers buy products, remain loyal and recommend them to others. Executives instinctively understand why customer experience deserves investment. The relationship between developer experience and engineering performance is far less obvious.

When executives hear Developer Experience, many unconsciously categorize it as an internal quality-of-life initiative. Something that would be nice to improve once more important business priorities have been addressed.

Ironically, the same executives care deeply about engineering performance. They worry when expensive engineering teams deliver slowly. They worry when quality declines. They worry when innovation stalls. They just don't naturally connect those outcomes with what we currently call Developer Experience. That's the problem. The name hides the real business impact.

As a result, conversations about developer productivity often drift in an unhealthy direction. Instead of asking how to build an environment where engineers consistently perform at their best, we ask questions like:

How can we measure developers?
How can we increase output?
How can we ship more features?
How can AI make developers faster?

These questions all assume performance is something we extract from people. I think that's backwards.

Performance Is an Emergent Property

Imagine an elite sports team. Nobody expects world-class athletes to win championships simply because they have better shoes. High-performance organizations invest across the entire system:

Coaching
Training
Nutrition
Recovery
Medical care
Sports psychology
Team dynamics
Equipment
Leadership
Purpose

No one believes any single investment creates champions. Performance emerges from the interaction of the whole system. Software engineering is no different. Good tooling matters. Fast build systems matter. AI coding assistants matter.

But so do:

Autonomy
Ownership
Trust
Sustainable pace
Customer proximity
Protected focus time
Psychological safety
Fast feedback loops
Cross-functional collaboration
The freedom to improve the system itself

These are often discussed as independent initiatives. They're not. They're all investments in engineering performance. This holistic reality is precisely why frameworks like SPACE exist. Developed by researchers from GitHub and Microsoft, the SPACE framework—which evaluates Satisfaction, Performance, Activity, Communication, and Efficiency—was built to stop organizations from falling into the trap of measuring developers purely by raw output (Activity). It proves mathematically and empirically that Performance and Efficiency cannot exist without Satisfaction and effective Communication.

When we look at software through the lens of SPACE, we see that developer well-being and system performance aren't competing priorities—they are interdependent variables of the exact same equation. That's why I believe Developer Experience has unintentionally constrained the conversation. The name naturally draws our attention toward tools and developer happiness, when the real objective is building an environment where exceptional engineering performance emerges naturally.

The Interest Rate Nobody Talks About

Technical debt is usually discussed in terms of its external cost:

Slower delivery
More production defects
Operational incidents
Higher infrastructure costs
Lost customers

These costs are real. But technical debt has another interest rate. The human one.

Every day spent fighting the tooling.
Every obvious refactoring postponed because "we don't have time."
Every unnecessary approval.
Every layer separating engineers from customers.
Every interruption.

Every reminder that shipping today's feature matters more than improving tomorrow's system. None of these destroys motivation overnight. They compound.

Eventually developers stop improving the system. Not because they stop caring. Because the system slowly teaches them that caring isn't rewarded. This is the part of technical debt we rarely discuss.

Technical debt doesn't only accumulate in software. It accumulates in people. Developers gradually lose ownership. Curiosity becomes compliance. Craftsmanship gives way to expediency. Enthusiasm slowly erodes into indifference.

Those costs rarely appear on a balance sheet, but every engineering organization eventually pays them.

Maybe We've Been Optimizing the Wrong Abstraction

If I asked an executive whether engineering performance matters, the answer would be immediate. If I asked whether developer experience matters, the conversation would probably require an explanation. Those are fundamentally different starting points. The irony is that we’re often talking about exactly the same thing.

A developer who spends hours waiting for builds, navigating brittle internal platforms, fighting legacy code, requesting permission for obvious refactorings, and constantly context-switching isn't simply having a poor experience. The organization is paying a massive price to hold them in that environment.

Maybe we should stop calling it Developer Experience and start calling it Developer Carry Cost.

In finance, Carry Cost is the ongoing expense required to hold and maintain an asset while waiting for it to generate a return. If you buy a physical or financial asset, you don't just pay for the acquisition—you pay the carrying costs to keep it operational.

In software engineering, the developer is the primary asset. Software is merely what that asset produces.

Now, framing human beings as "assets" and human frustration as a "carry cost" might feel uncomfortably cold—especially to engineers who are tired of being treated like cog-in-the-machine resources. But that discomfort is precisely the point.

The comfortable, polite language of "developer experience" and "well-being" has failed us. It allows leadership to relegate systemic engineering friction to an HR quality-of-life initiative—something to look into once "real" business priorities are met.

When developers spend 30% of their day battling broken tooling, slow pipelines, and administrative drag, that isn't just friction—it’s an astronomical Developer Carry Cost. You are paying top-market compensation for a high-value asset, while burning a third of its capacity just carrying it through a flawed system. Worse, under these conditions, human beings eventually disengage. They check out. The asset stops yielding not because the person lacks talent, but because the environment has worn them down.

Technical debt is often just the visible symptom on the codebase. Developer Carry Cost is the actual disease on the balance sheet.

We don't need softer words; we need language that immediately communicates what is at stake to leadership. Investing in the engineering environment isn't an internal luxury or an employee perk; it is a direct investment in lowering our Developer Carry Cost so our most valuable people can actually do their best work.

Why do so many organizations still struggle with developer experience? What do you make of the term Developer Carry Cost? Can you think of a better alternative? I’d love to hear your thoughts in the comments.

Emergent Design & Gall's Law: When Complex Coding Problems Dissolve Instead of Being Solved

Remo H. Jansen — Thu, 30 Jul 2026 12:05:34 +0000

I recently read an article by the main maintainer of InversifyJS describing the journey of rebuilding its dependency resolution algorithm. What caught my attention wasn't the performance improvements or the technical details. It was something much more familiar.

As I was reading, I realized they were experiencing the exact same phenomenon I had experienced years ago while creating InversifyJS. It reminded me of something that, until now, I had never really put into words.

The temptation to solve the hardest problem first

Every engineer has experienced it. You're implementing a feature when you encounter a design problem that feels wrong. You know the current approach won't scale, and you know there must be a beautiful abstraction somewhere, so you stop writing code and start designing.

Sometimes that's the right thing to do. Many times it isn't.

While building InversifyJS, I eventually adopted a different habit. Whenever I found myself thinking, "This feels too complicated, and I can't find a simple, elegant solution right now," I decided to wait.

Not because I ignored the problem, but because I didn't think I understood it well enough yet.

Instead, I focused on features where I had a reasonable level of confidence. I kept improving the parts of the system that felt obvious, leaving the difficult problems untouched.

At first, this almost felt irresponsible. Over time, it became one of the most valuable engineering lessons I have learned.

The magic wasn't finding the solution

The interesting part is that I rarely came back later with a better idea. Something stranger happened.

Implementing those simpler features changed the system itself. New abstractions naturally appeared. Responsibilities became clearer. Concepts that previously seemed unrelated suddenly fit together.

Eventually, I would return to the "hard" problem only to discover it wasn't hard anymore. Not because I had become smarter or because inspiration had struck overnight. The problem itself had changed.

Or perhaps a better way to put it is that the problem dissolved instead of being solved.

Looking back, I think this is one of the defining characteristics of good software design.

Why this happens

Every feature teaches you something about the problem domain. When we invent abstractions too early, we are making educated guesses. Sometimes we are right, but often we are creating abstractions around our current understanding rather than around the problem itself.

As more concrete features are implemented, patterns emerge naturally. The code starts revealing what actually belongs together. The abstraction is not invented; it is discovered.

This is why experienced engineers often say things like "the abstraction revealed itself," "the design fell out naturally," or "the code told me what it wanted."

These expressions sound almost mystical, but they describe a very practical engineering process. You are collecting evidence. Eventually, there is enough evidence that the right design becomes obvious.

Gall's Law explains it perfectly

Years later, I came across Gall's Law from Systemantics:

"A complex system that works is invariably found to have evolved from a simple system that worked."

I think this is one of the best observations ever made about software architecture.

Notice what it doesn't say. It doesn't say complex systems cannot be designed. It says the ones that actually work usually evolve.

That perfectly matches my experience with InversifyJS.

Many of the abstractions people now associate with the library were not part of some grand master plan. They emerged because earlier, simpler decisions created the right conditions for them.

Each feature made the next decision a little clearer. Each change revealed more about the shape of the problem. Eventually, some of the hardest problems no longer looked hard at all.

Emergent design as pragmatism, not procrastination

The approach I am describing is often called emergent design.

Emergent design is the idea that a software system’s architecture should evolve from the implementation of real requirements rather than being fully designed upfront. Instead of trying to predict every future need and creating abstractions in advance, engineers start with the simplest solution that works and allow the design to emerge through usage, feedback, and refactoring.

This does not mean designing without a plan or letting a codebase grow chaotically. It means recognizing that some architectural decisions are easier to make when we have more information. The structure of a system becomes clearer as we solve concrete problems, discover recurring patterns, and learn which concepts genuinely deserve to exist as abstractions.

It is important to distinguish this from simply avoiding difficult work. Emergent design is not an excuse to postpone decisions forever or to avoid thinking deeply about architecture. It is a pragmatic approach to dealing with uncertainty.

One of the easiest mistakes in software development is trying to solve problems before we fully understand them. We start designing abstractions for scenarios that might never happen, or we optimize parts of the system before we know where the real problems are.

This is how overengineering and premature optimizations often begin.

The problem is not that we are thinking too much. The problem is that we are making decisions based on assumptions instead of evidence.

A pragmatic engineer understands that some decisions become easier when the system has more information. Instead of building a complex solution for a hypothetical future problem, they focus on solving the problems that exist today in the simplest way possible.

Each solved problem gives you more information. Each refactoring changes the design space. Each feature teaches you something new.

The goal is not to avoid complexity. The goal is to introduce complexity only when it is justified.

A lesson I keep relearning

Reading the recent article about InversifyJS reminded me that this was not a unique experience. I had always assumed it was just a consequence of how I happened to build the project, but it was fascinating to see another maintainer independently arrive at the same place years later.

It is easy to think good architecture comes from moments of brilliance or from correctly predicting the future. My experience has been almost the opposite.

The best designs I have worked on did not come from trying to anticipate every possible problem or by creating the most sophisticated architecture from the beginning. They came from being pragmatic, solving real problems as they appeared, and allowing the design to evolve with better information.

Sometimes the most productive thing an engineer can do is not to solve the hardest problem immediately. It is to solve the next simplest one with confidence, learn from it, and let that knowledge reshape the system.

This approach avoids the trap of overengineering while also preventing premature optimizations based on assumptions.

If you are patient, and if the design is evolving in the right direction, you will occasionally discover something surprising.

The hard problem no longer exists.

It didn't get solved.

It dissolved.

I tried to compile TypeScript into a native binary with scriptc

Remo H. Jansen — Thu, 30 Jul 2026 09:44:14 +0000

TL;DR: I tried to compile the TypeScript 6 compiler into a native binary with scriptc, and I failed — it got 90% of the way there and then hit an internal compiler error it couldn't get past, so there is no native tsc at the end of this story. But it's a failure worth having: I learned exactly where a week-old TypeScript-to-native compiler runs out of road, and I got some interesting numbers along the way.

So when scriptc was released to the public a few days ago, I knew exactly how my week was going to end.

If you haven't seen it yet, scriptc is a compiler that takes TypeScript — plain, ordinary TypeScript, no special dialect, no annotations — and turns it into a small, fast native binary. No Node.js. No V8. No JavaScript engine shipped alongside your code. A "hello world" comes out at around 320KB and starts in a few milliseconds. The pitch is bold: what compiles behaves byte-for-byte like Node. It does this with a three-tier model — most code lowers straight to native, anything too dynamic can opt into an embedded engine with a --dynamic flag, and the truly impossible fails at build time with a precise diagnostic instead of a surprise.

It's experimental. It's early. It's exactly the kind of thing I can't leave alone.

And almost immediately, a mischievous thought showed up: could I compile TypeScript itself?

Not a toy. Not a fibonacci function. The actual compiler — tsc — the thing that has type-checked basically every line of TypeScript I've ever written. If scriptc can turn that into a native binary, it can turn anything into a native binary. It felt like the ultimate stress test, and I wanted to see it either fly or fall over.

Why 6, and not 7?

Here's where the timing gets interesting.

If you've been following the TypeScript roadmap, you know the ground just shifted. TypeScript 6.0 shipped as the final JavaScript-based release of the compiler, and TypeScript 7 is the ground-up rewrite in Go — the "native" port the team has been building in the open. So we now live in a brief, strange window where two tscs exist side by side: the old one written in TypeScript, and the new one written in Go.

That window is the whole reason this experiment is fun.

Compiling TypeScript 7 with scriptc would make no sense — it's already native. It's already Go compiled down to a machine binary. There's nothing to prove there. But TypeScript 6 is different. TypeScript 6 is the last version of the compiler that is itself written in TypeScript. It's the perfect candidate: a real, enormous, battle-tested TypeScript program that I could feed to scriptc and ask, politely, to make native.

And it sets up a delicious comparison. On one side, TypeScript 6 — the JavaScript compiler, dragged into native code by scriptc. On the other, TypeScript 7 — the Go compiler, native by birth. Two paths to the same destination. I wanted to race them.

So I pinned my versions — typescript@6.0.3 and the Go build typescript@7 — wrote a handful of scripts so I could reproduce the whole thing on demand, and told scriptc to do its worst.

The climb

The first surprise was a pleasant one.

I pointed scriptc's coverage tool at the shipped tsc bundle — a single ~6MB file of generated JavaScript — bracing for a wall of red. Instead: 90% of statements compile statically. 51,045 out of 56,117. Nine out of every ten statements in the TypeScript compiler lower to native code without so much as a flag. That number genuinely made me sit up. The remaining 10% — the dynamic corners of a program that has to reflect on itself constantly — is exactly what --dynamic exists for.

So I asked for a --dynamic build. And scriptc fell over.

Not gracefully, either. A stack overflow — deep inside scriptc's own lowering pass, recursing until V8 ran out of room. Later I hit some internal compiler errors. Six of them, spread across three patterns. A sparse array initializer in createBracketsMap that scriptc couldn't represent. A return condition ? voidCall() : voidCall() in the binder that tripped a "ternary must not be void" check. And a cryptic one — "union u50: arm 0 is jsval" — that pointed at nothing in particular.

Two of those three, I could fix. I wrote a tiny, behavior-preserving codemod that rewrote the bracket map and unrolled that ternary into a plain if/else. Five of the six errors vanished. I was, briefly, convinced I was going to win.

The wall

The sixth error did not move.

"union u50: arm 0 is jsval" — reported at line 1, column 1, which is scriptc's way of telling you it isn't about any single line at all. It's a whole-program problem: somewhere in the compiler there's a union type where one of the arms is a fully dynamic value, and scriptc v0.0.17 simply doesn't know how to lay that out in native memory. There's no source edit that fixes it, because there's no source location to edit. And it's only the first such union.

That's the wall. And I want to be precise about what kind of wall it is: it's not a missing feature or a flag I forgot. It's the compiler's own youth. scriptc is at version 0.0.17. Asking it to swallow the entire TypeScript compiler — one of the most reflective, self-referential codebases in the JavaScript world — was always going to be the boss fight, not the tutorial.

So, no. I did not get a native tsc.

The benchmark I could run

But I'd built the whole racetrack, and I wasn't going to leave it empty.

If I couldn't put native-TypeScript-6 on the starting line, I could at least run the closest honest race: type-check the exact same project — the TypeScript compiler's own src/compiler source, --noEmit, same machine — with everything that could actually run it. And to be fair to scriptc, I also gave it two programs it could fully compile — a cold-start "hello" and a compute-heavy prime sieve — so it wasn't judged only by the one test it fails.

Here's everything in one place. Node (6.x) is TypeScript 6 running on V8; Go (7.x) is tsgo; scriptc.dev is the native binary:

Benchmark	Node (6.x)	Go (7.x)	scriptc.dev
Type-check `tsc`'s own source (`--noEmit`)	523 ms	107 ms	✗ won't compile
Cold start (`console.log`)	48.9 ms	—	3.6 ms
Compute (primes under 2,000,000)	0.24 s	—	2.33 s

Three things jump out.

On the workload that actually matters — type-checking real code — the Go compiler is roughly five times faster than TypeScript 6 on Node. On bigger projects the team reports closer to ten, and I believe them; here, Node's startup is eating a real slice of TS6's time. The rewrite is not hype. It's just fast. (tsgo is a compiler, not a general-purpose runtime, so it doesn't line up for the other two rows — hence the dashes.)

Then the good news for scriptc: its native binary starts in 3.6 ms against Node's 48.9 ms — about 13× faster, in a self-contained 350KB file with no runtime to boot. That's the dream, right there.

And then the humbling one: on a hot numeric loop, Node was 9.6× faster than scriptc's native output. V8's JIT has been tuned for a decade; scriptc's code generator has been public for a week. That gap is not a scandal.

So here's the honest shape of it. Even if scriptc had compiled tsc, it would have done so in --dynamic mode — the same JavaScript compiler, running on scriptc's embedded engine rather than natively lowered logic. Given what I saw, that binary would most likely have been slower than TypeScript 6 on Node, and nowhere near Go. The prize was never going to be speed. The prize would have been a single, dependency-free, instantly-starting binary — and that is a prize worth wanting.

Your AI Agents Need Finite State Machines (FSMs)

Remo H. Jansen — Tue, 28 Jul 2026 23:40:17 +0000

In my previous article, I argued that AI changes the role of constraints in software development.

For years, many developers saw constraints as something to minimize. Dynamic languages gained popularity over static ones. Schema-less databases promised greater flexibility. Convention replaced configuration. Implicit behavior was often preferred over explicit definitions.

The motivation was understandable. Constraints felt like friction. They slowed us down. AI changes that trade-off.

Today, every explicit constraint becomes valuable context that AI can use to better understand our systems.

A database schema is no longer just a validation mechanism. It describes the structure and meaning of the data.
An OpenAPI specification is no longer just a contract between services. It tells an AI how those services are expected to interact.
A type definition is no longer only for the compiler. It helps AI understand the intent behind an API.

Constraints haven't become valuable because they prevent mistakes. They've become valuable because they communicate knowledge. I believe the same principle applies beyond software development. It applies to business workflows.

The Problem with AI Workflow Automation

There is enormous excitement around AI-powered workflow automation. Most current approaches are based on autonomous agents. An agent receives a request, reasons about the situation, selects tools, executes actions, and decides what should happen next.

For simple workflows, this can work remarkably well. For business-critical workflows, however, this architecture introduces unnecessary operational risk.

The AI is not only performing work. It is also responsible for discovering the business process while executing it. That is asking a probabilistic system to infer something that should already be known.

Business workflows contain rules that are independent of AI:

Some actions require approval.
Some actions must never happen twice.
Some transitions are impossible.
Some failures require retries.
Others require compensation or rollback.
Some actions require human intervention.

These are not AI problems. They are business rules. And business rules should not live inside prompts.

The Workflow Should Not Live in the Prompt

When AI workflows become more complex, the common solution is to add more agents.

A planner agent coordinates execution.
Specialized agents perform individual tasks.
Validation agents review the results.

Prompts become increasingly sophisticated. Yet the workflow itself often remains implicit. The workflow exists only through prompts, examples and emergent agent behavior.

This makes the process:

Difficult to understand.
Difficult to test.
Difficult to audit.
Almost impossible to verify.

Business processes deserve a better foundation.

Make the Workflow Explicit

Instead of asking AI to infer the workflow, define the workflow explicitly.

One of the simplest and most powerful ways to do this is with a finite state machine.

A finite state machine explicitly models:

the possible states of the process
the valid transitions between states
the conditions required for each transition
the actions associated with every transition

For example, a purchase approval process could look like this:

Draft
  ↓
Submitted
  ↓
Approved
  ↓
Purchased

When the process is in the Submitted state, the workflow might expose exactly three valid transitions:

Approve
Reject
Request More Information

The AI no longer has to invent the workflow. The workflow itself defines what is possible. The AI only has to determine which of the valid actions is the most appropriate. The workflow provides the boundaries. The AI provides the intelligence.

Explicit Constraints Become Explicit Context

The value of the finite state machine is not simply that it constrains the AI.

It makes the business process explicit.

The AI immediately knows:

the current state
the valid next actions
the required information
the business rules
the possible outcomes

Instead of inferring the workflow from prompts, examples, or previous executions, it receives a precise description of the process.

Just as an OpenAPI specification helps AI understand an API, a finite state machine helps AI understand a business process.

In both cases, explicit constraints become high-quality context.

A Finite State Machine Is More Than Documentation

This is where finite state machines become particularly interesting.

Unlike a prompt, an FSM is a formal model.

That means it is not only explicit.

It is verifiable.

Before an AI agent ever executes the workflow, we can analyze the model and answer questions like:

Can the workflow reach an invalid state?
Are there dead-end states?
Are all approvals enforced?
Can an action accidentally execute twice?
Are rollback paths defined?
Are all failure scenarios handled?
Can every process eventually reach completion?

These are properties that can be verified independently of the AI. This is a fundamental difference from prompt-driven workflows. A prompt describes a process. A finite state machine defines and constrains a process. The FSM becomes an executable safety boundary around the AI.

AI Operates Inside a Verified Boundary

The objective is not to make AI deterministic.

That is impossible.

The objective is to make the environment in which AI operates deterministic.

Without an explicit workflow, the AI constantly asks:

What should happen next?

With an FSM, the conversation changes.

The workflow says:

These are the only valid actions that can happen next.

The AI answers:

Given these valid options, which one is the most appropriate?

This is a subtle but profound architectural shift.

The AI no longer owns the workflow.

It navigates the workflow.

MCP Makes This Natural

This model becomes even more powerful when exposed through MCP.

Instead of exposing dozens of low-level tools, the workflow exposes its current state and the transitions that are currently available.

An AI agent can discover:

the current state
the available transitions
the information required to perform each transition
validation rules
rollback capabilities
escalation paths

The workflow becomes self-describing. Changing the business process means updating the workflow model. Not rewriting prompts. The AI automatically receives the new constraints as part of its context.

Explicit Constraints Drastically Reduce Operational Risk

Large language models are probabilistic. Business processes should not be. A finite state machine does not make the AI smarter. It makes the overall system safer.

By limiting the AI to explicitly defined transitions, we drastically reduce the operational risks of AI-driven workflow automation.

Invalid transitions become impossible.
Every state change is verifiable.
Every decision is auditable.
Rollback becomes part of the workflow instead of an afterthought.
Compliance rules become explicit instead of implicit.

Most importantly, the AI no longer decides what is possible. It decides how to navigate a process whose boundaries have already been defined.

Explicitness Creates Business Value

This is the same principle I discussed in my previous article.

Explicit schemas help AI understand data.
Explicit contracts help AI understand APIs.
Explicit types help AI understand code.
Explicit workflows help AI understand business processes.

The value does not come from adding more constraints. It comes from making the right constraints explicit.

As AI becomes increasingly responsible for business operations, I believe we will rely less on autonomous agents trying to infer business processes and more on explicit workflow models that define those processes in a way that both humans and AI can understand.

The future of AI workflow automation is not unlimited autonomy. It is controlled autonomy. AI provides intelligence. Explicit, verifiable workflow models provide correctness. The role of AI is not to own the workflow. Its role is to navigate it intelligently.

And that is where constraints stop being friction and start becoming business value.

DEV Community: Remo H. Jansen

Career safety in the Age of AI Layoffs

We've always resisted giving up the code

The business never really bought the code

Understanding code isn't the same as typing it

Domain expertise becomes a moat

The engineer becomes a product person

The compression of the middle

The next engineering skill is operating agents

Verification becomes more important than generation

So what actually makes a career safe?

Become replaceable at the task level

Coding was never the destination

Update 1: Technical depth is still relevant

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

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

An example

This is different from a cloud marketplace

Think of it as an OSS affiliate program

Cloud providers already have pieces of the technology

Why would a cloud provider do this?

The flywheel

This could change the economics of open source

Attribution should favor the projects that need it most

It does not have to be 1%

Existing vs. incremental consumption

Open-source neutrality matters

Separate attribution from payment

What if open source became a cloud distribution channel?

Let’s try it

The bigger opportunity

A call to action

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

Two decades of building software

Inversify

Experimenting with developer experience

From Inversify to RFLCT

What I think I'm actually good at

So what am I looking for?

What I'd love to do

What I bring

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

Where?

If this sounds like you

AI Code Is No Longer Slop

The Linux moment

Read the original

AI still produces bad code

“AI-generated” is not a quality metric

The real change is the cost of another attempt

Developers that brand AI as slop will be left behind

AI makes experimentation cheap

The Inversify problem is real

The value moved up the stack

“But you didn’t write the code”

“AI slop” is not a technical critique

We have seen this movie before

The productivity gap will compound

AI amplifies the developer

I would rather build and be wrong

RFLCT: Bringing Runtime Type Metadata to TypeScript 7

What is RFLCT?

The Magic: Before and After

What you write:

What RFLCT compiles it to:

Broader Than Just InversifyJS

How It Works: The Three Transformations

1. design:symbols — The Global Type Registry

2. design:arguments — Parameter Type Metadata

3. resolve<T>() — Compile-Time Type Resolution

Smart Symbol Qualification

Getting Started (Alpha Preview)

1. Build from Source

2. Project Setup

3. Configure Your Build Tool

Looking Forward & Next Steps

23 TypeScript Tools for Making Software Explicit in the AI Era

Schemas and Side Effects

1. Effect

2. Zod

1. `design:symbols` — The Global Type Registry

2. `design:arguments` — Parameter Type Metadata

3. `resolve<T>()` — Compile-Time Type Resolution