MontyCarloHall

CEOs have been saying the exact same thing for the entire history of automation. Take computing, for example, an industry that's always been unusually amenable to automation:

— in the 1960/1970s, when compilers came out. "We don't need so many programmers hand-writing assembly anymore." Remember, COBOL (COmmon Business-Oriented Language) and FORTRAN (FORmula TRANslator) were marketed as human-readable languages that would let business professionals/scientists no longer be reliant on dedicated specialist programmers.

— in the 1980s/1990s, when higher-level languages came out. "C++ and Java mean we don't need an army of low-level C developers spending most of their effort manually managing memory, and rich standard libraries mean they don't have to continuously reimplement common data structures from scratch."

— in the 1990s/2000s, when frameworks came out. "These things are basically plug-and-play, now one full-stack developer can replace a dedicated sysadmin, backend engineer, database engineer, and frontend engineer."

While all of these statements are superficially true, the result was that the world produced more software (and developer jobs) than ever, as each level of abstraction freed developers from having to worry about lower-level problems and instead focus on higher-level solutions. Mel's intellect was freed from having to optimize the position of the memory drum [0] to allow him to focus on optimizing the higher-level logic/algorithms of the problem he's solving. As a result, software has become both more complex but also much more capable, and thus much more common.

While this time with AI may truly be different, I'm not holding my breath.

[0] http://catb.org/jargon/html/story-of-mel.html

People currently assume AI will be an accelerant of inequality because all currently useful models (i.e. those potentially capable of mass labor disruption) are only able to run in multibillion dollar datacenters, with all returns accruing disproportionately to the oligarchs who own said datacenters.

I'm not sure this moat is inevitably perpetual. It's likely computing technology evolves to the point of being able to run frontier-level models on our phones and laptops. It's also likely that with diminishing marginal returns, future datacenter-level models will not be dramatically more capable than future local models. In that case, the power of AI would be (almost) fully democratized, obviating any oligarchic concentration of power. Everyone would have equal access to the ultimate means of production.

Before the industrial revolution, approximately 90% of people worked in agriculture. In fully industrialized countries, that figure is now <2%. That decrease constituted a nearly full replacement of everything humans were doing, better and more cheaply. While this time might be different, I don't think this is a given.

I think you underestimate just how much we value human achievement.

Why do we watch Olympic runners, when cars on your average city street easily exceed Usain Bolt's top speed on their morning drive to Starbucks? Why do we watch the Tour de France, when we can watch Uber Eats drivers on their 150cc scooters easily outpace top cyclists? I'm sure within a couple years a Boston Dynamics robot will be able to out-gymnast Simone Biles or out-skate Surya Bonaly. Would anyone watch these robots in competition? I doubt it. We watch Bolt, Biles, and Bonaly compete because their performance represents a profound confluence of human effort and talent. It is a celebration of human achievement, even though that achievement objectively pales in comparison to what our machines can accomplish.

I think the same is true for other aspects of human creativity and labor. As we are able to automate more and more, we will place increasing importance on what inherently cannot be automated: celebration of our fellow humanity. Another poster wrote that "bullshit jobs" [0] exist primarily because we value human contact [1]. I am inclined to agree.

[0] https://en.wikipedia.org/wiki/Bullshit_Jobs

[1] https://news.ycombinator.com/item?id=47738865

>Labour displacement leads to an erosion of standards of living

The two biggest labor displacements in human history were the agricultural and industrial revolutions, both of which resulted in enormous gains in human living standards. Can you think of a mass labor displacement that resulted in an overall erosion of living standards? I cannot.

They are pretty good friends of mine and I never sensed any tension. It really was a marriage-ending bolt out of the blue, like discovering an affair or severe financial infidelity.

Indeed, but the rage I've seen during political fights at family gatherings (and another politics-induced divorce) pales in comparison to the rage I saw in these two anecdotes. The worst political debates I've seen involved raised voices and some name calling, not spitting food and smashing plates. The only other political divorce I've seen slowly simmered over a few years after Trump was first elected, not in a literal matter of weeks.

