Engineering management after the cost of code collapsed • Hacker News Board

Re: Engineering management after the cost of code collapsed

#151

Post by chasd00 » Sat, Jul 25, 2026, 9:18 PM UTC

jdw64 wrote: post #106

Coding used to be an expensive task. Seeing how quickly repositories have grown with the rise of AI coding, it's clear how much people wanted to build things but were thirsting for the means to do so. Even languages like R, which were mostly used by graduate students and experts, have seen a massive increase in usage since vibe coding became popular. Honestly, when people say AI code quality is bad, Linus himself has…

> I think what I actually enjoyed wasn't programming itself, but the act of creating something.

i think this is the real difference between the pro-ai and anti-ai crowds.

Re: Engineering management after the cost of code collapsed

#152

Post by generic92034 » Sat, Jul 25, 2026, 9:18 PM UTC

jtorsella wrote: post #114

CharlesW wrote: post #71

Earlier quoted context omitted.

Pangram's marketing always reminds me of Anchorman's Sex Panther cologne: "They've done studies, you know. Sixty percent of the time, it works every time." Pangram's "100% AI generated" claims are right 65% of the time. https://link.springer.com/article/10.1007/s40979-026-00226-w

Did you read the paper you are linking to? It records a 0% false positive rate for evaluation of human-authored controls, and fewer than 5% of the hybrid and humanized papers had their AI levels overestimated by pangram. It is not completely clear from the data, but it seems that depending on whether the n=2 overestimates were “100% ai generated” assessments, the study you link says pangram’s 100% AI assessments were…

Still, I guess if you would care you could let the LLM perform loops with pangram tests, changing the text till it scores well enough.

Re: Engineering management after the cost of code collapsed

#153

Post by tripleee » Sat, Jul 25, 2026, 9:27 PM UTC

gste wrote: post #107

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…

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

Re: Engineering management after the cost of code collapsed

#154

Post by thih9 » Sat, Jul 25, 2026, 9:27 PM UTC

leptons wrote: post #104

mgaunard wrote: 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…

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.

Re: Engineering management after the cost of code collapsed

#155

Post by piker » Sat, Jul 25, 2026, 9:31 PM UTC

potatolicious wrote: post #140

piker wrote: post #130

Earlier quoted context omitted.

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.

A lot of stuff that underpins planet-scale infra is open source and has been for a long time. The general approaches and architectures for it have also been widely discussed and litigated in the commons so it's not just the code - the specific why is also very well documented. So despite its importance much of it is actually pretty in-distribution.

Okay, but then that does not square with calling a GPT implementation out-of-distribution, let alone "extremely" so.

Re: Engineering management after the cost of code collapsed

#156

Post by tripleee » Sat, Jul 25, 2026, 9:32 PM UTC

theptip wrote: post #128

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.

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…

it's really cool how in the past measuring developer productivity was incredibly difficult, but now its become easy if someone's making a point about LLMs

Re: Engineering management after the cost of code collapsed

#157

Post by sdevonoes » Sat, Jul 25, 2026, 9:41 PM UTC

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…

But searching on google or SO wasn’t the bottleneck either. It was searching on your own codebase (and dependant ones) for the exact place (a class, a file, a function) where to put/delete/update business logic without breaking production.

LLMs help, but they haven’t been trained on our own repos. I don’t need the LLM to help me with algos that are available online… I need them to help me with custom business logic

Re: Engineering management after the cost of code collapsed

#158

Post by ManuelKiessling » Sat, Jul 25, 2026, 9:42 PM UTC

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.

Re: Engineering management after the cost of code collapsed

#159

Post by sdevonoes » Sat, Jul 25, 2026, 9:48 PM UTC

stefangordon wrote: post #66

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…

Would that single person handle different topics such as: UI/UX, security, backups, distributed systems, data migrations, infrastructure, …?

Sure thing there are engineers out there that know some about all of the above (I personally do all of that on personal projects) but you still need specialists, otherwise it’s you alone with all the unknown unknowns that the llm may claim to solve, but you cannot verify

Re: Engineering management after the cost of code collapsed

#160

Post by bluefirebrand » Sat, Jul 25, 2026, 9:51 PM UTC

gste wrote: post #107

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…

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.

I haven't done "spec driven development" in my entire career, 15+ years

Until managers give up on Agile, we'll never get time to actually write specs