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.
Engineering management after the cost of code collapsed
171–180 of 217 posts
Re: Engineering management after the cost of code collapsed
#172The 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…
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
#173Earlier 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.
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.
Re: Engineering management after the cost of code collapsed
#174I 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.
Re: Engineering management after the cost of code collapsed
#175I 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 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> 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 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
#177Earlier 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.
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
#178Earlier 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…
Re: Engineering management after the cost of code collapsed
#179Earlier 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.
Re: Engineering management after the cost of code collapsed
#180Earlier 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.
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.