I 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 have not experienced this "llms dont write maintainable code narrative" I just tell it the shape of the entities and apis I want vaguely and the mental model and the output is excellent.
Engineering management after the cost of code collapsed
191–200 of 217 posts
Re: Engineering management after the cost of code collapsed
#192Earlier quoted context omitted.
you're a lot more skilled than I am if you're able to know the abstractions and patterns you want while only have a weak grasp on the actual code. For me the abstractions emerge as I understand what I'm actually working with
> while only have a weak grasp on the actual code. How much of a grasp does one need on the UEFI code operating their computer? The drivers that operate a hard drive? The communication protocols for their monitor? This seems to me to be the fallacy — that all code must always be understood to operate properly or to be useful. If the AI is sufficiently intelligent enough to understand the code, at some point (most) pe…
Re: Engineering management after the cost of code collapsed
#193Earlier quoted context omitted.
We’ve already lived through multiple floods of unmaintainable code, eg with unstructured JQuery. New tech stacks will appear and they will handle the mess to some extent.
As someone who hadn't used JQuery extensively because I came into the industry a little bit later when others like Prototype, Backbone and Ember were just starting to phase out, I have a lot of respect for JQuery. Or perhaps I have a lot of respect for the problems that JQuery solved which we now take for granted, like AJAX requests. With this and the pipe dream of continuous generation and deployment of code without…
React has about 3 to 4% of the top 10 million.
Re: Engineering management after the cost of code collapsed
#194Earlier quoted context omitted.
We still pay our software developers the same amount, but now an AI is the middleman taking more and more money (in the form of tokens) every day. With every new model, more tokens are consumed so the new model can "think" more. Nobody's even really reading or reviewing the code the AI produces, so software quality goes down, and we're paying more to produce it. And when there's a serious problem with the code? No hu…
We’ve already lived through multiple floods of unmaintainable code, eg with unstructured JQuery. New tech stacks will appear and they will handle the mess to some extent.
Re: Engineering management after the cost of code collapsed
#195Earlier quoted context omitted.
A pattern I have seen: The “old way” would be lots of debate (both bike shedding and useful) among engineers during design phase, and then you’d implement. Now it’s shifted so there are no design docs and there is only the generated prototype. People trying to do their design review while there’s already a functional-ish prototype and it goes nowhere. There’s an anchoring effect in place because the first thing alrea…
This is so accurate. I am a fairly senior individual contributor and its been more than a year since I saw a good design doc or quality design discussion. Before you can even question the design, someone has generated a 50k line prototype and already made up their mind because of all the “you’re absolutely right..” and “X is exactly what you need..” from AI.
A working prototype beats endless discussions over paper
Re: Engineering management after the cost of code collapsed
#196Earlier quoted context omitted.
This is so accurate. I am a fairly senior individual contributor and its been more than a year since I saw a good design doc or quality design discussion. Before you can even question the design, someone has generated a 50k line prototype and already made up their mind because of all the “you’re absolutely right..” and “X is exactly what you need..” from AI.
"Talk is cheap, show me the code" A working prototype beats endless discussions over paper
Re: Engineering management after the cost of code collapsed
#197Earlier quoted context omitted.
We’ve already lived through multiple floods of unmaintainable code, eg with unstructured JQuery. New tech stacks will appear and they will handle the mess to some extent.
jQuery is still used by approximately 7.78 million of the top 10 million websites. The people touting "modern frameworks" are in a niche and they don't even realize it.
[1]: https://www.rocketsoftware.com/en-us/insights/what-is-cobol
Re: Engineering management after the cost of code collapsed
#198Earlier quoted context omitted.
No, the tools really are bad, and everyone claiming they are good really is wrong. Or deliberately lying.
They're both wrong and deliberately lying.
Personally, I'm more on the LLM code is pretty bad from a design point of view, particularly when much of the code is already LLM generated.
Re: Engineering management after the cost of code collapsed
#199I 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…
Anyone who's seen tech debt where each item is well known and understood but just big in scope knows that this isn't true universally - depending on your team size and composition, any damn thing can be the bottleneck, often at different times too. I'll take everything that helps me resolve them with reasonable trade-offs, even if I need to come up with ways to mitigate the issues created by those trade-offs (like enforcing >90% test coverage as a starting point).
Re: Engineering management after the cost of code collapsed
#200I 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 have not experienced this "llms dont write maintainable code narrative" I just tell it the shape of the entities and apis I want vaguely and the mental model and the output is excellent.
I think for refactoring, you're definitely right as if you give them a good high level sketch you can get them to do all of the more tedious implementation.