Live data from Hacker News

Engineering management after the cost of code collapsed

karimjedda.com

141–150 of 217 posts

Re: Engineering management after the cost of code collapsed

#142

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…

This is where I've landed too, I imagine based off all the responses that it depends on domain and also the rigor you care about in your implementation. For me, what I do, and the quality required, there's just not much time (if any) saved on handing off the implementation to an LLM.

But that doesn't mean they're useless either. I use them all the time for review as you mentioned or to knock out one-off scripts that don't go anywhere near source control. There's just no world where I don't need to understand every line of code that I'm responsible for getting into our project.

Re: Engineering management after the cost of code collapsed

#143
post #107

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

This just doesn't match my experience writing idiomatic C code for embedded real-time systems with ChatGPT-5.5 and -5.6. Are Opus and Fable really that different? I general I find that a fully correct implementation for some function may take an hour and be nearly one-shot, but going from there to code I'd be willing to actually commit is at least 4x the time commitment with regular back-and-forth -- so four hours of deep engagement for every one hour of one-shot. ChatGPT-5.6 Sol seems to be better that -5.5 at the one hour do-it portion, but worse at the four hour do-it-well portion.

Re: Engineering management after the cost of code collapsed

#144

I’m struggling to imagine a project that would require more than one talented engineer and a bucket of tokens anymore. I think perhaps the assumption that engineering managers should have any employees may be outdated. I can imagine average and mediocre engineers equipped with tokens could create chaos and debt on a scale never before imaginable, so it’s easy to see how orgs who still have these employees around are…

> I think perhaps the assumption that engineering managers should have any employees may be outdated.

to me, the latest models and harnesses turn all devs into an engineering manager with one direct report. Some devs naturally take up the role and great things happen, for others it's like trying to get a fish to ride a bicycle. This is how it was pre-genai too so i don't think there's a right or wrong answer, some will take off with the technology and some will struggle.

Re: Engineering management after the cost of code collapsed

#145

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.

This very much. First thing built is what get approved. Even if it will generate 10x the workload down the line, because today's quality bar is very much demo level.

And then you get paged at 2am because prod is down and the support channel is more active than the team's one.

Re: Engineering management after the cost of code collapsed

#146
i agree with that but now at the pace where everything is moving really really fast, humans are using ai tools n all for imensively writing code and building new feature where they are also facing issues and frustration while debugging...llms are really good but sometimes they catch the issues but majority of time, they just grep or bash the things and eventually ending up not losing context....but if we go with your proposed way, then if humans build n llms review then it will be the slow process.....Hope I put my point correctly

Re: Engineering management after the cost of code collapsed

#147

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…

> writing was never the bottleneck. Understanding was.

Well put. This insight is worth repeating in every discussion on the subject, from software engineering to mathematics.

The problem is that understanding is not the product being sold. The business model is for everyone to become consumers of what the magical genie generates, where the "understanding" is kept on the side of the model providers. This ensures a future generation of consumers dependent on someone else to provide the understanding.

Otherwise, you can create your own answers based on actually understanding the code, theorem, proofs, etc. Smart consumers of LLMs will use them to increase their own knowledge and understanding, so that the service is augmenting their intelligence, not replacing it.

Re: Engineering management after the cost of code collapsed

#148

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.

Re: Engineering management after the cost of code collapsed

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

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…

btw, your last paragraph makes you sound like an ass.

Re: Engineering management after the cost of code collapsed

#150

Earlier quoted context omitted.

You can automate work but never owning the consequences. AI tasks emerge from human contexts, they perform work in the context and finally the outcomes collect in the context - gains, losses, risks, costs. So AI is great but it needs our skin for the start, middle and end of a task.

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.
Post reply on HN