I don't think most people in tech are quite aware of the level of visceral AI hatred amongst non-techies. I've personally witnessed the worst Thanksgiving dinnertable fight I've ever seen (after someone revealed that their recipe was AI-generated, a couple people literally spat out the food they were enjoying and threw their plates in the trash), and a divorce (a very solid marriage between two people who were once both staunchly anti-AI unraveled within weeks after one of them changed their tune and adopted AI at work).

S3 GET requests have negligible cost, at $0.0004/1000 requests. Upload requests are $0.005/1000, which is also negligible.

>This option enables local file caching, but does not change NFS cache coherency, and does not reduce latencies.

That's true for any NFS setup, not just EFS. The benefit of local NFS caching is to speed up reads of large, immutable files, where latency is relatively negligible. I'm not sure why AWS specifically dissuades users from enabling caching, since it's not like bandwidth to an EFS volume is even in the ballpark of EBS/NVMe bandwidth.

I agree, it's an oddly low threshold. The latency differential of NFS vs. S3 is a couple OOMs, so a threshold of ~10MB seems more appropriate to me. Perhaps it's set intentionally low to avoid racking up immense EFS bills? Setting it higher would effectively mean getting billed $0.03/GB for a huge fraction of reads, which is untenable for most people's applications.

Since EFS is just an NFS mount, I wonder if you could do this yourself by attaching an NVMe volume to your instance and setting up something like cachefilesd on the NFS mount, pointed to the NVMe.

Would

   mkfs.ext4 /dev/nvme0n1 && \
   mount /dev/nvme0n1 /var/cache/fscache && \
   mount -t s3files -o fsc fs-0aa860d05df9afdfe:/ /home/ec2-user/s3files

work out of the box? It does for EFS. It hardly seems worth it to offer a managed service that's effectively three shell commands, but this is AWS we're talking about.

The threshold at which the cache gets used is configurable, with 128kB the default. The assumption is that any read larger than the threshold will be a long sustained read, for which latency doesn't matter too much. My question is, do reads <128kB (or whatever the threshold is) from files >128kB get saved to the cache, or is it only used for files whose overall size is under the threshold? Frequent random access to large files is a textbook use case for a caching layer like this, but its cost will be substantial in this system.

This is essentially S3FS using EFS (AWS's managed NFS service) as a cache layer for active data and small random accesses. Unfortunately, this also means that it comes with some of EFS's eye-watering pricing:

— All writes cost $0.06/GB, since everything is first written to the EFS cache. For write-heavy applications, this could be a dealbreaker.

— Reads hitting the cache get billed at $0.03/GB. Large reads (>128kB) get directly streamed from the underlying S3 bucket, which is free.

— Cache is charged at $0.30/GB/month. Even though everything is written to the cache (for consistency purposes), it seems like it's only used for persistent storage of small files (<128kB), so this shouldn't cost too much.

Would reduced heating due to warmer winters offset this? Global carbon emissions due to heating are approximately 4 times the amount of carbon emissions due to cooling [0].

(Of course, the ideal scenario is not that rising carbon emissions from increased cooling get offset by lower emissions from decreased heating, but rather that we transition to abundant carbon-free energy from solar, wind, nuclear, etc. and are able to keep our houses as cool as we want in the summer and as warm as we want in the winter without any environmental consequences.)

[0] https://ourworldindata.org/grapher/co2-heating-cooling

I ran into a similar issue years ago, where the base infrastructure occupied the lion's share of the container size, very similar to the sizes shown in the article:

   Ubuntu base      ~29 MB compressed
   PyTorch + CUDA   7 – 13 GB
   NVIDIA NGC       4.5+ GB compressed

The easy solution that worked for us was to bake all of these into a single base container, and force all production containers built within the company to use that base. We then preloaded this base container onto our cloud VM disk images, so that pulling the model container only needed to download comparatively tiny layers for model code/weights/etc. As a benefit, this forced all production containers to be up-to-date, since we regularly updated the base container which caused automatic rebuilding of all derived containers.

I'm willing to bet you don't full-on YOLO vibecode like the lead Claude Code developer, running 10 Claude Code sessions in parallel to push 259 pull requests that modify >40k lines of code in a month [0]? There is zero chance any of that code was rigorously reviewed.

I use Claude Code almost every day [1], and when used properly (i.e. with manual oversight), it's an amazing productivity booster. The issue is when it's used to produce far more code than can be rigorously reviewed.

[0] https://www.reddit.com/r/ClaudeAI/comments/1px44q0/claude_co...

[1] https://news.ycombinator.com/item?id=45511128

>Waymo benefits from Google's unparalleled geospatial data.

How much of Waymo's training data is based on LIDAR mapping versus satellite/aerial/street view imagery? Before Waymo deploys in a new city, it deploys a huge fleet of cars that spend months of driving completely supervised, presumably to construct a detailed LIDAR map of the city. The fact that this needs to happen suggests Google's geospatial data moat is not as wide as it seems.

If LIDAR becomes cheap, you could imagine other car manufacturers would add it cars, initially and ostensibly to help with L2 driver aids, but with the ulterior motive of making a continuously updated map of the roads. If LIDAR were cheap enough that it could be added to every new Toyota or Ford as an afterthought, it would generate a hell of a lot more continuous mapping data than Waymo will ever have.

I am curious how much Claude Code is used to develop Anthropic's backend infrastructure, since that's a true feat of engineering where the real magic happens.

Isn't the main problem with pensions today the dramatic increase in life expectancy post-retirement? They were never intended to support decades of retirement: in the old days, you retired at 65 and there was a good chance you'd be dead by 70, at most 75. (When Social Security was established in the 1930s, life expectancy was only 61.) Nowadays, there's a good chance you'll live beyond 90, with expenses increasing disproportionately towards end-of-life. Combine that with a shrinking birthrate, and no feasible increase in ROI/worker contributions can sustain pension-funded retirements of 25+ years.

>I'd expect to see movements to force government regulation of AI.

I agree. It will be an interesting debate to watch play out, because a) lots of end-users love using AI and will be loath to give it up, and b) advances in compute will almost certainly allow us to run current frontier models (or better) locally on our laptops and phones, which means that profits no longer accrue to a few massive AI labs. It would also would make regulating it a lot tricker, since kneecapping the AI labs would no longer effectively regulate the technology.

