Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Engineering management after the cost of code collapsed

karimjedda.com

Post reply on HN
Print view View original

131–140 of 217 posts

Re: Engineering management after the cost of code collapsed

#131

Post by lordnacho »

Valectar wrote: post #120
lordnacho wrote: post #94

Earlier quoted context omitted.

> The other thing that the "LLMs write code camp" misunderstands is that writing was never the bottleneck. Understanding was. And understanding the code is still the bottleneck. But understanding is truly gained during the writing loop. The understanding you gain from pure reading or code review is marginal compared to the understanding you gain while writing. This was my stance a couple of years ago, but now I've gi…

> Quite a lot of changing the code is just useless busywork: re-wiring old functions, moving imports around, searching for locations that benefit from extracting a common piece of code. If other people are dissatisfied with LLM output quality while it seems to work fine for you, you might want to consider that the quality of code you produce is closer to the quality of code the LLM produces than what those other peop…

I understand what you mean. Those are just some small examples. But I had this conversation with a friend today, and it goes something like this:

1) It was good for me to spend years learning the little stuff. Loops, variables, if conditions, how to import stuff, git, debugging things, reasoning about the flow of control. Classic coding.

2) I had a false dawn at about 10 years in. I thought I understood a lot.

3) I learned I had a lot to learn. Very wide areas of programming I'd never touched, ways of thinking that started to click.

4) I spent another ten years covering holes, building a different type of experience. My guesses about how to do a project are much better now. My guesses about what really matters have changed.

5) Now the small stuff is actually just bothering me. I'm not going to learn much more from staring at little things. There are larger architectural things to think about, and the little things are just friction.

So that's where I'm coming from. I get that a lot of pushback is going to be from 10-year-me, who thought he'd gotten to a high level of understanding by slogging through the little stuff.

Re: Engineering management after the cost of code collapsed

#132

Post by lukeschlather »

supriyo-biswas wrote: post #105
tracerbulletx wrote: post #96

Earlier quoted context omitted.

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 could do this in the beginning of 2025. Unfortunately, given the over-proactiveness of model these days, I find that they end up inferring what my original request was and implementing it anyway, and then writing unit tests, etc. even when all I asked for was to wire up a few components, as an example.

I actually find the converse, that I try to scope things down into chunks small enough for the model to work on, but it will start trying to hack off pieces that don't belong because it thinks the restricted scope is the whole world and I have to stop it and explain the bigger picture so it stops trying to remove things that serve the full scope.

Re: Engineering management after the cost of code collapsed

#133

Post by bonzini »

ilovefood wrote: post #57
bonzini wrote: post #46

Earlier quoted context omitted.

It's depressingly hard to find one that isn't. You see the title, think this might be interesting, and puke by the second paragraph.

I'm really open to feedback. I checked your past comments and you posted: > AI is good at coding if there's an oracle. If the system is ancient, unreadable, untestable, that's exactly the opposite. It won't get the exact set of corner cases. I sort of mention this in the article, so I'm sure we're somewhat aligned on the core. How would you have worded things?

First of all I want to say it is not your fault, and also your article is clearly partly human, despite what Pangram says.

The thing that I like the least is the headings and the way LLMs always try to put a punchy line. "Correctness time splits in two" says nothing if you don't know what it splits in. Maybe "making it correct vs. describing what's correct"?

Another trope is short sentences: "Good engineers used to say this before LLMs, and now nobody can argue about the sunken cost of having written that code." instead of the longer and redundant "Good engineers said this before LLMs. It was true then. It is enforceable now in a way it was not, because nobody can argue that writing more code was the hard part".

Another clearly AI paragraph is "Plumbing time collapsed. Scaffolding a service, generating tests, translating between frameworks, writing the first draft of a migration: all of this is fast now, and any timeline built on those costs deserves compression." Instead: "The time to bring up a proof of concept or refactor old code has compressed, and you should take that into account when planning your timeline".

There are videos on YouTube about AI style, you just need to learn them and undo them when they're the most blatant.

Re: Engineering management after the cost of code collapsed

#135

Post by [deleted] »

ilovefood wrote: post #57
bonzini wrote: post #46

Earlier quoted context omitted.

It's depressingly hard to find one that isn't. You see the title, think this might be interesting, and puke by the second paragraph.

I'm really open to feedback. I checked your past comments and you posted: > AI is good at coding if there's an oracle. If the system is ancient, unreadable, untestable, that's exactly the opposite. It won't get the exact set of corner cases. I sort of mention this in the article, so I'm sure we're somewhat aligned on the core. How would you have worded things?

