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.
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.
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.
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.
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.
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.
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 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.
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.