Join the discussion
Write your take first — we'll ask for email only when you're ready to publish.
- Hacker News
- I don't think it changes much for good managers. It should always be able setting people and processes up so the team can land durable measurable impact. The managers that thought the job of software engineers was to write code were bad managers. PRs or LoC were never good metrics.by siliconc0w
- Agreed, which is why I also believe "token usage" and similar proxy metrics aren't the right ones for what's next.by ilovefood
- My take, as a non-coder (well, not software engineering, I write 'code' but it's infra, and utilities in go/bash/pythong)...
I work at a company where the biggest problems are not 'writing code', they are:
- Organising teams
- Designing the system
- Prioritisation of work
The fuckups that we make on a daily bases are not 'code errors' they are failures in THOSE three things. I'll go into detail if anyone cares.
by raffraffraff - Same as it ever was.by sanderjd
- don't forget 'actually making decisions'by convolvatron
- Generative language models have helped me most by drawing my attention to the importance of context, communicative compression, prompting, comprehension, coherence, and coordination in the domain of human groups.by treetalker
- > Sorting requires a model of how your org actually behaves: trust relationships, hallway knowledge, the consequences of past decisions. Almost none of this is written down.
This is a long-standing problem related to operational excellence and politics. I expect this will improve with AI adoption and integration. You can't get an exec to create a decision record and commit it to git. Managers have incentive to sequester information.
Engineering already has the discipline (maybe) and abilities to solve the problem. Version control, change control, ADRs, logging, structured docs, etc... We can trace an inbound packet or call through the entire stack. Management can't/won't do anything remotely close. 1-to-1 emails, meeting minutes, stale Word docs is the standard for most.
Inserting LLMs as the interface, and/or plugging into existing interfaces like email, is going to change things. Finally it will be possible to capture more institutional knowledge, without trying to teach an old dog new tricks.
by chickensong - Software development has always evolved. Sometimes slowly, sometimes quicker.
LLMs have brought a different unlock, and for everything we're seeing become easier, it allows people learn to use the tools to take on solving problems that couldn't be approached before.
by j45 - Your short post speaks of exactly what people should be talking about. Due to the panic related to job replacement, not many are talking about the new frontiers. Vibe coding is boring because it does the same faster/cheaper. I'm more interested in the things we couldn't do before but we now can because there's a crazy savant a few keystrokes away.by glimshe
- > 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.
by jboss10 - Yes correct, Gemma. Will correct it shortly.by ilovefood
- “Helping” is doing some heavy lifting in that sentence! It appears to be 100% AI.by trollbridge
- The worse problem is blog posts after the cost of writing collapsed.
Not everything has to be written as though it’s a middle manager’s idea of what makes for a good TED talk.
by antonvs - Yes the article took a while to get going, but once it did it was thoughtful and well reasoned.by JSR_FDED
- I read this entire article and didn’t sniff AI, plus it had some good insights…?by aplummer
- I closed the tab after seeing the AI hero image. Good to know I didn't miss anything.by nvme0n1p1
- In my experience, management is mostly pissing away the gains made by AI by either:
1. Pursuing polish and quality beyond previous norms
2. Replacing $100/mo/seat SAAS with something coded by a junior costing $200/day to develop over months.
The cost of code approaches zero, but the cost of having accountability, and hosting remains the same, and so individuals need to only coordinate to the extent that those things remain finite resources. Management needs to stop insisting that their directs adopt each others vibe coded tooling.
- I think #1 is quite a good thing, on net.by sanderjd
- "Shield the team from the business." The assumption underneath this one is that attention is finite and context switching is expensive. That assumption is intact. What changed is the cost of starving the team of context. Engineers prompting AI tools without business context just produce fluent, plausible, wrong work, at scale."
Too many teams and organizations have business types, mostly PM's who seek to lord over their area of know how and see themselves as delegators and mini CEOs, actively avoid looping engineers in to validate themselves. Engineers need to take on PM roles, and the PM role needs to be 1:50+ eng or go.
by 650 - The cost of code actually increased; code debt is being accumulated faster than we can clean it up.by mgaunard
- Yeah but look how much there is! Aren’t you impressed?
- 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.
by swat535 - 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 human is going to dig through the mess the AI created - so burn even more tokens/money trying to get the AI to fix it, or just start over from scratch again with the AI, hoping for better results. It's the definition of insanity. I'm looking for a new job, maybe even a new industry, a new career path - after 30 years in this industry, software development is jumping the shark.by leptons
- What is the right, best software organization in the current era of AI coding? This question is critical and wholly unanswered in comprehensive research along the same axis as Accelerate (2018, Forsgren, Humble, Kim).
There are a lot of (excruciatingly) long-form posts about what folks are pioneering but not a whole lot of follow up about what failed. Where are the short posts on the negative space? How did halving your staff work out? Flattening your org? All those dark factories, what haven't they produced? How about all the other things tried, failed, and unceremoniously scrapped?
We need to explore and communicate the negative space more efficiently. Don't repeat the same mistakes, and don't make me read 2653 words when 300 do it better.
by baron3dl - Great framing.by sanderjd
- > and don't make me read 2653 words when 300 do it better.
A million times this. Can we please RL the next models to learn the “if I had more time I would’ve written a shorter letter” method please.
I see it every day in tickets, many communication channels, PR descriptions, comments, documentation. All have at least 70% verbose fluff which is so taxing and makes it very hard to keep track of the one important thing they’re trying to communicate in the message
by coffeebeqn - Hard to say what caused what, but the internet seems to mistake verbosity for authority, and so does AI.
- 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 would have instead mostly been thinking and programming.
We've always had the ability to 2X if not 10X the output of each and every one of those poor souls. You don't end with this sort of programming purgatory because it's a productivity optimum, it very clearly isn't, but because it's a billable hours optimum and/or an org chart clout optimum and/or because of Jevons paradox got hands even in business management and the IT department was allocated too many dollars.
- > 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 of minutes for an optimized solution - not a bottleneck but not 100% smooth neither
You still have to test and validate your code. AI made this easier-ish but this is still where I see manual work being needed (even if you are automating tests - you still have to think on what you want the code to do)
by raverbashing - 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 rewritten. LLMs still aren't good at writing maintainable code. Can they write plausibly functional code? Yes. But it won't survive the long term. People using LLMs to write all their code are gambling on them eventually getting to a point where the LLMs can fix their own code. It's possible, but I wouldn't necessarily bet on it.
Where I have found immense value from LLMs is in code review. Repeated review by LLMs catches an amazing amount of potential issues. They really shine on security review, but are very effective with any kind of review.
The other thing that the "LLMs write code camp" misunderstands is that writing was never the bottleneck. Understanding was. And understanding the code is still the bottleneck. But understanding is truly gained during the writing loop. The understanding you gain from pure reading or code review is marginal compared to the understanding you gain while writing.
Most of the time previously spent writing was actually spent updating and deepening our understanding of the system under development. There's no replacement for that understanding in a world where LLMs are doing the writing.
But if you flip it: humans write, LLMs review, then you still get a major gain -- not in speed, but in quality. And you keep the understanding loop intact. I would propose that this might be the best way to deploy LLMs.
by dbingham