You are trying to justify blaming the tool, not how it is used.
Do you also blame a screwdriver for not being able to hammer nails into the wall? Learn the tool and how to use it, decide where it makes sense. Like you should do with all tools.
> The hardness/loop thins it's just yet another pattern invention to justify agentic coding.
In my case, building my harness has sped up reverse engineering immensely. An agent can debug kernels, UART, I2C busses, firmware blobs, binaries within minutes what otherwise would have taken me weeks if not months. And that's just because I gave it a workflow to do this, with build/debugging containers, and the possibility to write Go libraries and bindings in an isolated manner.
They are really good at doing the gruntwork, if you build a testable workflow for them. The TDD/unit/end-to-end tests turn plausible code into deterministic code, and that's the core difference in usage.
> Btw many of us still hand code, not just reading it, for assuring and be actually accountable for what we release.
I also never said that I am not proofreading and refactoring everything they generate, that's your assumption.
Thanks for clarification, I think we actually have some ground stuff we surely agree upon.
> Do you also blame a screwdriver for not being able to hammer nails into the wall? Learn the tool and how to use it, decide where it makes sense. Like you should do with all tools.
Problem is I see where everybody is going with this stuff, and since the software industry has been injected by mediocrity since a long time, they're all trying to use the screwdriver in problematic ways.
I see trends of people not caring anymore, you may argue they didn't before but the careless it's accelerating, not reading code anymore, not even opening an IDE anymore. And this hurts the industry as a whole because make managers believe they can have some expectations.
> The TDD/unit/end-to-end tests turn plausible code into deterministic code, and that's the core difference in usage.
I don't agree on this, for
1) you call it yourself "plausible" and that's a big problem cause it makes your code looks good but it's shit on a second review or in the long term. Human slop is easier to cleanup, and at least you have an attachment and know everything about the human tech debt. AI slop it's very hard to cleanup, sometimes it's cheaper to just throw it away and do it from scratch.
2) In my experience there is no amount of tdd/unit/e2e that guarantees you quality and robustness, let alone "deterministic" results. I saw 90% or more of green code coverage and the application behaving like total shit. Problem is the other trend here is letting AI writing the tests and many many times it pushes useless tests.
Instead of pushing the AI narrative that's better than capable software developers If we were honest from day one we wouldn't have all the stupid trends we have today. And that's our fault, we jumped on the AI bandwagon too early and too enthusiastically. Like we are the only category that's happy to admit that the work has been done by Claude. This is very stupid, we don't even have a self preservation instinct
Basically I see everyone accelerating towards a very negative end result and making developers useless sloperators