upvote

points

by cornstalks3 days ago |
comments
upvoteby kapperchino3 days ago|
next
[-]
Real, there are so many low hanging fruits for optimization but no one has time to do them. And they don’t incentivize spending your time on it either.
reply
upvoteby pjc503 days ago|
parent|
next
[-]
Exactly. Customer's RAM is free to the developer.
reply
upvoteby thewhitetulip3 days ago|
parent|
prev|
[-]
Especially when LLMs are used to generate most of the code anyways in bigcorps
reply
upvoteby inigyou3 days ago|
parent|
[-]
Is there a single example of a successful LLM project apart from Claude Code?
reply
upvoteby thewebguyd3 days ago|
parent|
next
[-]
If the CEOs are to be believed, then 75% of all new code in Google is AI generated. 46% of GitHub internal code, and roughly 30% across all of Microsoft is AI. Meta expects at least 65%, and snap reported 65% is AI generated.

Its how software is built now in these palces.

reply
upvoteby elcritch3 days ago|
parent|
next
[-]
Unfortunately doesn’t answer the question “successful LLM project”.

From what I’ve seen of GitHub and AWS this year the answer is no. That’s despite me being bullish on LLMs and finding them highly productive.

reply
upvoteby aabdi3 days ago|
parent|
[-]
https://blog.joemag.dev/2025/10/the-new-calculus-of-ai-based...?

in aws, some of the core bedrock services have been replaced with the new serving architecture. that thing was written basically with LLMs.

mind you, guy's a distinguished engineer, his team was basically all principals, but you can do it and some of the new teams are copying the style (though with less success, due to lack of technical skill).

reply
upvoteby inigyou3 days ago|
parent|
[-]
Amazon Bedrock is their LLM serving system, so it's basically in the same class as Claude Code: AI infrastructure.
reply
upvoteby FridgeSeal3 days ago|
parent|
prev|
next
[-]
Given the uhhh, quality and issues GitHub and Microslop have been exhibiting recently, that’s probably not a great indicator.
reply
upvoteby thewhitetulip3 days ago|
parent|
[-]
Github was down so much, I was surprised that they didn't use Copilot to fix their issues
reply
upvoteby inigyou3 days ago|
parent|
prev|
next
[-]
99% of my new writing is generated by scigen, but 0% of my successful writing.
reply
upvoteby 3 days ago|
parent|
prev|
[-]
deleted
reply
upvoteby TiredOfLife3 days ago|
parent|
prev|
[-]
Bun, Ghostty
reply
upvoteby thewhitetulip2 days ago|
parent|
[-]
Migration projects probably won't be the best fit here

An existing project has a well defined code base, test cases etc

If llms aren't able to migrate a good project then they wouldn't be of any use for general purpose programming

reply
upvoteby devmor3 days ago|
prev|
next
[-]
“Stop doing stupid stuff” is usually the biggest performance gain in commercial development.

We do stupid stuff as a stopgap to meet a deadline and then stupid stuff stays until it starts being a problem.

reply
upvoteby thewebguyd3 days ago|
parent|
[-]
There's nothing more permanent than a temporary fix. If deadlines are causing those stopgaps, the aggressive deadlines are the root problem.
reply
upvoteby ChrisMarshallNY3 days ago|
parent|
next
[-]
> There's nothing more permanent than a temporary fix.

That should be one of those Tech culture “laws.”

I suspect that the dependapocalyse is a significant factor. When every part of an operation has multiple context rebuilds, and resources are not shared across module boundaries, you get inefficient behavior.

But I’m skeptical that there’s a will to rethink that.

reply
upvoteby theandrewbailey3 days ago|
parent|
[-]
> That should be one of those Tech culture “laws.”

We already have something:

"Nothing is so permanent as a temporary government program."

Milton Friedman, Tyranny of the Status Quo

reply
upvoteby ChrisMarshallNY3 days ago|
parent|
[-]
Thanks for that.

