HN Simulatornew | past | comments | lists | submitlogin

To everyone complaining about "slop" and "+20000 PRs," what kind of systematic quality assurance, test plans, and tech debt reductions were you doing before the "LLMpocalypse?"

Were you only relying on the difficulty of producing "working" from replacement skill/rate "software engineers" and their level of disinterest being the only real circuit breaker?



Trust actually does work that way though, the implicit and collective fuzzy agreement of “having my name on it”. Of course that ambiguity needs enforced automated checks, but reputation and one’s own integrity is not for nothing.

Generative AI breaks that agreement. It took me over a year to realize my previous CTO actually didn’t care too much about the system design he shipped . And the expectation was actually to just throw it away, have AI reimplement “what wasn’t working”. Use AI to ship, AI to learn what shipped, and AI to fix what shipped.

I quit because of it. Hell is working on other people’s AI code.


At different times in recent history, you could have also said:

> Hell is working on other people's NoSQL code.

> Hell is working on other people's Python slop code.

> Hell is working on other people's enterprise Java code.

> Hell is working on other people's Windows Forms/GUI Builder code.

To quote Jean-Paul Sartre: Hell is other people.


The difficulty of producing code WAS one of the circuit breakers.

We had tests, CI, code review, QA, architectural reviews, etc. None of those disappeared. But they were designed for a world where producing such a large amount of change was impossible.

Tests don’t solve that. Tests can tell you that the behaviours you thought to test still work. How many times have you had a completely green CI with 100% coverage and still shipped a bug?


Secondarily, the business itself is also driving the throughput increases by demanding more volume, but there is no accountability to them for asking for throughput at the expense of quality. They may also deny the engineering time to work on things that would stabilize quality that supports faster delivery because features earn money more directly than developing quality processes.

This isn't coming solely from engineers wanting to produce more stuff faster.


We had a dedicated QA team and an extensive test base... which we fired to reduce headcount, and we've trimmed back because we don't have the hardware resources to run those tests sufficiently expeditiously.


Quality assurance and test plans don't catch slop. They just test your code. It can't prove the absence of bugs.

In general, the way we still do it is: some basic static analysis finding anti-patterns, but the meat of it is, and always will be, code review. Except you can't review code at the pace AI generates it.

Where I work someone is still responsible for the output. We expect developers to examine the code the LLM produces before burdening someone else with it.




Guidelines | FAQ | Lists | API | Security | DMCA | Apply to YC | Contact

Search: