I think the intended takeaway is to learn to solve those problems without line by line review. Start by being hands off on a low stakes project, and see how the model fails. Then, come up with, and try, solutions that aren't you doing archeology.

▲

troupo a day ago | parent [-]

This somehow assumes that the person above doesn't already do all the magic the people say work 100% of the time, and finds these issues. How does running into literally the same issues in a low-stakes project help?

▲

BobbyJo a day ago | parent [-]

I think it's a good assumption. Their comment implies they aren't harnessing the coding agent very strongly given the failure modes they mention.

Do you think it's better to experiment with high stakes projects? Do you think it'll be easier to avoid defaulting to line by line auditing of a project that is high stakes?

▲

troupo 17 hours ago | parent [-]

> Their comment implies they aren't harnessing the coding agent very strongly

Ah yes. "all the magic the people say work 100% of the time"

> Do you think it's better to experiment with high stakes projects?

This again assumes that people working on high stakes projects only work on one single project.

This again assumes that people finding issues with LLM-generated code have not tried every magic recipe under the sun from people claiming their hair growth elixir is 100% a working solution.

This again assumes that people experiencing something different from the others are inevitably stupid.

etc. etc.

▲

BobbyJo 10 hours ago | parent [-]

> Ah yes. "all the magic the people say work 100% of the time"

I don't see how this rebutts the implication.

> This again assumes that people working on high stakes projects only work on one single project.

No it doesn't. It's a very straightforward yes or no question.

> This again assumes that people finding issues with LLM-generated code have not tried every magic recipe under the sun from people claiming their hair growth elixir is 100% a working solution.

He's just describing very common failure modes that come from a lack of structure/linting.

You're framing things like this is some grand conspiracy. OP is literally describing flat tires and your rebuttal is "these magical round tires i keep hearing about." It's very strange.

LLMs will dedupe code if you give them structures to find the duplication. It's not magic. I do it every day.

	▲	troupo 6 hours ago \| parent [-]
		> You're framing things like this is some grand conspiracy. OP is literally describing flat tires and your rebuttal is "these magical round tires i keep hearing about." It's very strange. It's not. OP is literally stating a fact that he sees in his work with LLMs. Without even saying what he's working on. Your (and others') immediate assumptions: - he only works on one project - this only project is high stakes - they are not magicking their project with right magicks. Sorry, not "harnessing agents" - they lack structure/linting Ah yes. It's very strange of me to call out these assumptions. Now, let me step in the OP's shoes as a person who sees the same issues across multiple projects and doesn't believe in magic (and has tried all of them, except the very expensive ones). Here's the entirety of OP's text, emphasis mine: "Here I am still unable to stop myself from doing line-by-line code review. I notice too many things (redundant code, duplicate code, overly complex architecture, etc.) by doing it that I feel it would be careless not to." So: - no amount of "harnessing the coding agent very strongly" will fix those issues. Also, "harnessing an agent strongly" is as meaningless as "there's some magic that will fix it". Agents will always continue with code duplication and sloppy architecture. It's a fact of reality. You can run a "swarm of review agents" that will catch some of that, but this is just a) acknowledging the problem, and b) handing off the problem to the same LLMs that produced the problems in the first place and hoping that they will magically fix them - no amount of linting will help with things like code duplication, redundant code, or overly complex architecture. No linter catches bad architecture. Very few languages have tools to do semantic code analysis and catch duplicate or redundant code. - no idea what you mean by "structuring". To structure code correctly you need human input because <see issues described>. Any other "structure" is just running a bunch of the same LLMs on top of various markdown files telling them "make no mistakes" in various ways. I am not kidding or lying that just today I was "structuring" Opus 5.5 to remove duplication from code it was creating as I was watching it. Despite all the "structuring" and "harnessing" etc. And catching previous duplication introduces by Fable and Astra despite all the "structuring" and things like https://github.com/elixir-vibe/ex_dna