371–380 of 412 posts
Earlier quoted context omitted.
3gb of ram aren't enough everyday tasks at any sane resolution. That we still don't have 1200 ppi desktop monitors is as stupid as using black and white screens in 2000.
1200ppi! The Apple Studio Display is 218ppi and it's amazingly sharp. What do you need 1200ppi for?
Earlier quoted context omitted.
It's the exact opposite. Humans will hedonically adapt to anything. If they see enough AI posters pretty soon they will start to not care, at least the majority, while some minority will disagree. We've seen this pattern many times, from data privacy and people still using social media, to using non free software.
>If they see enough AI posters pretty soon they will start to not care.. Wrong analogy. A marketing item wants you to look at it. It takes advantage of an involuntary impulse. A repetitive boring AI artwork will not trigger the impulse to look it. So it is not about "caring"....
Right now GenAI content a bad thing, cringe, a sign of low-value or lack of attention to detail. I don't want to play even a free game if I think it was made by someone else prompting an AI, and that's despite liking the output when I do the same for myself.
If AI output is normalised and becomes simply "boring" or "mundane", those negatives must have also gone away.
After that (assuming there is an "after that", I don't want to bet either way), people would, as per your argument, need to un-boring them.
Earlier quoted context omitted.
"unless you're content with producing low quality work." - With the right guiding hand, it is a productivity multiplier without compromising quality. As a fully autonomous developer, it is a disaster.
> With the right guiding hand, it is a productivity multiplier without compromising quality This just reads like another variation of “it’s the user not the tool,” which is just endless runway for always blaming people and never acknowledging the limitations of LLM’s. I’d be curious to hear how the recipients of your work enabled by the “productivity multiplier” feel about the quality.
We actually have trendlines on user reported bugs, and I am happy to report they show a significant downtrend.
Earlier quoted context omitted.
You can't play an entire orchestra's sheet music on a single guitar either, but your playing ability still matters a lot. I would say that as of July 2026, with the right scaffolding, you can get reasonably good output out of a LLM, or better a combination of LLMs. For example, it pays off to prepare an implementation plan with one LLM and then let another LLM check it for flaws, then again. After several iterations…
> I would say that as of July 2026, with the right scaffolding, you can get reasonably good output out of a LLM, or better a combination of LLMs. Totally agree, I don’t think I said or implied otherwise. And yes can it can be the user and often even is, but when it comes to any LLM conversation I’ve been a part of it seems people think the only answer is “you’re using it wrong.” Evangelists swear it’s a 100x multipli…
Earlier quoted context omitted.
"unless you're content with producing low quality work." - With the right guiding hand, it is a productivity multiplier without compromising quality. As a fully autonomous developer, it is a disaster.
How are junior devs becoming qualified “guiding hands” these days? If the expert with LLM assistance is multiplied, what’s a company’s incentive to pay for a junior, and how would they train to get good in these conditions?
Earlier quoted context omitted.
How are junior devs becoming qualified “guiding hands” these days? If the expert with LLM assistance is multiplied, what’s a company’s incentive to pay for a junior, and how would they train to get good in these conditions?
Juniors are still useful, but not as pure "coders". The juniors you want to hire now can wear product, engineering and QA hats, and are self starters with good attention to detail and AI skills. These types of people are actually a bargain.
https://news.ycombinator.com/item?id=48743713
---
We've just done an official evaluation at work, using extensive statistics on our gigantic monorepo in a company with ~2000 devs over the course of 2 years, everyone from hardware engineers to regular old frontend engineers. It's a highly profitable and mature public company, and has been for going on a decade at this point without missing a beat. We were given infinite access & budgets to basically any and all AI tooling we could imagine, and we have several "AI Native" teams (whatever the fuck that even means). We're doing agentic coding, we have harnesses of all kind, skills, we have many teams doing spec-driven development, designers using all the various things like Figma Make and access to tools like Devin/Factory Droid/Claude Code/Codex/etc.
This is all to say, we as a company are using AI a lot in all possible corners, but thankfully our leadership isn't schizophrenic and isn't mandating everyone hit token limits or whatever, it's more of a "Let's see what works and what doesn't" type of thing, and we measure a lot of statistics. Nobody here really cares whether LLMs are the next coming of Christ or not, as a company there are many people (even in SLT) that are indifferent to LLMs, and many who are reasonably hyped.
I wish I could link to the actual document we were all shown since it has a beautiful breakdown of the methodology and a fine-grained breakdown of the stats and the categories measured, but in the grand scheme of things, ALL the AI tooling we have implemented (at least on the engineering side of the equation) has contributed to a total of... drum roll please... 7 (seven) Percent overall productivity increase! The most productive teams saw a productivity increase of around 20%, while some teams actually saw drops in productivity into the negative percentage points. My team, none of us really give a shit about AI and we're somewhere in the 3-5% range on certain categories of tasks, which I'd say is a fairly good assessment.
Productivity here is measured in many ways, including but not limited to speed of MR review and merge times, feature/ticket/roadmap closure/delivery, rollback/revert incidence rate, how often people interact with the MR review bots and implement their suggestions/fixes, how many times people check back on AI transcriptions/meeting notes (hint: Nobody looks back on any of it, it's all just noise that gets generated and never actually referenced outside a few extremely rare cases) and many more things I'm forgetting. It is an imperfect number of course, because measuring productivity in engineering is a sisyphean task, but in my opinion it is accurate to the reality on the ground and outside of all the hype and marketing bullshit.
So, I remain thoroughly unconvinced of these personal anecdotes of people being "massively" more productive, especially once you factor in the fact that we now have a 2000EUR budget/month/dev for all the AI tooling, those productivity numbers start looking pathetic once you factor in the costs (which are only increasing as the AI companies need to start recouping the gazillions they've burned). Some teams have started begging to disable coderabbit and other similar tools in their MRs because they're producing nothing but walls of noise that makes reviewing any MR a nightmare of sludging through endless slop of useless bullshit, ours included.
Earlier quoted context omitted.
It's the exact opposite. Humans will hedonically adapt to anything. If they see enough AI posters pretty soon they will start to not care, at least the majority, while some minority will disagree. We've seen this pattern many times, from data privacy and people still using social media, to using non free software.
>If they see enough AI posters pretty soon they will start to not care.. Wrong analogy. A marketing item wants you to look at it. It takes advantage of an involuntary impulse. A repetitive boring AI artwork will not trigger the impulse to look it. So it is not about "caring"....
Earlier quoted context omitted.
1200ppi! The Apple Studio Display is 218ppi and it's amazingly sharp. What do you need 1200ppi for?
To match the print quality from the 19th century.
Earlier quoted context omitted.
Yes, I’m a senior engineer at a 3-engineer startup, and there isn’t “junior-level” or “senior-level” work here. It’s all just work. Claude allows me to tear through the kind of gruntwork I’ve been doing ad nauseam for the last 15 years. If my tasks were things like squeezing 3% more efficiency out of an algorithm, that might be different. Although, even then, my PM (!) used Claude to boost the efficiency of one of ou…
> Although, even then, my PM (!) used Claude to boost the efficiency of one of our more complex Postgres queries by up to 5x Would you be kind to describe what test set-up do you have that a PM felt safe enough to deploy the changed query without the fear they'll break something?