Live data from Hacker News

Engineering management after the cost of code collapsed

karimjedda.com

191–200 of 217 posts

Re: Engineering management after the cost of code collapsed

#191

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.

A lot of people should try being more specific in their prompts, but then again at a certain point you're basically just writing all the code in sentence form!

Re: Engineering management after the cost of code collapsed

#192

Earlier 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…

[deleted]

Re: Engineering management after the cost of code collapsed

#193
post #177
post #154

Earlier 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…

jQuery is still used by approximately 7.78 million of the top 10 million websites. That's 77%.

React has about 3 to 4% of the top 10 million.

Re: Engineering management after the cost of code collapsed

#194
post #154

Earlier 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.

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.

Re: Engineering management after the cost of code collapsed

#195

Earlier 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.

"Talk is cheap, show me the code"

A working prototype beats endless discussions over paper

Re: Engineering management after the cost of code collapsed

#196

Earlier 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

Talk is cheap, that's why you do it before sinking months of man-effort into building a turd.

Re: Engineering management after the cost of code collapsed

#197
post #154

Earlier 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.

Cherry picked usage stats are off topic. The fact that 90% of Fortune 500 companies rely on COBOL[1] doesn’t make other languages a niche.

[1]: https://www.rocketsoftware.com/en-us/insights/what-is-cobol

Re: Engineering management after the cost of code collapsed

#198

Earlier 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.

LLm generation of code is an absurdly high dimensional process, and incredibly sensitive to the starting conditions and any other interactions so in some sense it's expected that there will be wildly different outcomes.

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

#199

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…

> The other thing that the "LLMs write code camp" misunderstands is that writing was never the bottleneck.

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

#200

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.

For me, at least, the overall design needs to come from using the code.

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.

Post reply on HN