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.
