[BalinKing]

I've never really understood this argument. If someone's a manager of an incompetent team, no amount of management skill will save the quality of the resulting software. I don't think "just treat LLMs like smart junior developers" fixes this, because well-functioning teams usually also have senior developers to keep things on track. Like, if we handed a team of genius-but-junior developers to the best "people person" manager in the world (i.e. who doesn't actually read the code), would we really expect decent results? Even if the manager tested the code by hand? I honestly don't think so, at least once the software gets past a certain (fairly low) threshold of size/complexity.

[westurner]

If you have a "this is an incompetent team" attitude, that's what quality software you'll get back; whether or not there's LLM use.

If you have a "I trust my competent team to write good enough tests and test coverage isn't my responsibility" attitude, that's what quality software you'll get back.

There are people producing good and excellent quality software with LLMs. Presumably you must discard low-quality code in order to maintain quality.

There's certainly a limit to code quality with current models. On number of lines of code per unit of time, LLM tools certainly already win.

Can costly automated code review for PRs catch most of the problems before they're under consideration for merge?

For example, the vscode repo has extensive copilot integration. Every PR gets auto code reviewed. But with their tokens or the contributors'?

If I take poor quality code (AI-assisted or not) and spend a few hundred dollars on tokens for a next gen model and agent to get to 100% coverage and review for security bugs and CWE common weaknesses, what quality code will I have without refactoring with proven patterns and type annotations and polishing docstrings?

[jagenabler2]

I don't think this argument holds. The OP made the very good point that most quality software teams are composed of both seniors and juniors, with the seniors (and even staff members sometimes) drawing the lines so that the system stays on rails.

If you're a manager now and your "team" is a bunch of coding agents, those agents are hardly junior engineers at best. It is equivalent or even worse than hiring a team of 3-5 junior engineers and letting them run rampant with your code.

[deaton]

> If you have a "I trust my competent team to write good enough tests and test coverage isn't my responsibility" attitude, that's what quality software you'll get back.

As much as this sentiment is nice, it is completely divorced from reality, unless the competence is verifiably there. If you take a bunch of juniors and say "yeah I trust them to do everything well enough," you're going to have a disaster on your hands.