> The cost of producing plausible code has collapsed
Who wants merely plausible code?
Engineering management after the cost of code collapsed
81–90 of 217 posts
Re: Engineering management after the cost of code collapsed
#82I think most of this is correct, in spite of potentially being built on a bad assumption. The assumption is that LLMs should be writing the code and human engineers reviewing and verifying the LLM output. And that this pushes the cost of producing down. And I fundamentally disagree with that. Every time I ask LLMs to write code, even with Opus 4.8 (haven't tried it with Opus 5 yet), what I get ends up being totally r…
I've come to realize that the smarter LLMs get, the less they understand the point of abstractions. I've been using it for a unity game for the past few years. Nowadays it will go sleuthing into packages and assembly and make decisions based upon what it sees there. It will make comments about why it's doing something based upon a function call 3 methods deep. God forbid any of these details change in a minor version…
Try reducing thinking and use lighter models. For example I observed that using Sonnet works much better (compared to Opus) for tasks I want to be in control of architecture and just need a faster code input.
Re: Engineering management after the cost of code collapsed
#83Sorry, "Gemini 4 helped with editing"?
Re: Engineering management after the cost of code collapsed
#84Gemini 4 eh????
Re: Engineering management after the cost of code collapsed
#85Earlier quoted context omitted.
How do you handle the fact that an LLM can't seem to help itself from disgorging page after page of words no matter what it's asked to do? I've never seen an LLM say "this looks good as-is; I would not spend any more time on it; what's next?" it will always seem to suggest using another pattern or additional abstractions or other yak shaving. But to be fair human code reviews have the same problem. It's like reviewer…
I’ve found stating “only call out critical issues, report but ignore everything else” will basically get what you want. Put that in a review skill and you’re good to go. To be clear I mostly only use Opus and Gemini Flash but this might work for others too.
> I’ve found stating “only call out critical issues, report but ignore everything else” will basically get what you want.
Disabling your C compiler warnings works too. You get to ship then leave work early!
Re: Engineering management after the cost of code collapsed
#86Sorry, "Gemini 4 helped with editing"?
dang it i tried to check for a dupe but there were too many comments!
Re: Engineering management after the cost of code collapsed
#87I think most of this is correct, in spite of potentially being built on a bad assumption. The assumption is that LLMs should be writing the code and human engineers reviewing and verifying the LLM output. And that this pushes the cost of producing down. And I fundamentally disagree with that. Every time I ask LLMs to write code, even with Opus 4.8 (haven't tried it with Opus 5 yet), what I get ends up being totally r…
How do you handle the fact that an LLM can't seem to help itself from disgorging page after page of words no matter what it's asked to do? I've never seen an LLM say "this looks good as-is; I would not spend any more time on it; what's next?" it will always seem to suggest using another pattern or additional abstractions or other yak shaving. But to be fair human code reviews have the same problem. It's like reviewer…
My guess would be that this is a matter of fine-tuning the model to the problem. You would need to run the review experiment N times, observe the distribution of answers, and then fine tune with model operational parameters.
Perhaps someone more knowledgable could jump in here to clarify?
Re: Engineering management after the cost of code collapsed
#88I think most of this is correct, in spite of potentially being built on a bad assumption. The assumption is that LLMs should be writing the code and human engineers reviewing and verifying the LLM output. And that this pushes the cost of producing down. And I fundamentally disagree with that. Every time I ask LLMs to write code, even with Opus 4.8 (haven't tried it with Opus 5 yet), what I get ends up being totally r…
How do you handle the fact that an LLM can't seem to help itself from disgorging page after page of words no matter what it's asked to do? I've never seen an LLM say "this looks good as-is; I would not spend any more time on it; what's next?" it will always seem to suggest using another pattern or additional abstractions or other yak shaving. But to be fair human code reviews have the same problem. It's like reviewer…
The verbosity itself seems to be a problem with post-4.6 Claude rather than a general issue with all LLMs. and IME the yak shaving is due to an overly generic prompt. We have a generic automated review bot but it’s prompted to only look for errors and never suggests refactoring; that was a conscious trade off to avoid what you’re talking about. If you’re reviewing interactively then you can give additional guidance about any code smells etc. that jump out
Re: Engineering management after the cost of code collapsed
#89I think most of this is correct, in spite of potentially being built on a bad assumption. The assumption is that LLMs should be writing the code and human engineers reviewing and verifying the LLM output. And that this pushes the cost of producing down. And I fundamentally disagree with that. Every time I ask LLMs to write code, even with Opus 4.8 (haven't tried it with Opus 5 yet), what I get ends up being totally r…
How do you handle the fact that an LLM can't seem to help itself from disgorging page after page of words no matter what it's asked to do? I've never seen an LLM say "this looks good as-is; I would not spend any more time on it; what's next?" it will always seem to suggest using another pattern or additional abstractions or other yak shaving. But to be fair human code reviews have the same problem. It's like reviewer…
I personally rely on this behavior of LLMs. For example, for reviewing prose, I might ask the LLM to find five issues. If there are obvious issues I missed, then it'll find them. But if all the issues it lists are minor or hallucinated, then I can have some confidence there weren't any glaring issues.
I do the same for LLM code review comments: some changes are out of scope or could be moved to a separate PR; some edge cases don't happen in practice and should just fail noisily instead of writing more code to maintain. When these are the only issues it's raising, then I know it's done.
Re: Engineering management after the cost of code collapsed
#90I’m struggling to imagine a project that would require more than one talented engineer and a bucket of tokens anymore. I think perhaps the assumption that engineering managers should have any employees may be outdated. I can imagine average and mediocre engineers equipped with tokens could create chaos and debt on a scale never before imaginable, so it’s easy to see how orgs who still have these employees around are…
> I’m struggling to imagine a project that would require more than one talented engineer and a bucket of tokens anymore
Try air traffic control?