You can have all the measures in place that are described in that post, and your code can still be bad. High unit test coverage tells you exactly zero about the solution itself.

And technical quality gates do not help if the human side lacks defense against slop code. If you don't have the right managers in place, the 2 years of experience vibecoder who ships a feature in 4 hours will always win against the 20+ year senior who actually looks at the code he is about to ship.

A recent HN article (below) concluded that asking agents to do TDD wasn't particularly helpful. I hope there is more research on this because TDD will be slower, use more tokens and results in more code to review.

https://news.ycombinator.com/item?id=49605246

That makes no sense. Garbage article.

If an LLM makes a good codebase bad, you can't in good faith blame the coders. You blame the LLM.

Since I am retired, my uses of agentic coding harnesses include:

1. update my old open source projects by searching for and fixing defects, adding tests and documentation

2. working on my own agentic coding harnesses, using the coding harness I am modifying to update itself. I am tightly in the loop

Sure, not highly practical use of AI, but I am retired!

> Unit tests at >95% coverage

Eh. I wouldn't focus on unit test coverage.

I think it's true that good, well tested code will have higher code coverage than crappy code.

But, above a certain point (which will vary from codebase to codebase), unit tests aren't meaningfully increasing confidence that the code is working.

I'd recommend focusing instead on the code being written in a pure 'functional core, imperative shell' to the extent that's possible. For that pure/functional part, 100% code coverage is attainable (& so not worth remarking on). For the impure parts, unit tests are probably using "mocks" just to get the code to compile anyway.

Wow what an opener comment thread. One thing is for sure, this is a very contentious topic lol. I have had this opinion since way before this ai boom; someone who pushes code to prod is responsible for what happens in prod with that code. This blogpost is very relatable

The issue that I have with this "skill issue" argument is that it is essentially "screw you, got mine". Whether it is teaching programming or going up to making software, it has always been an intractable problem to bring experience, heuristics and intuition to words, something teachable, transferrable. Ok, senior engineers with 30+ years of experience say they are using it right and I'm using it wrong, what do I do with that information? Back to sink or swim, just at a massively faster pace than before.

For the part, I do believe there is a way to gain the "eyes of experience" without spending the years, just not sure exactly how.

This is the same story we got about code quality we got before, but with AI added.

I have a suspect that the people who thing AI code is high quality are the same people that never cared about quality in the first place and now are advocating to stop even having code reviews

This is a variant of: if [tool] isn't giving you good results, then it's your fault.

For some values of [tool], this is right. Question, is it true for this particular value?