>Are those people cutting the grass/operating the elevators happier/unhappier than they would be otherwise?

There are numerous studies that show menial labor leads to poor mental health. Perhaps these people employed as makework automatons are happier than they would be if they had no employment whatsoever and were destitute on the street, but these are not the only two alternatives.

>I'll ignore the glazier example as it seems quite extreme, and also comes with more obvious/specific "victims"

The "victims" at the Taj Mahal/department store are the visitors/customers who have to pay slightly higher prices as a result. While not as extreme as the glazier in the broken window fallacy, the grass cutters/elevator operators exist on the exact same spectrum.

>Life and business is not about profit. It’s about bettering the lives of people.

This mentality results in the grass at the Taj Mahal being cut with hand tools [0], or Japan having a whole category of "useless jobs" like elevator operators [1, 2] that simply exist to provide employment. Taken to an extreme, this is the broken windows makework fallacy. If I smash a lot of windows, the local glazier gets paid handsomely, at the expense of everyone who had to pay for window replacements.

[0] https://www.youtube.com/shorts/wAH8jj9cm_o

[1] https://www.taipeitimes.com/News/editorials/archives/2015/06...

[2] http://www.ageekinjapan.com/elevator-operator/

>>Brynjolfsson found a 13% relative decline in employment for early-career workers (ages 22-25) in AI-exposed occupations since late 2022. For young software developers specifically, employment fell almost 20% from its 2022 peak

>This is confounding AI-exposed white collar occupations with occupations that were overrepresented with extended remote work.

Yup. If you look at Brynjolfsson's actual publication [0], you'll see that precipitous decline in hiring juniors in "AI-exposed occupations" starts in late 2022. This is when ChatGPT first came out, and far too early to see any effects of AI on the job market.

You know what else happened in late 2022? The end of ZIRP and Section 174, which immediately put a stop to the frantic post-COVID overhiring of bootcamp juniors just to pad headcount and signal growth. The problem with Brynjolfsson's paper is that it doesn't effectively deconvolve "AI-exposed occupations" from "ZIRP/Section 174-exposed occupations," which overlap significantly.

[0] https://digitaleconomy.stanford.edu/app/uploads/2025/11/Cana...

100% agreed. When/if that pivot happens will be the sign that gen-AI is truly disrupting the software market in a profound way. "You're using the model wrong/you're not using the latest model" is an oft-repeated argument against AI skeptics. Nobody knows how to use the latest models better than their developers.