[deleted]

Re: Engineering management after the cost of code collapsed

#137

Post by prymitive »

eikenberry wrote: post #113
gste wrote: post #107

Earlier quoted context omitted.

I think this is outdated. If you follow spec-driven development, get the model to do all the planning work upfront, review and iterate the plan, write clear markdown file documentation on the abstractions and patterns you want to follow, then you have every opportunity to tell the model how you want it to write the code. If you use Opus or Fable 5 it will then write the code better and faster than you will.

IMO "get the model to do all the planning work upfront, review and iterate the plan" is backwards. It works better if you do an initial plan yourself and then have the AI review it (and iterate as necessary). Makes you think about the design for a bit so you can have a semblance of a mental model.

I have never seen a plan written by LLM that wasn’t vague and light on details, every time I need to ask for more details and every time I ask to implement it trips over some dead end in the plan, discards the plan and continues as if there was no plan to begin with. Planning feels often just narrating the request and a wish list then what a human would do - methodically build enough understanding so that you’re confident of the direction you choose. LLM plans are overhyped and overrated.

Re: Engineering management after the cost of code collapsed

#138

Post by maccard »

lordnacho wrote: post #124
twister2920 wrote: post #99

Earlier quoted context omitted.

> And each time you do one of those, there's a decent chance you did something even more trivial like forgetting a semicolon or calling the wrong function. how did you decide to pick the most trivial kind regression for this example? do you compile your code before checking it in? > A human junior programmer could perfectly well understand what this meant, but he would have to go through all of the above to get to th…

> how did you decide to pick the most trivial kind regression for this example? Why would this be a regression? You might just be writing a new line of code. > do you compile your code before checking it in? Well obviously. That is generally how you discover that a semicolon is missing. > the main efficiency you have described here is offloading the verification of a change onto the LLM. that is the bottleneck. reade…

> Somehow, the non-deterministic model has built me the deterministic code that I want, very fast, pretty much all the time. A year ago it would get stuck. Now it doesn't, for me at least, and for competent programmers that I know.

I still find the models get stuck or go on _massive_ side quests. Just today, I asked claude to write a hello world C++ program using import std; I interrupted it when It decided I needed a new toolchain installed, and started checking for docker installations. This is super basic stuff, it hadn't even generated a plan, it just started searching for LLVM versions rather than running clang --version.

> If you haven't caught on to the new way of working, well, that's a skill issue...

Honestly, it feels like the emperor has no clothes on this topic, and the crowd defending LLMs to death are way too quick to call it a skill issue.

Re: Engineering management after the cost of code collapsed

#139

Post by twister2920 »

lordnacho wrote: post #124
twister2920 wrote: post #99

Earlier quoted context omitted.

> And each time you do one of those, there's a decent chance you did something even more trivial like forgetting a semicolon or calling the wrong function. how did you decide to pick the most trivial kind regression for this example? do you compile your code before checking it in? > A human junior programmer could perfectly well understand what this meant, but he would have to go through all of the above to get to th…

> how did you decide to pick the most trivial kind regression for this example? Why would this be a regression? You might just be writing a new line of code. > do you compile your code before checking it in? Well obviously. That is generally how you discover that a semicolon is missing. > the main efficiency you have described here is offloading the verification of a change onto the LLM. that is the bottleneck. reade…

> Well yeah, and I've automated my workflows completely. I don't have the problems I used to have. If you haven't caught on to the new way of working, well, that's a skill issue...

I use LLMs, but they're just a tool in the workflow, and I make sure to review the output. they might remember semicolons but they make much more pernicious mistakes that are harder to detect

Re: Engineering management after the cost of code collapsed

#140

Post by potatolicious »

piker wrote: post #130
theptip wrote: post #128

Earlier quoted context omitted.

Agreed, all of the staff/principal engineers I work with are ~99%+ AI generated code, and increasing business value delivered as a result. This is on planet scale infra not CRUD apps. (And yes, you do need to carefully review the output and give steers/corrections. It’s still faster.) At this point if you can’t get the agent to write good code then either I) you are in a very specific niche (like Karpathy trying to w…

How is a GPT implementation “extremely out of distribution” but “planet scale infra” isn’t? That’s got me totally confused about your point that I was taking seriously.

A lot of stuff that underpins planet-scale infra is open source and has been for a long time. The general approaches and architectures for it have also been widely discussed and litigated in the commons so it's not just the code - the specific why is also very well documented.

So despite its importance much of it is actually pretty in-distribution.

Post reply on HN