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 be...
For further actions, you may consider blocking this person and/or reporting abuse
The cheap experiment loop is the part that matches how coding agents actually change the work. An afternoon prototype is easy now. The expensive part moved to deciding what should never ship, then reading the result hard enough to throw half of it away when the agent invents an abstraction nobody asked for. Blanket "AI slop" skips that filter. The filter is the job.
TBH, this conversation is tiring, but I think we share the same feeling from much of what I read in your post.
The bitter truth is that no matter how hard we try to separate human effort from AI collaboration, the time spent drawing that boundary may be more valuable elsewhere. Someone in 2050 will still choose to download slop over a genuinely useful solution to a real pain point. The provenance of the effort won't change that.
This hits the exact inflection point of modern systems engineering, Remo.
The distinction between dogmatic Luddism ("all generated code is slop") and un-curated generation (actual slop) is the core divide of 2026.
Your formulation that the scarce resource has moved up the stack from syntactic output to architectural judgment is spot-on. Code generation is essentially free; what remains expensive is understanding the failure modes, the boundary constraints, and whether the system should have been built in the first place.
Using an LLM to collapse the feedback loop of an architectural hypothesis, taking a build-time AOT reflection idea like "rflct" from an RFC to an executable, testable alpha in an afternoon, is the textbook definition of leverage.
The critical difference is that you already held the mental model of Inversify's 10-year decorator trade-offs in your head. The model didn't design the architecture; it simply acted as a high-speed, non-deterministic compiler for your constraints.
The developers dismissing rapid prototyping as "slop" are confusing the provenance of keystrokes with the rigor of the evaluation.
If the tests run, the memory bounds hold, and the architect understands the execution path, the speed of the loop is an asset, not a liability.
Excellent piece.
The strongest point here is that AI changes the cost of experimentation, not just the cost of typing code.
I’ve seen the same thing happen with architectural work: the real advantage is being able to prototype an idea, break it, test the assumptions, and move on quickly when the evidence says it’s wrong. AI is extremely useful in that loop when the developer is still responsible for the reasoning and review.
“AI slop” by itself also isn’t useful technical feedback. If the architecture is flawed, point to the flaw. If the generated code has a correctness, performance, or maintainability problem, demonstrate it. That gives the author something they can actually improve.
The interesting developers to watch won’t be the ones who blindly trust AI or reject it completely. They’ll be the ones who can use it aggressively while still knowing exactly what they’re shipping.
That shift toward faster validation and iteration is probably the bigger story than code generation itself.
That's a really interesting perspective. Since the true value is shifting towards system design and architecture, what is your actual approach when defining the initial structure to test a new idea?
It really depends on what you are trying to test. For an end-user product the only validation might be some form of usability test, asking how much people would pay for this software, etc. In my particular case this time around it was more of an engineering problem than a user problem. We were relying on an API that has become non-standard and is due to become deprecated at some point. We were facing an existential threat. Then I came across typia.io and that was the moment I thought: We could use a compiler plugin to generate the metadata we need. So my hypothesis became: Can we generate the same metadata that --emitDecoratorMetadata generates, but using a plugin and types instead of decorators. I described the simplest possible use case to the AI:
We want (current API):
To emit the same metadata as (new API):
And in terms of verification I asked the AI to generate TDD-style tests. Write a test that verifies the metadata. Change the API. The tests should still pass. The ability to verify via unit tests is one of the reasons AI performs extremely well in refactoring scenarios.
After this it was a matter of tackling more complex use cases one at a time.
If my problem was an end-user problem I would probably set a strong foundation of “contracts”. For example I might design the database schema and the REST API and give the AI those as contracts that cannot be violated. You could even write automated architecture tests that check for violations of separation of concerns (imports from incorrect layers) to enforce a given architecture.
In both cases the end goal is to verify if the idea is viable ASAP. In the refactor case, as soon as the rewrite is done and the tests are still green your verification is completed. In the end-user case you will have to listen carefully to how the users feel.
Thank you for the detailed breakdown! The idea of using strict contracts and TDD to keep the AI within architectural boundaries is brilliant. I'll definitely start applying this approach to my own projects. Great insights!
The cost of experimentation collapsed. The cost of evaluation didn't - and that asymmetry is the part of your argument I'd push on, because it changes what compounds.
Developer B explores five ideas a day. Each one still needs the same judgment it always did: is the architecture sound, what are the failure modes, is it correct under load. That work didn't get cheaper. So B's advantage compounds only while evaluation keeps up - and the moment it doesn't, what compounds is a growing pile of unevaluated artifacts that all look finished. rflct has a runtime, types, tests, examples and a CLI after a couple of hours. So would a version of rflct that's subtly wrong.
Your own framing already contains the answer - judgment moved up the stack - but I think it's stronger stated as a constraint rather than a shift: iteration speed is now bounded by evaluation capacity, not by generation capacity. That's a much more actionable thing to optimise than "use AI aggressively."
Which makes the concrete question worth asking: for rflct specifically, how did the time to convince yourself it was right compare to the couple of hours it took to build? If it was longer - and I'd guess it was - that ratio is the real headline, and it's a number almost nobody publishes.
Heinrich has isolated the fundamental scaling constraint of modern software engineering: Amdahl’s Law applied to the Software Development Lifecycle (SDLC).
When you collapse the generation time ($T_{\text{gen}}$) toward zero, the overall cycle time
$T_{\text{total}} = T_{\text{gen}} + T_{\text{eval}}$
becomes 100% dominated by human evaluation capacity ($T_{\text{eval}}$).
The dangerous illusion is that because an artifact like "rflct" compiles, passes basic unit tests, and exposes a CLI, it feels finished. But as Heinrich pointed out, a subtly flawed architecture that silently leaks memory or introduces deadlocks under concurrency looks identical on the surface.
This is why Developer B’s advantage only compounds if they solve the Evaluation Bottleneck.
If evaluation remains a purely manual, line-by-line human inspection of generated tokens, Developer B will inevitably hit a cognitive ceiling, transitioning from an "accelerated explorer" into an exhausted reviewer drowning in Verification Debt.
The only mechanism that allows evaluation to keep pace with generation is automating the invariant verification layer:
Architectural Fitness Functions (like Heinrich’s "go list -deps" boundary tests) that mechanically fail the build on structural violations.
Property-Based Testing (PBT) that fuzzes state machines across millions of randomized inputs rather than relying on 3 hardcoded happy-path unit tests.
Formal Contract Boundaries (like WebAssembly capability sandboxes) that physically trap failure modes regardless of what the generated code attempts to do.
Remo’s hypothesis holds only when the engineer’s mental model acts as an uncompromising filter, backed by automated verification.
The Evaluation-to-Generation Ratio ($T_{\text{eval}} / T_{\text{gen}}$) is indeed the real headline of 2026.
Spot-on analysis from both sides.
u built it ? 🤣 .. wait.. or is this post also written by the AI ?
It depends.. what you define as "built"? If you come up with the idea, desing the solution and application architecture, desing the verification process, code review the whole thing... but yes, I did not write 1 line of code. Maybe I should say I "designed and verified" insted of "built" but again, does it really matter? or what matters is if the end result is useful?