Addendum to counterpoint: why haven't those SotA gen-AI companies become the most productive software companies on earth, and release better and cheaper competitors to all currently popular software?

People always gripe about the poor quality of software staples like Microsoft Office or GitHub or Slack. Why hasn't OpenAI or Anthropic released a superior office suite or code hosting platform or enterprise chat? It would be both a huge cash cow and the best possible advertising that AI-facilitated software development is truly the real deal 10x force multiplier they claim.

If someone invents a special shovel that can magically identify ore deposits 100% of the time, they aren't going to sell it with the rest of the shovelmongers. They're going to keep it to themselves and actually mine gold.

>I know it seems hard, but just stop using Google, Amazon, Meta products.

I noticed your own app's website [0] hosts videos on YouTube [1] and uses Stripe as a payment processor [2], which is hosted on AWS. You also mentioned that your app is vibe coded [3]; the AI labs that facilitated your vibecoding likely built and run their models using Meta's PyTorch or Google's TensorFlow.

"Just stop using" makes for a catchy manifesto in HackerNews comments, but the reality is a lot more complicated than that.

[0] https://wordsunite.us/

[1] https://www.youtube.com/watch?v=AbCM99cz9W8

[2] https://wordsunite.us/terms

[3] https://news.ycombinator.com/item?id=45644698

That's a top-down organizational change mandating certain capabilities for all Amazon software. Unlike these AI mandates, it's not dictating the exact tools developers use to write that software, but rather what the software itself should do. For reference, here's the API mandate [0]:

   1. All teams will henceforth expose their data and functionality through service interfaces.

   2. Teams must communicate with each other through these interfaces.

   3. There will be no other form of interprocess communication allowed: no direct linking, no direct reads of another team’s data store, no shared-memory model, no back-doors whatsoever. The only communication allowed is via service interface calls over the network.

   4. It doesn’t matter what technology they use. HTTP, Corba, Pubsub, custom protocols — doesn’t matter.

   5. All service interfaces, without exception, must be designed from the ground up to be externalizable. That is to say, the team must plan and design to be able to expose the interface to developers in the outside world. No exceptions.

   6. Anyone who doesn’t do this will be fired.

This is very different from saying "any developer who doesn't use an IDE and a debugger will be fired," which is analogous to what the AI mandates are prescribing.

[0] https://nordicapis.com/the-bezos-api-mandate-amazons-manifes...

>I'm sorry, but did you forget what page this comment thread is attached to? It's literally about corporate communication from CEOs reorganizing their companies around AI and mandating that employees use it.

That’s exactly my point. The fact that management is trying to top-down force adoption of something that operates at the individual level and whose adoption is thus inherently a bottom-up decision says it all. Individual workers naturally pick up tools that make them more productive and don’t need to be forced to use them from the top-down. We never saw CEOs issue memos “reorganizing” the company around IDEs or software frameworks and mandate that the employees use them, because employees naturally saw their productivity gains and adopted them organically. It seems the same is not true for AI.

>Think about the Industrial Age transition from individual craftspeople working on small shops using hand tools to make things into working in factories on large-scale assembly lines.

I wouldn't analogize the adoption of AI tools to a transition from individual craftspeople to an assembly line, which is a top-down total reorganization of the company (akin to the transition of a factory from steam power to electricity, as a sibling commenter noted [0]). As it currently exists, AI adoption is a bottom-up decision at the individual level, not a total corporate reorganization. Continuing your analogy, it's more akin to letting craftspeople bring whatever tools they want to work, whether those be hand tools or power tools. If the power tools are any good, most will naturally opt for them because they make the job easier.

>The nature of the work and your enjoyment of it is a fundamental part of the compensation package of a job.

That's certainly a part of it, but I also think workers enjoy and strive to be productive. Why else would they naturally adopt things like compilers, IDEs, and frameworks? Many workers enjoyed the respective intellectual puzzles of hand-optimizing assembly, or memorizing esoteric key combinations in their tricked-out text editors, or implementing everything from scratch, yet nonetheless jumped at the opportunity to adopt modern tooling because it increased how much they could accomplish.

[0] https://news.ycombinator.com/item?id=46976955