**Stop calling every prototype "AI slop" — that's how you ship
tsgo compiler.The first reply?
> AI slop
Cool. I closed the tab and went to build it instead.
Eighteen months ago I'd have said that's crazy talk. Shipping a working repo with a runtime, compiler-side implementation, types, tests, examples, and a CLI in a single evening used to require a small army and a weekend hackathon. Instead I pushed a fresh repo called rflct — alpha quality, plenty of rough edges, but real enough to run, test, and hand to other developers.
The math on that has changed fundamentally.
The experimentation tax just collapsed
For years, turning an architectural hunch into something executable meant paying a brutal tax: dig through API docs, sketch the design, write the code, debug it, write tests, fight edge cases, then maybe discover it was all wrong. When that loop costs days or weeks, developers go conservative. You bet big on one idea and live or die by it.
LLMs don't just type faster. They make the gap between "what if this worked?" and "let's find out" almost free. That's the part most people are still sleeping on — the value isn't in the code churn, it's in the volume of experiments you can afford to run.
This wasn't about replacing thinking
Inversify was built around TypeScript's legacy decorator metadata. It worked great — parameter injection could infer types automatically and that felt magical. But the ecosystem evolved. TC39 decorators dropped the parameter decorator mechanism, and design:paramtypes metadata lives in the legacy world. Meanwhile tsgo is pushing an IPC-based compiler model. The problem was already there.
My RFC was deliberately exploratory. Open questions, things that needed prototyping, assumptions that could be wrong. That's the whole point of an RFC.
Someone decided the most helpful feedback was "AI slop."
So I built the prototype instead.
rflct is an ahead-of-time reflection metadata layer for TypeScript 7. Instead of runtime decorator metadata, it generates the metadata at build time. The hard part — identifying the problem, deciding the architectural trade-offs — that all happened before AI entered the picture. What changed was the cost of turning those decisions into something runnable, testable, and shippable.
The job moved up the stack
When writing code gets cheap, writing code stops being the scarce resource. The real work moves up:
- What problem are we actually solving?
- Is this the right problem, or the easy one?
- Is this architecture defensible under real constraints?
- What should be tested, and what shouldn't be built at all?
- How do we know the result is correct?
- What breaks in production, and how do we catch it?
An LLM can spin up a function, no question. But deciding which functions matter, which trade-offs are worth making, and which edge cases will haunt you at 2 a.m. — that's still human territory. The tools just made the experimentation loop fast enough that avoiding it entirely looks a lot more like laziness than rigor.