Two narratives about AI
calnewport.com
calnewport.com
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.
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.
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.
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.
- 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.
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.
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
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.
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.
That’s a load bearing phrase
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)
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.
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.
That sounds like a contradiction to Brooks's law, which I don’t see being invalidated by AI tooling.
Former cloud data lake enterprise architecture & agile development experts as well.
True Renaissance Men.
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.
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.
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.
Which sounds an awful lot like politics.
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.
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.
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.
Personally I'd rather write a compiler than a specification, but to each their own.
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.
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.
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.
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.
so we need to program in natural language now but targeting some subset of it that is no learnable?
and this is better how?
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.
"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
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.
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.
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.
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.
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!
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.)
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.
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.
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
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.
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"
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
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
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.
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.
So, I don't know that the tools are inherently rightward-pushing
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
* 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'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
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).
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.
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.
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.)
> 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.
Now with AI they do.
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!
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.
It's almost enraging that with the hype around LLMs, the development of real automatic programming AI seems to have halted.
> 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-...
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.
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.
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.
Your analogy with programming makes little sense and distracts. It's better to discuss the actual point.
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.
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 ?
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.
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?
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.
LLMs.md
├── data_model.md
├── architecture.md
├── infrastructure.md
├── business_logic.md
├── known_issues.md
└── conventions.mdI 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.
> 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
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.
> 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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
One would usually show some kind of evidence after making such a statement. Claims from CEOs of AI companies don't count.
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?
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.
It sounds like a large part of the problem is getting your identity wrapped up into this. Both the CEOs and the devs.
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 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.
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.
* AI is the next electric screwdriver * AI is THE steam engine.
My pick is that the AI is not THE steam engine.
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.
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.
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 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.
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...
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.
> 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?
But poor as accurate source of knowledge or provider of accurate answers.
>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.
>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.
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.
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"
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.
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 what do you mean “done this to itself”. What is this?
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?
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?
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, now: "I can tell you didn't write that. AI did it!"
You really ought to make up your mind.
>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.
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.
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.
Projection
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.
just kidding.
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.
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.
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.
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.
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".