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

161–170 of 217 posts

Re: Engineering management after the cost of code collapsed

#161

Post by preg_match »

tripleee wrote: post #153
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.

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

I agree, but this works too because AI makes prototyping more rapid. It's common to be stuck with suboptimal solutions because of time constraints. Maybe the feature isn't really what the customer wants, or maybe the code isn't actually very good. But it reaches prod anyway.

But, with AI, the cost of code has gone down more than it already has. Well, cheap things are easy to throw away. So you prototype, prototype, prototype, and close the loop as much as possible with the customer. True agile development, not big A Agile.

The problem is this requires alignment from management, and we're just not seeing it at many company. They can't grasp that things have changed, and that throwing away code is free. They don't trust engineers to close that gap, so customers and stakeholders are still waaaaaay over there and we're delivering features they don't want.

Re: Engineering management after the cost of code collapsed

#162

Post by bluefirebrand »

RyanHamilton wrote: post #76
SoftTalker wrote: post #68

Earlier 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 tried and tried to get an LLM to delete code, it couldn't do it. I knew a file was 40% bad so what I ended up doing was deleting the file, then asking AI to create the missing file. That's how I got AI to delete code :)

Sounds like the AI got you to delete the code for it.

Re: Engineering management after the cost of code collapsed

#163

Post by gste »

written-beyond wrote: post #111
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.

Depends on how long that planning/review cycle takes.

True, but I think people are also missing the trick behind markdowns that reference each other and are used for context window management. They go in your source control, they are reusable, extendable, and composable in the same way code is. So planning is not a one-off effort. It compounds over time. If you're doing it right your plan is referencing automation techniques - testing, CI/CD, etc. This further compounds so that the agents verify their own work against the standards that you set.

To be honest, the models are getting so good that they do most of this unprompted now.

Re: Engineering management after the cost of code collapsed

#164

Post by dalemhurley »

tripleee wrote: post #153
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.

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

I think you can have some system design in mind upfront, but agree the bulk emerges as you code. Clean Code practices worked exactly this way in which you write and then rewrite the clean code.

Re: Engineering management after the cost of code collapsed

#165

Post by lordnacho »

twister2920 wrote: post #139
lordnacho wrote: post #124

Earlier quoted context omitted.

> 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

But are those pernicious issues more common than what you would write yourself? Keeping in mind that you will get your LLM code back a lot sooner and have more time left over to check for them?

Re: Engineering management after the cost of code collapsed

#166

Post by lordnacho »

maccard wrote: post #138
lordnacho wrote: post #124

Earlier quoted context omitted.

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

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

I feel it's the other way around. The LLM skeptics are unwilling to admit that these things can get you there faster than you would on your own, in the face of clear evidence.

Re: Engineering management after the cost of code collapsed

#167

Post by OutOfHere »

pillefitz wrote: post #150
OutOfHere wrote: post #117

Earlier quoted context omitted.

It's not as if management owns any consequences. At best they adapt, but so can AI. Management tasks are not like engineering tasks.

As stated in the sibling comment, management is very similar to engineering.

Of course management would like to make that claim, but I don't see it substantiated. In what way is management "owning the consequences" -- are they losing their equity or risking an unpaid suspension?

Re: Engineering management after the cost of code collapsed

#168

Post by OutOfHere »

pillefitz wrote: post #148
OutOfHere wrote: post #91

Engineers do not need management. Investors do. As I understand it, the purpose of management is to match financial resources with material+human resources to perform feasible tasks. There is nothing here I see that can't be done by an experienced token generator. If anything, automating management seems easier than automating engineering. As for leadership, it can be done by the investors.

This is such a simplistic view I have difficulties deciding where to even start. Think of a manager as someone who engineers the fabric of the organization. Most of my time is spent debugging, communicating, finding the right abstractions, configuring processes - all very similar to the engineering work I previously did.

How would an investor see it? If an investor had access to a top-ranked management model, would s/he willingly spend 100x more on a person instead?

Or if you're saying you still do engineering/product work, then perhaps it shouldn't come with a management title. Whispering task allocation ideas to the AI is for everyone to do.

Re: Engineering management after the cost of code collapsed

#169

Post by layer8 »

ManuelKiessling wrote: post #158
dbingham wrote: post #36

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…

To be honest, it feels like you are contradicting yourself. If LLMs are, as you stated, really good at catching potential issues, then they are, almost by definition, really good at producing code without potential issues, if guided correctly: all they need to do is inspect and iterate, until they do not find any more potential issue in the code they produced.

That isn’t necessarily true. LLMs could be good at finding issues that human miss when coding, while being bad at catching issues that they themselves miss while generating code.

Re: Engineering management after the cost of code collapsed

#170

Post by swat535 »

mgaunard wrote: post #9

The cost of code actually increased; code debt is being accumulated faster than we can clean it up.

Business never cared about code debt, LLM helps building features faster into production and from their POV, that's all that matters.

If your engineers are "wasting time" optimizing artisan code whilst the competition has released their next version, they'll be told to use AI.

The other reality is that by the time you figure out the right abstraction, business has already pivoted, or your feature will be rewritten , or dumped all together. Obviously there are niche industries where this is not the case but in majority of companies, the churn is exhausting.

My point is this: we can shout all we want about "maintenance" and "technical debt", but it's guaranteed to fall on deaf ears.

LLM has validate upper management's assumption that engineering is nothing but a cost center.

I think that our industry is fundamentally shifting.

Post reply on HN