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?
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?
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.
> 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.
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?
This isn't coming solely from engineers wanting to produce more stuff faster.
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.