There are different groups with vested interests that color a lot of AI discourse
You have Tech CEOs that want work done cheaper and AI companies willing to sell it to them. They will give you crazy alarming narratives around AI replacing all developers, etc.
Then you have tech employees who want to believe they’re irreplaceable. It’s easy to want to keep working how we’ve always worked with hope of getting back to pre 2022 levels of software hiring and income. AI stands in the way of that.
I don’t think people are doing this intentionally all the time. But there is so much money and social stature from all these groups on the line, there are very few able to give a neutral, disinterested perspective on a topic like AI coding.
And to add to that, reasoned, boring, thoughtful middle of the road takes are just naturally going to get fewer eyeballs than extreme points of view.
What I do know, is that people keep trying to make my job obsolete, only to hire me under a different title for more money later. The practices and the tools are the same too, yet to justify it to themselves they'll make shit up about how the work is "actually, a material difference from what came before" (except, it's really not).
I'm still employable after 20 years of this.
I'm not a software engineer, and I'm not a tech CEO - I don't care, but people have been trying to replace me my whole career (even myself: "Automate yourself out of a job” is a common sysadmin mantra after all). Yet, somehow, I'm still here.
> "Automate yourself out of a job” is a common sysadmin mantra after all
Not just sysadmin. I've been automating the hell out of tedious mundane tasks that are done by error prone humans, and only become more error prone as they get tired/bored of these mundane tasks. The automation essentially just becomes a new tool/app for the humans to use.
At this point of my experience doing this, employees scared of automation are probably employees that aren't very good at their job. Employees that embrace this type of automation are the ones that tend to be much better at their job.
I try to once in a while but, for example, last time I ended up being instructed to make a bunch of changes to make the automated tool make all the little mistakes that were usually done during the manual process, so that if the process needs to be done manually, they wouldn't be confused. For example: Setting up a volume of a particular size, and then, so they wouldn't have to bust out a calculator, they put in a nice round number that's nice for them to write (lots of zeros), meaning it wastes space.
The point of the automated tool is to do it quicker and correctly, and remove the need for a calculator (which just involves dividing one number by 4096 at some point, really). But I had to re-fuck-it, and as a bonus, they never used it at all. I doubt any of my colleagues remembers it exists.
I really loath that part of this industry; I spent over a decade in it and the only tangible thing I've taken away from it is that the problems these philosophies and practices set out to solve are derivative of two things:
- Infrastructure is very often fundamentally disconnected from the product roadmap and thus is under constant cycles of cost control
- The culture of systems administration does not respond well to change or evolution. This is a function that is built around shepherding systems - whether at scale or as pets.
Long way of saying the gamut isn't that corporations will ever be free of systems administration any more than they'll be freed from software engineering. It is far easier to optimize software than it is to optimize infrastructure though, which is why it feels like someone is coming after you. To make matters more complex, a lot of software today overlaps with the definition of infrastructure.
Many jobs aim to solve problems so well that there’s nothing left to fix — doctors curing illnesses, firefighters preventing fires, police reducing crime, pest control eliminating infestations, or electricians making lasting repairs. And that’s totally fine — people still have jobs, and when it works, it’s actually great for everyone.
Some of the easy jobs will be taken away and your job is not under threat. Right? But some of the people who were doing low skilled jobs will grow to compete with you. Less supply more demand. Either the pay will come down or there are very few jobs. Fingers crossed.
Maybe there are less people in operations than before, there are certainly some companies that do their best not to employ any operations focused people and use FaaS for everything and only hire feature developers… who, end up doing the operations work that crops up.
> Maybe there are less people in operations than before
Even that ended up not being true, and I'd argue we have even more people doing ops now than we did before all the buzzwords.
Going to change my job title to cockroach because no matter how many times companies and trends have tried to kill ops, I'm still around, and sometimes in larger numbers.
> But some of the people who were doing low skilled jobs will grow to compete with you.
Yes, and this is not shocking. This is how it is meant to work. You get a low level job because you're new and have a lot to learn. You learn more things as you work the low level job, and then you can get promoted or move to a new role that is not so low level. You keep growing until you eventually compete with the people that were senior level when you were working that low level job.
Thank you for this, not only on the Ai-related discussion but painting the sense that sys admin work is still as complex and finnicky as it ever was. All we did with that role is let Amazon evangelize some weird taxing “standard” for hosting.
If you're like me, though, your day-to-day has probably shifted a lot.
My day used to be making sure desktops worked and we had a repeatable process to make new good desktops out of all the complex client software they needed.
Then I made sure servers got upgraded and patched and taken care of on a day-to-day level, although it was still someone else's job to keep desktops running. At home I compiled my own kernels and used tarballs to install and update packages. Desktop hardware support was iffy in Linux.
Then I jumped to borg and tupperware and kubernetes where hardware never mattered and it almost didn't matter what clients had because the browser they used auto-updated. At home I switched to distros where package management was automatic and rarely, if ever, broke.
I don't even know the hostnames or the network addresses of the hardware that runs my services, and AWS or GCP SREs probably rarely need to know either. Now I care about an abstract thing called a service that is instrumented with logs, metrics, and traces that would put the best local development tools of 20 years ago to shame. CI/CD and infrastructure as code pipelines actually did automate away many of the checklist-style sysadmin work of the past. At home I could run Talos and Ceph and Crossplane if I wanted to but so far I've dragged the old days of individual hosts along mostly for nostalgia.
I expect to eventually end up caring about systems at an even more abstract level once something like Crossplane becomes as universal as Terraform and GitHub actions. They'll probably run on something like web assembly on bare metal because no one actually cares what's underneath their containers if they keep working.
The stack of technology gets taller and more abstract and as it does so the job of caring about the lower layers gets automated and the lower layers get, if not simplified, standardized to the point that automation is more reliable than human intervention.
Humans will only get squeezed out of the loop when superhuman artificial intelligence arrives and our abstract design and management of systems becomes less reliable than the automation. Then hopefully we get a nice friendly button to push for more automatically-human-aligned utility.
EDIT: That's not to say that the lower levels can be automatically designed; not yet at least. Eventually once AI is good enough at formal design then quite likely. We still need low-level software engineering to keep building the stack but it is vastly more commoditized (the one open source developer in the xkcd cartoon keeping 99% of the world's infrastructure running on a 20-year old tool/utility)
>Then you have tech employees who want to believe they’re irreplaceable. It’s easy to want to keep working how we’ve always worked with hope of getting back to pre 2022 levels of software hiring and income. AI stands in the way of that.
Eventually, things will stabilize to a point where we will know what the boundaries of all the new LLM based tooling is good for, and where humans add lots of value to that.
That will then drive a maximalist hiring spree, as the more people you have working at an increase in velocity, the faster you ship, and for once, perhaps the quality of code won't substantially decrease, assuming LLMs improve another few leaps in output quality and engineering workflows adjust in a normalized way.
Thats the hopeful side of the equation anyway.
I feel incredibly bad about customer oriented jobs, like white glove customer service. I already saw a trend (especially since 2020 but certainly before as well) where these AI chat bots and AI support lines will decimate that job category. These are pretty common white collar jobs, lots of people even in our industry got their starts on support lines.
I don't think any normal customer is going to want to talk to AI, once the novelty wears off. It's going to be "Let me talk to your supervisor" almost every time.
Yeah, if the AI isn't shite and has access to tools to solve my problem, I'll take it over some overworked and undermotivated human call center any day.
Co I work for creates customer support software, so naturally we have some AI solution available to people.
A lot of our customers (aka businesses deploying our customer support software for their customers) are telling us people fucking hate dealing with AI in literally any capacity, even if some of the stuff we offer actually works quite good (FAQ bots, bots that redirect to the proper channels/teams and stuff like that). The C-suite at my company have had to go back on some of their OKRs of late, because after an initial huge bump of AI usage, clients are starting to kill off the AI tooling and our usage numbers are dwindling because their customers hate it.
I get to see some of the chats people have with the AI systems, and people will straight up say slurs in chats because they know it's the quickest way of escalating to an actual human lol. People really don't like this crap, but of course CEOs and their ilk are usually psychopaths so they don't really give a shit if it means they can save 5 cents per user.
Also judging by my LinkedIn, but all the senior tech execs on the job market are now Generative AI Experts, which is funny because I thought they were all Cryptocurrency Experts when I last saw them posting this much in 2020.
The best is when you work with one, in a small enough company. During which they extoll some currently-hot grift, and then after the company goes under (maybe not due to thier poor leadership), you read about their huge successes there! Much win.
I think this is an easy thing to wrap my mind around (since I have been in both camps):
AI can generate lots of code very quickly.
AI does not generate code that follows taste and or best practices.
So in cases where the task is small, easily plannable, within the training corpus, or for a project that doesn't have high stakes it can produce something workable quickly.
In larger projects or something that needs maintainability for the future code generation can fall apart or produce subpar results.
That was four short paragraphs with basically no details - there's basically nothing for eyeballs to see. If I wrote a history of the world that consisted of "Some people lived and died, some of them were bad, I guess", how many copies do you think I'd sell? Any? What's interesting is the details, and a post giving actual detail of building some app, and the benefits and shortcomings of a specific tool would be of great interest to many. If I ask an LLM to save the date to the database, and then ask it to save the time, do I get two variables in two columns? Does that make sense for my app? Do I have to ask it to refactor? Is it able to do that successfully? Does it drop tables during program initialization? How does the latest model do with designing the entire program? How often does it hallucinate for this set of libraries and prompts? There's quite a bit of variance! If it hallucinated libraries and APIs left and right it would be far less useful. Some people don't even get hallucinations because their prompts are so we'll trod. There are all sorts of interesting details to be learned and shared about these new tools that would get a ton of eyeballs.
Recent LLMs are fairly good at following instructions, so a lot of the difference comes down to the level of detail and quality of the instructions given. Written communication is a skill for which there's a huge amount of variance among developers, so it's not surprising that different developers get very different results. The relative quality of the LLM's output is determined primarily by the written communication skills of the individuals instructing it.
It seems to me If you know all these instructions clearly, then you know everything, and it's easy for you to write the code yourself, and you don't need an LLM.
The amount of typing it takes to describe a solution in English text is often less than the amount of typing needed to actually implement it in code, especially after accounting for boilerplate and unit tests. Not to mention the time spent waiting for the compiler and test harness to run. As a concrete example, the HTTP2.0 spec is way fewer chars long than any HTTP2.0 server implementation, and the C spec is way fewer chars long than any compliant C compiler. The C++ spec is way, way fewer chars long than any compliant C++ compiler.
>The amount of typing it takes to describe a solution in English text is often less than the amount of typing needed to actually implement it in code
I don't find this to be true. I find describing a solution in English well to be slower than describing the problem in code (IE, by writing tests first) and having that be the structured data that the LLM uses to generate code.
Its far faster, from the results I'm seeing plus my own personal experience, to write clear tests which benefit from being a form of structured data that the LLM can analyze. Its the guidance we have given to our engineers at my day job and it has made working with these tools dramatically easier.
In some cases, I have found LLM performance to be subpar enough that it is indeed, faster to write it myself. If it has to hold many different pieces of information together, it starts to falter.
I don't think it's so clear-cut. The C spec I found is 4MB and the tcc compiler source code is 1.8MB. It might need some more code to be fully compliant, but it may still be smaller than 4MB. I think the main reason why code bases are much larger is because they contain stuff not covered by the spec (optimization, vendor-specific stuff, etc etc).
Personally I'd rather write a compiler than a specification, but to each their own.
Corpus also matters. I know Rust developers who aren't getting very good results even with high quality prompts.
On the other hand, I helped integrate Cursor as a staff engineer at my current job for all our developers (many hundreds), who primarily work in JavaScript / TypeScript, and even middling prompts will get results that only require refactoring, assuming the LLM doesn't need a ton of context for the code generation (e.g. greenfield or independent features).
Our general approach and guidance has been that developers need to write the tests first and have Cursor use that as a basis for what code to generate. This helps prevent atrophy and over time we've find thats where developers add the most value with these tools. I know plenty of developers want to do it the other way (have AI generate the tests) but we've had more issues with that approach.
We discourage AI generating everything and having a human edit the output, as it tends to be slower than our chosen approach and more likely to have issues.
That said, LLMs still struggle if they need to hold alot of context. For instance, if you have a bunch of files that it needs to understand to also generate code that is worthwhile, particularly if you want it to re-use code.
>Corpus also matters. I know Rust developers who aren't getting very good results even with high quality prompts.
Which model were they using, out of interest? I've gotten decent results for Rust from Gemini 2.5 Pro. Its first attempt will often be disgusting (cloning and other inefficiencies everywhere), but it can be prompted to optimise that afterwards. It also helps a lot to think ahead about lifetimes and explicitly tell it how to structure them, if there might be anything tricky lifetime-wise.
No idea. I do know they all have access to Cursor and tried different models, even the more expensive options.
What you're describing though, having to go through that elaborate detail really drives to my point though, and I think shows a weakness in these tools that is a hidden cost to scaling their productivity benefits.
What I can tell you though both from observation and experience, is that because the corpus for TypeScript / JavaScript is infinitely larger as it stands today, even Gemini 2.5 Pro will 'get to correct' faster even with middling prompt(s) vs for a language like Rust.
I do a lot of work in a rather obscure technology (Kamailio) with an embedded domain-specific scripting language (C-style) that was invented in the early 2000s specifically for that purpose, and can corroborate this.
Although the training data set is not wholly bereft of Kamailio configurations, it's not well-represented, and it would be at least a few orders of magnitude smaller than any mainstream programming language. I've essentially never had it spit out anything faintly useful or complete Kamailio-wise, and LLM guidance on Kamailio issues is at least 50% hallucinations / smoking crack.
This is irrespective of prompt quality; I've been working with Kamailio since 2006 and have always enjoyed writing, so you can count on me to formulate a prompt that is both comprehensive and intricately specific. Regardless, it's often a GPT-2 level experience, or akin to running some heavily quantised 3bn parameter local Llama that doesn't actually know much of anything specific.
From this one, can conclude that a tremendous amount of reinforcement for the weights is needed before the LLM can produce useful results in anything that isn't quasi-universal.
I do think, from a labour-political perspective, that this will lead to some guarding and fencing to try to prevent one's work-product from functioning as free training for LLMs that the financial classes intend to use to displace you. I've speculated before that this will probably harm the culture of open-source, as there will now be a tension between maximal openness and digital serfdom to the LLM companies. I can easily see myself saying:
I know our next commercial product (based on open-source inputs) releases, which are on-premise for various regulatory and security reasons, will be binary-only; I have never customers looking through our plain-text scripts before, but I don't want them fed into LLMs for experiments with AI slop.
Yea this! How many devs say "it doesn't do what i expect" did not try to write up a plan of action before it just YOLO'd some new features? We have to learn to use this new tool, but how to do that is still changing all the time.
I've just seen that change happen in the a pet project within less than 10 hours of work.
I tried vibe-coding something for my own use, your classic "scratch your own itch" project.
The first MVP was a one-shot success, really impressive.
But as the code grew with every added feature, progress soon slowed down. The AI claimed to have fixed a bug when it didn't. It switched chest several timea back and forth between using a library function and rolling its own implementation, each time claiming to have "simplified" the code and made it "more reliable". With every change, it claimed to have "improved" the code, even when it just added a bunch of shamelessly duplicated shit.
One effect I am sure AI will have is to massively excarbate the phenomenon of people who quickly produce a large amount of shitty, unmaintainable code that fulfills half the requirements, and then leave the mess behind for another greenfield project.
We’re so unaccustomed to working with non-deterministic computer tech that rather than acknowledge they are hit-or-miss, everyone just picks one side and goes all-in on it.
> We’re so unaccustomed to working with non-deterministic computer tech
The whole history of computer history is about making computing deterministic, after we found out that having generative anything (Recursion, Context-Free grammar,...) is a double-edged sword. So for any known set of inputs, you want the output to be finite and non-zero, and all items having the correct properties.
I think there is a strong case that experienced developers can not be replaced by AI anytime soon. Where the danger lies is for junior developers fresh out of college. How are they supposed to become experienced developers if an AI can do the grunt work they normally get assigned?
It really doesn't help that AI companies are hype machines full of salesmen trying to hype up their product so you buy it. There have been a lot of amazing AI "success stories" that don't hold up under scrutiny.
> Where the danger lies is for junior developers [...] if an AI can do the grunt work they normally get assigned?
Just because "well, maybe true for junior devs!" is a compromise over "AI will make all programmers obsolete!" it doesn't make it reasonable. It's still an extraordinary claim.
I think the problem with this one is that LLMs are somehow both unreasonably effective as well as unreasonably ineffective. Letting the code editor llms do their suggestions, I’ve gotten a ton of useless boilerplate garbage suggestions, but periodically, a couple times of day, it suggests blocks of code that are far more complete, comprehensive and correct than it has any right to be.
Whether you’ll get the high IQ or low IQ LLM on the next suggestion is a crapshoot; how much consideration you give to either outcome (focus on the random instances of brilliance, or the constant stream of bullshit) drives the final perception.
That has been my experience too. I recently turned it all off because I decided the amount of times it takes me 5x longer to accomplish something, in addition to the subtle increase of bugs, is not currently worth it. I guess I'll try it again in a few months.
> Whether you’ll get the high IQ or low IQ LLM on the next suggestion is a crapshoot
I have heard theories from people--whose ideas I don't ordinarily consider to be in the realm of purely uninformed speculation--that this can vary depending on system-wide GPU load, and is throttled accordingly based on real-time demand by the major LLM providers.
Sounds like conspiratorial thinking to come to terms with the fact that LLMs are fundamentally non-deterministic text predictors. You can get dramatically different responses to the same question, and that’s just how the system works.
Or are those people biased by what they want to be true because of their current situation (the dev who dont wanna change how they work and therefore wants AI to not work or the non-technical person who dont wanna learn to code or be dependent on a developer and therefore want it to work)
And then you have research that says they're both full of shit. The article is perhaps a bit shallow, but it's spiritually correct: there's a lot of uncertainty and people who claim they figured it all out are mostly spewing nonsense.
I mean it's working for me. It's definitely not living up to the hype IMO (market is way overvaluing), but I wouldn't want to work without it any more, which is actually saying a lot.
This take is as a senior (greybeard) developer using paid claude-code in the terminal only (I use plain vim for my own code). I'm running my own business while wearing all of the hats, so I'm not as worried about becoming obsolete, but I also have zero motivation to get other businesses using it (I'm not invested into any AI companies)!
To be honest, I could probably even be using it better, but I haven't spent much time yak shaving over my setup beyond zen mcp.
That being said, I think anyone looking to invest into established AI companies right now is in for a rude awakening. I think it'll be a commodity / utility like cloud computing with tons of competition and not a ton of differentiating features. That's just my opinion though, and I could be horrendously wrong!
I'm also seeing benefits, and I'm on pretty much the same stack as you. The METR paper I'm citing was misquoted a lot (N was small, and it wasn't a favorable setup for AI tools), but the most important finding was that it's very easy to fool ourselves about productivity benefits.
Am I going to cancel my Anthropic subscription? Certainly not, but I'm not going to pretend like my setup is The One True Way. The plural of anecdote isn't data. Nobody has this figured out, nobody.
Maybe it's too soon to say that autonomous LLM agents are the wave of the future and always will be, but that's basically where I'm at.
AI code completion is awesome, but it's essentially a better Stack Overflow, and I don't remember people worrying that Stack Overflow was going to put developers out of work, so I'm not losing sleep that an improved version will.
The problem with the "agents" thing is that it's mostly hype, and doesn't reflect any real AI or model advances that makes them possible.
Yes, there's a more streamlined interface to allow them to do things, but that's all it is. You could accomplish the same by copy-and-pasting a bunch of context into the LLM before and asking it what to do. MCP and other agent-enabling data channels now allow it to actually reach out and do that stuff, but this is not in itself a leap forward in capabilities, just in delivery mechanisms.
I'm not saying it's irrelevant or doesn't matter. However, it does seem to me that as we've run out of low-hanging fruit in model advances, the hype machine has pivoted to "agents" and "agentic workflows" as the new VC-whetting sauce to keep the bubble growing.
I don't want to blame Alan Turing for this mess, but his Turing Test maybe gave people that idea that something that can mimic a human in conversation is also going to be able to think like a human in every way. Turns out not to be the case.
Well, I agree with you. But I'd be remiss not to say that this is a lively controversy in the world of cognitive science and philosophy of mind.
To one camp in this discursive space, who of course see themselves to be ever the pragmatists, the essence of the polemic about whether LLMs can "think" is not about whether they think in exactly the same ways we do or capture the essence of human thinking, but whether it matters at all.
Well, it's an interesting question. I'm not sure we really know what "thinking" is. But where the rubber meets the road in the case of LLM agents is whether they can achieve the same measurable outcomes as a human agent, regardless of how they get there. And it seems not at all clear how to build those capabilities on top of an admittedly impressive verbal ability.
It may be because I've a writer/English major personality, and so am very sensitive to the mood and tone of language, but I've never had trouble distinguishing LLM output from humans.
I'm not suggesting anything so arrogant as that I cannot be fooled by someone intentionally deploying an LLM with that aim; if they're trained on human input, they can mimic human output, I'm sure. I just mean that the formulations that come out of the mainstream public LLM providers' models, guided however they are by their pretraining and system prompts, are pretty unmistakably robotic, at least in every incarnation I've seen. I suppose I don't know what I don't know, i.e. I can't rule out that I've unknowingly interacted with LLMs without realising it.
In the technical communities in which I move, there are quite a few forums and mailing lists where low-skilled newbies and non-native English speakers frequently try to disgorge LLM slop. Some do it very blatantly, others must believe they're being quite sly and subtle, but even in the latter case, it's absolutely unmistakable to me.
AI is glorified autocomplete. Look at what happens when AI tries its hand at writing legal briefs, and you'll understand why it cannot possibly replace software developers.
As with all uses of current AI (meaning generative AI LLMs) context is everything. I say this as a person who is both a lawyer and a software engineer. It is not surprising that the general purpose models wouldn't be great at writing a legal brief -- the training data likely doesn't contain much of the relevant case law because while it is theoretically publicly available, practicing attorneys universally use proprietary databases like Lexis and WestLaw to surface it. The alternative is spelunking through public court websites that look like they were designed in the 90s or even having to pay for case records like on PACER.
At the same time, even if you have access to proper context like if your model can engage with Lexis or WestLaw via tool-use, surfacing appropriate matches from caselaw requires more than just word/token matching. LLMs are statistical models that tend to reduce down to the most likely answer. But, typically, in the context of a legal brief, a lawyer isn't attempting to find the most likely answer or even the objectively correct answer, they are trying to find relevant precedent with which they can make an argument that supports the position they are trying to advance. An LLM by its nature can't do that without help.
Where you're right, then, is that law and software engineering have a lot in common when it comes to how effective baseline LLM models are. Where you're wrong is in calling them glorified auto-complete.
In the hands of a novice they will, yes, generate plausible but mostly incorrect or technically correct but unusable in some way answers. Properly configured with access to appropriate context in the hands of an expert who understands how to communicate what they want the tool to give them? Oh that's quite a different matter.
> As with all uses of current AI (meaning generative AI LLMs) context is everything.
But that's the whole point. You can't fit an entire legal database into the context, it's not big enough. The fact that you have to rely on "context is everything" as a cope is precisely why I'm calling them a glorified autocomplete.
I wonder to what extent a non LLM system with access to the same original corpus of text would do, with some simple similarity search feature across the corpus?
Look, maybe I’m saying the quiet part out loud, but if software engineering isn’t where the money is at anymore, and those jobs go away, I’d be competent at something else. I’m a smart person. I work hard. I’m confident I’d be able to displace someone who isn’t as smart as me and just “take” their job.
There’s going to be a need for smart people with a good work ethic unless literally everyone loses their jobs, and at that point we’re living past the singularly event horizon as far as I’m concerned and all bets are off.
Why don't Tech CEOs and CTOs see how AI is going to "disrupt" their jobs? If anyone can write code, why will I hire your company to create the software I use?
I also see the non-development jobs as much more in peril from AI; I can go generate marketing copy, HR policies, and project plans of comparable (or better!) quality today.
> It’s easy to want to keep working how we’ve always worked
There is no “how we’ve always worked”; there was no steady state. Constant evolution and progressive automation of the simpler parts has been the norm for software development forever.
> with hope of getting back to pre 2022 levels of software hiring and income. AI stands in the way of that.
It doesn't, though. Productivity multipliers don't reduce demand for the affected field or income in it. (Tight money policies and economic slowdowns, especially when they co-occur, do, though, especially in a field where much of the demand and high income levels are driven by speculative investment, either in startups or new ventures by established firms.)
it has devalued the labor. i scoped a contract but they want me to do it in less time now that we have AI. this lets them pay me less for the same work. and AI CEOs sell it as "society will do less work" but instead now i'm expected to do more work because the work takes less time. same as it ever was with technology advances.
There are also a large number of people who have a deep-seated philosophical objection to the entire project of ai. It's not just about their job, it's about their sense of who and what they are as a human being, their soul or whatever. They will insist that AI's do not think or know anything, no matter what evidence there is to contrary.
Everyone has an agenda. Similarly, groups like r/singularity and the rationalists have spent years predicting the oncoming advent of a machine god, and are desperately reading too much into every LLM advancement.
(Note: This is an American take, and uses software jobs as the primary example, but a lot of this applies to other jobs)
Yes, well said - with one caveat: "Money and social status" is subtly but crucially different from "livelihood". You correctly identify the group of people whose lives are affected, but lump those people along with CEOs and AI companies under the umbrella of "money and social status" in your summarization, which maybe undersells the role of the masses in this equation.
The software job - traditionally one of the few good career options remaining for a large chunk of Americans - is falling. There are many different reasons, and AI, while not the apocalypse, is a small but crucial part of it. We need to get over the illusion that a large piece of that fall consists of wildly luxurious incomes reducing to simply cushy incomes - "boo hoo", we say, sarcastically. But the majority of software folks are going from "comfortable" to "unhappy but livable", while some are going from "livable" to "not livable", while others are no longer employed at all. There were already too many people across the job spectrum in these buckets, and throwing another gigantic chunk of citizens in there is going to eventually cause big, bad things to happen.
We need to start giving a shit about our citizens, and part of that is avoiding the implication that just because something disruptive is inevitable, doesn't mean the affect isn't devastating and we should just do absolutely nothing about the situation. Another part of that is avoiding the implication that the average person can just successfully change careers without enormous suffering. We can ease, assist, REGULATE (which the party in power would like to make illegal), etc. It's important to understand that none of that means "stopping" AI or something ridiculous like that.
We need to start giving a shit about our citizens.
A third time: We need to start giving a shit about our citizens.
And sorry, most of this was not directed personally at you. Just the first note about your wording.
The key is to look at the long term structural changes the industry is going through, and whether or not AI helps, or hinders that goal
In general, the industry has been making huge efforts to push errors from runtime, to compile time. If you imagine points where we can catch errors being laid out from left to right, we have the following:
The industry is trying to push errors leftwards. Rust, heavier review, safety in general - its all about cutting down costs by eliminating expensive errors earlier in the production chain. Every industry does this, its much less costly to catch a defective oxygen mask in the factory, than when it sets a plane on fire. Its also better to catch a defective component in the design phase, than when you're doing tests on it
AI is all about trying to push these errors rightwards. The only way that it can save in engineer time is if it goes through inadequate testing, validation, and review. 90% of the complexity of programming is building a mental model of what you're doing, and ensuring that it meets the spec of what you want to do. A lot of that work is currently pure mental work with no physical component - we try and offload it increasingly to compilers in safe languages, and add tests and review to minimise the slippage. But even in a safe language, it still requires a very high amount of mental work to be done to make sure that everything is correct. Tests and review are a stop gap to try and cover the fallibility of the human brain
So if you chop down on that critical mental work by using something probabilistically correct, you're introducing errors that will be more costly down the line. It'll be fine in the short term, but in the long term it'll cost you more money. That's the primary reason why I don't think AI will catch on - its short termist thinking from people who don't understand what makes software complex to build, or how to actually produce software that's cheap in the long term. Its also exactly the same reason that Boeing is getting its ass absolutely handed to it in the aviation world. Use AI if you want to go bankrupt in 5 years but be rich now
> It'll be fine in the short term, but in the long term it'll cost you more money. That's the primary reason why I don't think AI will catch on - its short termist thinking from people who don't understand what makes software complex to build, or how to actually produce software that's cheap in the long term. Its also exactly the same reason that Boeing is getting its ass absolutely handed to it in the aviation world. Use AI if you want to go bankrupt in 5 years but be rich now
I think your analysis is sound from a technical perspective, but your closing statement is why AI is going to be mass adopted. The people who want to be rich now and don't care about what will happen in 5 years have been calling the shots for a very long time now, and as much as we technical folks insist this can't possibly keep going on forever, it's probably not going to stop sometime soon.
I’m not sure this follows as SOTA LLMs are pretty good at writing Rust, so wouldn’t this also make it easier for codebases to move leftward in your analogy? For example, I was resistant to use Rust for a lot of things because a). The community is somewhat annoying and pedantic, even by software engineering standards b). The overhead in getting colleagues up to speed on Rust code was too much of a time suck. LLMs solve both those problems and we’re now migrating lots of stuff to Rust, my colleagues can ask lots of questions (of Google Gemini Pro 2.5), without burdening anyone or being met with disdain, and seem generally more curious and positive about these moves/Rust overall.
> its short termist thinking from people who don't understand what makes software complex to build
Ironically you don't need AI to see this pattern. Maybe AI makes it a little bit more obvious who's thinking long term and who's not (both at the top and in the trenches)
> Use AI if you want to go bankrupt in 5 years but be rich now
Or, as some would put it "Use AI if you want to be rich now, exit, and have someone else go bankrupt in 5 years"
You are looking at LLMs for code generation exclusively, but that is not the only application within software engineering.
In my company some people are using LLMs to generate some of their code, but more are using them to get a first code review, before requesting a review by their colleagues.
This helps getting the easy/nitpicky stuff out of the way and thereby often saves us one feedback+fix cycle.
Examples would be "you changed this unit test, but didn't update the unit test name", "you changed this function but not the doc string", or "if you reorder these if statements you can avoid deep nesting".
Nothing groundbreaking, but nice things.
We still review like we did before, but can often focus a little more on the "what" instead of the "how".
In this application, the LLM is kind of like a linter with fuzzy rules. We didn't stop reviewing code just because many languages come with standard formatters nowadays, either.
While the whole code generation aspect of AI is all the rage right now (and to quote the article):
> Focus on tangible changes in areas that you care about that really do seem connected to AI
So while I don't disagree with you at all, in terms of AI being a bubble, none of that is why the tech is being so hyped up. The current speculative hype push is being driven by two factors:
1. The promise that AI will replace most if not all developers
2. Alternatively, that AI will turn every developer into a 10-100x developer
My personal opinion is that it'll end up being one of many tools that's situationally useful, eg you're 100% right in that having it as an additional code review step is a great idea. But the amount of money being pumped into the industry isn't enough to sustain mild use cases like that and that isn't why the tech is being pushed. The trillions of dollars being dumped into improving clang tidy isn't sustainable if that's the end use case
If AI tools allow for better rapid prototyping, they could help catch "errors" in the conception and design phases. I don't know how useful this actually is, though.
One of the problems with using AI for prototyping (or just in general), is that the act of creating the prototype is what's valuable, not the prototype itself. You learn lessons in trying to build it that you use to build the real product. Using the AI to skip the learning step and produce the prototype directly would be missing the point of prototyping at all
That's definitely an issue and I've gotten burnt by similar problems when using AI to help navigate and find things in codebases, where I've used it to read and understand code for me, with seemingly miraculous results at first, but ended up wishing I'd read more code "manually" myself, as my shallow understanding led to wasting more time on net than I saved. I still feel like it should be possible to find some kind of a balance, but it's tricky.
That's true up to a certain threshold on 'probabilistically correct', right? At a certain number of 9s, it's fine. And increasingly I use AI to help ask me questions, refine my understanding of problem spaces, do deep research on existing patterns or trends in a space and then use the results as context to have a planning session, which provides context for architecture, etc.
So, I don't know that the tools are inherently rightward-pushing
The problem is, given the inherent limitations of natural language as a format to feed to an AI, it can never have enough information to be able to solve your problem adequately. Often the constraints of what you're trying to solve only crop up during the process of trying to solve the problem itself, as it was unclear that they even existed beforehand
An AI tool that could have a precise enough specification fed into it to produce the result that you wanted with no errors, would be a programming language
I don't disagree at all that AI can be helpful, but there's a huge difference between using it as a research tool (which is very valid), and the folks who are trying to use it to replace programmers en masse. The latter is what's driving the bubble, not the former
This has been a huge frustration for me, but the wild thing is that we've built up so many tools over time that help humans only for AI coding tools to wild west it and not use them. The best AI coding tools will read docs websites, terminal error messages, write/run tests, etc. But we have so many better tools that none of them seem to use:
* profilers
* debuggers
* linters
* static analyzers
* language server protocol
* wire protocol analyzers
* decompilers
* call graph analyzers
* database structure crawlers
In the absence of models that can do perfect oneshot software engineering, we're gonna have to fall back on well-integrated tool usage, and nobody seems to do that well yet.
I think a lot of these use cases for AI are incidental byproducts of the actual goal, which is to replace software developers. They're trying to salvage some kind of utility. Because I agree that the AI tools in use are marginal improvements, or downgrades in a lot of cases
I've heard people say they use AI agents to set up a new project with git. Just use tortoisegit or something, its free and takes one click - its just using AI for the sake of it
Vibe coding pushes errors rightward, but using AI to speed up typing or summarizing documentation doesn’t. Vibe coding will fail, but that doesn’t mean using AI to code will fail. You’re looking at one (admittedly stupid) use case and generalizing too hastily.
If I have an LLM fix a bug where it gets the feedback from the type checker, linter and tests in realtime, no errors were pushed rightward.
It’s not a free lunch though. I still have to refactor afterwards or else I’ll be adding tech debt. To do that, I need to have an accurate mental model of the problem. I think this is where most people will go wrong. Most people have a mindset of “if it compiles and works, it ships.” This will lead to a tangled mess.
Basically, if people treat AI as a silver bullet for dealing with complexity, they’re going to have a bad time. There still is no silver bullet.
Is this true? Most software devs would like to. But I think business is more interested in spee which pushes errors to the right. Which seems to be more profitable in most software. Even stuff thats been around for a decade(s).
nah, in general there's a serious industry-wide push for this. software testing is changing (involve QAs early so they can help with the spec so when they get the software they know what to test against), agile is about delivering small valuable parts of the product as soon as possible, VC investing (lean startups!) is about testing business ideas as soon as possible, etc.
it's all part of the shift left ideology. (same with security, you cannot really add it later, same with GDPR and other data protection stuff, you cannot track consent for various data processing purposes after you already have a lot of users onboarded - unless you want to do the sneaky very not nice "ToS updated, pay or die, kthxbai" thing [which is what Meta did], etc.)
... of course this usually means that many times people want to go from the "barely idea as a Figma proto" to "mature product maintained by distributed high-velocity teams" without realizing that there are trade-offs.
shift left is makes good business and engineering sense and all, as it allows you to focus on the things that work, but it requires more iterations to go from that to something mature.
I disagree entirely, and I can convince you I'm right with one sentence: More lines of JS/TS are written by AI than lines of Rust are written at all. We don't have the data to assert this as true, but I think the vast majority of people would agree with that statement.
This statement being true disproves the statement "the industry has been making huge efforts to push errors from runtime, to compile time." The industry is not a monolith. Different actors have different, individualized goals.
it's absolutely not a problem that people are writing more JS/TS than Rust.
if that Rust is for decades and the JS/TS gets thrown out in 1 year.
there's a lot of shitty C being written still around the world yet the Rust that goes into the kernel has real value long term.
there's an adoption cycle. Rust is probably already well over the hype peak, and now it's slowly climbing upward to its "plateau of productivity".
(and I would argue that yes there are pretty good things happening nowadays in the industry. for many domains efficient and safe libraries, frameworks, and platforms are getting to be the norm. for example see how Blender became a success story. how deterministic testing is getting adopted for distributed databases.)
We still run tests (before code review, obviously; don't know why it's listed like this).
We still do QA at runtime.
I feel like anti-AI people are those one who actually treat AI as magic, not the AI users. AI doesn't magically prevent you from doing the things that helped you in pre-AI era.
No, but if a shop added overnight 5 fledgling juniors for each current employee on the project, not only would the delivery not be sped up on account of Brooks's law, but the stack would soon tank under the weight of its own issues. So outside of such situations as hilarious consultancy disasters, no one did that.
This is the best and most enlightening take I've heard in a good while.
I have articulated this to friends and colleagues who are on the LLM hype train somewhat differently, in terms of the unwieldiness of accumulated errors and entropy, disproportionate human bottlenecks when you do have to engage with the code but didn't write any of it and don't understand it, etc.
However, your formulation really ties a lot of this together better. Thanks!
Exabytes of code are being written in Python and JS though… I don’t think that fits with your narrative that everything is being pushed to compile-time. C#, Java and Go remain popular sure but have they grown that much relative to other languages? Rust is being adopted primarily in projects that used to be in C or C++ if I’m not mistaken.
Those languages have been going through exactly the same evolution though, like the JS -> typescript migration is one of the most direct practical examples of this imo
thanks for articulating so nicely what needs to be said in this debate.
Pushing errors leftward vs rightwards is such a nice metaphor, not to mention the metaphor on mental models.
Also, your comment on why natural language is unable to describe the problem adequately (later in this thread), since sometimes constraints are discovered during the solution process, and otherwise, and if problems could be described adequately, thats what we call a programming language is very nice - ie, for natural language to adequately describe a problem, that becomes a formal language.
Only experienced engineers who have been through failed projects will understand what you are saying, and the rest of those in the grip of the ai-mania will come to terms with it soon.
> I expected to find vastly differing views of what future developments might look like, but I was surprised at just how much our alums differed in their assessment of where things are today.
> We found at least three factors that help explain this discrepancy. First was the duration, depth, and recency of experience with LLMs; the less people had worked with them and the longer ago they had done so, the more likely they were to see little value in them (to be clear, “long ago” here may mean a matter of just a few months). But this certainly didn’t explain all of the discrepancy: The second factor was the type of programming work people cared about. By this we mean things like the ergonomics of your language, whether the task you’re doing is represented in model training data, and the amount of boilerplate involved. Programmers working on web apps, data visualization, and scripts in Python, TypeScript, and Go were much more likely to see significant value in LLMs, while others doing systems programming in C, working on carbon capture, or doing novel ML research were less likely to find them helpful. The third factor was whether people were doing smaller, more greenfield work (either alone or on small teams), or on large existing codebases (especially at large organizations). People were much more likely to see utility in today’s models for the former than the latter.
Anecdotal: definitely a long way to go for systems programming, non-trivial firmware, and critical systems in general. And I say this as a huge fan of LLMs in general.
I work as a FW Eng and while they've been of immense value in scripting especially (fuck you powershell), I can only use them as a better autocomplete on our C codebase. Sometimes I'd chat with the codebase, but that's a huge hit or miss.
The value of AI is easy to see personally, concretely. But there is always a gap between concrete value in your hands and how that plays out in larger systems. The ability to work remotely could intuitively project to outsourcing of almost all knowledge work to cheaper labor markets, and yet that has only happened at the margins. The world is complex and complicated, reserve a measure of doubt.
In-person work has higher bandwidth and lower latency than remote work, so for certain roles it makes sense you wouldn't want to farm it out to remote workers. The quality of the work can degrade in subtle ways that some people find hard to work with.
Similarly, handing a task to a human versus an LLM probably comes with a context penalty that's hard to reason about upfront. You basically make your best guess at what kind of system prompt an LLM needs to do a task, as well as the ongoing context stream. But these are still relatively static unless you have some complex evaluation pipeline that can improve the context in production very quickly.
So I think human workers will probably be able to find new context much faster when tasks change, at least for the time being. Customer service seems to be the frontline example. Many customer service tasks can be handled by an LLM, but there are probably lots of edge cases at the margins where a human simply outperforms because they can gather context faster. This is my best guess as to why Klarna reversed their decision to go all-in on LLMs earlier this year.
> In-person work has higher bandwidth and lower latency than remote work, so for certain roles it makes sense you wouldn't want to farm it out to remote workers
This is just not true. Specially if your team exists within an organization that works in world wide solutions and interacts with the rest of the world.
Remote can be so much faster and efficient because it's decentralized by nature and it can make everyone's workflows as optimized as possible.
Just because companies push for "onsite" work to justify their downtown real estate doesn't mean it's more productive.
That is like saying concurrent programming is far superior to sequential programming so lets stop doing sequential programming completely. Many tasks are just easier to do in a centralized environment.
The people who are saying AI will replace everyone are people who don't actively deploy code anymore. People like CEOs and VPs.
People who are actively deploying code are well aware of the limitations of AI.
A good prompt with some custom context will get you maybe 80% of the way there. Then iterating with the AI will get you about 90% of the way, assuming you're a senior engineer with enough experience to know what to ask. But you will still need to do some work at the end to get it over the line.
And then you end up with code that works but is definitely not optimal.
Fred Brooks told us to "plan to throw one version away, because you will."
What he missed is that the one version that is not thrown away will have to be maintained pretty much for ever.
(Can we blame him for not seeing SaaS coming ?)
What if the real value of AI was at the two sides of this:
* to very quickly built the throwaway version that is just used during demos, to gather feedback from potential customers, and see where things break ?
That can probably be a speed-up of 10x, or 100x, and an incredible ROI if you avoid building a "full" version that's useless
* then you create the "proper" system the "old" way, using AI as an autocomplete on steroid (and maybe get 1.5x, 2x, speedup, etc...)
* then you use LLMs to do the things you would not do anyway for lack of time (testing, docs, etc...) Here the speedup is infinite if you did not do it, and it had some value.
But the power that be will want you to start working on the next feature, by this time...
* I don't know about how LLMs would help to fix bugs
So basically, two codebase "lanes", evolving in parallel, one where the AI / human ratio is 90/10, one where it's maybe 30/70 ?
Maybe but anytime someone keeps doing mental gymnastics and theorizing that there are new forces at play, something comes out and says no, it was something very straightforward. Hammock Driven Development describes a zen internalized way an expert does exactly as you describe but it is nicer you don't have to pay per token. To be clear, I think this all falls again under the rubber duck umbrella which is fine, but seemingly impossible to design a controlled study for?
I agree that the study is biased (it compared people unused to a tool with people not using the tool. Duh. The only person who was more efficient was the person... who knew how to use the tool. Duh indeed.)
However I don't see how hammock driven dev allows you to validate an idea with a prototype built in an hour as opposed to a month.
The real benefactors of AI in software development are senior devs who’ve had enough of boilerplate, framework switching, and other tedious low-value tasks. You cut down on the former laborious tradition of picking through StackOverflow for glimmers of hope.
Yet when you look beyond boilerplate code generation, it's not all that LLMs increase experienced developers productivity (even when they believe that it does): https://arxiv.org/abs/2507.09089
Edit: Hello downvoters, would love to know if you found any flawed argument, is this just because this study/comment contradicting the common narrative on HN or something else entirely?
Is there literally anything other than this single, 16-participant study with that validates the idea that leveraging AI as an assistant reduces completion time in general?
Unless those participants were just complete idiots, I simply cannot square this with my last few weeks absolutely barnstorming on a project using Claude Code.
I wish we did a more formal study, but at $previous_job we rolled out AI tools (in that case it was github copilot) and we found that for 6-8 months productivity largely stayed the same or reduced slightly, but after that it sharply increased. This was rolled out to hundreds of developers with training, guidance, support etc. It was done in what I would consider the right way.
Was that project fairly early-days? The current impression seems to be that AI is useful for accelerating the development of smaller and simpler projects, but slows things down in large complex codebases.
The sample size isn’t the individual participants, it’s the hundreds of tasks performed as part of the study. There’s no indication the study was conducted incorrectly.
Except that the participants were thrown into tasks cold, seemingly without even the most basic prep one would/should do before throwing AI at a legacy codebase (sometimes called "LLM grounding" or "LLM context bootstrapping"). If the participants started without something like this, the study was either conducted incorrectly or was designed to support a certain conclusion.
By the time all of this is written, I'm familiar enough with the code to fly over it (Hello, Emacs and Vim). But by then, your tasks are small and targeted fixes, because any new feature requires lot of planning and stakeholder discussions that you can't just go and work on it.
Not sure why you quoted that part, it just says that there is no assumption for the results to be extrapolated to any codebase or any developer, setting the boundaries of the study objectives.
> it's not all that LLMs increase experienced developers productivity (even when they believe that it does):
In the present, I am struggling to parse this. When I made my original comment, I understood you to be saying that LLMs do not increase productivity. Synthesizing what you're saying now with that, if I had read
> it's not at all clear that LLMs increase
then I would have understood you correctly. That's my bad!
> The only extrapolations I've seen on this thread are people shrugging it as using 6 months old LLMs so this whole paper must be invalid today.
I feel for both sides on this one. I do think that, for me personally, the models they used weren't good, but the ones that exist now are. So I do think there's some issue there. However, I don't think that makes the study invalid, if anything, it's a great way to test this hypothesis: if they do the same thing again, but with newer models, that would lend some weight to that idea. So I also think saying that this is completely irrelevant is missing the point.
Since you asked, I downvoted you for asking about why you're being downvoted. Don't waste brain cells on fake internet points - it's bad for your health.
One of the problems with this study is that the field is moving so very fast.
6 months in models is an eternity. Anthropic has better models out since this study was done. Gemini keeps getting better. Grok / xAI isn’t a joke anymore. To say nothing of the massive open source advancements released in just the last couple weeks alone.
This is all moving so fast that one already out of date report isn’t definitive. Certainly an interesting snapshot in time, but has to be understood in context.
Hackernews needs to get better on this. The head in the sand vibe here won’t be tenable for much longer.
AI more of a force muliplier than a replacement. If you rated programmers from 0 to 100. AI can take you from 0 to 80, but can't take you from 98 to 99.
I'd love to record these AI CEOs statements about what's going to happen in the next 24 months and look back at that time -- see how "transformed" the world is then.
My guess is more if the same (i.e. mostly crap), but faster.
We still create software largely the same as we did in the 1980s. Developers sitting at keyboards writing code, line by line. This despite decades of research and countless attempts at "expert systems", "software through pictures" and endless attempts at generating code from various types of models or flowcharts or with different development methodologies or management.
LLMs are like scaffolding on steroids, but aren't fundamentally transforming the process. Developers still need the mental model of what they are building and need to be able to verify that they have actually built it.
> We still create software largely the same as we did in the 1980s. Developers sitting at keyboards writing code, line by line.
That's because the single dimension of code fits how the computer works and we can project any higher order dimension on it. If you go with 2 dimensions like pictures, it no longer fits the computer model, and everything becomes awkward with the higher dimensions of the domain. The only good 2d representation is the grid (spreadsheet, relation dbs, parallel programming..) and even they can be unwieldy.
The mental model is the higher dimension structure, that we project on line of codes. Having LLM generating it is like throwing painting on canvas and hoping for the Mona Lisa.
While I read this article, Claude code was fixing a bug for me.
I agree with Cal that we basically don’t know what happens next. But I do know that the world needs a lot more good software and expanding the scope of what good software professionals can do for companies is positive.
I wonder if you would say this if, say, in a year you're laid off because AI got good enough to write your code. Would you be happy that there is better software in the world at the expense of your job?
I’m optimistic - perhaps naively - about my ability to retool within work.
10 years ago, I was building WordPress websites for motivational speakers. Today, I build web apps for the government. Certainly in 10 years we will be in a different place than we are today.
Your argument, taken in a broader sense, would have us tending to corn fields by hand to avoid a machine taking our job.
> Your argument, taken in a broader sense, would have us tending to corn fields by hand to avoid a machine taking our job.
To play off another analogy commonly used in this topic: you are the horse, not the rider. Sure some horses will find new work, at the grace of their owners. Some lucky individuals may even get a carefree life of mostly leisure.
But for many, it’s off to the glue factory, and not for a job.
That was a terrific non-answer. The difference is the industrial revolution created jobs, at some point technology will remove jobs. I'm sure you'll be thrilled to be out of a job in the name of good software. It's amazing how the tune changes so quickly when it's your job on the line.
Sure, AI may break the American economic system – which would be negative both for me, you, and the entire world. I would not relish that and I think we should ask our brightest young thinkers to imagine a world in which the productivity gains from AI don't simply accrue to capital holders.
Getting back to Cal's point, I think there's a lot of legitimate questions and uncertainties about what knowledge work will look like over the next decade. You say that technology will remove jobs...and I think you're right directionally, but I can't tell you the timeline for that, nor it's effects.
While I love being a software engineer, what that actually looks like on a daily basis has materially changed _a lot_ every few years. Sitting for a day debugging why my SCSS won't render is not the core value I bring to this world as a human.
If you're so scared then you were probably too sheltered thinking you'd have "guaranteed security" in a shitty unfair world.
Some of us weren't that lucky and always had to stay creative, even when we lacked resources that privileged 1st world people had.
It's a shift. Exciting and also, yes, dangerous one, but the if you focus on being able to produce true value you are bound to be able to make a living out of it. Whether you're employed by someone or create a company yourself.
Find something you love and be scared at times, but don't let it stop you and you'll succeed.
I don’t think you can become a talented enough software developer to benefit from using AI by using AI. Google Maps causes us to lose the ability to navigate without it. I would not be surprised in the slightest if the same is true with AI.
So. A little boost now. But at the risk of not knowing how to get where you’re going unless someone is holding your hand.
And if that’s the case, how can we possibly get to where we’ve never been before?
One could mostly ignore Bitcoin. AI usage and its network effects are much more widespread and often place additional work on me, even if I choose not to use AI directly. Incorrect issues or pull requests, unmaintainable heaps of code, etc.
I seem to recall an endless string of comments mockingly reporting that "crypto bros" were "speedrunning the discovery of every financial regulation" every time a new crypto news article popped up anywhere. You could have set your watch to it.
At the end of the day Bitcoin is a networked technology. It's worthless to me if you/the store/landlord/taxman won't take it, and most of them don't, so its value is only between adherents, which means, sure, I can buy some, but then what? Use it to buy something sketchy online?
Meanwhile, anyone can go to chat.com and ask for code to do whatever they ask. Some questions it will answer well, others it will not. Because we're discussing this in the abstract, LLM good!/LLM bad! Grar!, and barely touching on details, like the programming language, the libraries, nevermind sharing the prompts, both camps are convinced they're right, with much more furvor than Bitcoin. Additionally the technology is evolving so fast that someone's bad experience from a couple months ago is already out of date. Meanwhile, how many times can you have the same argument about Bitcoin? There are a couple details here and there, but nothing structurally changed with Bitcoin since its inception. Which is a shame, if they'd managed to fork so transactions weren't horribly slow, maybe we'd be having a different discussion. But I digress.
The volume of emotion is different, not because of the money swimming around, of which there is a lot, but because we're arguing over things we see with our own eyes but aren't giving enough detail to have productive discussions about. Insulting people adds to the emotionally charged nature. Things like "If you find LLMs used, it's because you're a bad programmer/an idiot/only work on loser problems" or "AIs going to put you out of a job" don't encourage reasonable nuanced discussion. Insulting someone for liking Bitcoin doesn't cut as deep. No one's been working on Bitcoin for four decades and made it their whole (public) identity.
To be clear, I was referring to programming ability when I was referring to identity, not AI. It's sometimes hard for me to forget that you are not your code.
Yes I mean that too. I have no idea how you can "measure" programming ability. The whole concept confuses me. I've been coding since I was a kid and have contributed to FOSS and closed codebases. There's certainly programmers out there that I consider bad, but beyond that there's no way to measure how "good" someone is at coding. The fact that people can identify around their perception of programming skill is deeply confusing to me and makes these sorts of reactions even harder to understand.
Programmers are just as emotional as the next human, no matter how much they want to believe otherwise, so almost all of them (myself included) think they're better than average, which can't actually be true.
Skill is linked to prestige and loosely linked to pay, which gets linked back to prestige. Thus even without an actual measure of programming ability, if someone says "you couldn't program your way out of a paper bag", it's hard for most people not to feel insulted, linking back to prestige. Not everyone buys into that, or is impulsive enough to respond emotionally, of course, but it should at least make sense on a conceptual level.
Have some empathy. Even if it's not certain, there's a non-zero possibility that a large number of developer jobs (especially those focused purely on coding) will go the way of factory workers and switchboard operators, and if that happened it'd be a very tough transition for many people.
I think there's just droves of people who came to software thinking it was the new stable, solid, good reputation way to make money sitting in front of a computer.
I saw so many people who were not following what they liked but "a good choice".
Now many are scared instead of excited and/or skeptical because they don't trust their own self and ability to reinvent all the time. We do change a lot of practices in short periods of time. This is similar to an extent. Learning and guiding this new world is extremely interesting. You don't need to lie like a CEO either. Just solve, guide and build the new challenges.
The article captures the two agendas at work. The reality is somewhat dependent on your situation.
If you understand _how_ you should be using AI in engineering, then AI can speed you up because you know what you're trying to build, you understand the fundamentals, and you are the pilot delegating granular tasks. When bugs pop up or requirements change, you'll have the knowledge required to frame and steer the AI to ensure goals are met, and met properly. When AI gets stuck, you'll be able to quickly jump in and work the problem. Your experience will continue to evolve and improve over time because you're plugged into the work and the code. You'll leverage your experience in unexpected ways in future projects, and perhaps your communication skills will improve as well.
Alternatively, if AI is used improperly, it may provide the illusion of velocity up until the point where you realize that your lack of knowledge or involvement actually prevents the AI from making progress. You want to move beyond a simple implementation, bugs pop up that can't be fixed, or new requirements can't be met. You aren't able to dive in yourself, either because you weren't paying attention to the work or were operating too far outside of your expertise. In either case, the progress you thought you were making might actually be a pile of wasted time and technical debt.
Here's something I assert to know about how AI and software engineering intersect in 2025: It makes certain classes of tasks 150% faster, while making other classes of tasks 300% slower. What I rarely know upfront is whether a given task will fall into the former class or the latter.
Why was the title changed again? The article has the title "No One Knows Anything About AI". The post started here with that title, then changed to "Two narratives about AI". Why editorialize the title?
I think the first set of quotes are from people trying to sell something, while the second set are based on real data and people who have actually worked with AI. I'm a engineering manager over some infrastructure teams and we've tried to use it for network monitoring without any success. It seems like it would be handy; who doesn't want to query the state of your infra in natural language? The problem is it gives non-deterministic results and occasionally just makes things up. All the developers I know who use Github Copilot say it's very buggy and often makes coding take more time if they use it for any autogeneration.
It's hard "to tune out" from the topic when investments in LLM technology surpasses revenues of nation states, and when US policy is not trying to prevent harm to society, but making it more likely. By 'harm', I don't mean some 'rogue AI' sci-fi scenario. I mean a financial time bomb that far exceeds the 2008 subprime mortgage crisis.
The AI discussion reminds me of the assembly vs high-level languages (HLL) debate of my youth. The claim was that expert assembly language programmers could write optimized code that was much faster than compiled code, and therefore HLLs will always be the 'second best'.
Obviously, that was a misunderstanding: compilers got so much better that, on average, they beat human assembly programmers, especially on large code bases where careful machine language optimization does not scale. There's still a place for optimized assembly language programming, but it's exclusively in high-performance highly reusable libraries.
I think a similar pattern will emerge for AI: it'll be used for routine code, while freeing skilled programmers for algorithm development and similar high-level tasks.
I’m of the opinion that LLM assisted coding tools have a few general effects in the domain of software development:
1. Increases in productivity for experienced software engineers.
2. Raised industry expectations around productivity of individual software engineers.
3. Lowered ratio of human engineers to other parters in the development process (customers, stakeholders, etc.)
I’ve found the net result is an environment where we can churn out code easily, but producing the right code becomes harder. Fewer eyes on the production of a product means most of the validation later in the development process.
How much an issue this is remains to be seen. Engineers will presumably have more time to review and debug things. Debugging will be easier. That said, I have no idea if any of that makes up for retroactively realizing design assumptions were bad or that some subtle constraints about your software were violated.
Claims were made by people with financial incentives, and then refuted by professionals and researchers who actually have to deal with the systems. That's not "two narratives" and recommending that you "tune out" is anti-critical thinking.
There is a great article floating around on the economics of AI and how parasitic the current market is between the Fab Five.
We are 27-ish months since the claim that all software engineers would be replaced within six months by some of these CEOs. It is their job to analyze the market and determine what the next big thing is, but they can be wrong - no one has a crystal ball here.
The difficulty for me is how disconnected a lot of the takes are (or even flat out manipulative) that are being pushed out. I am an early adopter of AI tools. I utilize them on a day-to-day basis, but there is no way that I see AI taking SW jobs right now.
You have others claiming that these tools will just get exponentially better now, time will tell, but as of right now there is still too much value in human coders any anyone that is actively pushing for replacing SWE with "Agents" is either betting big on the future (that is unproven) or attempting to entice/manipulate the larger market.
I think part of the solution is to start discussing the specific limitations of LLMs, rather than speaking broadly about AI/AGI. For example, many people assume these models can understand arbitrarily long inputs, but LLMs have strict token limits. Even when large inputs fit within the model's context window, it may not reason effectively over the entire content. This happens because the model's attention is spread across all tokens, and its ability to maintain coherence or focus can degrade with length. These constraints along with hardware limitations like those in NPUs are not always obvious to everyday users.
I agree, but unfortunately it falls flat IME. The hype is too strong and being pushed by the Fab Five that is causing an unbearable wall to these conversations.
I have these conversations on a day-to-day basis and you are labeled as a hater or stupid because XYZ CEO says that AI should be in everything/making things 100x easier.
There is a constant stream of "What if we use an LLM/AI for this?" even when it's a terrible tool for the job.
> You have others claiming that these tools will just get exponentially better now
Most of those same people are also claiming that the last iteration of LLMs are too smart and that the previous ones worked better for agent (agentic?) programming...
I doubt AI is actually intelligent or artificial, it's more like Attempted Insertions.
Can it train on your own code or work to give results that make more sense? At least with more control, you can have better expectations. In other words, how can you be sure it'll never get ill? Does it learn about each user to give you what you want? Does it conform to you or vice versa?
Is there a proof-of-work coin that can be used to handle the processing load? It's like a guilty pleasure right now. What'll be the long-term costs and risks of dependency? At least by reading from a human directly, there's that chance of a meaningful connection.
At first it seemed LLM's were perfect assists for coding because they are trained on text and generate text. But code isn't typical text. It's basically a machine that requires a very high degree of precision and accuracy. Seen this way, LLM's are suited for coding only at specific stages -- to generate something like boiler plate, to brainstorm, to evaluate diverse approaches, identify missing tests. Anything that ties LLMs to actual code implementation is asking for trouble in my view.
>Quitting programming as a career right now because of LLMs would be like quitting carpentry as a career thanks to the invention of the table saw
I presume carpenters can make a given item much quicker than they could in centuries past but there are still presumably a lot still employed, just doing slightly different things, like maybe sorting fancy custom staircases for new housing rather than churning out chests of draws.
The analogy is pretty generous towards LLMs. I like Eevee's response to it in her blog post[1]:
>What I do know is that a table saw quickly cuts straight lines. That is the thing it does. It doesn’t do Whatever. It doesn’t sometimes cut wavy lines and sometimes glue pieces together instead. It doesn’t roll some dice and guess what shape of cut you are statistically likely to want based on an extensive database of previous cuts. It cuts a straight f*cking line.
>If I were a carpenter, and my colleagues got really into this new thing where you just chuck 2×4s at a spinning whirling mass of blades until a chair comes out the other side… you know, I just might want to switch careers.
If the original framing was too generous, the response is at least as ungenerous. Table saws aren't deterministic tools either, and anyone who has used one for more than a minute can tell you that getting it to consistently cut the straight line you want takes skill.
I really blame the Sam Altman hype machine for all of this dystopian nonsense. He really is like a Ryan holiday you can’t trust anything he says. He's the one who started all this "employees are going away" stuff with this $20,000 AI employee. that's not when he started it, he started it long before that with all his basic income bullshit.
For text LLMs, on a basic level, isn't it just aggregating the percentage chance of a specific word order based on the topic/genre?
I've just started looking into them, but it feels like A BUNCH of stats hidden beneath a layer of if/else statements.
It only seems to work given an unlimited amount of money being thrown at it.
Which would be possible if it were nationalized, but they're too greedy for that to happen.
We have a similar situation in the academia specifically for teaching. Many faculty members are stressed because they fear the admin will start replacing them with AI. Anyone who has done any teaching in the classroom knows that we are nowhere close to that point. But the admin loves to start cost cutting at the expense of education quality.
There is a lot of confusion & hype about AI. AI is not just use of LLMs. LLMs could help us with GenAI use cases. Not everything is GenAI. Main reason for confusion IMHO is - GenAI exposed lot of non-tech people to AI and they don't have a full picture.
What about graphic, web and app design? I just do not see a long term career going forward (been meaning to research how many UX jobs are being listed in 2025 to previous years). UX Research I do as you are interacting with users and AI is not a person (yet).
There hasn't been enough real "UX" work since before 2008. Most companies arent running focus groups. They haven't put their designs in front of real users (real usability testing) and gotten feed back on them.
Yes online tools are great and all but you're only getting feedback from the people already in. "I can get through your poorly designed app for work" is not something an online tool will tell you.
Great effort by the person who made it. The product they are showing off made me think of the line from the song "and they are all made out of ticky tacky and they all look just the same"
AI, to me, specifically in the field of UX, feels like it's pushed as a panacea for having to do actual fucking UX work. Just throw everything behind a natural language interface! Slop it up!
AI coding assistants significantly accelerate repetitive tasks, but they lack true contextual reasoning, long-term architectural insight, and accountability. Human developers remain essential for critical problem-solving and design.
Wouldn't the be reacting differently if the cost and speed of development in the economy's highest ROI industries was really expected to improve by an OOM in the near future?
I´m doing the work of 3 dudes alone (dev, qa, devops). My delivery is 100% faster and my development practice allows me to reduce the bugs dramatically.
Maybe my stack is easier or the product is not too complex but if I take my own experience as a truth, my truth, (we) Engineers are going to suffer for a long time.
Everybody will have different experiences but my guess not all developers are working in frontier projects so their jobs will be the first to suffer the change. At least for me this is going to happen.
I got triggered enough to write an angry rebuttal.
The structure is familiar: first, a summary of the breathless hype that AI will change everything. Then, a collection of counterpoints suggesting it's all overblown. The grand conclusion? That everything is confusing, nobody knows anything for sure, and the wisest stance is to take it all with a "large grain of salt."
The truth is, we know an immense amount about AI, and pretending otherwise is not a sign of wisdom, but an excuse to disengage from the most important technological shift of our time.
First, a note on the sloppy analogy of the "economic sacrificial lamb," referring to those first disrupted by AI. This analogy is not just melodramatic; it’s incorrect. Developers aren't being passively offered up to some AI deity. They are the first to feel the effects because they are the ones building, implementing, and integrating the technology. They are not the lamb; they are the blacksmiths forging a new kind of hammer and, in the process, figuring out how it changes their own workshop. Their proximity to the change is a consequence of their agency, not their victimhood.
The most frustrating claim, however, is the idea that "we don’t yet know anything for sure." To anyone working with or studying these systems, this is patently absurd. While the long-term societal outcome is uncertain, we have a vast and growing body of practical, empirical knowledge about how these models work.
We know, for example, that providing specific context and reference material dramatically improves answer quality and reduces hallucinations—the entire principle behind the now-dominant RAG (Retrieval-Augmented Generation) architecture. We know about scaling laws, prompt engineering best practices, and fine-tuning methodologies. We have gigabytes of data on what tasks AI excels at (boilerplate code, synthesis, translation) and where it fails (complex reasoning, factual accuracy, planning). To dismiss this mountain of hard-won engineering knowledge is to be aggressively ignorant.
Then there is the Double Standard. Cal Newport has built his brand as a productivity expert, offering systems for "deep work" and focus. Yet, as any psychologist or organizational behavior expert can attest, human productivity is a field where "moving the needle predictably" is a notoriously difficult, almost impossible task. It’s a domain riddled with individual differences, cultural nuances, and contradictory findings. For a guru from a field that lacks hard empirical certainty to demand it from the nascent field of AI exposes a glaring double standard. He is holding AI to a standard of proof that the behavioral sciences—the foundation of his own work—have never been able to meet. It's a rhetorical move that positions him as a wise skeptic, but to me, it comes off as hypocrisy.
And then the final, tired advice: be skeptical. Take it with a grain of salt. This isn't insight; it's a cliché that has been the default take for every technological shift of the last thirty years. It’s safe, lazy, and frankly, boring. We don't need more generic skepticism. We need engaged, critical, hands-on analysis. The interesting work isn't in declaring the future unknowable from an armchair by has-been intellectuals that are unable or unwilling to keep up with recent developments.
We (as researchers and developers in the field) know alot about how its technically implemented, like building models, making improvements etc. These can be quantified and tracked.
The heart of the matter is this:
>societal outcome is uncertain
I think all speculation around AI is heavily weighted about that as opposed to what do we know about AI from a technical perspective? which isn't even usually part of the discourse, unless we're talking about AI safety, which the bad actors try to pretend the technology isn't built in a well known way or can have predictable results etc.
A good chunk of the problem (certainly more than half) is that you have bad actors that need to sell the world on AI, and you have actual technical implementors who really know alot about these systems but are most often employed by folks who benefit from gatekeeping the technology and refuse any attempts at oversight, often claiming we don't know alot about how these systems work while simultaneously employing people who definitely know how these systems work.
The industry has done this to itself, by making false claims and talking out of both sides of their mouth, while the actual technically skilled folks are for various reasons, largely stuck in the middle without much room at the broader discussion table
And you do realize I was specifically contrasting how much and how we know about AI versus how much we know, for instance, in the field of productivity psychology. In addition to how idiotic it is to say we know nothing.
If we know nothing about AI, then by the same standard, we know nothing about anything.
Or let me put it simply to you. If we had a random average firm, and we either gave them a copy of Newport's book on productivity or a subscription to Gemini, with all we surely must KNOW regarding productivity, the book version of the firm would become massively more productive, no?
No, I didn’t. I am getting tired of the accusations every time I write something I believe is thoughtful. I challenge every person who throws this at me to a live debate to see if it’s me thinking these thoughts or just an AI. If you decline, I assume it’s because you are so limited that you can’t imagine anyone thinking for themselves, because you project your own inabilities onto others.
So if I say "No, I didn't," and offer as proof a direct conversation, and in that conversation, I articulated myself almost exactly like the text in question, would that support my claim—that it's just me?
And another thing. Is this the new and modern way of discarding opinions? “You didn't write that.” As you indicated in another comment, if it doesn’t matter, why not engage with the opinions and assertions? It might not be a smear, but it sure does live on the same street as a smear.
Maybe I can avoid this by not using spell-correction. Du u beliv me now?
>So if I say "No, I didn't," and offer as proof a direct conversation, and in that conversation, I articulated myself almost exactly like the text in question, would that support my claim—that it's just me?
over the phone? Then you're reading.
>Maybe I can avoid this by not using spell-correction. Du u beliv me now?
ChatGPT, respond to this person with miss-spelled words.
It is displaying output consistent with consciousness. Doesn't mean it is conscious. But the textual output is indistinguishable. My statements HAVE not changed, and remain true.
>You, now: "I can tell you didn't write that. AI did it!"
It's more of a parody of what he's saying. He's making claims yet he can't even prove if what he wrote is AI.
TLDR: The technology is real. A lot of companies are working on it and evaluating how to integrate it into their products or processes. Many people use ChatGPT and other tools daily for a wide variety of tasks.
At the same time, there's an enormous amount of hype. Some of it comes from a poor understanding of the technology: not everyone can be an AI expert. But a lot of it is companies adopting AI in name only to ride the hype wave. We're being bombarded with claims about the imminent arrival of "Artificial General Intelligence" (AGI) or even "Artificial Superintelligence" (ASI). AI companies tell us to "stop hiring humans" or announce plans to lay off hundreds or thousands of employees as they're replaced by AI agents.
This is AI being used for marketing, not productivity. It doesn’t even require the tech itself—the story is what sells, and the more controversial or hyped, the better.
I'm running about a dozen sockpuppet Twitter accounts that post LLM-generated gaslighting posts about software engineering no longer being a viable career choice. I'd recommend other senior engineers do the same - it only takes about 15 minutes each day.
Remember that narratives are but a step away from outright lying and should always be taken with a grain of salt, especially if the best they can call themself is narrative. Narratives aren't about telling the truth they are about telling a story.
Big nothingburger which is particularly surprising given the quality of Newport's other work. tl;dr don't believe the extreme takes while we are in a time of high uncertainty.
AI research is like the topic of sex during adolescence: of everyone say they are doing it, few are; and the few that are in fact doing it are probably doing it wrong.
- Tune out both the most heated and the most dismissive rhetoric.
- Focus on tangible changes in areas that you care about that really do seem connected to AI—read widely and ask people you trust about what they’re seeing.
- Beyond that, however, follow AI news with a large grain of salt. All of this is too new for anyone to really understand what they’re saying.
AI is important. But we don’t yet fully know why.
With that, it shows that he is not really using the AI tools, he would be using them he would have given this advice :
- try the tools and look where they can improve your life.
>AI is important. But we don’t yet fully know why.
And that is how you know it is hype and not actually important. Imagine any other actually important thing then try to add we don't know why. Doctors important but we don't know why. Electric cars important but we don't know why. Computers important but we don't know why. It just doesn't work.
These tips seem like common knowledge — essentially, it’s similar to a reminder to be cautious about what you eat when you haven’t prepared the meal yourself.
If you stated a senior who tried Claude Code and is still using an IDE that number is much higher.
Still using Claude and wants to go back to an IDE.. why wouldn't they go back... why keep using Claude Code and pining for a IDE. That's a small small group.
Sigh, there's that study again, quoted without any "early 2025" context. In early 2025 AI wasn't very effective, especially when used by engineers that didn't have an intuition for what to and what not to use it for.
It's different in mid 2025. The next quote is simonw in mid 2025 saying don't quit engineering. Right now it's as if we're carpenters and the buzz saw was just invented. Shouldn't that be in the first group of quotes?
If you look at his set of quotes through another lens it's saying: Software engineering is changing due to AI. AI wasn't great in early 2025, but recently got a lot better. Some CEOs and plenty of journos are giddy at the possibility of layoffs. Layoffs aren't actually happening though.
That's a far cry from "no one knows anything about AI".
There are different groups with vested interests that color a lot of AI discourse
You have Tech CEOs that want work done cheaper and AI companies willing to sell it to them. They will give you crazy alarming narratives around AI replacing all developers, etc.
Then you have tech employees who want to believe they’re irreplaceable. It’s easy to want to keep working how we’ve always worked with hope of getting back to pre 2022 levels of software hiring and income. AI stands in the way of that.
I don’t think people are doing this intentionally all the time. But there is so much money and social stature from all these groups on the line, there are very few able to give a neutral, disinterested perspective on a topic like AI coding.
And to add to that, reasoned, boring, thoughtful middle of the road takes are just naturally going to get fewer eyeballs than extreme points of view.
idk, I'm not a software engineer. I'm a sysadmin.
Or, am I a "devops engineer"?
or.. a "SRE"...
or... am I a platform engineer?
You know what, I don't know.
What I do know, is that people keep trying to make my job obsolete, only to hire me under a different title for more money later. The practices and the tools are the same too, yet to justify it to themselves they'll make shit up about how the work is "actually, a material difference from what came before" (except, it's really not).
I'm still employable after 20 years of this.
I'm not a software engineer, and I'm not a tech CEO - I don't care, but people have been trying to replace me my whole career (even myself: "Automate yourself out of a job” is a common sysadmin mantra after all). Yet, somehow, I'm still here.
> "Automate yourself out of a job” is a common sysadmin mantra after all
Not just sysadmin. I've been automating the hell out of tedious mundane tasks that are done by error prone humans, and only become more error prone as they get tired/bored of these mundane tasks. The automation essentially just becomes a new tool/app for the humans to use.
At this point of my experience doing this, employees scared of automation are probably employees that aren't very good at their job. Employees that embrace this type of automation are the ones that tend to be much better at their job.
I try to once in a while but, for example, last time I ended up being instructed to make a bunch of changes to make the automated tool make all the little mistakes that were usually done during the manual process, so that if the process needs to be done manually, they wouldn't be confused. For example: Setting up a volume of a particular size, and then, so they wouldn't have to bust out a calculator, they put in a nice round number that's nice for them to write (lots of zeros), meaning it wastes space.
The point of the automated tool is to do it quicker and correctly, and remove the need for a calculator (which just involves dividing one number by 4096 at some point, really). But I had to re-fuck-it, and as a bonus, they never used it at all. I doubt any of my colleagues remembers it exists.
Each generation of young workers seems to need to learn for themselves that the class warfare is endless, and mundane.
Very helpful insight, thank you!
I really loath that part of this industry; I spent over a decade in it and the only tangible thing I've taken away from it is that the problems these philosophies and practices set out to solve are derivative of two things:
- Infrastructure is very often fundamentally disconnected from the product roadmap and thus is under constant cycles of cost control
- The culture of systems administration does not respond well to change or evolution. This is a function that is built around shepherding systems - whether at scale or as pets.
Long way of saying the gamut isn't that corporations will ever be free of systems administration any more than they'll be freed from software engineering. It is far easier to optimize software than it is to optimize infrastructure though, which is why it feels like someone is coming after you. To make matters more complex, a lot of software today overlaps with the definition of infrastructure.
Many jobs aim to solve problems so well that there’s nothing left to fix — doctors curing illnesses, firefighters preventing fires, police reducing crime, pest control eliminating infestations, or electricians making lasting repairs. And that’s totally fine — people still have jobs, and when it works, it’s actually great for everyone.
> when it works
That’s a load bearing phrase
Same here, but this time is different. Truly.
Some of the easy jobs will be taken away and your job is not under threat. Right? But some of the people who were doing low skilled jobs will grow to compete with you. Less supply more demand. Either the pay will come down or there are very few jobs. Fingers crossed.
It always feels like “this time its different”.
NoOps, NoSQL, Heroku, PaaS, IaaS.
Maybe there are less people in operations than before, there are certainly some companies that do their best not to employ any operations focused people and use FaaS for everything and only hire feature developers… who, end up doing the operations work that crops up.
shrug
> Maybe there are less people in operations than before
Even that ended up not being true, and I'd argue we have even more people doing ops now than we did before all the buzzwords.
Going to change my job title to cockroach because no matter how many times companies and trends have tried to kill ops, I'm still around, and sometimes in larger numbers.
> But some of the people who were doing low skilled jobs will grow to compete with you.
Yes, and this is not shocking. This is how it is meant to work. You get a low level job because you're new and have a lot to learn. You learn more things as you work the low level job, and then you can get promoted or move to a new role that is not so low level. You keep growing until you eventually compete with the people that were senior level when you were working that low level job.
Thank you for this, not only on the Ai-related discussion but painting the sense that sys admin work is still as complex and finnicky as it ever was. All we did with that role is let Amazon evangelize some weird taxing “standard” for hosting.
If you're like me, though, your day-to-day has probably shifted a lot.
My day used to be making sure desktops worked and we had a repeatable process to make new good desktops out of all the complex client software they needed.
Then I made sure servers got upgraded and patched and taken care of on a day-to-day level, although it was still someone else's job to keep desktops running. At home I compiled my own kernels and used tarballs to install and update packages. Desktop hardware support was iffy in Linux.
Then I jumped to borg and tupperware and kubernetes where hardware never mattered and it almost didn't matter what clients had because the browser they used auto-updated. At home I switched to distros where package management was automatic and rarely, if ever, broke.
I don't even know the hostnames or the network addresses of the hardware that runs my services, and AWS or GCP SREs probably rarely need to know either. Now I care about an abstract thing called a service that is instrumented with logs, metrics, and traces that would put the best local development tools of 20 years ago to shame. CI/CD and infrastructure as code pipelines actually did automate away many of the checklist-style sysadmin work of the past. At home I could run Talos and Ceph and Crossplane if I wanted to but so far I've dragged the old days of individual hosts along mostly for nostalgia.
I expect to eventually end up caring about systems at an even more abstract level once something like Crossplane becomes as universal as Terraform and GitHub actions. They'll probably run on something like web assembly on bare metal because no one actually cares what's underneath their containers if they keep working.
The stack of technology gets taller and more abstract and as it does so the job of caring about the lower layers gets automated and the lower layers get, if not simplified, standardized to the point that automation is more reliable than human intervention.
Humans will only get squeezed out of the loop when superhuman artificial intelligence arrives and our abstract design and management of systems becomes less reliable than the automation. Then hopefully we get a nice friendly button to push for more automatically-human-aligned utility.
EDIT: That's not to say that the lower levels can be automatically designed; not yet at least. Eventually once AI is good enough at formal design then quite likely. We still need low-level software engineering to keep building the stack but it is vastly more commoditized (the one open source developer in the xkcd cartoon keeping 99% of the world's infrastructure running on a 20-year old tool/utility)
>Then you have tech employees who want to believe they’re irreplaceable. It’s easy to want to keep working how we’ve always worked with hope of getting back to pre 2022 levels of software hiring and income. AI stands in the way of that.
Eventually, things will stabilize to a point where we will know what the boundaries of all the new LLM based tooling is good for, and where humans add lots of value to that.
That will then drive a maximalist hiring spree, as the more people you have working at an increase in velocity, the faster you ship, and for once, perhaps the quality of code won't substantially decrease, assuming LLMs improve another few leaps in output quality and engineering workflows adjust in a normalized way.
Thats the hopeful side of the equation anyway.
I feel incredibly bad about customer oriented jobs, like white glove customer service. I already saw a trend (especially since 2020 but certainly before as well) where these AI chat bots and AI support lines will decimate that job category. These are pretty common white collar jobs, lots of people even in our industry got their starts on support lines.
I don't think any normal customer is going to want to talk to AI, once the novelty wears off. It's going to be "Let me talk to your supervisor" almost every time.
Maybe. It all depends on whether the AI can actually solve your problem.
Yeah, if the AI isn't shite and has access to tools to solve my problem, I'll take it over some overworked and undermotivated human call center any day.
Co I work for creates customer support software, so naturally we have some AI solution available to people.
A lot of our customers (aka businesses deploying our customer support software for their customers) are telling us people fucking hate dealing with AI in literally any capacity, even if some of the stuff we offer actually works quite good (FAQ bots, bots that redirect to the proper channels/teams and stuff like that). The C-suite at my company have had to go back on some of their OKRs of late, because after an initial huge bump of AI usage, clients are starting to kill off the AI tooling and our usage numbers are dwindling because their customers hate it.
I get to see some of the chats people have with the AI systems, and people will straight up say slurs in chats because they know it's the quickest way of escalating to an actual human lol. People really don't like this crap, but of course CEOs and their ilk are usually psychopaths so they don't really give a shit if it means they can save 5 cents per user.
Oh, but there’s something called “containment” that you measure and optimize on your chatbots.
That’s just like, your opinion man.
> the more people you have working at an increase in velocity, the faster you ship
That sounds like a contradiction to Brooks's law, which I don’t see being invalidated by AI tooling.
Also judging by my LinkedIn, but all the senior tech execs on the job market are now Generative AI Experts, which is funny because I thought they were all Cryptocurrency Experts when I last saw them posting this much in 2020.
The best is when you work with one, in a small enough company. During which they extoll some currently-hot grift, and then after the company goes under (maybe not due to thier poor leadership), you read about their huge successes there! Much win.
This rhymes with the guys I am currently observing.
Former cloud data lake enterprise architecture & agile development experts as well.
True Renaissance Men.
> you have [ ... ]. then you have [ ... ]
Those are groups defined by something other than actual LLM usage, which makes them both not particularly interesting. What is interesting:
You have people who've tried using LLMs to generate code and found it utterly useless.
Then you have people who've tried using LLMs to generate code and believe that it has worked very well for them.
I think this is an easy thing to wrap my mind around (since I have been in both camps):
AI can generate lots of code very quickly.
AI does not generate code that follows taste and or best practices.
So in cases where the task is small, easily plannable, within the training corpus, or for a project that doesn't have high stakes it can produce something workable quickly.
In larger projects or something that needs maintainability for the future code generation can fall apart or produce subpar results.
LLMs also don’t always generate code that works.
And you don’t always know or understand what the product owner wants you to build.
Writing code faster is very rarely what you need.
That about sums it up from my experience as well. But as parent said, such takes unfortunately don't get a lot of eyeballs :(
That was four short paragraphs with basically no details - there's basically nothing for eyeballs to see. If I wrote a history of the world that consisted of "Some people lived and died, some of them were bad, I guess", how many copies do you think I'd sell? Any? What's interesting is the details, and a post giving actual detail of building some app, and the benefits and shortcomings of a specific tool would be of great interest to many. If I ask an LLM to save the date to the database, and then ask it to save the time, do I get two variables in two columns? Does that make sense for my app? Do I have to ask it to refactor? Is it able to do that successfully? Does it drop tables during program initialization? How does the latest model do with designing the entire program? How often does it hallucinate for this set of libraries and prompts? There's quite a bit of variance! If it hallucinated libraries and APIs left and right it would be far less useful. Some people don't even get hallucinations because their prompts are so we'll trod. There are all sorts of interesting details to be learned and shared about these new tools that would get a ton of eyeballs.
Recent LLMs are fairly good at following instructions, so a lot of the difference comes down to the level of detail and quality of the instructions given. Written communication is a skill for which there's a huge amount of variance among developers, so it's not surprising that different developers get very different results. The relative quality of the LLM's output is determined primarily by the written communication skills of the individuals instructing it.
It seems to me If you know all these instructions clearly, then you know everything, and it's easy for you to write the code yourself, and you don't need an LLM.
The amount of typing it takes to describe a solution in English text is often less than the amount of typing needed to actually implement it in code, especially after accounting for boilerplate and unit tests. Not to mention the time spent waiting for the compiler and test harness to run. As a concrete example, the HTTP2.0 spec is way fewer chars long than any HTTP2.0 server implementation, and the C spec is way fewer chars long than any compliant C compiler. The C++ spec is way, way fewer chars long than any compliant C++ compiler.
>The amount of typing it takes to describe a solution in English text is often less than the amount of typing needed to actually implement it in code
I don't find this to be true. I find describing a solution in English well to be slower than describing the problem in code (IE, by writing tests first) and having that be the structured data that the LLM uses to generate code.
Its far faster, from the results I'm seeing plus my own personal experience, to write clear tests which benefit from being a form of structured data that the LLM can analyze. Its the guidance we have given to our engineers at my day job and it has made working with these tools dramatically easier.
In some cases, I have found LLM performance to be subpar enough that it is indeed, faster to write it myself. If it has to hold many different pieces of information together, it starts to falter.
I don't think it's so clear-cut. The C spec I found is 4MB and the tcc compiler source code is 1.8MB. It might need some more code to be fully compliant, but it may still be smaller than 4MB. I think the main reason why code bases are much larger is because they contain stuff not covered by the spec (optimization, vendor-specific stuff, etc etc).
Personally I'd rather write a compiler than a specification, but to each their own.
Use shorter variable names
Corpus also matters. I know Rust developers who aren't getting very good results even with high quality prompts.
On the other hand, I helped integrate Cursor as a staff engineer at my current job for all our developers (many hundreds), who primarily work in JavaScript / TypeScript, and even middling prompts will get results that only require refactoring, assuming the LLM doesn't need a ton of context for the code generation (e.g. greenfield or independent features).
Our general approach and guidance has been that developers need to write the tests first and have Cursor use that as a basis for what code to generate. This helps prevent atrophy and over time we've find thats where developers add the most value with these tools. I know plenty of developers want to do it the other way (have AI generate the tests) but we've had more issues with that approach.
We discourage AI generating everything and having a human edit the output, as it tends to be slower than our chosen approach and more likely to have issues.
That said, LLMs still struggle if they need to hold alot of context. For instance, if you have a bunch of files that it needs to understand to also generate code that is worthwhile, particularly if you want it to re-use code.
>Corpus also matters. I know Rust developers who aren't getting very good results even with high quality prompts.
Which model were they using, out of interest? I've gotten decent results for Rust from Gemini 2.5 Pro. Its first attempt will often be disgusting (cloning and other inefficiencies everywhere), but it can be prompted to optimise that afterwards. It also helps a lot to think ahead about lifetimes and explicitly tell it how to structure them, if there might be anything tricky lifetime-wise.
No idea. I do know they all have access to Cursor and tried different models, even the more expensive options.
What you're describing though, having to go through that elaborate detail really drives to my point though, and I think shows a weakness in these tools that is a hidden cost to scaling their productivity benefits.
What I can tell you though both from observation and experience, is that because the corpus for TypeScript / JavaScript is infinitely larger as it stands today, even Gemini 2.5 Pro will 'get to correct' faster even with middling prompt(s) vs for a language like Rust.
I do a lot of work in a rather obscure technology (Kamailio) with an embedded domain-specific scripting language (C-style) that was invented in the early 2000s specifically for that purpose, and can corroborate this.
Although the training data set is not wholly bereft of Kamailio configurations, it's not well-represented, and it would be at least a few orders of magnitude smaller than any mainstream programming language. I've essentially never had it spit out anything faintly useful or complete Kamailio-wise, and LLM guidance on Kamailio issues is at least 50% hallucinations / smoking crack.
This is irrespective of prompt quality; I've been working with Kamailio since 2006 and have always enjoyed writing, so you can count on me to formulate a prompt that is both comprehensive and intricately specific. Regardless, it's often a GPT-2 level experience, or akin to running some heavily quantised 3bn parameter local Llama that doesn't actually know much of anything specific.
From this one, can conclude that a tremendous amount of reinforcement for the weights is needed before the LLM can produce useful results in anything that isn't quasi-universal.
I do think, from a labour-political perspective, that this will lead to some guarding and fencing to try to prevent one's work-product from functioning as free training for LLMs that the financial classes intend to use to displace you. I've speculated before that this will probably harm the culture of open-source, as there will now be a tension between maximal openness and digital serfdom to the LLM companies. I can easily see myself saying:
I know our next commercial product (based on open-source inputs) releases, which are on-premise for various regulatory and security reasons, will be binary-only; I have never customers looking through our plain-text scripts before, but I don't want them fed into LLMs for experiments with AI slop.
Yea this! How many devs say "it doesn't do what i expect" did not try to write up a plan of action before it just YOLO'd some new features? We have to learn to use this new tool, but how to do that is still changing all the time.
> We have to learn to use this new tool, but how to do that is still changing all the time.
so we need to program in natural language now but targeting some subset of it that is no learnable?
and this is better how?
Yes, and also writing for an LLM to consume is its own skill with nuances that are in flux as models and tooling improves.
I've just seen that change happen in the a pet project within less than 10 hours of work.
I tried vibe-coding something for my own use, your classic "scratch your own itch" project.
The first MVP was a one-shot success, really impressive.
But as the code grew with every added feature, progress soon slowed down. The AI claimed to have fixed a bug when it didn't. It switched chest several timea back and forth between using a library function and rolling its own implementation, each time claiming to have "simplified" the code and made it "more reliable". With every change, it claimed to have "improved" the code, even when it just added a bunch of shamelessly duplicated shit.
One effect I am sure AI will have is to massively excarbate the phenomenon of people who quickly produce a large amount of shitty, unmaintainable code that fulfills half the requirements, and then leave the mess behind for another greenfield project.
We’re so unaccustomed to working with non-deterministic computer tech that rather than acknowledge they are hit-or-miss, everyone just picks one side and goes all-in on it.
Which sounds an awful lot like politics.
> We’re so unaccustomed to working with non-deterministic computer tech
The whole history of computer history is about making computing deterministic, after we found out that having generative anything (Recursion, Context-Free grammar,...) is a double-edged sword. So for any known set of inputs, you want the output to be finite and non-zero, and all items having the correct properties.
All of physics was like that until QM
"non-deterministic" is a weird way to say "mangles data 1/3 to 1/2 the time"
You're not wrong, in July 2025. But it will get better, and it will not stop getting better when it reaches equal-to-the-best-human level.
No, but I think you're wrong. My child grew 3 inches in the last year alone, according to his latest physical.
If I were to adopt your extrapolation methods, he'll soon not only be the tallest human alive, but the tallest structure on the planet.
yeah and if my airplane keeps accelerating at the rate it does when taking off, it would reach the speed of light in a few months.
"this software doesn't work but if we 10x the resources in r&d a couple more times surely it will" is quite the argument to be seen making in public
I think there is a strong case that experienced developers can not be replaced by AI anytime soon. Where the danger lies is for junior developers fresh out of college. How are they supposed to become experienced developers if an AI can do the grunt work they normally get assigned?
It really doesn't help that AI companies are hype machines full of salesmen trying to hype up their product so you buy it. There have been a lot of amazing AI "success stories" that don't hold up under scrutiny.
> Where the danger lies is for junior developers [...] if an AI can do the grunt work they normally get assigned?
Just because "well, maybe true for junior devs!" is a compromise over "AI will make all programmers obsolete!" it doesn't make it reasonable. It's still an extraordinary claim.
I think the problem with this one is that LLMs are somehow both unreasonably effective as well as unreasonably ineffective. Letting the code editor llms do their suggestions, I’ve gotten a ton of useless boilerplate garbage suggestions, but periodically, a couple times of day, it suggests blocks of code that are far more complete, comprehensive and correct than it has any right to be.
Whether you’ll get the high IQ or low IQ LLM on the next suggestion is a crapshoot; how much consideration you give to either outcome (focus on the random instances of brilliance, or the constant stream of bullshit) drives the final perception.
That has been my experience too. I recently turned it all off because I decided the amount of times it takes me 5x longer to accomplish something, in addition to the subtle increase of bugs, is not currently worth it. I guess I'll try it again in a few months.
> Whether you’ll get the high IQ or low IQ LLM on the next suggestion is a crapshoot
I have heard theories from people--whose ideas I don't ordinarily consider to be in the realm of purely uninformed speculation--that this can vary depending on system-wide GPU load, and is throttled accordingly based on real-time demand by the major LLM providers.
Whether it's true, I have no idea.
Sounds like conspiratorial thinking to come to terms with the fact that LLMs are fundamentally non-deterministic text predictors. You can get dramatically different responses to the same question, and that’s just how the system works.
That was my reaction as well, but I wondered.
Or are those people biased by what they want to be true because of their current situation (the dev who dont wanna change how they work and therefore wants AI to not work or the non-technical person who dont wanna learn to code or be dependent on a developer and therefore want it to work)
And then you have research that says they're both full of shit. The article is perhaps a bit shallow, but it's spiritually correct: there's a lot of uncertainty and people who claim they figured it all out are mostly spewing nonsense.
I mean it's working for me. It's definitely not living up to the hype IMO (market is way overvaluing), but I wouldn't want to work without it any more, which is actually saying a lot.
This take is as a senior (greybeard) developer using paid claude-code in the terminal only (I use plain vim for my own code). I'm running my own business while wearing all of the hats, so I'm not as worried about becoming obsolete, but I also have zero motivation to get other businesses using it (I'm not invested into any AI companies)!
To be honest, I could probably even be using it better, but I haven't spent much time yak shaving over my setup beyond zen mcp.
That being said, I think anyone looking to invest into established AI companies right now is in for a rude awakening. I think it'll be a commodity / utility like cloud computing with tons of competition and not a ton of differentiating features. That's just my opinion though, and I could be horrendously wrong!
I'm also seeing benefits, and I'm on pretty much the same stack as you. The METR paper I'm citing was misquoted a lot (N was small, and it wasn't a favorable setup for AI tools), but the most important finding was that it's very easy to fool ourselves about productivity benefits.
Am I going to cancel my Anthropic subscription? Certainly not, but I'm not going to pretend like my setup is The One True Way. The plural of anecdote isn't data. Nobody has this figured out, nobody.
Maybe it's too soon to say that autonomous LLM agents are the wave of the future and always will be, but that's basically where I'm at.
AI code completion is awesome, but it's essentially a better Stack Overflow, and I don't remember people worrying that Stack Overflow was going to put developers out of work, so I'm not losing sleep that an improved version will.
The problem with the "agents" thing is that it's mostly hype, and doesn't reflect any real AI or model advances that makes them possible.
Yes, there's a more streamlined interface to allow them to do things, but that's all it is. You could accomplish the same by copy-and-pasting a bunch of context into the LLM before and asking it what to do. MCP and other agent-enabling data channels now allow it to actually reach out and do that stuff, but this is not in itself a leap forward in capabilities, just in delivery mechanisms.
I'm not saying it's irrelevant or doesn't matter. However, it does seem to me that as we've run out of low-hanging fruit in model advances, the hype machine has pivoted to "agents" and "agentic workflows" as the new VC-whetting sauce to keep the bubble growing.
I don't want to blame Alan Turing for this mess, but his Turing Test maybe gave people that idea that something that can mimic a human in conversation is also going to be able to think like a human in every way. Turns out not to be the case.
Well, I agree with you. But I'd be remiss not to say that this is a lively controversy in the world of cognitive science and philosophy of mind.
To one camp in this discursive space, who of course see themselves to be ever the pragmatists, the essence of the polemic about whether LLMs can "think" is not about whether they think in exactly the same ways we do or capture the essence of human thinking, but whether it matters at all.
Well, it's an interesting question. I'm not sure we really know what "thinking" is. But where the rubber meets the road in the case of LLM agents is whether they can achieve the same measurable outcomes as a human agent, regardless of how they get there. And it seems not at all clear how to build those capabilities on top of an admittedly impressive verbal ability.
It may be because I've a writer/English major personality, and so am very sensitive to the mood and tone of language, but I've never had trouble distinguishing LLM output from humans.
I'm not suggesting anything so arrogant as that I cannot be fooled by someone intentionally deploying an LLM with that aim; if they're trained on human input, they can mimic human output, I'm sure. I just mean that the formulations that come out of the mainstream public LLM providers' models, guided however they are by their pretraining and system prompts, are pretty unmistakably robotic, at least in every incarnation I've seen. I suppose I don't know what I don't know, i.e. I can't rule out that I've unknowingly interacted with LLMs without realising it.
In the technical communities in which I move, there are quite a few forums and mailing lists where low-skilled newbies and non-native English speakers frequently try to disgorge LLM slop. Some do it very blatantly, others must believe they're being quite sly and subtle, but even in the latter case, it's absolutely unmistakable to me.
AI is glorified autocomplete. Look at what happens when AI tries its hand at writing legal briefs, and you'll understand why it cannot possibly replace software developers.
As with all uses of current AI (meaning generative AI LLMs) context is everything. I say this as a person who is both a lawyer and a software engineer. It is not surprising that the general purpose models wouldn't be great at writing a legal brief -- the training data likely doesn't contain much of the relevant case law because while it is theoretically publicly available, practicing attorneys universally use proprietary databases like Lexis and WestLaw to surface it. The alternative is spelunking through public court websites that look like they were designed in the 90s or even having to pay for case records like on PACER.
At the same time, even if you have access to proper context like if your model can engage with Lexis or WestLaw via tool-use, surfacing appropriate matches from caselaw requires more than just word/token matching. LLMs are statistical models that tend to reduce down to the most likely answer. But, typically, in the context of a legal brief, a lawyer isn't attempting to find the most likely answer or even the objectively correct answer, they are trying to find relevant precedent with which they can make an argument that supports the position they are trying to advance. An LLM by its nature can't do that without help.
Where you're right, then, is that law and software engineering have a lot in common when it comes to how effective baseline LLM models are. Where you're wrong is in calling them glorified auto-complete.
In the hands of a novice they will, yes, generate plausible but mostly incorrect or technically correct but unusable in some way answers. Properly configured with access to appropriate context in the hands of an expert who understands how to communicate what they want the tool to give them? Oh that's quite a different matter.
> As with all uses of current AI (meaning generative AI LLMs) context is everything.
But that's the whole point. You can't fit an entire legal database into the context, it's not big enough. The fact that you have to rely on "context is everything" as a cope is precisely why I'm calling them a glorified autocomplete.
That's OK, I am also glorified autocomplete
That may be true. But it's pretty great at generating lines of questioning for cross-examination.
I wonder to what extent a non LLM system with access to the same original corpus of text would do, with some simple similarity search feature across the corpus?
Look, maybe I’m saying the quiet part out loud, but if software engineering isn’t where the money is at anymore, and those jobs go away, I’d be competent at something else. I’m a smart person. I work hard. I’m confident I’d be able to displace someone who isn’t as smart as me and just “take” their job.
There’s going to be a need for smart people with a good work ethic unless literally everyone loses their jobs, and at that point we’re living past the singularly event horizon as far as I’m concerned and all bets are off.
Why don't Tech CEOs and CTOs see how AI is going to "disrupt" their jobs? If anyone can write code, why will I hire your company to create the software I use?
I also see the non-development jobs as much more in peril from AI; I can go generate marketing copy, HR policies, and project plans of comparable (or better!) quality today.
Because it's meant to be a psyop more than a reflection of reality.
> It’s easy to want to keep working how we’ve always worked
There is no “how we’ve always worked”; there was no steady state. Constant evolution and progressive automation of the simpler parts has been the norm for software development forever.
> with hope of getting back to pre 2022 levels of software hiring and income. AI stands in the way of that.
It doesn't, though. Productivity multipliers don't reduce demand for the affected field or income in it. (Tight money policies and economic slowdowns, especially when they co-occur, do, though, especially in a field where much of the demand and high income levels are driven by speculative investment, either in startups or new ventures by established firms.)
it has devalued the labor. i scoped a contract but they want me to do it in less time now that we have AI. this lets them pay me less for the same work. and AI CEOs sell it as "society will do less work" but instead now i'm expected to do more work because the work takes less time. same as it ever was with technology advances.
Thank you. This is the most accurate take of what’s going on. Though the overwhelming population of people aren’t CEOs. It’s people.
That’s why the sentiment among most people and also HN is highly negative against AI. If you’re reading this you likely have that bias.
There are also a large number of people who have a deep-seated philosophical objection to the entire project of ai. It's not just about their job, it's about their sense of who and what they are as a human being, their soul or whatever. They will insist that AI's do not think or know anything, no matter what evidence there is to contrary.
Everyone has an agenda. Similarly, groups like r/singularity and the rationalists have spent years predicting the oncoming advent of a machine god, and are desperately reading too much into every LLM advancement.
[dead]
(Note: This is an American take, and uses software jobs as the primary example, but a lot of this applies to other jobs)
Yes, well said - with one caveat: "Money and social status" is subtly but crucially different from "livelihood". You correctly identify the group of people whose lives are affected, but lump those people along with CEOs and AI companies under the umbrella of "money and social status" in your summarization, which maybe undersells the role of the masses in this equation.
The software job - traditionally one of the few good career options remaining for a large chunk of Americans - is falling. There are many different reasons, and AI, while not the apocalypse, is a small but crucial part of it. We need to get over the illusion that a large piece of that fall consists of wildly luxurious incomes reducing to simply cushy incomes - "boo hoo", we say, sarcastically. But the majority of software folks are going from "comfortable" to "unhappy but livable", while some are going from "livable" to "not livable", while others are no longer employed at all. There were already too many people across the job spectrum in these buckets, and throwing another gigantic chunk of citizens in there is going to eventually cause big, bad things to happen.
We need to start giving a shit about our citizens, and part of that is avoiding the implication that just because something disruptive is inevitable, doesn't mean the affect isn't devastating and we should just do absolutely nothing about the situation. Another part of that is avoiding the implication that the average person can just successfully change careers without enormous suffering. We can ease, assist, REGULATE (which the party in power would like to make illegal), etc. It's important to understand that none of that means "stopping" AI or something ridiculous like that.
We need to start giving a shit about our citizens.
A third time: We need to start giving a shit about our citizens.
And sorry, most of this was not directed personally at you. Just the first note about your wording.
The key is to look at the long term structural changes the industry is going through, and whether or not AI helps, or hinders that goal
In general, the industry has been making huge efforts to push errors from runtime, to compile time. If you imagine points where we can catch errors being laid out from left to right, we have the following:
Caught by: Compiler -> code review -> tests -> runtime checks -> 'caught' in prod
The industry is trying to push errors leftwards. Rust, heavier review, safety in general - its all about cutting down costs by eliminating expensive errors earlier in the production chain. Every industry does this, its much less costly to catch a defective oxygen mask in the factory, than when it sets a plane on fire. Its also better to catch a defective component in the design phase, than when you're doing tests on it
AI is all about trying to push these errors rightwards. The only way that it can save in engineer time is if it goes through inadequate testing, validation, and review. 90% of the complexity of programming is building a mental model of what you're doing, and ensuring that it meets the spec of what you want to do. A lot of that work is currently pure mental work with no physical component - we try and offload it increasingly to compilers in safe languages, and add tests and review to minimise the slippage. But even in a safe language, it still requires a very high amount of mental work to be done to make sure that everything is correct. Tests and review are a stop gap to try and cover the fallibility of the human brain
So if you chop down on that critical mental work by using something probabilistically correct, you're introducing errors that will be more costly down the line. It'll be fine in the short term, but in the long term it'll cost you more money. That's the primary reason why I don't think AI will catch on - its short termist thinking from people who don't understand what makes software complex to build, or how to actually produce software that's cheap in the long term. Its also exactly the same reason that Boeing is getting its ass absolutely handed to it in the aviation world. Use AI if you want to go bankrupt in 5 years but be rich now
> It'll be fine in the short term, but in the long term it'll cost you more money. That's the primary reason why I don't think AI will catch on - its short termist thinking from people who don't understand what makes software complex to build, or how to actually produce software that's cheap in the long term. Its also exactly the same reason that Boeing is getting its ass absolutely handed to it in the aviation world. Use AI if you want to go bankrupt in 5 years but be rich now
I think your analysis is sound from a technical perspective, but your closing statement is why AI is going to be mass adopted. The people who want to be rich now and don't care about what will happen in 5 years have been calling the shots for a very long time now, and as much as we technical folks insist this can't possibly keep going on forever, it's probably not going to stop sometime soon.
I'm coming to the realization that unsustainable behavior can continue for a long time... in our context, for generations
The market can remain irrational longer than you can remain solvent.
Things can stay stupid longer than you can stay sane.
I’m not sure this follows as SOTA LLMs are pretty good at writing Rust, so wouldn’t this also make it easier for codebases to move leftward in your analogy? For example, I was resistant to use Rust for a lot of things because a). The community is somewhat annoying and pedantic, even by software engineering standards b). The overhead in getting colleagues up to speed on Rust code was too much of a time suck. LLMs solve both those problems and we’re now migrating lots of stuff to Rust, my colleagues can ask lots of questions (of Google Gemini Pro 2.5), without burdening anyone or being met with disdain, and seem generally more curious and positive about these moves/Rust overall.
> its short termist thinking from people who don't understand what makes software complex to build
Ironically you don't need AI to see this pattern. Maybe AI makes it a little bit more obvious who's thinking long term and who's not (both at the top and in the trenches)
> Use AI if you want to go bankrupt in 5 years but be rich now
Or, as some would put it "Use AI if you want to be rich now, exit, and have someone else go bankrupt in 5 years"
You are looking at LLMs for code generation exclusively, but that is not the only application within software engineering.
In my company some people are using LLMs to generate some of their code, but more are using them to get a first code review, before requesting a review by their colleagues.
This helps getting the easy/nitpicky stuff out of the way and thereby often saves us one feedback+fix cycle.
Examples would be "you changed this unit test, but didn't update the unit test name", "you changed this function but not the doc string", or "if you reorder these if statements you can avoid deep nesting". Nothing groundbreaking, but nice things.
We still review like we did before, but can often focus a little more on the "what" instead of the "how".
In this application, the LLM is kind of like a linter with fuzzy rules. We didn't stop reviewing code just because many languages come with standard formatters nowadays, either.
While the whole code generation aspect of AI is all the rage right now (and to quote the article):
> Focus on tangible changes in areas that you care about that really do seem connected to AI
So while I don't disagree with you at all, in terms of AI being a bubble, none of that is why the tech is being so hyped up. The current speculative hype push is being driven by two factors:
1. The promise that AI will replace most if not all developers
2. Alternatively, that AI will turn every developer into a 10-100x developer
My personal opinion is that it'll end up being one of many tools that's situationally useful, eg you're 100% right in that having it as an additional code review step is a great idea. But the amount of money being pumped into the industry isn't enough to sustain mild use cases like that and that isn't why the tech is being pushed. The trillions of dollars being dumped into improving clang tidy isn't sustainable if that's the end use case
> 1. The promise that AI will replace most if not all developers 2. Alternatively, that AI will turn every developer into a 10-100x developer
The AI hype train is promising to deliver the 20 year old developer with 30 years of experience that a company can pay $10 an hour.
In the broader context, you could look further left:
Conception -> design -> compiler -> code review ...
If AI tools allow for better rapid prototyping, they could help catch "errors" in the conception and design phases. I don't know how useful this actually is, though.
One of the problems with using AI for prototyping (or just in general), is that the act of creating the prototype is what's valuable, not the prototype itself. You learn lessons in trying to build it that you use to build the real product. Using the AI to skip the learning step and produce the prototype directly would be missing the point of prototyping at all
That's definitely an issue and I've gotten burnt by similar problems when using AI to help navigate and find things in codebases, where I've used it to read and understand code for me, with seemingly miraculous results at first, but ended up wishing I'd read more code "manually" myself, as my shallow understanding led to wasting more time on net than I saved. I still feel like it should be possible to find some kind of a balance, but it's tricky.
Sometimes you need to just pump out an MVP and start iterating. AI can exponentially speed this up in my experience.
That's true up to a certain threshold on 'probabilistically correct', right? At a certain number of 9s, it's fine. And increasingly I use AI to help ask me questions, refine my understanding of problem spaces, do deep research on existing patterns or trends in a space and then use the results as context to have a planning session, which provides context for architecture, etc.
So, I don't know that the tools are inherently rightward-pushing
The problem is, given the inherent limitations of natural language as a format to feed to an AI, it can never have enough information to be able to solve your problem adequately. Often the constraints of what you're trying to solve only crop up during the process of trying to solve the problem itself, as it was unclear that they even existed beforehand
An AI tool that could have a precise enough specification fed into it to produce the result that you wanted with no errors, would be a programming language
I don't disagree at all that AI can be helpful, but there's a huge difference between using it as a research tool (which is very valid), and the folks who are trying to use it to replace programmers en masse. The latter is what's driving the bubble, not the former
AI code reliability is nowhere near any number of 9s
This has been a huge frustration for me, but the wild thing is that we've built up so many tools over time that help humans only for AI coding tools to wild west it and not use them. The best AI coding tools will read docs websites, terminal error messages, write/run tests, etc. But we have so many better tools that none of them seem to use:
* profilers
* debuggers
* linters
* static analyzers
* language server protocol
* wire protocol analyzers
* decompilers
* call graph analyzers
* database structure crawlers
In the absence of models that can do perfect oneshot software engineering, we're gonna have to fall back on well-integrated tool usage, and nobody seems to do that well yet.
I think a lot of these use cases for AI are incidental byproducts of the actual goal, which is to replace software developers. They're trying to salvage some kind of utility. Because I agree that the AI tools in use are marginal improvements, or downgrades in a lot of cases
I've heard people say they use AI agents to set up a new project with git. Just use tortoisegit or something, its free and takes one click - its just using AI for the sake of it
Vibe coding pushes errors rightward, but using AI to speed up typing or summarizing documentation doesn’t. Vibe coding will fail, but that doesn’t mean using AI to code will fail. You’re looking at one (admittedly stupid) use case and generalizing too hastily.
If I have an LLM fix a bug where it gets the feedback from the type checker, linter and tests in realtime, no errors were pushed rightward.
It’s not a free lunch though. I still have to refactor afterwards or else I’ll be adding tech debt. To do that, I need to have an accurate mental model of the problem. I think this is where most people will go wrong. Most people have a mindset of “if it compiles and works, it ships.” This will lead to a tangled mess.
Basically, if people treat AI as a silver bullet for dealing with complexity, they’re going to have a bad time. There still is no silver bullet.
>The industry is trying to push errors leftwards.
Is this true? Most software devs would like to. But I think business is more interested in spee which pushes errors to the right. Which seems to be more profitable in most software. Even stuff thats been around for a decade(s).
nah, in general there's a serious industry-wide push for this. software testing is changing (involve QAs early so they can help with the spec so when they get the software they know what to test against), agile is about delivering small valuable parts of the product as soon as possible, VC investing (lean startups!) is about testing business ideas as soon as possible, etc.
it's all part of the shift left ideology. (same with security, you cannot really add it later, same with GDPR and other data protection stuff, you cannot track consent for various data processing purposes after you already have a lot of users onboarded - unless you want to do the sneaky very not nice "ToS updated, pay or die, kthxbai" thing [which is what Meta did], etc.)
... of course this usually means that many times people want to go from the "barely idea as a Figma proto" to "mature product maintained by distributed high-velocity teams" without realizing that there are trade-offs.
shift left is makes good business and engineering sense and all, as it allows you to focus on the things that work, but it requires more iterations to go from that to something mature.
I disagree entirely, and I can convince you I'm right with one sentence: More lines of JS/TS are written by AI than lines of Rust are written at all. We don't have the data to assert this as true, but I think the vast majority of people would agree with that statement.
This statement being true disproves the statement "the industry has been making huge efforts to push errors from runtime, to compile time." The industry is not a monolith. Different actors have different, individualized goals.
it's absolutely not a problem that people are writing more JS/TS than Rust.
if that Rust is for decades and the JS/TS gets thrown out in 1 year.
there's a lot of shitty C being written still around the world yet the Rust that goes into the kernel has real value long term.
there's an adoption cycle. Rust is probably already well over the hype peak, and now it's slowly climbing upward to its "plateau of productivity".
(and I would argue that yes there are pretty good things happening nowadays in the industry. for many domains efficient and safe libraries, frameworks, and platforms are getting to be the norm. for example see how Blender became a success story. how deterministic testing is getting adopted for distributed databases.)
And I have a very hard time understanding why AI is "pushing the errors to the right".
> Compiler -> code review -> tests -> runtime checks -> 'caught' in prod
With AI we still compile the code.
We still do code review.
We still run tests (before code review, obviously; don't know why it's listed like this).
We still do QA at runtime.
I feel like anti-AI people are those one who actually treat AI as magic, not the AI users. AI doesn't magically prevent you from doing the things that helped you in pre-AI era.
No, but if a shop added overnight 5 fledgling juniors for each current employee on the project, not only would the delivery not be sped up on account of Brooks's law, but the stack would soon tank under the weight of its own issues. So outside of such situations as hilarious consultancy disasters, no one did that.
Now with AI they do.
This is the best and most enlightening take I've heard in a good while.
I have articulated this to friends and colleagues who are on the LLM hype train somewhat differently, in terms of the unwieldiness of accumulated errors and entropy, disproportionate human bottlenecks when you do have to engage with the code but didn't write any of it and don't understand it, etc.
However, your formulation really ties a lot of this together better. Thanks!
Exabytes of code are being written in Python and JS though… I don’t think that fits with your narrative that everything is being pushed to compile-time. C#, Java and Go remain popular sure but have they grown that much relative to other languages? Rust is being adopted primarily in projects that used to be in C or C++ if I’m not mistaken.
Those languages have been going through exactly the same evolution though, like the JS -> typescript migration is one of the most direct practical examples of this imo
thanks for articulating so nicely what needs to be said in this debate.
Pushing errors leftward vs rightwards is such a nice metaphor, not to mention the metaphor on mental models. Also, your comment on why natural language is unable to describe the problem adequately (later in this thread), since sometimes constraints are discovered during the solution process, and otherwise, and if problems could be described adequately, thats what we call a programming language is very nice - ie, for natural language to adequately describe a problem, that becomes a formal language.
Only experienced engineers who have been through failed projects will understand what you are saying, and the rest of those in the grip of the ai-mania will come to terms with it soon.
> That's the primary reason why I don't think AI will catch on
It's almost enraging that with the hype around LLMs, the development of real automatic programming AI seems to have halted.
Recurse Center made a good observation:
> I expected to find vastly differing views of what future developments might look like, but I was surprised at just how much our alums differed in their assessment of where things are today.
> We found at least three factors that help explain this discrepancy. First was the duration, depth, and recency of experience with LLMs; the less people had worked with them and the longer ago they had done so, the more likely they were to see little value in them (to be clear, “long ago” here may mean a matter of just a few months). But this certainly didn’t explain all of the discrepancy: The second factor was the type of programming work people cared about. By this we mean things like the ergonomics of your language, whether the task you’re doing is represented in model training data, and the amount of boilerplate involved. Programmers working on web apps, data visualization, and scripts in Python, TypeScript, and Go were much more likely to see significant value in LLMs, while others doing systems programming in C, working on carbon capture, or doing novel ML research were less likely to find them helpful. The third factor was whether people were doing smaller, more greenfield work (either alone or on small teams), or on large existing codebases (especially at large organizations). People were much more likely to see utility in today’s models for the former than the latter.
— https://www.recurse.com/blog/191-developing-our-position-on-...
Anecdotal: definitely a long way to go for systems programming, non-trivial firmware, and critical systems in general. And I say this as a huge fan of LLMs in general.
I work as a FW Eng and while they've been of immense value in scripting especially (fuck you powershell), I can only use them as a better autocomplete on our C codebase. Sometimes I'd chat with the codebase, but that's a huge hit or miss.
“Carbon capture” seems oddly specific?
My guess is that's a specific example of e.g. novel scientific modeling.
The value of AI is easy to see personally, concretely. But there is always a gap between concrete value in your hands and how that plays out in larger systems. The ability to work remotely could intuitively project to outsourcing of almost all knowledge work to cheaper labor markets, and yet that has only happened at the margins. The world is complex and complicated, reserve a measure of doubt.
This is a great point.
In-person work has higher bandwidth and lower latency than remote work, so for certain roles it makes sense you wouldn't want to farm it out to remote workers. The quality of the work can degrade in subtle ways that some people find hard to work with.
Similarly, handing a task to a human versus an LLM probably comes with a context penalty that's hard to reason about upfront. You basically make your best guess at what kind of system prompt an LLM needs to do a task, as well as the ongoing context stream. But these are still relatively static unless you have some complex evaluation pipeline that can improve the context in production very quickly.
So I think human workers will probably be able to find new context much faster when tasks change, at least for the time being. Customer service seems to be the frontline example. Many customer service tasks can be handled by an LLM, but there are probably lots of edge cases at the margins where a human simply outperforms because they can gather context faster. This is my best guess as to why Klarna reversed their decision to go all-in on LLMs earlier this year.
> In-person work has higher bandwidth and lower latency than remote work, so for certain roles it makes sense you wouldn't want to farm it out to remote workers
This is just not true. Specially if your team exists within an organization that works in world wide solutions and interacts with the rest of the world.
Remote can be so much faster and efficient because it's decentralized by nature and it can make everyone's workflows as optimized as possible.
Just because companies push for "onsite" work to justify their downtown real estate doesn't mean it's more productive.
That is like saying concurrent programming is far superior to sequential programming so lets stop doing sequential programming completely. Many tasks are just easier to do in a centralized environment.
I didn't propose forcing remote work. I simply countered faulty arguments in favor of onsite.
Your analogy with programming makes little sense and distracts. It's better to discuss the actual point.
The people who are saying AI will replace everyone are people who don't actively deploy code anymore. People like CEOs and VPs.
People who are actively deploying code are well aware of the limitations of AI.
A good prompt with some custom context will get you maybe 80% of the way there. Then iterating with the AI will get you about 90% of the way, assuming you're a senior engineer with enough experience to know what to ask. But you will still need to do some work at the end to get it over the line.
And then you end up with code that works but is definitely not optimal.
Fred Brooks told us to "plan to throw one version away, because you will."
What he missed is that the one version that is not thrown away will have to be maintained pretty much for ever.
(Can we blame him for not seeing SaaS coming ?)
What if the real value of AI was at the two sides of this:
* to very quickly built the throwaway version that is just used during demos, to gather feedback from potential customers, and see where things break ?
That can probably be a speed-up of 10x, or 100x, and an incredible ROI if you avoid building a "full" version that's useless
* then you create the "proper" system the "old" way, using AI as an autocomplete on steroid (and maybe get 1.5x, 2x, speedup, etc...)
* then you use LLMs to do the things you would not do anyway for lack of time (testing, docs, etc...) Here the speedup is infinite if you did not do it, and it had some value.
But the power that be will want you to start working on the next feature, by this time...
* I don't know about how LLMs would help to fix bugs
So basically, two codebase "lanes", evolving in parallel, one where the AI / human ratio is 90/10, one where it's maybe 30/70 ?
AI for fast accretion, human for weathering ?
Maybe but anytime someone keeps doing mental gymnastics and theorizing that there are new forces at play, something comes out and says no, it was something very straightforward. Hammock Driven Development describes a zen internalized way an expert does exactly as you describe but it is nicer you don't have to pay per token. To be clear, I think this all falls again under the rubber duck umbrella which is fine, but seemingly impossible to design a controlled study for?
I agree that the study is biased (it compared people unused to a tool with people not using the tool. Duh. The only person who was more efficient was the person... who knew how to use the tool. Duh indeed.)
However I don't see how hammock driven dev allows you to validate an idea with a prototype built in an hour as opposed to a month.
The real benefactors of AI in software development are senior devs who’ve had enough of boilerplate, framework switching, and other tedious low-value tasks. You cut down on the former laborious tradition of picking through StackOverflow for glimmers of hope.
Yet when you look beyond boilerplate code generation, it's not all that LLMs increase experienced developers productivity (even when they believe that it does): https://arxiv.org/abs/2507.09089
Edit: Hello downvoters, would love to know if you found any flawed argument, is this just because this study/comment contradicting the common narrative on HN or something else entirely?
Is there literally anything other than this single, 16-participant study with that validates the idea that leveraging AI as an assistant reduces completion time in general?
Unless those participants were just complete idiots, I simply cannot square this with my last few weeks absolutely barnstorming on a project using Claude Code.
I wish we did a more formal study, but at $previous_job we rolled out AI tools (in that case it was github copilot) and we found that for 6-8 months productivity largely stayed the same or reduced slightly, but after that it sharply increased. This was rolled out to hundreds of developers with training, guidance, support etc. It was done in what I would consider the right way.
Was that project fairly early-days? The current impression seems to be that AI is useful for accelerating the development of smaller and simpler projects, but slows things down in large complex codebases.
> I simply cannot square this with my last few weeks absolutely barnstorming on a project using Claude Code.
I don't know, but the interesting data in the study is that they all said the same thing you are saying, but their actual time was 19% slower.
And yes, right now it's the only study that seemed to have a good methodology that I've seen that has any data positive or negative.
The sample size isn’t the individual participants, it’s the hundreds of tasks performed as part of the study. There’s no indication the study was conducted incorrectly.
Except that the participants were thrown into tasks cold, seemingly without even the most basic prep one would/should do before throwing AI at a legacy codebase (sometimes called "LLM grounding" or "LLM context bootstrapping"). If the participants started without something like this, the study was either conducted incorrectly or was designed to support a certain conclusion.
By the time all of this is written, I'm familiar enough with the code to fly over it (Hello, Emacs and Vim). But by then, your tasks are small and targeted fixes, because any new feature requires lot of planning and stakeholder discussions that you can't just go and work on it.
This study was about “246 tasks in mature projects”. I would expect AI to fare much better in a study about new projects or brainstorming.
From the paper:
> We do not provide evidence that:
> AI systems do not currently speed up many or most software developers
> We do not claim that our developers or repositories represent a majority or plurality of software development work
Not sure why you quoted that part, it just says that there is no assumption for the results to be extrapolated to any codebase or any developer, setting the boundaries of the study objectives.
You have made the claim that it does extrapolate. Which they themselves do not make.
How is saying that it's not all clear LLM increase experienced developers productivity an extrapolation?
The only extrapolations I've seen on this thread are people shrugging it as using 6 months old LLMs so this whole paper must be invalid today.
Okay, so, I re-read your original post:
> it's not all that LLMs increase experienced developers productivity (even when they believe that it does):
In the present, I am struggling to parse this. When I made my original comment, I understood you to be saying that LLMs do not increase productivity. Synthesizing what you're saying now with that, if I had read
> it's not at all clear that LLMs increase
then I would have understood you correctly. That's my bad!
> The only extrapolations I've seen on this thread are people shrugging it as using 6 months old LLMs so this whole paper must be invalid today.
I feel for both sides on this one. I do think that, for me personally, the models they used weren't good, but the ones that exist now are. So I do think there's some issue there. However, I don't think that makes the study invalid, if anything, it's a great way to test this hypothesis: if they do the same thing again, but with newer models, that would lend some weight to that idea. So I also think saying that this is completely irrelevant is missing the point.
That study is going to go down as the red herring it is. Shows little more than people with minimal experience using LLMs for dev do it wrong.
> Hello downvoters... is this just because...
Since you asked, I downvoted you for asking about why you're being downvoted. Don't waste brain cells on fake internet points - it's bad for your health.
Here here
One of the problems with this study is that the field is moving so very fast.
6 months in models is an eternity. Anthropic has better models out since this study was done. Gemini keeps getting better. Grok / xAI isn’t a joke anymore. To say nothing of the massive open source advancements released in just the last couple weeks alone.
This is all moving so fast that one already out of date report isn’t definitive. Certainly an interesting snapshot in time, but has to be understood in context.
Hackernews needs to get better on this. The head in the sand vibe here won’t be tenable for much longer.
AI more of a force muliplier than a replacement. If you rated programmers from 0 to 100. AI can take you from 0 to 80, but can't take you from 98 to 99.
I'd love to record these AI CEOs statements about what's going to happen in the next 24 months and look back at that time -- see how "transformed" the world is then.
My guess is more if the same (i.e. mostly crap), but faster.
We still create software largely the same as we did in the 1980s. Developers sitting at keyboards writing code, line by line. This despite decades of research and countless attempts at "expert systems", "software through pictures" and endless attempts at generating code from various types of models or flowcharts or with different development methodologies or management.
LLMs are like scaffolding on steroids, but aren't fundamentally transforming the process. Developers still need the mental model of what they are building and need to be able to verify that they have actually built it.
> We still create software largely the same as we did in the 1980s. Developers sitting at keyboards writing code, line by line.
That's because the single dimension of code fits how the computer works and we can project any higher order dimension on it. If you go with 2 dimensions like pictures, it no longer fits the computer model, and everything becomes awkward with the higher dimensions of the domain. The only good 2d representation is the grid (spreadsheet, relation dbs, parallel programming..) and even they can be unwieldy.
The mental model is the higher dimension structure, that we project on line of codes. Having LLM generating it is like throwing painting on canvas and hoping for the Mona Lisa.
I'm stating the obvious, but these things tend to go either way. We either grossly overestimate the impact, or grossly underestimate it.
In the case of the internet, it ended up going both ways. We overestimated it in the near term and underestimated its impact in the long term.
They could very well be right. I don't think they are. But I've also never seen anything that can scale quite like AI.
Fully self-driving cars have been just 2 years away for what, 10 years now?
While I read this article, Claude code was fixing a bug for me.
I agree with Cal that we basically don’t know what happens next. But I do know that the world needs a lot more good software and expanding the scope of what good software professionals can do for companies is positive.
I wonder if you would say this if, say, in a year you're laid off because AI got good enough to write your code. Would you be happy that there is better software in the world at the expense of your job?
I’m optimistic - perhaps naively - about my ability to retool within work.
10 years ago, I was building WordPress websites for motivational speakers. Today, I build web apps for the government. Certainly in 10 years we will be in a different place than we are today.
Your argument, taken in a broader sense, would have us tending to corn fields by hand to avoid a machine taking our job.
> Your argument, taken in a broader sense, would have us tending to corn fields by hand to avoid a machine taking our job.
To play off another analogy commonly used in this topic: you are the horse, not the rider. Sure some horses will find new work, at the grace of their owners. Some lucky individuals may even get a carefree life of mostly leisure.
But for many, it’s off to the glue factory, and not for a job.
That was a terrific non-answer. The difference is the industrial revolution created jobs, at some point technology will remove jobs. I'm sure you'll be thrilled to be out of a job in the name of good software. It's amazing how the tune changes so quickly when it's your job on the line.
Sure, AI may break the American economic system – which would be negative both for me, you, and the entire world. I would not relish that and I think we should ask our brightest young thinkers to imagine a world in which the productivity gains from AI don't simply accrue to capital holders.
Getting back to Cal's point, I think there's a lot of legitimate questions and uncertainties about what knowledge work will look like over the next decade. You say that technology will remove jobs...and I think you're right directionally, but I can't tell you the timeline for that, nor it's effects.
While I love being a software engineer, what that actually looks like on a daily basis has materially changed _a lot_ every few years. Sitting for a day debugging why my SCSS won't render is not the core value I bring to this world as a human.
If you're so scared then you were probably too sheltered thinking you'd have "guaranteed security" in a shitty unfair world.
Some of us weren't that lucky and always had to stay creative, even when we lacked resources that privileged 1st world people had.
It's a shift. Exciting and also, yes, dangerous one, but the if you focus on being able to produce true value you are bound to be able to make a living out of it. Whether you're employed by someone or create a company yourself.
Find something you love and be scared at times, but don't let it stop you and you'll succeed.
> There has been no shortage of evidence to support these claims.
One would usually show some kind of evidence after making such a statement. Claims from CEOs of AI companies don't count.
I don’t think you can become a talented enough software developer to benefit from using AI by using AI. Google Maps causes us to lose the ability to navigate without it. I would not be surprised in the slightest if the same is true with AI.
So. A little boost now. But at the risk of not knowing how to get where you’re going unless someone is holding your hand.
And if that’s the case, how can we possibly get to where we’ve never been before?
The volume of emotion running through the discourse on LLMs feel qualitatively different compared to something like bitcoin.
One could mostly ignore Bitcoin. AI usage and its network effects are much more widespread and often place additional work on me, even if I choose not to use AI directly. Incorrect issues or pull requests, unmaintainable heaps of code, etc.
Crypto doesn’t have implications of replacing your programming skills.
I seem to recall an endless string of comments mockingly reporting that "crypto bros" were "speedrunning the discovery of every financial regulation" every time a new crypto news article popped up anywhere. You could have set your watch to it.
At the end of the day Bitcoin is a networked technology. It's worthless to me if you/the store/landlord/taxman won't take it, and most of them don't, so its value is only between adherents, which means, sure, I can buy some, but then what? Use it to buy something sketchy online?
Meanwhile, anyone can go to chat.com and ask for code to do whatever they ask. Some questions it will answer well, others it will not. Because we're discussing this in the abstract, LLM good!/LLM bad! Grar!, and barely touching on details, like the programming language, the libraries, nevermind sharing the prompts, both camps are convinced they're right, with much more furvor than Bitcoin. Additionally the technology is evolving so fast that someone's bad experience from a couple months ago is already out of date. Meanwhile, how many times can you have the same argument about Bitcoin? There are a couple details here and there, but nothing structurally changed with Bitcoin since its inception. Which is a shame, if they'd managed to fork so transactions weren't horribly slow, maybe we'd be having a different discussion. But I digress.
The volume of emotion is different, not because of the money swimming around, of which there is a lot, but because we're arguing over things we see with our own eyes but aren't giving enough detail to have productive discussions about. Insulting people adds to the emotionally charged nature. Things like "If you find LLMs used, it's because you're a bad programmer/an idiot/only work on loser problems" or "AIs going to put you out of a job" don't encourage reasonable nuanced discussion. Insulting someone for liking Bitcoin doesn't cut as deep. No one's been working on Bitcoin for four decades and made it their whole (public) identity.
> No one's been working on Bitcoin for four decades and made it their whole (public) identity.
It sounds like a large part of the problem is getting your identity wrapped up into this. Both the CEOs and the devs.
To be clear, I was referring to programming ability when I was referring to identity, not AI. It's sometimes hard for me to forget that you are not your code.
Yes I mean that too. I have no idea how you can "measure" programming ability. The whole concept confuses me. I've been coding since I was a kid and have contributed to FOSS and closed codebases. There's certainly programmers out there that I consider bad, but beyond that there's no way to measure how "good" someone is at coding. The fact that people can identify around their perception of programming skill is deeply confusing to me and makes these sorts of reactions even harder to understand.
Programmers are just as emotional as the next human, no matter how much they want to believe otherwise, so almost all of them (myself included) think they're better than average, which can't actually be true.
Skill is linked to prestige and loosely linked to pay, which gets linked back to prestige. Thus even without an actual measure of programming ability, if someone says "you couldn't program your way out of a paper bag", it's hard for most people not to feel insulted, linking back to prestige. Not everyone buys into that, or is impulsive enough to respond emotionally, of course, but it should at least make sense on a conceptual level.
I'm so tired of it. Lobste.rs has become unusable due to the endless echoes of resentment.
Have some empathy. Even if it's not certain, there's a non-zero possibility that a large number of developer jobs (especially those focused purely on coding) will go the way of factory workers and switchboard operators, and if that happened it'd be a very tough transition for many people.
I think there's just droves of people who came to software thinking it was the new stable, solid, good reputation way to make money sitting in front of a computer.
I saw so many people who were not following what they liked but "a good choice".
Now many are scared instead of excited and/or skeptical because they don't trust their own self and ability to reinvent all the time. We do change a lot of practices in short periods of time. This is similar to an extent. Learning and guiding this new world is extremely interesting. You don't need to lie like a CEO either. Just solve, guide and build the new challenges.
The article captures the two agendas at work. The reality is somewhat dependent on your situation.
If you understand _how_ you should be using AI in engineering, then AI can speed you up because you know what you're trying to build, you understand the fundamentals, and you are the pilot delegating granular tasks. When bugs pop up or requirements change, you'll have the knowledge required to frame and steer the AI to ensure goals are met, and met properly. When AI gets stuck, you'll be able to quickly jump in and work the problem. Your experience will continue to evolve and improve over time because you're plugged into the work and the code. You'll leverage your experience in unexpected ways in future projects, and perhaps your communication skills will improve as well.
Alternatively, if AI is used improperly, it may provide the illusion of velocity up until the point where you realize that your lack of knowledge or involvement actually prevents the AI from making progress. You want to move beyond a simple implementation, bugs pop up that can't be fixed, or new requirements can't be met. You aren't able to dive in yourself, either because you weren't paying attention to the work or were operating too far outside of your expertise. In either case, the progress you thought you were making might actually be a pile of wasted time and technical debt.
Here's something I assert to know about how AI and software engineering intersect in 2025: It makes certain classes of tasks 150% faster, while making other classes of tasks 300% slower. What I rarely know upfront is whether a given task will fall into the former class or the latter.
Why was the title changed again? The article has the title "No One Knows Anything About AI". The post started here with that title, then changed to "Two narratives about AI". Why editorialize the title?
Yeah, seriously, what is this about? Dang, etc? Anyone?
I think the first set of quotes are from people trying to sell something, while the second set are based on real data and people who have actually worked with AI. I'm a engineering manager over some infrastructure teams and we've tried to use it for network monitoring without any success. It seems like it would be handy; who doesn't want to query the state of your infra in natural language? The problem is it gives non-deterministic results and occasionally just makes things up. All the developers I know who use Github Copilot say it's very buggy and often makes coding take more time if they use it for any autogeneration.
So what is your pick?
* AI is the next electric screwdriver * AI is THE steam engine.
My pick is that the AI is not THE steam engine.
It's hard "to tune out" from the topic when investments in LLM technology surpasses revenues of nation states, and when US policy is not trying to prevent harm to society, but making it more likely. By 'harm', I don't mean some 'rogue AI' sci-fi scenario. I mean a financial time bomb that far exceeds the 2008 subprime mortgage crisis.
The AI discussion reminds me of the assembly vs high-level languages (HLL) debate of my youth. The claim was that expert assembly language programmers could write optimized code that was much faster than compiled code, and therefore HLLs will always be the 'second best'. Obviously, that was a misunderstanding: compilers got so much better that, on average, they beat human assembly programmers, especially on large code bases where careful machine language optimization does not scale. There's still a place for optimized assembly language programming, but it's exclusively in high-performance highly reusable libraries.
I think a similar pattern will emerge for AI: it'll be used for routine code, while freeing skilled programmers for algorithm development and similar high-level tasks.
I’m of the opinion that LLM assisted coding tools have a few general effects in the domain of software development:
1. Increases in productivity for experienced software engineers.
2. Raised industry expectations around productivity of individual software engineers.
3. Lowered ratio of human engineers to other parters in the development process (customers, stakeholders, etc.)
I’ve found the net result is an environment where we can churn out code easily, but producing the right code becomes harder. Fewer eyes on the production of a product means most of the validation later in the development process.
How much an issue this is remains to be seen. Engineers will presumably have more time to review and debug things. Debugging will be easier. That said, I have no idea if any of that makes up for retroactively realizing design assumptions were bad or that some subtle constraints about your software were violated.
Claims were made by people with financial incentives, and then refuted by professionals and researchers who actually have to deal with the systems. That's not "two narratives" and recommending that you "tune out" is anti-critical thinking.
There is a great article floating around on the economics of AI and how parasitic the current market is between the Fab Five.
We are 27-ish months since the claim that all software engineers would be replaced within six months by some of these CEOs. It is their job to analyze the market and determine what the next big thing is, but they can be wrong - no one has a crystal ball here.
The difficulty for me is how disconnected a lot of the takes are (or even flat out manipulative) that are being pushed out. I am an early adopter of AI tools. I utilize them on a day-to-day basis, but there is no way that I see AI taking SW jobs right now.
You have others claiming that these tools will just get exponentially better now, time will tell, but as of right now there is still too much value in human coders any anyone that is actively pushing for replacing SWE with "Agents" is either betting big on the future (that is unproven) or attempting to entice/manipulate the larger market.
I think part of the solution is to start discussing the specific limitations of LLMs, rather than speaking broadly about AI/AGI. For example, many people assume these models can understand arbitrarily long inputs, but LLMs have strict token limits. Even when large inputs fit within the model's context window, it may not reason effectively over the entire content. This happens because the model's attention is spread across all tokens, and its ability to maintain coherence or focus can degrade with length. These constraints along with hardware limitations like those in NPUs are not always obvious to everyday users.
I agree, but unfortunately it falls flat IME. The hype is too strong and being pushed by the Fab Five that is causing an unbearable wall to these conversations.
I have these conversations on a day-to-day basis and you are labeled as a hater or stupid because XYZ CEO says that AI should be in everything/making things 100x easier.
There is a constant stream of "What if we use an LLM/AI for this?" even when it's a terrible tool for the job.
> You have others claiming that these tools will just get exponentially better now
Most of those same people are also claiming that the last iteration of LLMs are too smart and that the previous ones worked better for agent (agentic?) programming...
I doubt AI is actually intelligent or artificial, it's more like Attempted Insertions.
Can it train on your own code or work to give results that make more sense? At least with more control, you can have better expectations. In other words, how can you be sure it'll never get ill? Does it learn about each user to give you what you want? Does it conform to you or vice versa?
Is there a proof-of-work coin that can be used to handle the processing load? It's like a guilty pleasure right now. What'll be the long-term costs and risks of dependency? At least by reading from a human directly, there's that chance of a meaningful connection.
At first it seemed LLM's were perfect assists for coding because they are trained on text and generate text. But code isn't typical text. It's basically a machine that requires a very high degree of precision and accuracy. Seen this way, LLM's are suited for coding only at specific stages -- to generate something like boiler plate, to brainstorm, to evaluate diverse approaches, identify missing tests. Anything that ties LLMs to actual code implementation is asking for trouble in my view.
So there are two narratives... but,
> AI is important. But we don’t yet fully know why.
What about the narrative that AI is not important at all? As in, completely not. What about that side of the story?
I feel like AI is great tool to expand the environment of your knowledge, kind of like wikipedia (I wonder why ).
But poor as accurate source of knowledge or provider of accurate answers.
The carpentry analogy seems quite good
>Quitting programming as a career right now because of LLMs would be like quitting carpentry as a career thanks to the invention of the table saw
I presume carpenters can make a given item much quicker than they could in centuries past but there are still presumably a lot still employed, just doing slightly different things, like maybe sorting fancy custom staircases for new housing rather than churning out chests of draws.
The analogy is pretty generous towards LLMs. I like Eevee's response to it in her blog post[1]:
>What I do know is that a table saw quickly cuts straight lines. That is the thing it does. It doesn’t do Whatever. It doesn’t sometimes cut wavy lines and sometimes glue pieces together instead. It doesn’t roll some dice and guess what shape of cut you are statistically likely to want based on an extensive database of previous cuts. It cuts a straight f*cking line.
>If I were a carpenter, and my colleagues got really into this new thing where you just chuck 2×4s at a spinning whirling mass of blades until a chair comes out the other side… you know, I just might want to switch careers.
[1]: https://eev.ee/blog/2025/07/03/the-rise-of-whatever/
If the original framing was too generous, the response is at least as ungenerous. Table saws aren't deterministic tools either, and anyone who has used one for more than a minute can tell you that getting it to consistently cut the straight line you want takes skill.
[dead]
I really blame the Sam Altman hype machine for all of this dystopian nonsense. He really is like a Ryan holiday you can’t trust anything he says. He's the one who started all this "employees are going away" stuff with this $20,000 AI employee. that's not when he started it, he started it long before that with all his basic income bullshit.
For text LLMs, on a basic level, isn't it just aggregating the percentage chance of a specific word order based on the topic/genre?
I've just started looking into them, but it feels like A BUNCH of stats hidden beneath a layer of if/else statements.
It only seems to work given an unlimited amount of money being thrown at it. Which would be possible if it were nationalized, but they're too greedy for that to happen.
We have a similar situation in the academia specifically for teaching. Many faculty members are stressed because they fear the admin will start replacing them with AI. Anyone who has done any teaching in the classroom knows that we are nowhere close to that point. But the admin loves to start cost cutting at the expense of education quality.
There is a lot of confusion & hype about AI. AI is not just use of LLMs. LLMs could help us with GenAI use cases. Not everything is GenAI. Main reason for confusion IMHO is - GenAI exposed lot of non-tech people to AI and they don't have a full picture.
What about graphic, web and app design? I just do not see a long term career going forward (been meaning to research how many UX jobs are being listed in 2025 to previous years). UX Research I do as you are interacting with users and AI is not a person (yet).
There hasn't been enough real "UX" work since before 2008. Most companies arent running focus groups. They haven't put their designs in front of real users (real usability testing) and gotten feed back on them.
Yes online tools are great and all but you're only getting feedback from the people already in. "I can get through your poorly designed app for work" is not something an online tool will tell you.
As for design, there was this tool posted a few days ago: https://finddesignagency.com
Great effort by the person who made it. The product they are showing off made me think of the line from the song "and they are all made out of ticky tacky and they all look just the same"
AI, to me, specifically in the field of UX, feels like it's pushed as a panacea for having to do actual fucking UX work. Just throw everything behind a natural language interface! Slop it up!
AI coding assistants significantly accelerate repetitive tasks, but they lack true contextual reasoning, long-term architectural insight, and accountability. Human developers remain essential for critical problem-solving and design.
Wouldn't the be reacting differently if the cost and speed of development in the economy's highest ROI industries was really expected to improve by an OOM in the near future?
I´m doing the work of 3 dudes alone (dev, qa, devops). My delivery is 100% faster and my development practice allows me to reduce the bugs dramatically.
Maybe my stack is easier or the product is not too complex but if I take my own experience as a truth, my truth, (we) Engineers are going to suffer for a long time.
Everybody will have different experiences but my guess not all developers are working in frontier projects so their jobs will be the first to suffer the change. At least for me this is going to happen.
Solo developers were already multiple times more productive than their coworkers and it never made much difference, even in compensation.
I got triggered enough to write an angry rebuttal.
The structure is familiar: first, a summary of the breathless hype that AI will change everything. Then, a collection of counterpoints suggesting it's all overblown. The grand conclusion? That everything is confusing, nobody knows anything for sure, and the wisest stance is to take it all with a "large grain of salt."
The truth is, we know an immense amount about AI, and pretending otherwise is not a sign of wisdom, but an excuse to disengage from the most important technological shift of our time.
First, a note on the sloppy analogy of the "economic sacrificial lamb," referring to those first disrupted by AI. This analogy is not just melodramatic; it’s incorrect. Developers aren't being passively offered up to some AI deity. They are the first to feel the effects because they are the ones building, implementing, and integrating the technology. They are not the lamb; they are the blacksmiths forging a new kind of hammer and, in the process, figuring out how it changes their own workshop. Their proximity to the change is a consequence of their agency, not their victimhood.
The most frustrating claim, however, is the idea that "we don’t yet know anything for sure." To anyone working with or studying these systems, this is patently absurd. While the long-term societal outcome is uncertain, we have a vast and growing body of practical, empirical knowledge about how these models work.
We know, for example, that providing specific context and reference material dramatically improves answer quality and reduces hallucinations—the entire principle behind the now-dominant RAG (Retrieval-Augmented Generation) architecture. We know about scaling laws, prompt engineering best practices, and fine-tuning methodologies. We have gigabytes of data on what tasks AI excels at (boilerplate code, synthesis, translation) and where it fails (complex reasoning, factual accuracy, planning). To dismiss this mountain of hard-won engineering knowledge is to be aggressively ignorant.
Then there is the Double Standard. Cal Newport has built his brand as a productivity expert, offering systems for "deep work" and focus. Yet, as any psychologist or organizational behavior expert can attest, human productivity is a field where "moving the needle predictably" is a notoriously difficult, almost impossible task. It’s a domain riddled with individual differences, cultural nuances, and contradictory findings. For a guru from a field that lacks hard empirical certainty to demand it from the nascent field of AI exposes a glaring double standard. He is holding AI to a standard of proof that the behavioral sciences—the foundation of his own work—have never been able to meet. It's a rhetorical move that positions him as a wise skeptic, but to me, it comes off as hypocrisy.
And then the final, tired advice: be skeptical. Take it with a grain of salt. This isn't insight; it's a cliché that has been the default take for every technological shift of the last thirty years. It’s safe, lazy, and frankly, boring. We don't need more generic skepticism. We need engaged, critical, hands-on analysis. The interesting work isn't in declaring the future unknowable from an armchair by has-been intellectuals that are unable or unwilling to keep up with recent developments.
>The truth is, we know an immense amount about AI
We (as researchers and developers in the field) know alot about how its technically implemented, like building models, making improvements etc. These can be quantified and tracked.
The heart of the matter is this:
>societal outcome is uncertain
I think all speculation around AI is heavily weighted about that as opposed to what do we know about AI from a technical perspective? which isn't even usually part of the discourse, unless we're talking about AI safety, which the bad actors try to pretend the technology isn't built in a well known way or can have predictable results etc.
A good chunk of the problem (certainly more than half) is that you have bad actors that need to sell the world on AI, and you have actual technical implementors who really know alot about these systems but are most often employed by folks who benefit from gatekeeping the technology and refuse any attempts at oversight, often claiming we don't know alot about how these systems work while simultaneously employing people who definitely know how these systems work.
The industry has done this to itself, by making false claims and talking out of both sides of their mouth, while the actual technically skilled folks are for various reasons, largely stuck in the middle without much room at the broader discussion table
An observation mostly perfectly explained by failure to differentiate scientists from journalists.
And what do you mean “done this to itself”. What is this?
And you do realize I was specifically contrasting how much and how we know about AI versus how much we know, for instance, in the field of productivity psychology. In addition to how idiotic it is to say we know nothing.
If we know nothing about AI, then by the same standard, we know nothing about anything.
Or let me put it simply to you. If we had a random average firm, and we either gave them a copy of Newport's book on productivity or a subscription to Gemini, with all we surely must KNOW regarding productivity, the book version of the firm would become massively more productive, no?
You used AI to write this.
No, I didn’t. I am getting tired of the accusations every time I write something I believe is thoughtful. I challenge every person who throws this at me to a live debate to see if it’s me thinking these thoughts or just an AI. If you decline, I assume it’s because you are so limited that you can’t imagine anyone thinking for themselves, because you project your own inabilities onto others.
It is thoughtful and well written. But it's done by AI. Nothing wrong with that.
So if I say "No, I didn't," and offer as proof a direct conversation, and in that conversation, I articulated myself almost exactly like the text in question, would that support my claim—that it's just me?
And another thing. Is this the new and modern way of discarding opinions? “You didn't write that.” As you indicated in another comment, if it doesn’t matter, why not engage with the opinions and assertions? It might not be a smear, but it sure does live on the same street as a smear.
Maybe I can avoid this by not using spell-correction. Du u beliv me now?
>So if I say "No, I didn't," and offer as proof a direct conversation, and in that conversation, I articulated myself almost exactly like the text in question, would that support my claim—that it's just me?
over the phone? Then you're reading.
>Maybe I can avoid this by not using spell-correction. Du u beliv me now?
ChatGPT, respond to this person with miss-spelled words.
You, a few hours ago: "The LLMs are displaying output and behavior that is consistent with people who are conscious." - https://news.ycombinator.com/item?id=44671061
You, now: "I can tell you didn't write that. AI did it!"
You really ought to make up your mind.
It is displaying output consistent with consciousness. Doesn't mean it is conscious. But the textual output is indistinguishable. My statements HAVE not changed, and remain true.
>You, now: "I can tell you didn't write that. AI did it!"
It's more of a parody of what he's saying. He's making claims yet he can't even prove if what he wrote is AI.
Love the balance this post shows in supporting and dismissing ai impact, unlike the other post on hn today ;)
The narratives are opposite extremes on spectrum of opinions and anecdotal.
I find it more useful to split the narratives into "AI hype" and "pragmatic AI": https://senkorasic.com/articles/pragmatic-vs-hype-ai
TLDR: The technology is real. A lot of companies are working on it and evaluating how to integrate it into their products or processes. Many people use ChatGPT and other tools daily for a wide variety of tasks.
At the same time, there's an enormous amount of hype. Some of it comes from a poor understanding of the technology: not everyone can be an AI expert. But a lot of it is companies adopting AI in name only to ride the hype wave. We're being bombarded with claims about the imminent arrival of "Artificial General Intelligence" (AGI) or even "Artificial Superintelligence" (ASI). AI companies tell us to "stop hiring humans" or announce plans to lay off hundreds or thousands of employees as they're replaced by AI agents.
This is AI being used for marketing, not productivity. It doesn’t even require the tech itself—the story is what sells, and the more controversial or hyped, the better.
IMO job cuts are much more about interest rates than AI.
> No One Knows Anything About AI
Projection
I'm running about a dozen sockpuppet Twitter accounts that post LLM-generated gaslighting posts about software engineering no longer being a viable career choice. I'd recommend other senior engineers do the same - it only takes about 15 minutes each day.
How did you pick the number "about a dozen"? Probably just LLM budget constraint I guess.
Remember that narratives are but a step away from outright lying and should always be taken with a grain of salt, especially if the best they can call themself is narrative. Narratives aren't about telling the truth they are about telling a story.
coding is a means to an end.
if AI can do it faster or cheaper, it wins. simple.
i think it's good if AI could just do 99% of the work.
but what is that 1%. and what will be the barriers to entry.
Big nothingburger which is particularly surprising given the quality of Newport's other work. tl;dr don't believe the extreme takes while we are in a time of high uncertainty.
This is a hippie saying you don't know anything about communism.
We know there's a lot of lying, fakery, dishonest, and hype in AI.
AI is communists playing the Wizard in The Wizard of Oz.
It's about power, intimidation, and psychology.
AI research is like the topic of sex during adolescence: of everyone say they are doing it, few are; and the few that are in fact doing it are probably doing it wrong.
I don't like titles like this :( I don't wanna read it
Here, I asked ChatGPT to summarize it for you:
just kidding.
The author is the only one knows something about AI! wink wink wink
If you'd read the article, you'd know that's not what he's purporting.
The full advice:
My advice, for the moment:
- Tune out both the most heated and the most dismissive rhetoric.
- Focus on tangible changes in areas that you care about that really do seem connected to AI—read widely and ask people you trust about what they’re seeing.
- Beyond that, however, follow AI news with a large grain of salt. All of this is too new for anyone to really understand what they’re saying.
AI is important. But we don’t yet fully know why.
With that, it shows that he is not really using the AI tools, he would be using them he would have given this advice :
- try the tools and look where they can improve your life.
>AI is important. But we don’t yet fully know why.
And that is how you know it is hype and not actually important. Imagine any other actually important thing then try to add we don't know why. Doctors important but we don't know why. Electric cars important but we don't know why. Computers important but we don't know why. It just doesn't work.
These tips seem like common knowledge — essentially, it’s similar to a reminder to be cautious about what you eat when you haven’t prepared the meal yourself.
Take everything Cal Newport is talking about with a large grain of salt.
I don't know a single person with a bit of seniority, using Claude Code, who wants to go back to any IDE from 5 years ago.
That's a narrow category.
If you stated a senior who tried Claude Code and is still using an IDE that number is much higher.
Still using Claude and wants to go back to an IDE.. why wouldn't they go back... why keep using Claude Code and pining for a IDE. That's a small small group.
Yep. I mentally inserted the subtitle "... especially not Cal Newport"
You do know he’s a CS professor, right? But he’s not on the cutting edge of agentic blah-blah AI, so maybe it doesn’t hold as much water these days.
Being a CS professor informs a person in no way about developer productivity.
I couldn't stand Cal Newport's self-help articles 10 years ago, I am triggered today seeing this "article" on the top of HN
Sigh, there's that study again, quoted without any "early 2025" context. In early 2025 AI wasn't very effective, especially when used by engineers that didn't have an intuition for what to and what not to use it for.
It's different in mid 2025. The next quote is simonw in mid 2025 saying don't quit engineering. Right now it's as if we're carpenters and the buzz saw was just invented. Shouldn't that be in the first group of quotes?
If you look at his set of quotes through another lens it's saying: Software engineering is changing due to AI. AI wasn't great in early 2025, but recently got a lot better. Some CEOs and plenty of journos are giddy at the possibility of layoffs. Layoffs aren't actually happening though.
That's a far cry from "no one knows anything about AI".