I feel that there is a bit of a difference, though, because that’s really a cynical (and probably accurate) observation on the behavior of bureaucracy, and I feel the temporary fix thing is of a “finer granularity,” and applies to basic human nature.

reply
upvoteby devmor3 days ago|
parent|
prev|
next
[-]
In my experience, many of those deadlines are commonly the only reason the company continues to exist as well.

The root of the problem is much more deeply ingrained in our economic system.

reply
upvoteby jcgrillo3 days ago|
parent|
prev|
next
[-]
I swapped the engine on my lawn mower ~3yr ago because it no longer had any compression and was very hard to start. The new engine has an electric starter. I didn't have time to fabricate a proper battery tray so I ratchet strapped a 2x4 to the gas tank and strapped the battery to that. It stayed that way until last month when I finally had time to weld up a battery tray.

Sometimes when some janky p.o.s. solution works well enough, it truly is good enough.

reply
upvoteby timacles3 days ago|
parent|
prev|
next
[-]
Honestly, after years of seeing this play out, a lot of devs really lack the judgement to know when something is good enough to deliver and will endlessly delay projects to “ do the right thing”
reply
upvoteby devmor3 days ago|
parent|
[-]
Absolutely. It’s one of the defining characteristics of what makes someone a capable senior in the role IMO.

I have known a lot of extremely talented developers, some with more technical skill than me, that simply failed at their job because they couldn’t come to terms with the fact that their job isn’t to produce the most perfect code possible for the problem.

reply
upvoteby throwaway20373 days ago|
parent|
[-]
In my experience, I have only developed internal enterprise software for my entire career. Most of this stuff is gloried CRUD. Above all: Ship early and ship often. You don't get paid more for having less bugs. (Of course, don't ship crap, but you don't need perfection.) Also, often the specs (in my line of business) are unwritten, so you learn more by releasing quickly, then watching (internal) customers use the product and provide feedback.
reply
upvoteby msalsas3 days ago|
parent|
prev|
next
[-]
Totally agree. In these days of fast devs it's common to see PO's excitement reducing deadlines and assumimg a dev can deliver 5 feats in a day instead of trying to stabilize and fix bugs. Sad
reply
upvoteby jopsen3 days ago|
parent|
prev|
[-]
No deadline, no product.

Shipping is very important, sometimes more important than what you ship :)

reply
upvoteby dabinat3 days ago|
prev|
next
[-]
The key word here is “server”. Optimizing memory server-side directly translates to cost savings for companies. There is a lot less incentive to optimize memory for code that runs on the user’s computer.
reply
upvoteby throwaway20373 days ago|
parent|
next
[-]

    > Optimizing memory server-side directly translates to cost savings for companies.
Only if those cost savings exceed the cost of development. Optimisation work is usually done by the most experienced, and hence most expensive engineers. It is also possible that the optimisation efforts will fail to produce meaningful results. In my career, I have seen more optimisation efforts fail than succeed.
reply
upvoteby Byamarro3 days ago|
parent|
prev|
next
[-]
That's a clever observation and is very true. Development time tho historically was also very expensive hence push for easy to work with dev stacks such as js
reply
upvoteby avarun3 days ago|
parent|
prev|
[-]
There's plenty of incentive if it causes your users to churn.
reply
upvoteby remus3 days ago|
parent|
next
[-]
It is typically hard to directly attribute churn though, whereas some massive EC2 instance costing you $30/day is a clear line item where cost savings can be measured easily.
reply
upvoteby znpy3 days ago|
parent|
prev|
[-]
Nah that simply doesn’t happen. Users routinely blame that on the hardware or on the operating system, occasionally rightfully so.

My anecdotal data point: my MacBook neo with 8 gb of ram running mac os is much snappier than my thinkpad x13g1 (ryzen 7 pro, 8c/16t+ 32gb memory) running linux.

Same user (me), same apps, same websites, same data.

I don’t really blame the apps.

reply
upvoteby hashmap3 days ago|
prev|
[-]
even a lot of the fancy algorithms are ways to not do something you dont need to do, it's rooting out waste all the way down.
reply