Live data from Hacker News

Engineering management after the cost of code collapsed

karimjedda.com

171–180 of 217 posts

Re: Engineering management after the cost of code collapsed

#171

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…

“Not in speed, but in quality” — unfortunately though, not a single CEO, executive, company, VC, investor or anyone with the power to make decisions cares about quality instead of speed.

I’m happy to report that I work for ones that do. Privately owned company with decades-long history, no VC, no profit maximization mindset.

Re: Engineering management after the cost of code collapsed

#172
post #9

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

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…

The current crop of big influential companies is old and super bureaucratic, possibly with the exception of Apple which from the outside seems to have less bureaucracy.

I’ve been wondering whether 2006 Google, Amazon, Facebook would be acting like this if LLMs were launched back then, or if these companies are just due for getting replaced and this is just their big mistake making phase. Prior big companies also entered a big mistake making phase, the mistakes just looked different because different era etc.

Re: Engineering management after the cost of code collapsed

#173
post #130

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.

Go read Karpathy on this, his telling will be more nuanced than mine for the specific example. But the whole point of NanoGPT is that it’s distilling all of his wisdom and taste into a very dense and maximally educational version that fits on a single screen. It’s simply not something that has been done before in the corpus.

Planet scale infra often requires some novel ideas at the architectural layer (the engineers can input those) and then it’s mostly in-distribution C++ / Rust / Go; most of the hyperscalers open-source their stacks, for one. But for two, a ring buffer, look-aside cache, deterministic hash, b-tree, lsm-tree, etc. are all well-known patterns.

Hyperscaling is also often a very clear objective function; i need this code path to run in this many microseconds/nanoseconds, so i can hit the scale numbers I need. Claude/Sol can extract prod logs and build a representative micro-benchmark, and then hill-climb on it autonomously. Thats straight up the fairway for the training set, even if it often has a high bar for finishing and requires sophisticated Workflows or lots of tokens to explore the search space.

E2A: sorry sorry, typo, I meant microGPT. I can see why this would be confusing.

https://karpathy.github.io/2026/02/12/microgpt/

Re: Engineering management after the cost of code collapsed

#174

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.

[dead]

Re: Engineering management after the cost of code collapsed

#175

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…

> They really shine on security review, but are very effective with any kind of review.

They are getting more and more hostile for making any security assesments. I wonder will they even write secure code in the future if they can’t point vulnerabilities from existing code.

Re: Engineering management after the cost of code collapsed

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

“Helping” is doing some heavy lifting in that sentence! It appears to be 100% AI.

I couldn't get through it.

I find it exhausting trying to read anything that smells remotely like linkedin AI slop at this point.

Re: Engineering management after the cost of code collapsed

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

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 a human in the loop, I can't even think of a problem it's solving or attempting to solve. The closest thing I can think of is library or language upgrades... but we already have automated solutions for those e.g. codemods and migration scripts.

Re: Engineering management after the cost of code collapsed

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

No, the tools really are bad, and everyone claiming they are good really is wrong. Or deliberately lying.

Re: Engineering management after the cost of code collapsed

#179

Earlier quoted context omitted.

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

No. We continue to believe the evidence, which says "these tools suck".

Re: Engineering management after the cost of code collapsed

#180

Earlier quoted context omitted.

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.

The art of management - beyond the day to day operations - is largely organization of abstraction and incentives.

As we’ve collapsed the cost of the operations then largely the point of such an llm is constructing above.

If you’re an engineer why wouldn’t you pay more for better abstractions in an llm? That’s half the work anyways.

To put some more context into this: a manager defines the shape of a group of people. They own amorphous blob of responsibilities and various services. This leads to context confusion and lack of ownership and diffuse ability to operate services.

To fix the manager goes: Team a is responsible for say the device platform. Team b is for the applications platform. Each is responsible for their domain and the abstraction of team. Each is then responsible for their own ops, roi, quality, else. This attempts to maximize consistency of context, incentives, and scaling. Whether it works or not is frankly up in the air.

But notice this is basically the same as deciding in your intra service modularization and how you define the interfaces. Can you objectively say that whatever abstraction you usually write is correct? No. You just hope with experience and pragmatism.

Post reply on HN