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

31–40 of 217 posts

Re: Engineering management after the cost of code collapsed

#31

Post by raverbashing »

marginalia_nu wrote: post #29

Code was very rarely the bottleneck in the first place. If programmer productivity was something we actively optimized for, we wouldn't have crammed programmers like sardines in warm and noisy open floor offices with 2000 ppm CO2 levels and then further constantly interrupt them with emails and slack pings and meetings all day long, Jira rigmarole wouldn't make up a significant portion of what they did, programmers w…

> Code was very rarely the bottleneck in the first place.

I disagree. Kinda

What AI has made much simpler is that you don't have to waste time checking docs and have the best autocomplete system by a long shot - this was a bottleneck unless you were doing Java or some other language with "perfect" AC

What AI made "kinda easier": solving for usual problems. The stuff you would search Stack Overflow, or think a couple of minutes for an optimized solution - not a bottleneck but not 100% smooth neither

You still have to test and validate your code. AI made this easier-ish but this is still where I see manual work being needed (even if you are automating tests - you still have to think on what you want the code to do)

Re: Engineering management after the cost of code collapsed

#33

Post by ilovefood »

add-sub-mul-div wrote: post #28
ilovefood wrote: post #27

Earlier quoted context omitted.

Yes correct, Gemma. Will correct it shortly.

You don't build credibility by putting out slop and correcting it every time someone points out that it's wrong. You think it's our job to proofread and fact-check?

A genuine mistake. I make these posts for myself, mainly to structure & share my thoughts. Let me know if you find other errors, I appreciate the feedback.

Re: Engineering management after the cost of code collapsed

#34

Post by siliconc0w »

I don't think it changes much for good managers. It should always be able setting people and processes up so the team can land durable measurable impact. The managers that thought the job of software engineers was to write code were bad managers. PRs or LoC were never good metrics.

Re: Engineering management after the cost of code collapsed

#35

Post by marginalia_nu »

raverbashing wrote: post #31
marginalia_nu wrote: post #29

Code was very rarely the bottleneck in the first place. If programmer productivity was something we actively optimized for, we wouldn't have crammed programmers like sardines in warm and noisy open floor offices with 2000 ppm CO2 levels and then further constantly interrupt them with emails and slack pings and meetings all day long, Jira rigmarole wouldn't make up a significant portion of what they did, programmers w…

> Code was very rarely the bottleneck in the first place. I disagree. Kinda What AI has made much simpler is that you don't have to waste time checking docs and have the best autocomplete system by a long shot - this was a bottleneck unless you were doing Java or some other language with "perfect" AC What AI made "kinda easier": solving for usual problems. The stuff you would search Stack Overflow, or think a couple…

This just says that we can output code faster. I'm saying that the rate at which we output code wasn't the thing that was slowing down development. We've always been able to increase that even without AI by adjusting the working environment and removing obstacles to programming.

In larger organizations, quite often it's the business that is holding back development. They can only handle so much change and speed needs direction to be velocity. Drafting requirements is generally much slower than implementing them.

Like the number one complaint from programmers has been that they don't get to do programming. They want to write code, not update jiras or spend hours in meetings.

Re: Engineering management after the cost of code collapsed

#36

Post by dbingham »

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 rewritten. LLMs still aren't good at writing maintainable code. Can they write plausibly functional code? Yes. But it won't survive the long term. People using LLMs to write all their code are gambling on them eventually getting to a point where the LLMs can fix their own code. It's possible, but I wouldn't necessarily bet on it.

Where I have found immense value from LLMs is in code review. Repeated review by LLMs catches an amazing amount of potential issues. They really shine on security review, but are very effective with any kind of review.

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.

Most of the time previously spent writing was actually spent updating and deepening our understanding of the system under development. There's no replacement for that understanding in a world where LLMs are doing the writing.

But if you flip it: humans write, LLMs review, then you still get a major gain -- not in speed, but in quality. And you keep the understanding loop intact. I would propose that this might be the best way to deploy LLMs.

Re: Engineering management after the cost of code collapsed

#37

Post by cineticdaffodil »

mathgeek wrote: post #4
cineticdaffodil wrote: post #2

Can a llm predict the price of a change to a codebase in tokens and predict the origin of the price, aka cam it see good and bad architecture?

Ask it to do so, would love to know your results.

I did, the problem is that you need a sort of standardized feature change to compare similar repos. So the metric is relative only to same projects lacking that same feature. So no, its a useless thing. No architecture score comparisson between apples and oranges.

Re: Engineering management after the cost of code collapsed

#38

Post by dataplumb3r »

ilovefood wrote: post #27
jboss10 wrote: post #20

> Gemini 4 helped with the editing. Does this guy have access to Gemini 4 already? I'm guessing Gemma 4 was happy to be mistaken for Gemini and didn't catch this mistake.

Yes correct, Gemma. Will correct it shortly.

If you wrote an initial draft you should consider using a better model or just posting what you wrote.

The smaller models can be sufficient for coding but for document writing not highly specific I've yet to be satisfied with AI output. I certainly wouldn't expect gemma to produce good outputs.

Re: Engineering management after the cost of code collapsed

#39

Post by georgeburdell »

In my experience, management is mostly pissing away the gains made by AI by either:

1. Pursuing polish and quality beyond previous norms

2. Replacing $100/mo/seat SAAS with something coded by a junior costing $200/day to develop over months.

The cost of code approaches zero, but the cost of having accountability, and hosting remains the same, and so individuals need to only coordinate to the extent that those things remain finite resources. Management needs to stop insisting that their directs adopt each others vibe coded tooling.

Re: Engineering management after the cost of code collapsed

#40

Post by raffraffraff »

My take, as a non-coder (well, not software engineering, I write 'code' but it's infra, and utilities in go/bash/pythong)...

I work at a company where the biggest problems are not 'writing code', they are:

- Organising teams

- Designing the system

- Prioritisation of work

The fuckups that we make on a daily bases are not 'code errors' they are failures in THOSE three things. I'll go into detail if anyone cares.

Post reply on HN