I agree with many perspectives in this thread. I empathize with OP. I’m scared about the future of my job and already feel it less fulfilling, despite being more productive than ever.
But I have one singular counterexample to most scary narratives and essays about LLMs writing software, which is my coworker who hardly uses LLMs at all. At least, he hardly uses them compared to me. He still writes most of his code by hand. He still greps around the codebase without claude code. Like he’s definitely using claude code, but only for like one-off specific tasks.
He’s a totally average developer, like everybody else on my team (including me). But he’s clearly more helpful than the rest of us. When people from other teams have questions about how something works, he’s always the first to respond. He’s always the one providing useful context in planning calls. He catches stuff in code review that I didn’t catch, and claude/copilot didn’t catch.
I think I’ve leaned too far into AI, partly because I’m a lazybones and am kind of burned out already. But there’s a stark contrast between me and my coworker that there didn’t used to be. I think the context rot is really setting in, and getting worse. So I think there’s still value in caring about the details
>> He catches stuff in code review that I didn’t catch, and claude/copilot didn’t catch.
This, I find completely unbelievable. Because we had (emphasis on had) seasoned engineers on the team who similarly eschewed AI tools and insisted on doing everything by hand in the manner you describe, well after the rest of the team adopted AI. Yet when it came to code reviews, even in parts of the codebase they were familiar with, the bugs they found often came down to nits, bike-shedding and opinion-based feedback (that they usually tried to frame as objective fact). They would also disagree with almost every AI finding, arguing that it was an unrealistic scenario or an edge case not worth worrying about.
Fundamentally, I don't think humans are going to be capable of providing high quality feedback on PRs authored by AI agents unless those PRs are fairly small in lines of code and volume. It's just way too much information and context for one person to keep in their head. I read a statistic that said the average lines of code a senior engineer can read and provide good feedback on is about 400 per hour, and that number goes down the more time they spend doing code reviews. So, to anyone who insists on trying to keep up with AI, I say: good luck.
You both have anecdotes. Anecdotes don’t “cancel” each other out.
Here’s a third one. In some of the code reviews I’ve encountered that AI gives a lot of feedback, it’s just providing noise. Things that should be ignored or when following the feedback causes more harm which requires more token to “fix” later on. That can also happen. Sometimes the thing it spits out goes against the common sense, and sometimes it works very well.
> So, to anyone who insists on trying to keep up with AI, I say: good luck.
This I agree with, for a different reason. It’s like trying to swim in a sea of honey and trash mix. It’s exhausting.
> Here’s a third one. In some of the code reviews I’ve encountered that AI gives a lot of feedback, it’s just providing noise
Something I've found fun is seeing how long it takes for an llm review tool to come back satisfied with a PR. Think 100 lines of code changed, nothing terribly significant, but also not trivial. I'll have a local Claude session setup to babysit the PR and wait for feedback, accept all the recommendations, push the change up and request a review. I cap the number of iterations at 10 just so I'm not blowing a stupid amount of money. I've yet to come up with a PR where the llm reviewer is satisfied with the changes and has _no feedback_.
So where's the reasonable cutoff point for llm based reviews?
Huh, I've had many times when `codex /review` comes back satisfied on the first shot, both with handwritten and LLM-assisted PRs.
We use only one round of LLM review, and have discussed as a team still assessing recommendations, not just accepting everything blindly. So somewhere in the (0,1] rounds of review. Sounds like our preferred ratio of human to LLM involvement is different than yours, though.
>> Here’s a third one. In some of the code reviews I’ve encountered that AI gives a lot of feedback, it’s just providing noise.
This is completely normal if you haven't written your own custom skill with instructions on what types of issues the AI should emphasize, which ones would be considered nits and which ones aren't a problem at all.
In our repos we use a classification system: blocker, should-fix and nit. Each one has specific definitions, criteria and examples encoded in the skill file. When the time comes to review a PR, agents invoke the skill, and frankly do a stellar job. A human then reads each finding, asks the AI follow-up questions and makes the final decision in terms of whether the finding goes in the PR review.
The reason I know this works is that we have one guy on the team who does not use this skill, and blindly throws his agents at PRs. And the results are exactly as you describe.
> This is completely normal if you haven't written your own custom skill with instructions on what types of issues the AI should emphasize, which ones would be considered nits and which ones aren't a problem at all.
> This is completely normal if you haven't written your own custom skill with instructions
This line of thinking comes from the assumption that LLM are somehow infallible and can’t be wrong, which is obviously not the case.
Writing skills and other magic incantations is the first thing that comes to mind of anyone who sees the review results for the first few times. What makes you think we didn’t do that?
Claude's code review skill, in particular, can find some good stuff. But it has some big blind spots around certain types of code. And it likes to come up with a lot of nits too—I think it's really really trained to try to always find between 2 and 8 things or somesuch. Good news is that it is very receptive to "nah" on the bikeshed ones and doesn't stick with them, but will stick with big issues. It'll probably bring up a few more nits though that it didn't bring up the first time!
But I can completely believe that someone who knows the code by heart would have a better signal to noise ratio on their reviews.
I'm trying to find the sweet spot because I've found some NASTY bugs Claude missed, and also had Claude find some nasty ones for me. And this is in codebases with tens-of-thousands of AI-generated lines of code + AI-driven reviews. So I want to bring both to the table.
The existence of some of these major "oh man that changes a lot of our assumptions" bugs that were only found because someone poked on the agent and said "I don't think you're paying enough attention to this" justifies that, IME.
And the better you are at pointing the agent at the truly-important parts, the better the agent's gonna be at finding shit you missed.
Claude's code review is a lot less interesting then getting Claude to reproduce the bugs it claims to find in code review, which has had an absurdly high hit rate for me.
The biggest problem I see with how a bunch of people use these tools is they go to them as an oracle, rather then letting them be plugged into and interactive with problem.
And it's in that later context that Claude is amazing: it can run tests and setup scenarios which would take days or get stuck in some weird problem loop. And then you can just say "okay, walk me through this problem" and see it yourself right there.
> The biggest problem I see with how a bunch of people use these tools is they go to them as an oracle, rather then letting them be plugged into and interactive with problem.
At work they have some scale of how "advanced" of an "AI engineer" you are.
IIRC, using the model interactively means you're stuck and "level 3." IIRC, level 5 (the best) is having some agent interview you about what to do, generate a story from that, then some other agent consumes the story and implements it, etc. I think you're supposed to check their work at each step, but that sounds inhuman and unfulfilling.
A lot of bugs are essentially that the code does something plausible correctly, but it's the wrong thing to do. People who are familiar with the codebase and its purpose can often spot those bugs. Those with less experience usually can't.
The issue is tacit knowledge, or implicit context. Most details are never written down. If you don't know them from experience, you have to guess. If you guess, you often guess wrong. And even if you know something from experience, you are often not aware of it, until you see something that violates it. So it's not possible for you to write it down in advance.
You can replace people with AI in the above, and nothing fundamentally changes.
Some holdouts excel at what they do to the point of retaining significant value, earnestly worried about being out of touch with what we do, some holdouts just suck and are bitter.
I deal with a lot of non-LLM users at work and quite often the conversation hits a dead end, where I'm like , ok but see, your app has this performance blockage due to your not having an index here - do some performance tests and you'll see (it was a hang caused by a FOR UPDATE locking the entire table due to lack of an index). And you can hear the pause (it's all over Slack) where they just aren't going there, because writing a performance suite for the issue in question would be a lot of effort to do by hand and in the "before times" would be a difficult undertaking to justify. Because they don't consider an LLM, a task they most certainly should be doing becomes a non starter. Never mind my own Claude had a whole plan ready to go to do this whole suite for them in about five minutes so they could study the impact of the index, but I really didn't want to just go ahead and do this all for them. At some point your non-LLM coworkers need to stare directly at work we'd never be willing to do before that's now trivial, and in fact is now part of the job.
Right, but performance testing has always been hard and LLMs are awful at it. So maybe your coworker was right?
I’m definitely on the “just use the clanker” end of the spectrum. But knowing when and is good. Constantly having to argue with people’s reposting of Claude’s idea of what’s wrong has left me burned out. At this point, if I have any idea about what’s going on and someone tells me “Claude says”, I will ignore them.
In this case, it sounds like you could have made a ten line repro that shows the problem. Why not just send that, something human interpretable?
What LLMs are you using? Just simply telling Sol 6.1, Opus 5.5, Fable or Astra to performance test something will get you a solid improvement in poorly optimized code.
Giving it a specific plan will get you a solid test harness.
And setting up an autoresearch system and running it overnight will get you expert level optimizations if you set the metric up right.
Performance testing has always had problems with isolation, mocking, covariance of services etc. I’ve just spent two weeks driving down latency across our framework, and autoresearch was definitely not a viable path. Most of these loops have these logarithmic, non-step change curves.
Just like with actual research, the real benefits came from me asking why is it like X and not like Y?
The original performance testing framework Claude created to bench our different versions against did not even mock high variance provider calls…
yes but you can use an llm to do the grunt work which still speeds up the process, you don't need to be like "computah speed this up", you can be like "computah, write me a profiling script using lldb to inspect this one hotpath and look for X, Y, and X" etc etc.
> Right, but performance testing has always been hard and LLMs are awful at it. So maybe your coworker was right?
LOL, you're making the same mistake they did. thinking "index" means "too much time spent fetching the rows". read again - it's a FOR UPDATE so the entire table gets locked and other processes get totally blocked.
> Constantly having to argue with people’s reposting of Claude’s idea of what’s wrong has left me burned out.
It wasn't just claude's idea, it was my idea too, the claude topic was that it would write a suite that proves the problem, in this case, very loud logging messages that were occurring for the customer when this quasi-deadlock situation occurred. it was not subtle.
> In this case, it sounds like you could have made a ten line repro that shows the problem.
no, it involved running a galera server and about four other services with a specific set of data conditions, again, read what I wrote, creating a proof of concept suite was not trivial to do by hand.
But why would you have to make the succinct suite by hand? Not what I was suggesting, I have gotten in the habit of sending extremely concise, human readable repro scripts made by Claude.
Partially because I can read and validate it actually shows what it claims to show, and partially because I expect people want to know what I’m telling them.
> I think I’ve leaned too far into AI, partly because I’m a lazybones and am kind of burned out already.
I've been doing systems / backend programming since I was 10 (in C in those days), so I was burned out by the time I was 20, and I'm now 40. The temptation to trade on that knowledge in a very short-term way is strong, but I know where it leads -- to the rot you describe.
This is rotten but I'm secretly glad that Claude et al are metering by the token.
I'm not sure that folks realize that the purpose of software engineering is to program in a way that doesn't just function, but optimizes for future readability, maintainability, and behavioral change in line with product requirements.
There's a reason why programmers are not paid "by the line", and it's because LoC as an incentive structure is a disaster that leads to brittle and verbose slop code -- and we knew that even before LLMs.
So I'm glad that the (long-term) economics mediate against token-hogging software by making it literally more expensive to deal with.
I just hope that managerial types are smart enough to realize that "time to understand/upgrade/change a codebase" still matters, whether that's expressed in terms of SWE work hours or LLM tokens.
I would not bet on the managerial types responding to anything but (a) blunt monetary incentives and (b) the latest buzz from other people in their general professional category, e.g. at the country club.
This is one (of several) reason why many larger open source project ban or severely restrict the usage of LLMs. They want contributors to fully understand the changes they are making.
Recently we have received several bug reports with AI suggested fixes. They looked reasonable enough and seemed to resolve the issue at hand. I then took a deeper look and discovered that every single suggestion only hid the symptom but did not address the underlying issue. Applying the suggested fixes would have hurt our codebase, so I eventually had to reject all of them and write my own solutions. This was only possible because I'm deeply familiar with the codebase and the broader context. Someone with less knowledge would have probably just applied the LLM suggestions without much questioning. I find this rather worrying.
I guess in popular open source projects the stakes are just higher than in some proprietory software that will be replaced in a few years anyway. The irony, of course, is that LLMs have mostly been trained on open source code.
Also, some of the projects I'm involved in are over 20 years old. One even celebrated it's 30th anniversary. This means there is also the question of historical responsibility.
I think the ideal state is a team with a mix of programmer types. Some are detailed focused and anti-AI, some are AI maximalists, some use AI for architecture but review carefully, etc. Just as people use one LLM to review another LLM's output, there is value to diversity of thought, more than ever.
Where things go off the rails is making sweeping workflow changes for all developers. Eventually we will realize that LLMs have the same gaps of insight and hit the same local maxima. More than ever, diversity of thought is necessary when everyone is outsourcing a chunk of their thinking to a nondeterministic parrot that is somewhat deterministic in its problem-solving
>But I have one singular counterexample to most scary narratives and essays about LLMs writing software, which is my coworker who hardly uses LLMs at all
Nice, but that's not a counterexample that refutes the scare narratives about LLMs. That one that prove their point.
> When people from other teams have questions about how something works, he’s always the first to respond. He’s always the one providing useful context in planning calls. He catches stuff in code review that I didn’t catch, and claude/copilot didn’t catch.
Who is dealing with the situation where people like this always-helpful colleague is now sidelined by the lazy liars now that AI allows them to pose as proficient ?
Since they're very happy to suddenly have the ability to "solve" problems and are now marketing themselves across the floor while the knowledgeable doesn't do this because 1) he considers it's normal 2) he's still busy reading and learning instead of waving hands.
You explained exactly the person that I am as well. Same motivation, same inability to use stuff I don't fully understand, same way of learning things, same feeling of emptyiness after LLMs appeared. It's wild, and I do not have an answer either. I just try to adopt and use the agent as some form of new processor for logic. And invent my own language around it for the logic harness to jail and align it properly, which is the only interesting thing right now to me as it touches fundamental principles of logic, information theory, computer science - but everything else, like writing compilers for regular problems, writing programs, writing code, are all dead uninteresting to me now, even though I exactly know that other people struggle to get complex stuff out of LLMs (like seeing this Theo spending half a million dollar in tokens on a TypeScript compiler that I could build in like a month for 1/1000 of the price), but this doesn't give me as much really to attack it - and the reason is, because once I solve it and publish it, people can just steal the ideas, the energy that went into it (all the thousands of micro decisions), this was not possible before on the same scale and needed the same brain power. This inbalance pretty much makes it impossible to me to release anything anymore as open-source.
Maybe you can help me understand. What determines the flight level of understanding you need to function? Obviously you don’t need to know everything down to the last atom cluster (in objects), or down to every last line of assembly (in software). Why does a clean interface with a contract not suffice? What really distinguishes a low level library from a higher level one, in that sense?
Working on platforms of sufficient scale, there’s a lot happening that’s out of your control. You can build the mental model around it, but it will contain a lot of black boxes where an abstraction hides details.
Generated code changes this, probably, but I’m curious by what degree.
For me at least I have to be able to believe I can understand any part of the stack if I want in reasonable effort. I would happily dive into semiconductor physics if I happen to want to (I'm a former physicist so the atom level I pretty much already learnt at school).
Honest question: What is preventing you from understanding any part of the stack now?
You could potentially ask an LLM to explain it, but I would venture a guess that wouldn't feel like the right source to help you. You could use the LLM to help you identify source material written by humans in order to learn anything new. It doesn't have to "do all the work for you".
Modern AI systems are powerful. They are not omnipotent or omniscient. Understanding the details is still valuable, especially if you want to push the frontier of any known field.
In any event, the situation isn't hopeless. At least not yet. :)
> You could potentially ask an LLM to explain it, but I would venture a guess that wouldn't feel like the right source to help you.
I don’t think this works, at least for me. Even on the 5.5 versions of Claude it’s still arduous to read at this point.
> You could use the LLM to help you identify source material written by humans in order to learn anything new. It doesn't have to "do all the work for you".
This probably depends on the shop, but humans aren’t writing docs anymore. That was the first thing to go, sadly.
I hear what you're saying. I often tweak the CLAUDE.md file to improve the quality of its output. It's an ongoing experiment.
As for "humans writing the docs", you raise a good point although it's not quite what I imagined when I wrote that line. I was thinking more about having the LLM/Agent create a list of verified output by humans with reputations as experts in whatever field interests you. This is important when pushing the boundaries of research, although it's overkill for wanting to know whether or not a new technology could be useful in your existing project (or the next one).
What use case did you have in mind when you brought up the docs situation? Sounds like you had some direct experience with that one.
I think a distinction is clearly emerging between docs intended for humans, and docs intended for agents. The latter is where all the Markdown-ridden slop should go; I'm not insulting humans with that.
You can ask frontier models with all the bells, whistles, language servers etc to give you every example of X. And it gives you 12 examples and says that's all of them. When you know damn well there are at least 40 (but not exactly how many). So you say no, you know it has missed some, such as X23, and X27. So it goes away and comes back again and says yes, there are 41 X, here they are. How much digging should you do to see if its right?
I have many times gone looking myself to find that it has still missed some. Asked it to go check for those, to look harder it goes oopsie and says now im sure ive gotten all of them (has it?)
All this to say, I have been burned, repeatedly, multiple times a day, for the last year+. I still use these tools, but I truly cannot understand how some people treat them as oracles that know everything about our codebases
Excellent points. I agree that frontier models get things wrong all the time. They are NOT oracles. I believe that we need to encourage our peers to become sophisticated operators of these systems, instead of treating the output like Moses and the 10 Commandments. Perhaps we need more specialists, because the major AI labs lack the incentives to venture down the long tail of knowledge. Agents can be a piece of the learning puzzle, despite their imperfections. Again, thanks for your reply. It gave me lots to think about.
You need to define the goal in a way that you will trust the completion. If you are not sure how you yourself would verify that there are 41, then you are in trouble. Verification must be deterministic, or it's worthless.
What the large models do really well nowadays, is that they won't lie to you if your deterministic verification fails. If you tell an OpenAI or Anthropic model that they need to run a certain `grep` or search or whatever command to verify, then they will do it. I haven’t seen them lie about this for a year, and trust them in this.
Surely you can see that for basically every example of this sort of problem, fully defining a deterministic check is the same as finding them all?
Like you're telling me if I had a script that printed all X, and it's my responsibility to ensure it has no bugs, then the agent could tell me all X and I could trust it?
This is not helpful at all? I am capable of running scripts myself and using the output directly.
No? It's like saying "why bother doing maths, a calculator can figure out the solution to any question you have if you just put the right equation in" there might be more to maths, it turns out. Most of it lying inside of finding "the right equation"
In many case it is the sheer accidental complexity. I tried to get into Linux codebase and gosh it's so much harder than FreeBSD. And Chromium, LLVM... I don't believe it has to be that way. I use Common Lisp software (besides Emacs) written by human for anything I can and these have always been a joy to use or work with.
It seems the way industry is heading towards wrt LLM will make this even much, much worse.
It's the Mad Hatter's tea party, you sit down, you figure out how it works, and then poof a third of its gets overwritten and your past investment is significantly washed away by someone who absolutely didn't put the same amount of thought into what is replacing it.
A strict, formal, reproducible way to communicate with the machine.
A compiler is a rather predictable piece of software; reproducible builds are a thing. An LLM has approximate knowledge of many things, and approximate and fuzzy ways to do anything even moderately complex. This is great for research, ok for planning, and it sucks for execution. The fact that LLMs can write satisfactorily working code from high-level requests is a miracle, and, as with most miracles, we're likely not noticing something, being dazzled by the slight previously unseen.
Not OP but similar type of brain here. Certain types of abstractions make me uncomfortable, the worst being "trust me bro" type web framework abstractions where there isn't a direct link between A and B, just a contract definition that says "A and B will integrate... somehow".
When an API says it takes something, I need to know the exact form of that "thing". Saying "you can give it this object" doesn't suit me because where are the edge cases, where are the interactions, how can I know for sure I'm giving it what it needs. The docs never tell you where to find the object def, then you spend 3 hours diving into the source code to understand it's just a two item struct or something.
LLMs introduced an explosion of complexity, suddenly code bases sprout out of nowhere, and there's no point in following all the different datapaths through because the guy who loves testing out the latest claude will just change everything in a few days anyway.
With low level programming, nearly everything is just raw data, aligned to meaning. I like to tell juniors confused about file types, that file types are a social construct, they're just a bag of bytes with some structure. Same thing applies with low level programming. You know what a byte is, you know the endianness, the signedness, you can feel comfort in knowing you're not missing anything, and then you build up from there seeing each block build upon the previous.
> I like to tell juniors confused about file types, that file types are a social construct, they're just a bag of bytes with some structure.
I always get confused about what the hiring landscape looks like. How is it that people are grinding leetcode or whatever just to get into places, but still have those kinds of gaps in fundamental understanding?
Because even prior to LLMs, “knows how to program” and “understands computers” could be disjoint. I worked with someone who didn’t understand how to find what was consuming their disk space, nor how to fix it, or most egregiously, that they needed to empty the Trash (MacOS) to actually reclaim the disk space.
I'm not in a field where leetcode is the deciding factor but there's similar gamified focuses. The idea being you can pick out self-motivated autodidacts with those kinds of challenges/experience in the challenges, then fill in the connective tissue later.
This was just one example of a capable intern who was tripped up by file types.
> No one confessed the Machine was out of hand. Year by year it was served with increased efficiency and decreased intelligence. The better a man knew his own duties upon it, the less he understood the duties of his neighbor, and in all the world there was not one who understood the monster as a whole. Those master brains had perished.
- E.M. Forster, _The Machine Stops_
Abstraction is terrific and terrifying. It is the shoulders of giants we build upon, but when it begins to scale nonlinearly I fear it endangers us as much as enraptures us.
> You know what a byte is, you know the endianness, the signedness, you can feel comfort in knowing you're not missing anything, and then you build up from there seeing each block build upon the previous.
IMO you’ve chosen a flight level you’re comfortable with (which is fine!) but there is much going on below the abstraction that lets you view a file as a bag of bytes.
I’m saying this as someone who uses SwiftUI and CoreBluetooth on a daily basis, and I have to trust these foundations just as you seem to trust the C compiler and a filesystem.
Not the person you are responding to, but for me I really like to have a general understanding of how things work under the covers, but then have confidence that the contracts between me and those lower layers are rock solid, and that's simply not the case with LLMs.
Take software. In college I took computer architecture and digital logic design courses, and I thought they were immensely valuable in understanding how computers actually work and what software is actually doing. Sure, modern chip design is obviously several orders of magnitude more complex that what I studied, but I understand the basic concepts, and more importantly I have faith that chip designers do understand the nitty gritty details. Moving up the stack, I also had to build a rudimentary compiler in college. Again, modern compilers are a lot more complex, but I know that if something breaks, there is an identifiable bug either in my code or the compiler (or maybe even the chip). And importantly, while I may not have the skills to debug all the layers, when someone explains the bug to me, I can understand it in context (e.g. I'm not a chip designer but I thoroughly understand how Spectre is exploited and mitigated).
LLMs are nothing like that. Not even their builders understand the low level details. They're inherently stochastic systems, so people get slightly different results every time they're run. There is no "clean interface with a contract". And perhaps most importantly, many programmers are still expected to be responsible for their code, even when AI agents are generating so much of it that it's impossible to understand (or even read) it all. That's the thing that really stresses me out, when I'm responsible for a system but I don't really understand how it works.
To me the reasoning of understanding all the things you use in a rock solid way is hard to grasp.
You just typed some text and hit send. You trust that the combination of letters that form words and the combination of words that form sentences, arrive somewhere in a list of comments? But do you understand how those bytes (utf8 or utf16 or..) are transmitted (which endianness, how are they packaged, does it use sentinels or length codes), where do they end up (database, plain text), how is the text organised (alphabetical, by data, by points...)? In fact you are not sure about any of those. Still you typed and hit send. So how is that much different from writing a prompt and hit send?
So first of all, when LLMs first came on the scene, I did want to understand them better. I read the Attention is All You Need paper, I did Karpathy's transformer course, etc. And I think this basic understanding of LLMs and further reinforcement techniques makes me understand better how to use LLMs, e.g. what their limitations are, etc.
But most importantly, there are very different qualifications in my head for things I just use and then get on with my day, and tools that are integral to things I am building. I take the bus but I don't really understand how a diesel engine works. But if I'm building it, I'm responsible for it. In fact, you brought up some networking issues in your comment. For a long time when I was a software engineer (primarily a web developer) I felt that my knowledge of network engineering was lacking, so I specifically took some courses in network engineering to better understand how my code interacted with the network. You also brought up text encodings. Once at my job I did a full, rabbit-hole deep dive into text encodings and localization because we had frequent bugs related to localization, and I still find a lot of developers misunderstand a bunch of the important details in localization (e.g. the difference between an encoding and a unicode code point).
But sure, I don't need to understand every minutia of detail at the atomic detail. But I really like to know that I could, and in the meantime I have a enough of an understanding to build a complete conceptual model in my head.
Now consider the case where I send you a message (in a language that's not english) and it doesn't render as text on your screen. Reasonably, because I understand how network protocols work, I can assume that it's not a little/big endian mixup between our systems - the HTTP request would not have worked, then, as utf-8 and utf-16 are incompatible (unlike the weird utf-8 ascii mix). With HN, I can open up developer tools see what encoding it is sent as over-the-wire, and then I can ask you to look at the encoding on your end. I can say "the vibecoded browser you use is trying to interpret this as utf-16 but hackernews only sends utf-8". I can dial down the root cause of the problem and then address it.
Contrast that to a situation where I ask an LLM to use a tool and it can only do it like 98% of the time. How do you root cause that. How do you fix it such that that doesn't happen again?
Also consider: occasionally your support agent gives people free plane tickets.
Yes, we've made a lot of progress towards LLMs being fairly good, and adversarial systems and such do work, but it is asymptotic approach to 100%, never actually 100%
> What determines the flight level of understanding you need to function?
The level where r and fl are seen as different letters?
Look, I know this comes off like I'm being an ass, which means I am being an ass, and I'm sorry. I also make many mistakes and need much forgiveness.
I'm also seeing many more innocent typos such as yours on HN. Does it matter? I don't know. Every other response to your question seemed to understand that you meant "right" instead of "flight", but that's also the kind of error, i.e.
`if x=1` instead of `if x==1` which is easy to make but not always easy to catch visually when you are looking at the logic internal to the loop.
To me, bending "right" to "flight" reads like a fun way to clarify that the question is not about proficiency but about depth. Not a typo the way I read it.
This was actually helpful: I thought "flight level" was some new hip expression that I had not seen before. I was pondering what "flight" added there; is it like the hexagonal architecture that is not actually hexagonal?
But sure, "right" makes sense in the circumstances.
Not the GP, but I think I have a similar urge to go deep in understanding details. I definitely find myself different than many peers who are more comfortable operating with ambiguity.
"A clean interface contract" is actually all I need to stop pulling the thread, but I find that is rare in large software systems. More typical is that the provided interface lacks details about edge cases, such that multiple behaviors could meet the interface. That's what makes me want to dive deeper and figure out what those cases are, what I think is the best behavior, and what the system actually does.
Huge part of it. A big part of my idea of the negative impact of the internet in general is that it constantly exposes you to people who are doing the same things you love and are interested in, just way better and more effortless, alongside yet more people criticising even these golden gods for this or that failure you could only hope to reach.
It's an imposter syndrome machine, but one you could perhaps tune out because it wasn't really useful for much except entertainment. LLMs bring the experience of being followed around by that machine talking into your ear any time you have an issue or problem - you could just ask your fabulously talented friend to do it instead. And they are sadly tremendously useful so keeping that mental compartmentalisation is way harder
I think there is a basic human need to to be "the guy" everyone goes to when they need help with a specific thing. Where "everybody" is roughly a Dunbar's numbers worth of people, a tribe or a village if you will.
We've developed fabulously effective ways to wrench the fulfillment of this need away from a huge amount of people
I think programmers are frustrated in part because the code used to be our place to do our thinking, but now LLMs just buzz through the file changing thousands of lines and we can't keep up.
It's still valuable to deeply understand parts of a program, but we don't have any tooling that helps us do that. We just have to raw-dog it by thinking really really hard and remembering how all the code connects together.
I want a tool that gives programmers a place to record their thoughts. Developers need a place to draw and write, and also interleave blocks of code that automatically update to match the actual state of the code.
The closest thing I know to this is org-babel, part of Emacs, which allows you to push code blocks out of an org file into an actual source files, or pull them in from actual source files. This is mostly done manually by invoking functions called `tangle` and `detangle`.
I intend to investigate this further in Emacs, since I'm an Emacs user, but Emacs is never going to be the friendly UI we need to make this tooling common.
Yeah, I can relate to this. However, I haven't found it too difficult to adjust. I have found myself creating draft PRs, and then just sitting on them and thinking about it for a day or two before I even consider merging it. This lag time is the time that I used to spend typing it out and thinking as I went along, now that's happening later. I have closed more than a couple of my own PRs once I had time to consider them. I am rarely shocked when I wake up the next day, look at it, and think: "Eh, this change is not sufficient because it doesn't address X".
No, indeed. They rely on LLMs to do that, and that necessarily adds a degree of entropy that will eventually cause the thing to vibrate apart, but much later, in the future. Meanwhile, the incentives are to fix (or "fix") the bug now.
Oh yeah. The AI hype cultural moment will wear off, but we'll be stuck with the technical debt, cognitive debt and slop code, which has made it into critical production systems, for decades, probably.
The code--as long as you don't try to modify or evolve it, engendering further nondeterministic degradation--will mostly work, but 0.01% of the time it won't, and you'll never be able to predict when and where that'll be.
> now LLMs just buzz through the file changing thousands of lines and we can't keep up. It's still valuable to deeply understand parts of a program, but we don't have any tooling that helps us do that.
I do it differently, I focus on better recording what the user wanted, the so-called "user intent". To do this, I record all messages typed by the user since the start of the project, whether 3,000 or 10,000 messages. An LLM can churn through them in 10 minutes and derive a fresh, up-to-date interpretation from the raw data. This can be used to judge whether the implementation has diverged from the intent, or, in other words, to realign the code and tests. The messages the user writes are usually designs or corrections, a very rich, compact signal. If the user struggles with something, it could result in a tool, a skill, updates to the project docs, or new tests.
But a codebase is a state machine, and given the somewhat random style of LLM outputs, those amplify to an extent that the recorded intent needs to include the outputs too, in a way? Or are you basically doing high detail specs?
The workflow I use to still keep up with everything is to start coding by hand and only once I have a good idea how the rest is gonna look like and am bored I had off the rest of the pr to the LLM.
Could be just defining the methods without filling them but depending on the mood I code more by hand or less.
> It's still valuable to deeply understand parts of a program
Part of woe is that once you've reviewed, validated, and comprehended a piece... Later gets casually mangled by some other LLM-generated urgent change.
Yes to this. With the speed of ai code generation, the team has to decide not to rip things apart in every pr even though it is possible, since this destroys any hope of maintaining even a bit of understanding.
Some parties mean that making understanding irrelevant of the whole goal of ai driven development, though.
I feel like we also need better non-LLM driven ways (like better static analysis tools) to analyze LLM-driven changes. The way changes are presented in modern IDEs was designed around reviewing human-created changes and doesn’t really feel like it’s keeping up with presenting and validating what modern LLMs are doing.
I've been playing with often asking Claude to generate visualizations for me of what it's doing in the sense of diagrams of different types. Sometimes it's as simple as "show me what you're doing using an infographic". Othertimes I'll ask it for sequence or class diagrams or bipartite graphs if it's designing some sort of mapping. Bipartite graph is also very helpful for following the plan of a big branch rewrite or squash which I often do before making a PR to get rid of all those confusing in-between commits.
I find forcing it to visualize things immensely helpful. I'm usually studying git diffs but when working of a big feature or refactor that can just be too hard.
I've never been very pro "visual programming" and always hated UML et al, but part of me is starting to wonder if it's time for us to give it another serious go.
UML is not a terrible idea from a systems architecture point of view but UML is absolutely terrible at describing business logic. And in today’s age of CRUD apps and frameworks, for some devs, business logic is the entire problem to be solved.
What is “valid” input? What is the failure scenario at the boundary for the consumers of your application? How are exceptions in the business handled? All of these are questions that might have a somewhat obvious answer, but if your goal as a business is to do something radically different compared to your competition, the “obvious” answer might be the wrong one.
The usefulness of UML is highly reliant on the names you choose. And current LLMs are really, really bad at naming things. "The collector's refresh cycle has a bug: when the cache hydrates, the Cartesian grouping is misaligned" type nonsense - it absolutely will name a class "CartesianMisalignmentHandler" if you let it, good luck understanding what that is on a UML diagram
> I want a tool that gives programmers a place to record their thoughts. Developers need a place to draw and write, and also interleave blocks of code that automatically update to match the actual state of the code.
I think the solution is still code, just at a much higher level of abstraction. Maybe a start is kind of typed ADR or FSM that guides (constrains) the agents.
I believe more type checking guarantees will be more and more important for agents.
I don't think the solution is code, because I still want a place where I can write my own chain-of-thought, without it having to rise to the level of "code". I just want to put my chicken-scratch drawings and diagrams somewhere. I just want a place to think that won't change out from under me.
> It's still valuable to deeply understand parts of a program, but we don't have any tooling that helps us do that. We just have to raw-dog it by thinking really really hard and remembering how all the code connects together
Which is frankly exhausting to do when you have to keep up with the rate of LLM changes
I can sling code at about 20x speed with an LLM, but I can only understand it well enough to support it at 5x speed and I can only make decisions that won't piss off the rest of the company at about 3x speed. My job as a software engineer is to therefore slow down to working merely 3x faster than before despite the extra headroom that the LLM gives me. Anybody can give into the seduction of new features poorly understood, to be a specialist means to bother spending the extra time.
Or at least that's the current model I'm playing with.
This is my dilemma as well currently, because there's no obvious place to draw that line. The boundaries are all subjectively defined.
I could change a whole UI completely in 30 minutes to something fundamentally better but then 30 people would all wake up and be upset they weren't consulted and need training for it. That training and consultation will take hours and hours. And probably generate feedback - some of it correct, some of it misguided - that needs to be human negotiated, taking more hours. The effective maximum rate of change is limited so dramatically more by other factors than the technical implementation that we have to completely redesign process now to cater to those factors.
We are in a weird space now because most of the process is still built around a presumption that technical implementation is a lot of work. The main reason to be upset that you weren't consulted about a change is because there's a presumption that you will be stuck with it - ie: it's a lot of work to change it back. But it isn't a lot of work, it's effectively free. All this is just living in inertia right now.
I've been handling it as a sort of voluntary A/B test.
A is what you're used to, B is what I recommend. If I can convince people to start using B instead, I can look at the metrics for A and conclude that it's effectively dead, and then I can remove it.
It's working out for me, but maybe not a fair comparison because I only have something like 15 users.
Yeah it's an interesting one - I have had the same thought process. If code is free, and I trust the tests and the review process, why not deploy a different branch to production for every user that wants one? it's only at the point where shared resources such as database schemas conflict that it becomes an issue, but a large slice of user requests don't even touch those. If something gets deployed broken in one branch, someone can flip branches and use the one that works. As long as the system maintains strongly enforced safety boundaries, a thousand roses can bloom outside of those boundaries.
It does beg the question where it all leads however ...
> But it isn't a lot of work, it's effectively free. All this is just living in inertia right now.
... but it isn't free. You're introducing a certain amount of entropy and drift every time you let the coding agent loose on it. There's a hidden cost of loss of cohesion that comes with changing anything and then changing it back, and while that cost exists with human developers, too, the pace at which they work and think limits the damage and the risks. LLMs just compound them, but the consequences are long-term, while the incentives are to do the thing now.
I've been having agents build knowledge graphs, they're a tremendous mess to start with, but I take the time to manually drag nodes around or group them in meaningful ways so that it's actually human-browsable. This is boring enough to create space for me to think in. It leads me to go on expeditions into the code which surface the missing details. It's also a nice way to communicate context to agents. Like, I can hide all but the relevant nodes from an agent before suggesting that it query the graph to understand which service references which other service via which api, which database tables are read/written by such an action, etc...
Curious, how do you do this? What tools are you using to build and manipulate the graphs, and how do you feed that context back to the agents? The manual organization part sounds particularly interesting.
I find that there are domains where LLMs are much faster and more skilled than I am, particularly in extremely well-documented but technical and complicated, but a lot of domains where they cannot do anything at all (mostly novel issues, weird architecture issue resolution, etc.).
Building a basic X11 window manager is almost a one shot prompt.
Modifying a UI toolkit to make it work with MSAA/IA2 is simply not possible.
There's a lot of room for deep work left... for now.
When you say this is simply not possible you sparked my interest. I would be curious to chat about your approach?
If I were trying to accomplish this particular goal I would first consider what the agent could see. In particular does it have an accessibility inspector of some kind? or even NVDA hooked up with NVDA Remote so that it can actually see the implicit a11y tree for the toolkit it is working on? My email is in my profile and I would love to chat about this.
> It's still valuable to deeply understand parts of a program, but we don't have any tooling that helps us do that. We just have to raw-dog it by thinking really really hard and remembering how all the code connects together.
I deeply relate to this. When engineers were writing all the code that meant every part was deeply understood by _someone_ on the team, and they could valuably contribute to maintenance and further development. It wasn’t perfect, people leave, people forget things, etc, but the overall coverage was high and valuable.
Now, every agent-produced MR introduces code that is deeply understood by _no one_. It’s the “original developer left five years ago” problem, but now growing on every single new piece of code. Reviewing doesn’t give you the same depth of understanding, and the continually increasing impulse is to just approve, maybe nudge it about some isolated enum types or something, but don’t take the time to understand it, just keep the train going.
But then what happens when something breaks and the cloud agents are down…
> It's still valuable to deeply understand parts of a program, but we don't have any tooling that helps us do that.
Doesn't the LLM do that, if you want it to? I do use it to write code, but the more striking ability it grants me is a means of understanding legacy code far faster. I can ask "what actually causes this branch to be taken" and it's usually right. Ok sometimes it's not right, but I'm not always right either even after I spend tens of minutes reading code.
It's also exceptionally good (i.e. fast) at looking through git history to figure out where/when a certain behavior originated, which can be difficult (time consuming) if code is continuously being refactored.
Sure you could use it to vibecode. I don't, rather the opposite, I understand my own changes better. But I still fear that I'm going to be obsolete as soon as it figures out what questions to ask. And I'm unwittingly training it to do that.
> But I still fear that I'm going to be obsolete as soon as it figures out what questions to ask.
Code and business requirements, outside of maybe very pedestrian CRUD apps, is diverse enough that I don't see that to be a realistic concern. A far bigger concern is that it may not matter whether they're asking the right questions, and that sufficient brute force can overcome any objections like 92% of the time--good enough for government work, good enough for the MBA frat boy who lords over you and always saw you as a needlessly expensive typist anyway...
To the extent that I set business requirements, it's me helping people with vague ideas make them more concrete. But that's not enough work per year to keep me on the payroll.
In my case the questions I'm talking about are lower level questions about the code that are steps along the way to achieving whatever higher level goal we've agreed on.
Agreed. Coding agents are an excellent tool for navigating an codebase to deeply understand the code (certainly better than grep!). My existential question is more about whether deeply understanding the code is worth doing at all. If your identity as a programmer was based around being the one who understood the code the best, why is that valuable when anyone can use the agents the same way?
The annoyance I have is that it isn't one of the other. I spend a lot of time thinking and fighting with whatever frontier model we're on today. I've seen people let LLMs make absolutely atrocious decisions and just click next and collect checks.
I just posted this morning about this type of engineering has secured us numerous customers and put some projects in our backlog that either need significant rework or at least a very close eye to see if their issues crop up.
IDK, the idea that we shouldn't be thinking is a worrying one. I still have to think a lot.
What I'm _mostly_ worried about is that the path to get to high performing senior is basically a burned bridge with our current training techniques, and I'm not sure we'll adapt before a brain-drain situation in the industry.
Not exactly what you asked for, but I now keep pencil and paper next to me, and that has been incredibly refreshing for brainstorming / mental processing
This piece is either a psyop or written by the victim of a psyop. I believe the former is more likely. It establishes for granted that LLMs produce more optimized code than performance-oriented humans do. This could not be further from the truth, and I think any human who writes low-level performance-oriented code knows this. It's not even remotely close to being close; LLM code is abysmal if you look at the details. I think the only way you could come to this misconception is if you were not a low-level programmer; certainly LLMs can produce more optimized code than whatever abominations JS devs do, although even this is not a given.
Take, for example, Claude Desktop and Claude Web. They recently bragged about reducing their first paint from 4500ms to 1000ms. For an interface that displays text and sends/receives HTTP chat requests for more text, let's remember. This is from a frontier company that can allocate infinite compute to the frontier models consumers don't even have access to. Let's not get into how it consumes gigabytes of memory. We wrote more efficient GUIs than this in the 80s with 128kb of RAM on a 4mhz CPU.
These despair pieces do not reflect reality in any form, and they're so far from reality that I believe this is more likely to be an article written intentionally to deceive people who don't know better than it is to be genuine. Performance engineer jobs are not going anywhere. LLMs are not generating better compilers nor better kernels than what exists. They're producing insanely inefficient CRUD garbage.
> Take, for example, Claude Desktop and Claude Web. They recently bragged about reducing their first paint from 4500ms to 1000ms. For an interface that displays text and sends/receives HTTP chat requests for more text, let's remember. This is from a frontier company that can allocate infinite compute to the frontier models consumers don't even have access to. Let's not get into how it consumes gigabytes of memory. We wrote more efficient GUIs than this in the 80s with 128kb of RAM on a 4mhz CPU.
Developer tolerance of low performing software has been a problem since before LLMs though. The whole industry seems to think O(seconds) is a perfectly acceptable amount of time to launch a program. For decades, as computers got more and more powerful developers tolerated proportionally poorer and poorer performance. There's almost no such thing as a "performance-oriented human" anymore outside of a few niche industries, and nobody is really producing and sharing much hand-optimized high-performing code anymore, so it's no surprise that LLMs trained on the Internet are not good at it either.
I think it's tied to the fact that many developers are given unreasonably capable systems (compared to end users) for running their software, or else exclusively test on small data sets or without considering resource limitations or real-world situations.
I've seen plenty of product demos that work fine with test data, but once you introduce real world things like: 200+ concurrent users that need to do more than just navigate to the 3 most easily demonstrated screens; application is hosted at a data center in another state; making that hosted system be a shared tenant; introducing data of real-world complexity; making the client system be a system spec'ed for a basic office worker 5 years ago; installing web filtering and other applications and not only running your one application.
Suddenly, loading N,000 records into a dynamic gridview table on a page load becomes a real bad idea, and the occasional needing to view logs or audit trails that reach N,000,000 records to load into that same dynamic gridview table means the site just times out.
It's a similar reason why you can sometimes find that you have to scroll right and left on a site. Well, that's because the dev has multiple 32-inch monitors in 4k or 8k, and they're not designing the interface for the 1080p laptop screen that most of their userbase actually has.
> You could dream all you want about how you would write better version of claude desktop. Fact is: you didn't. And you never will.
I already did, actually. I work in an LLM startup that produces small models for specialised purposes and I wrote our frontend interfaces, which are vastly superior to both Codex and Claude's interfaces. Unlike OpenAI and Anthropic, we are profitable, turning 8-digit revenue with zero outside investment. We have complete ownership, without tens~hundreds of billions in expenses and debt. Excellence in software still has a place in the world, even if the VC darlings get most of the attention, because at the end of the day consumers and enterprises alike will pay for software that truly works well.
Yes, if you one-shot some code with an LLM, it can be terrible. But if you let it profile and optimize it, there is no obvious limit. LLMs have more patience to investigate performance issues and fix them than humans.
Again, I wish this wasn't so, but I see it in my job daily. There is code in my projects that is vastly faster because of LLM optimizations. Not only can they find more in less time, but they find things I and my co-workers would not have thought of.
I'll take your claim that I'm capable of writing a psyop piece as compliment :) Truth be told I'd rather be writing a psyop arguing the opposite point than dealing with these emotions.
To your main argument: I absolutely agree that LLMs are terrible at producing working code, or efficient code, and that they're incapable of solving lots of important problems. I've seen LLMs make embarrassing typos, patch vulnerabilities with differently vulnerable code, and go through the motions of optimization as if blindfolded.
That is, however, not the central matter here. IMO, at present what management thinks LLMs are capable off has a larger impact than what LLMs are actually capable off, and while I'm hoping that the market will regulate itself once more and more slop projects break down, that'll take time, and I'm not confident that LLMs won't improve sufficiently by that point that the most glaring mistakes will be fixed. Of course, new and non-obvious issues may still be present, and they may cause trouble at a later point, but again, that won't happen immediately and I think we'll just end up in this infinite loop for the time being.
I will also add that AI companies' claims affect the general public's perception of the acceptable level of software quality. If Anthropic says 1000ms is great, and other companies follow the same approach, people will consider that the norm and not demand better software. This enshittification has started a long time ago -- just look at how bloated Windows and the web are -- and I don't think it's going to end just because we know things can work better.
Taking a step back, I think it's really a question of how many people will understand the value of what people like you and I can deliver. That number has been falling bit by bit before the LLMpocalypse, but now it's just becoming abysmal.
I understand the fear that perception matters, and it does, which is why I take issue with articles like this and use terminology like 'psyop'. You are effectively harming your own cause when you write things like this:
> If anyone can point an LLM at slow code and it automatically finds a hot loop and uses a trick it found somewhere on the 'net to vectorize it, there is little point in hiring someone with a focus on that.
If you yourself are saying there is no point to hiring you because an LLM can do what you can do, when it actually can't, you are actively contributing to the perception you don't want to proliferate. And although I am financially set from my own work, I am also opposed to that perception proliferating because it is wrong, and the discourse around blatantly untrue things is extremely tiring. We need to bring perception closer to reality, not perpetuate the divergence of perception from reality. OpenAI and Anthropic have an extremely vested interest in influencing both industry and consumers to believe things about their products that are not true, because their dubious financial future is staked on people believing those things, but we don't need to help them along.
> LLMs are not generating better compilers nor better kernels than what exists. They're producing insanely inefficient CRUD garbage.
Exactly. People always talk about how LLMs can produce CRUD user-apps and then say, ok there's no more reason for humans to write code anymore.
These CRUD apps are the most trivial, simple things. The AI agents make inferior, bloated, unmaintainable, and unreliable versions of these simplest of things which have already been done to death.
There is a a whole other realm of programming innovative tools, performant systems, truly insightful solutions that people will need to keep working on. No AI agent swarm is creating the next FFMPEG, or coming up with and implementing the whole idea of using monads and do notation. They're not creating true progress (spam-solved math proofs have yet to hold out as solid and useful), only making half-baked, inferior copies of the patterns that are already out there.
Saying, "Some programming is being replaced by AI agents therefore all programming will be replaced by AI agents," is a big converse logic error.
Even if LLMs aren’t producing more performant code today, them solving frontier math problems (especially discovering new optimizations) suggests they’re close. You can algorithmically judge performance, and recent advancements have been in the algorithmically judgeable.
LLMs recently optimized integer multiplication and matrix multiplication beyond the known theoretical limits.
If you tell them to optimize and give them evals and targets, they will optimize. And they will be more thorough and diligent about it than you.
We're all going to have to cope with the fact that LLMs are now better at programming than us. It is professional irresponsibility to not use an LLM in 2026.
> We're all going to have to cope with the fact that LLMs are now better at programming than us. It is professional irresponsibility to not use an LLM in 2026.
As a categorical generalisation, this is absurd. Much depends on much, and the devil is in the details. In certain domains, this might be true, though the word "better" is doing a lot of work there. It is certainly not true in all domains; my consulting practice, where code is written by hand, is thriving, and my clients are mostly AI companies who have discovered the limits of "vibe coding" in this particular area.
Thank you, this is coming close to my own reaction to the article.
Folks reading this: none of this bullshit and hype is inevitable. You don't have to be delusionally enthusiastic about something just because a lot of people around you are.
Absolutely right! Honestly, I hate AI even though it COULD make me 10x more productive in what I do. I can think of a dozen tasks that AI could help me with.
Audio processing for instance: I process audio by hand, it's more of a rote task, and it takes me hours a week to do it. AI COULD give me what I want in probably one minute. One minute instead of one hour.
But firstly, I've built up my audio processing skill over years and I enjoy it. It's calming. It's not creative, thinking up new stuff-type work but it's calming. And secondly, I want to do things myself. I don't want to let a machine do everything so I can concentrate on the high level stuff.
In fact, what I've found is that my mind works best when I'm NOT concentrating on high-level stuff. When I just go about my tasks by hand.
Do I write code to save time? Yes I do. But I write the code by hand and I understand how things work from first principles, as far as possible of course.
So, I don't use AI. AI could take away hours of work for me and I don't use it because I hate it and I hate the idea it represents.
Your comment feels like it was written 18 months ago.
A vibe coded typescript compiler runs twice as fast as the one maintained by two dozen people led by some of the most brilliant language and compiler experts out there backed by thousands of open source contributors.
All of that by saying "here's the tests, implement it in rust".
> Your comment feels like it was written 18 months ago.
AI bros have been making the same claim for the last 3 years. It wasn't true then, it isn't true now, and it won't be true the next time either. You just aren't willing to admit the emperor has no clothes.
> It establishes for granted that LLMs produce more optimized code than performance-oriented humans do.
I didn't read the piece as claiming anything of the sort. I read it as claiming that employers don't care.
The author is well known around here and has demonstrated quite a bit of low-level technical proficiency; see previous submissions https://hn.algolia.com/?q=purplesyringa.moe .
On the one hand, the Claude code thing was indeed a weird brag, because they took shit performance and made it suck slightly less. It's not in the same ballpark as getting a 2% boost in an already highly optimized system (e.g. Google search results page lets say).
But it was also a tale of simply needing to tell the models what to care about. They built metrics (I'm sure they vibe-coded them) and then told the system to optimize itself to those metrics. And it sort of worked. Of course most LLM code is not performant by default, you still have to prod it to optimize itself. You can't one shot it yet. But nothing about the trajectory of this stuff tells me it won't get there some day soon.
I also thought that, and then I started pointing Claude at various projects and having it look for optimizations. The projects themselves were, of course, largely AI-generated. What I found was that simply asking it to improve performance could indeed help, but if I pointed out specific architectural issues - like storing massive graphs in a giant JSON blob - and then recommended a solution (normalize, store in SQLite, recursive CTEs to walk it), the performance ceiling went WAY up.
Now, you could argue that AI didn’t fix that, I told it what to fix, and it just wrote the code. That’s valid, I suppose. The view I’m coming around to is that LLMs do know how to write performant code, but their corpus is so full of garbage that you have to tell it explicitly what you want, which requires you to know how to spot the problems and solve them.
I will not make any claims that they can write kernels or compilers well, because I haven’t tried to do either of those, on my own or with an LLM.
Another anecdote: yesterday, I got tired of dealing with Mumble on my LAN (random audio issues on the Mac clients, poor echo cancellation, etc.) and asked Claude to build a replacement. I gave it a rough spec, including non-goals (private use only, so no encryption needed, and I don’t care about supporting a large number of clients), then told it to build it in Rust, supporting MacOS and Windows both natively. Two hours later, it worked. Not just kind of, it worked flawlessly on Macs and Windows, and the audio quality and echo cancellation was perfect. The only bug I found - which it fixed - was denormal numbers was causing relatively high CPU (~1/2 of a core) usage on Windows due to x86_64 handling of that. The binary is 5 MB. It ran its own echo cancellation training while writing it to tune parameters. It implemented RFC 2198 without me mentioning it (hell, I didn’t even know about it - it’s fascinating!). When I fed it back some logs, it saw that one client had higher latency than expected (meshed WiFi without a backhaul), and then proceeded to create a network simulator so it could test various latency and jitter scenarios to solve it. While doing so, it also determined that Windows was lying about its latency numbers by 25 msec, and addressed that.
So again, I think LLMs are capable of excellent work, you just have to know what you need to ask for.
Actually LLMs are creating better compilers than what exists. In 2 weekends I let a LLM write almost fully compliant re-targetable C23 compiler (except for a few C library related things that are worthless for its targets) with state of the art optimization for five 8 and 16-bit fairly different architectures. For PIC16F/18F it's slightly better than XC8. For 8051 it's waaay better at optimization than industry standard Keil C51, and of course sdcc. Dev process found several pretty startling miscompilations that XC8 is prone to. And it's tiny. Codebase is like 0.5 MiB with data file for all ~1100 PIC microcontrollers that normally take gigabytes in XC8 taking 350 KiB.
So it's optimized both on code/data size needed for the compiler, which is like 3 orders of magnitude smaller. It has better coverage of C23, and it produces smaller, faster and more correct code. :)
>>“I didn’t care about practicality, building useful programs, or writing code per se: all I wanted is to understand how the machine works.”
I like lifting heavy things and moving them around. In fact I like it so much it’s a massively effective buoy for my mental health. However, I don’t expect the economy to make space for me to move farm equipment around to make food and expect to get paid a living wage doing it.
Software like food is now a civilizational requirement and transient LLM crappiness notwithstanding, accessing well-built flexible plentiful software is a major unlock for humanity.
I’m happy now to go the gym and lift heavy things and let everyone have plentiful food grown by mechanized agriculture. I’m looking forward to do the same for my intellectual pursuits.
the problem is we refuse (americans) to let things that we need to be civilized to be in the public domained, "owned" by government and pushed into our "free" spaces.
Libraries are the last time americans agreed on basic principal that a public space with a public good is worth investing in everywhere.
Honest: racism. Social services would benefit black people. Since 60s "integration" half the country has convinced themselves that cementing pools, literally, is better than letting black people integrate.
It comes in lots of flavors but it all is a facade against allowing black people benefits.
That's certainly honest, but isn't remotely accurate. I know plenty of people who are opposed to social services through the government (note the qualifier there), but are perfectly happy to have black people in their lives and communities. They simply believe that social services are best provided by private charity, not the government.
Great sentiment about reserving intellectual heavy lifting to your personal life. I've always valued keeping enough in the tank for myself (and now my family) outside of work.
It seems in our profession there might be less satisfaction from work, but if it leaves me with more space to accomplish things in my own time, I think I prefer it.
If you do intellectual things only in your free time, well, working people don't have much free time. One of the perks of software development (and other LLM-impacted professions) for nerdy types is that it allowed them to do intellectual things all day, and even get paid for it. Now all those hours at work are no longer fulfilling.
> It seems in our profession there might be less satisfaction from work, but if it leaves me with more space to accomplish things in my own time, I think I prefer it.
I wonder why you expect to have more space to accomplish it. What happens when the managers realise that they can get more 3x, 5x, 10x, whatever x more software?
Also, let's briefly revisit the source of all economic value: scarcity. If you can kick your feet up more, you can't expect to be paid as much for it.
I could have done many different things as a career - I chose what I do because I love(d) it. I think many of us were raised believing that a job you love is not a job and we’re now grieving the loss of fulfillment that came along with doing something you love and getting paid for it. I spend far more time working for people I don’t know than I do with my family or my hobbies, and perhaps I was foolish enough to think I’d escaped from wasting my life doing something I despise. You are correct that we can all seek fulfillment outside of work, but for those of us that used to get it there it hurts, or maybe it’s just me.
I know things get worse before they get better - but some of us are at the point in our career where we likely won’t be around to see it get better again.
I think you're right. And no, it's not just you. You've tapped into something very central and animating about software as a craft, and the cognitive and psychological feedback that got most of those who are really good at it to be interested in it in the first place. I share your sense that we'll probably not be arounds to see what "better" looks like, if it ever even happens.
Personally speaking, I started my programming journey a long time ago, building stuff for DOS - one of the first-ish things I did was build a Windows-like GUI interface, which was quite functional given the circumstances, basically writing pixel colors to the framebuffer in C.
The whole thing was quite functional, and a few thousand lines total, and built a bit naively - the framework and the app were under 10k lines combined total.
Later I tried rebuilding it for Win32, and it ended up being more code (sans bespoke UI framework), and I'm not sure it was better, though I'm certain, the whole mass of code doing the thing was an order of magnitude more.
If I were to attempt building it in Electron, I could add 2-3 orders of magnitude to that easy, all for the same basic functionality.
All I'm saying is abstraction isn't really what it's cracked up to be.
It didn't (fully), but adding it wouldn't have been more than a days work. You have a hierarchy of enclosing layout rectangles, you take an invalidation rectangle, and you recursively intersect children and them draw them with the painters algorithm.
Vestiges of the system did exist, as there were scrollable panels and controls had an idea that they were not visible due to falling outside of their parent rect, and all drawing functions were aware of being clamped to a boundary box.
So I'd say some of the hard(ish) stuff was already done, and people did end up using it in production so it actual survived contact with a paying customer, which is saying something.
Partial redraws are mostly a waste of complexity at this point. It's much faster easier just to re-layout and re-draw the whole thing in a frame. It can be done in a millisecond if you're not beholden to the browser.
Why do you look forward to this happening to your intellectual pursuits?
If I grant you that cheap plentifull code will be a net boon to humanity, it's still normal to be unhappy that it's you specifically that will need to be ground-down in the cogs of progress. 5 years ago I also believed that the future could (and would!) be vastly better for many people, I just didn't know that betterment would be conditional on me losing the work I enjoy. In that sense LLM's are only a loss to me.
Many people feeling equanimous about this stuff are financially secure, later in their career or working at a manegerial level. That's fine, but at that point you're obviously not suffering the same pain as the author.
I think personal lament is different from organizing to stop what is good for civilization.
There is a lot of the latter happening so my comment remains relevant.
“I need to block abundance for all because I don’t feel safe with change”
is probably the most dangerous sentiment coursing through our civilization right now, and it’s coming now for me, and this is my rationalization from giving in to my baser instincts.
The few already have Abundance. I don’t care about them.
I’m talking housing, infrastructure, shipping, medical care, all critical services and sectors where fixing decades of lagging productivity will help the working class the most.
But AI is touted as the replacement for the working class? It’s TAM is “the combined wages and salaries of everyone below the C-suite” and it gets trillions of investment dollars, and letters of marque for copyright infringement and hacking, to pursue this market.
I mean, just look at the sequence of events you’re expecting here:
1. Ai companies achieve their stated goals
2. ???
3. Housing, infrastructure, medical care, etc get better for the working class
Are you the king of the underpants gnomes or something? How could it ever turn out this way? Why does anyone think it would? Am I taking crazy pills?
If those goals are fully eliminating need for human labor, then I agree it probably won't be good for most people. But that will probably take at least decades.
Anything short of that, and I think economy will be pretty similar to what it is now. You still need working class and need it to be productive, so you do need them to be reasonably happy, housed, healthy, and you need good infrastructure. With lower cost for all this, why wouldn't things improve, like all times throughout history?
Not parent but I could image an (utopian?) society in which AI/LLM helps us develop software and hardware that can help generating better and cheaper outputs in those fields. Not saying it's going to happen but it could be a possible outcome.
“Are you the king of the underpants gnomes or something?”
No I’m just at the frontlines of this so called “replacement” and all I’m seeing is people doing more with less with no possibility of replacement. I have no idea what all this marketing pablum about TAM replacement is. All I’m seeing is growing businesses serving more people with less resources.
Could it be that CEO’s of struggling businesses are lying about why they’re doing the layoffs? Why are we suddenly believing them on this one issue?
Who says that just because production becomes cheap anyone but the few will benefit from that? The few already control AI, what makes you think they will share its bounties? Why would they? The goodness of their hearts? The same guys that are sitting on their pile of gold like a dragon right now while countless die every day from things their resources could've fixed? What makes you think they'd suddenly change their behavior?
Every technology revolution since the Gutenberg press has followed the same pathway? There is no evidence AI is any different. They had oligarchs back then, hell they had feudal lords backs then!
There are definitely transient upheavals as civilization adapts to the new norm and we can do much to reduce those effects.
But the end result is the same, more of everything made cheaper for the working class.
We are at the tail end of a 50 year productivity plateau and rising costs. We’re looking down the barrel of the first reduction in the QoL for our kids. I for one want to see what this tech has to offer.
I completely disagree with the way you frame this.
The "abundance" is not all positive valence. It is a flood of superficial good with an unmanaged ratio of negative byproduct mixed in.
Some of the "change" is not merely doing things a bit differently. The LLM flood is effectively attacking existing feedback and control mechanisms without any attempt to establish appropriate replacements.
I think there are several more dangerous sentiments coursing through civilization these days:
1. That people bear no moral responsibility to act in good faith, and the corollary that one can enjoy the fruits of production while externalizing all the liabilities.
2. That strategies like "move fast and break things" and "fake it until you make it" are universally applicable and appropriate, rather than only in the low-stakes entertainment/media/marketing fields where they flourished in recent decades.
3. That mere acquisition of capital gives one the right to perform N=1 experiments on global civilization, the economy, and the enviromment.
“The LLM flood is effectively attacking existing feedback and control mechanisms without any attempt to establish appropriate replacements.”
I think these are problems to be worked on and they are being worked on. The work just looks boring and will not make any newsfeeds anytime soon. Our systems are changing and adapting as we speak.
See my other comments as to why that sentiment is the most dangerous sentiment. It’s easy to point to the problem of oligarch’s or clearly labellable “bad actors” and incompetence.
But neighbors agitating to block housing, unions blocking productivity enhancing technologies? Much more difficult to treat these as a “problem” as they are just a mass of historically disenfranchised people protecting their interests. But they are doing wide damage, and that same sentiment is now coming to software developers.
What is civilization if not the amalgamation of people?
If sentiment around people is that they don't want this (and that seems to be the case, based on many many articles like the above, as well as opinion surveys), then who are you to tell them what's good for them?
People don't seem to want an improverishment of mind and soul in exchange for vague promises of some sort of other abundance.
> Why are they being forced to that dubious trade?
Because it's just the prisoner's dilemma in disguise. Most people don't really like the idea of AI, a lot of people especially outside of programming hate it, and I bet deep down inside a lot of programmers would prefer if AI never existed.
But it's easier to say that AI will bring great wonders because the alternative is acknowledging the reality - the diminishing returns of technology. And that brings a lot of cognitive dissonance if you're a programmer.
I'm not sure it maps well to game theory. I think it's more of a false dilemma.
There is the old adage in many academic fields that "progress happens one funeral at a time." It's an age-old, rueful take on how our own learning and adaptation proceeds within a collective society. It is a rendering of an objective truth seen at the intersection of evolutionary processes, memetics, and the human condition. It is not a call to action.
Sometimes, I think the most worrisome thing is the ever so slight possibility that some clever, naive upstart will hear this adage and, rather than ponder the lesson about patience and complex social systems, instead conclude that the short path to a lot of progress is a bunch of killing.
Even if we ignore the obvious psychopathy it takes to embrace such an idea, it is still fantastically myopic. Yes, in a hypothetical way it might happen... after the great chaos, some new civilization might emerge with an impressive growth spurt.
But, it is infantile fantasy to believe that such chaos can be applied in a goal-directed fashion, or that the perpetrator(s) can expect to survive it and enjoy the result. Nobody can control who nor what knowledge passes through the gauntlet, nor what direction it spins after that.
What troubles me most, perhaps, is that the current zeitgeist makes me think some people are oblivious to these caveats.
It wasn't programmers who brought us the idea that all problems, obstacles and goals can be conceptualised as an insufficiency of code, apps or gadgets, without any thought to politics, negative externalities, institutions, or philosophy.
That came from SV technocrats and associated capital owners.
Not even touching your caricature of the AI argument, but “most dangerous sentiment [in] civilization right now” is a crazy thing to say during the current global political zeitgeist.
This argument spans AI, housing, infrastructure, scaling medical access, the whole shebang of critical solutions to 21st century problems is held back to couch the discomfort of the few.
Whether it’s neighbors blocking housing, union bosses blocking port automation at the height of COVID, medical association’s controlling doctor quotas it’s the same sentiment, a fear of change.
I grant that a healthy distrust of the (capitalist) parties involved is fine but the reaction when given power is the same, veto: Stop everything now. Change is scary.
That's a very, very narrow view of software. The firmware inside an internal combustion engine control unit did not take someone's job away. The software to assemble genomes from DNA fragments did take someone's job away. Nor did an MP3 codec, a game, or a search engine. All this stuff gave us more than we had before, it wasn't just automating existing capabilities.
Even when software has been used for automation it's been done to eliminate boring labour, not creative work. Eliminating jobs like switchboard operators or coal stokers is a good thing because those were unenjoyable and even dangerous jobs that nobody wants to do.
> The firmware inside an internal combustion engine control unit did not take someone's job away.
Of course it did. Cars and motorcycles used to need to be taken to the mechanics all the time. Now they just run and run without issue, thanks to what you mention.
> All this stuff gave us more than we had before
Absolutely. Just like all automation. It takes away jobs, but increases production. That's why it's worth it in the end.
> Even when software has been used for automation it's been done to eliminate boring labour, not creative work.
Yes, and now AI is eliminating the boring labour of programmers. Will they come to terms with the fact that their jobs are unenjoyable and nobody actually wants to do them, like the coal stokers and switchboard operators?
But I agree with you that there are some outliers within programming that go beyond automating jobs and processes. Like the examples you give.
Cars still need to be taken to mechanics all the time. In fact, I'd hazard a guess that there are far more mechanics now tab there were prior to ECUs.
> Yes, and now AI is eliminating the boring labour of programmers. Will they come to terms with the fact that their jobs are unenjoyable and nobody actually wants to do them, like the coal stokers and switchboard operators?
If it was just replacing the boring part there would be no problem. In fact, we could just use it to replace the boring bits and give ourselves more time to be creative and do the human part. The danger is it ends up replacing thinking completely, though.
I wonder if you've ever done a truly unpleasant job like those mentioned? Have you never written software that has made people really happy because it makes their job less unpleasant?
I've personally been working on software to help with cancer treatment for the past 6 years. You can't even say I'm taking away the jobs of undertakers because people will still die anyway and demand for healthcare is never going to decrease.
The enjoyable part of a job is receiving the salary. That's how it is for many or even most people.
> I wonder if you've ever done a truly unpleasant job like those mentioned?
I've had some of the worst jobs you could think of, and I was proud that I could make my own living and not depend on anybody else.
> In fact, we could just use it to replace the boring bits and give ourselves more time to be creative and do the human part.
That's the ideal outcome. However, there's limited demand for that. "Grunt work" is still what's needed mostly, whether done by man or machine.
> I've personally been working on software to help with cancer treatment for the past 6 years. You can't even say I'm taking away the jobs of undertakers because people will still die anyway and demand for healthcare is never going to decrease.
You probably took away potential jobs from administrators who would have done the things manually which your software does. Or if you're a better programmer than your peers, then you took away the jobs from the two programmers which would have been needed to do the same job as you do by yourself.
What I'm saying is that working as a programmer is about automation and efficiency and that means taking away jobs. Just like the steam machine and everything else we've automated. That's why nobody cries for programmers now that they are being out-automated themselves.
Can you put yourself in other people's shoes and see how it is offensive that tech workers now demand continued employment at comfortable jobs with high salaries, when there is no longer any demand for them? Instead of being grateful for having enjoyed such a good situation for many years while others haven't.
I fully expect my own job to be replaced by AI in the coming years. It's inevitable, and I can only be grateful for what I've been given and that I had the chance to enjoy a comfortable job while it lasted.
Honestly it just sounds like you're jaded after years of working meaningless tech jobs. It's not all like that. I've been working on improved early detection of cancer. Humans are totally incapable of detecting cancer that early; it's not taking automating any existing job. You can do good stuff with computers. It's not all about shovelling shit that people don't need, although all of big tech is, sadly, about that, of course.
I'm sorry that you think the enjoyable part of work is getting paid. Again, it's not all like that. A lot of people's jobs give them satisfaction from seeing jobs getting done that aren't easy. Nobody wants to be machine, we get joy from using our brains to solve problems.
The bad part about AI is it's replacing the need to think. I think everyone is going to get depressed when they've all forgotten how to think.
I don't work a tech job, and I'm enjoying my job and find it meaningful. But AI is already becoming capable of doing it, so it will be only a matter of time. What can I do, force customers to pay us to do something AI can do for "free" and just as well?
The enjoyable part of work getting paid was in reference to coal stokers and switchboard operators, these professionals you mentioned who were happier to be replaced.
> You can do good stuff with computers.
Of course! I'm not arguing for nor against automation and machine replacing man. What I'm saying is that programmers are the group who should be the last to complain, as that is what they've been doing to others since the beginning.
And many or even most of them realize this and do not complain about these new tools.
> I've been working on improved early detection of cancer. Humans are totally incapable of detecting cancer that early; it's not taking automating any existing job.
That sounds amazing and congratulations for doing it!
This is like saying the steam engine took people's jobs. It did. Industrialization created even more. This isn't a vouch for industrialization or capitalism but software has certainly enabled all kinds of new classes of creativity and opportunity.
Exactly! So while people would have empathy with people losing their jobs to a steam engine, would they have empathy with workers at the steam engine factory losing their jobs to an automatic riveting machine? Would they have empathy with a steam engine designer losing his job?
I found that since LLMs can produce any code I want, I don't really feel the same drive to learn React or whatever is popular and trendy to make myself useful in a new job. Instead I feel like I have the space to play with something that I enjoy instead, like learning Z80 assembly and writing games for the Gameboy that I would have wanted as a kid. I think you're right that it feels just like going to the gym, intellectually.
Yes, but in terms of your marketability--even in a world with LLMs--it seems to me that learning React or whatever is popular and trendy is quite vital. You can't propose good architectures in /plan or review slop PRs in React without knowing React to a level of depth that could only come from having toyed with it, and thought in code.
It is still an open question though exactly how big the need will be to propose good architecture or review slop. I petsonally think it will still be important, but it will vary by application for sure.
This metaphor does fall apart somewhat when you consider that farm tractors are not made from farmhand muscle fibers, whereas LLMs are in fact made out the stuff they’re rapidly replacing.
No, but I think you could tell a sufficiently compelling allegorical / metaphorical story about how farm tractors, in destroying the livelihood of farmhands, might as well have pried their muscle fibres out of their live bodies.
For sure. No, there's a tragically awful irony in the fact that the clankers run entirely on the (unpaid for) intellectual output and cognitive labour of humanity, white-collar professionals, academics, specialists and creatives, yet the idea is that these people are supposed to be obsoleted by the clankers.
Can you show me something, that is not just a one-off or demonstration, that is well-built? Code that is a joy for humans to read? That is not a harness or anything like that, but something we wish we could have gotten made this well so easily before, and that we now have?
I want to be intrinsically motivated too, and I am a good bit of the time. But let’s not pretend intrinsic motivation is an infinite well. We can suffer intellectually from a lack of places to socialize our pursuits.
> If anyone can point an LLM at slow code and it automatically finds a hot loop and uses a trick it found somewhere on the 'net to vectorize it, there is little point in hiring someone with a focus on that.
LLMs are not very good at performance issues unless you walk into it with a clear idea of the likely root cause and the bigger picture regarding actual hardware and desired customer experiences.
"Please make the code go faster"
vs
"I am noticing what appears to be contention between threads under workload A, B & C, but not with workload D".
These are completely different universes of capability and outcomes.
Even if an LLM can fight its way to the answer on its own, you can achieve a specific desired result much faster and with significantly lower risk if you are genuinely an expert.
I've seen a concrete example of this recently. I profiled the client's product "the hard way" and arrived at a change to a single line of code that would eliminate a mutex issue. One of the client's developers used the LLM and wound up with a change set that touched hundreds of files, but otherwise achieved approximately the same performance fix. The other developer even had my hint that it was a single file change and couldn't figure out how to do this despite prompting a leading edge model regarding this exact possibility over and over.
Taste and aesthetics apply to absolutely everything. Not just UI/UX design. Perhaps it is even more important that we care about the things that are invisible to the customer. It is certainly easier to forget about them or treat them like they don't matter as much.
Not every optimisation is the same. LLMs can optimize code that is behind known practices, but won't usually invent new data structures or algorithms to solve a unique problem.
While it's unlikely for LLMs to implement patterns not present in their training, current training techniques absolutely can produce practices and data structures and algorithms that humans have never done before. Modern LLMs are not just trained on text. They are trained on computer use, including - at a high level - solving programming problems with code. They are not just rewarded for producing the most likely next token. They are rewarded for producing tokens that solve problems. Patterns and techniques can emerge from this that are not present in any human behavior.
They are rewarded for code compiling, thats about it. Thats why the code is terrible. Ive yet to look at a project made by an llm whos user swore this "frontier model is the one", where the code wasnt utter garbage. The heavy llm users dont care as long as it compiles.
The fact that you're pointing it to PyTorch code in the first place is being specific.
Pointing a frontier model to a 10 or 100MLoC codebase and saying "make this code fast, make no mistakes" doesn't work. As an experiment I recently tried this with a relative small (500KLoC) codebase and it got stuck on believing that the primary cause of slowdown was the database not using a connection pool. (Which was completely irrelevant for this specific code.)
I am sure people could find code such that an LLM can optimize it 10x fold. I have seen many types of code in my life (well written, horribly written, fast, slow, etc.).
I do feel there is a limit to LLM-s today. I did not try, but I doubt it will work if I would tell it "make me a web browser that is bug free, perfectly secure, works as efficient as possible on my architecture and has best UX for me personally".
Knowing where that limit is, is as hard as it always was knowing how fast a team of engineers was going to do a project.
I felt there were limits 4 years ago. I couldn't get even an 8k context window.
It's starting to feel like the important gaps are the only ones left that need to be closed before there aren't any left. It also feels like next year they will start meaningfully closing.
> I did not try, but I doubt it will work if I would tell it "make me a web browser that is bug free, perfectly secure, works as efficient as possible on my architecture and has best UX for me personally".
I do feel there is a limit to human-s today. I did not try, but I doubt it would work if I asked literally any programmer I know "make me a web browser that is bug free, perfectly secure, works as efficient as possible on my architecture and has best UX for me personally".
Hell, I'm willing to bet they'd fail at this task even with an unconstrained snacks and kombucha budget. Humans have a long way to go. My job is safe.
This doesnt even apply to his issue. What does PyTorch code have to do with complex concurrency or complex systems in general.
Theres lots of bad Pytorch code, just go ask george hotz. This isnt the magic you think it is. And nobody wants to hire the guy that just points llms at things and says make it faster. Things have value because talented humans make them. Its why a luxury coat is worth more than the linens that make it, or one from walmart made by a machine. This will 1000% apply to programmers. I think OP will be fine.
I don't know why but in Typescript when I tell an LLM to write code to check if a character is of a type, it often uses a whole Set() instead of just using a string and doing indexof. It's weird because not only should strings be faster, doing it with strings should also be the prevalent way in the dataset. Yet it uses a Set.
Grief is exactly what many engineers (not just programmers) are going through right now. They (we) are going through the process of coming to terms with the death of something we loved - not a transformation, but death - and figuring out what comes after that.
This isn't about having trouble adapting to change, because many engineers going through this are adapting just fine as far as others can observe, adopting LLMs, changing the way they work and whatnot.
The grief comes from either that new normal being something they don't identify with anymore, or that new normal being just... different. The former will inevitably prolong the grief, while the latter will eventually result in the grief subsiding (even though some sadness for what was lost will never really disappear).
We're being asked to adapt, but perhaps we should just accept that things are not going back to what they were, look around, and decide not to do the things we used to love in a new way that we cannot love. Others might not even notice we chose that path, and think we just "adapted".
> We're being asked to adapt, but perhaps we should just accept that things are not going back to what they were, look around, and decide not to do the things we used to love in a new way that we cannot love
I would love to take this path but unfortunately I have to make money to pay my bills and afford to eat. I don't know how I would afford to keep my home without continuing this career, as mangled as it is now thanks to AI
It doesn't have to mean abandoning this career. For example, if you used to program because you love the details and the control, doing the same with LLMs and pretend it is still about details and control will make you miserable.
But you might be able to choose to leave that to others, and fill some other role in the development process where you don't have to pretend.
I think this is true for some programmers. For others like myself, the change and constant radical improvement is what we loved about technology in the first place. I'm essentially living the dream I had when I was 5 and saw Wargames for the first time. Sure, it was fun to program by hand but now we have AI, which allows us to do even more amazing things and we're very early in the curve there.
> Grief is exactly what many engineers (not just programmers) are going through right now. They (we) are going through the process of coming to terms with the death of something we loved - not a transformation, but death - and figuring out what comes after that.
Very well put.
A large part of that "what comes after" is grappling with the next hard question: after the death of the craft we loved, are we - our skills, our intuition, our problem solving - even needed anymore?
Even if we still are now, will there be a time when there also won't be a place for us?
I believe we're still needed, because AI has no "want", no intrinsic motivation, therefore no real sense of alignment with real-word goals. Without us humans in the loop, the industry would become self-drinking beer.
Whether or not the folks with the money agree with this is another issue...
The new normal involves fewer and fewer humans in the loop. So it's not just that things are changing and we need to adapt, I think the world will be able to get by with a lot less labor (more capital though). It's not like we're losing a fun hobby, it's a living. It's ikigai but more importantly it's food in the table.
Some seem to think we'll just get 10x as much done. But I just don't think there's that much more stuff that actually needs doing. We won't build 10 Google Mapses, and there aren't 9 other apps that have the utility of Google Maps.
(Please debate me on this as I don't want to be right.)
We will build more small mods and variations. Ideally we won’t rebuild the codebase 10 times, but 10 different people would like their Google Maps to be slightly different.
You need to have millions of people using a complicated app in order to find and fix all the bugs, I.e. millions of people sort of share in/amortize the bug discovery load. This doesn't work if everyone has a unique complicated app, which is also sorta what happens if you just allow every UI thing or behavior to be controlled by a setting.
Ignoring that, I still don't think minor tweaks for my own Google Maps adds so much more value that you continue to pay developers the same amount you do now. That is, the value of personalized maps is not 10x generalized maps, so how do the economics keep working?
I also tend to believe that the market for SW developers will shrink.
In Europe, the AI revolution is hitting at the same time as an economic crisis triggered by expensive energy which is in turn making companies cut costs / local positions and outsource to cheap locations.
The idea that more SW will be built is likely correct, but it might not be a well-paying job or be done in Europe at all.
This is the kind of person for whom AI is making the most negative change. I feel sad for them. For me, I love this new world. I never took pleasure in craftsmanship or perfectionism, I just want things to work and then iterate on it with as little effort as possible.
I find it a breath of fresh air to be able to tackle backlogged tech debt items simultaneously with business priorities in parallel and stuff like that.
That being said, I can't see this entire field existing in five years anymore. I'm hoping for at least two more years, but who knows?
This stuff is coming for all white collar, the barrier to entry is completely gone now. Maybe not the barrier to mastery (yet), but the bottom has fallen out.
... could never have had a proof attempt presented without the mathematicians setting the stage and working to verify the proof.
I think you might be viewing AI and humanity as a zero sum experiment. It's really not. Go read some David Brin (Existence is a good start). We don't know all the positive and negative aspects to come, but we aren't in a dark forest situation. Existentially, AI is here, what are we going to do with it?
I see sentiment like this (which is valid; it’s a different perspective), and then I look at my company’s current caseload of breaches and how most of the (insane) increase in business we’ve received is caused by poorly coded apps with obvious security issues, along with the inability of orgs to remediate those issues or adequately follow incidents because no one actually knows the applications anymore.
And I’m wondering if this isn’t the enormous amount of organizational debt from having security second to everything finally coming calling.
I’ll give you an example of one that was written recently actually.
The initial compromise happened because the app explicitly did not verify auth claims when a specific string was in the ISS field. Well, fuzzers exist and are common.
The next issue was that once you’re in, there was no delineation between admin and regular users. Everyone had all privileges if they just made the calls.
Anyway, we did the usual post-remediation investigation and write up. The devs were of course using the latest models, as they were instructed, and the issue stemmed from a problem they’d been having integrating a specific company into their auth scheme.
Eventually, after many enumerations, the model opted to just skip auth altogether if that companies ISS was present. The devs, being in the habit of just accepting the changes did so and because of the nature of the code implemented nothing caught it in the pipeline.
This is sadly an incredibly common story and it won’t be fixed by models improving I don’t believe.
Not in security, but "vibe coding remediation"--that's the best way I can think to describe it--has been a booming business in my line of work (SIP/VoIP infrastructure engineering) as well.
How long it'll last, I can't say, only that before LLMs, the industry entered a phase of consolidation and quiescence that had me seriously worried about a fade into irrelevance. The delusions of businesspeople and the managerial class about what LLMs can do has fueled a very nice business renaissance, as they run into the limits but have committed to contracts, business models, etc.
I agree, and the field possibly not existing in 5 years is a big issue. Like, how are young people supposed to take a mortgage, start a family, or any other big commitments like that, if their whole education and work experience may be useless in a couple of years?
I don't care whether I'm writing code or reviewing LLM generated stuff, but the prospect of losing my job and having to survive on welfare for the rest of my life isn't nice.
From my perspective this is the thing that the people who have been talking about how good these damn things have gotten now were trying to get you to do all along. Understand that they're getting better, it doesn't seem to be stopping, and we really, really need to figure this part out ASAP.
What seems to happen though is it always gets pulled into a discussion of "But they can't X" or "but ma taste!" or the old generic canard "can't replicate what's not in the training data"
All I want is for people to see that yes, this is happening, accept it, then figure out what a good response would be to it. Instead we get everything from stochastic parrot parrots to "Dario is just marketing when he tries to warn us" to the old an thoughtless "But if you think it's bad, why are you doing it?"
> except learning another job which isn’t (yet) doable by AI.
Why? Why are jobs necessary? Who needs to have them? Should we pay people to be stopgaps/just in case jobs in case the machine fails (probably?) -- who organizes that? Do we have a human economy and AI economy? How to keep them decoupled? Does this mean stamping provenance (who made what onto what?) should be a core of the future? Right now? What does that look like? Are there other things we can do to ensure we get the Banks future and not a shittier one? Is the Banks future a good one? Is disempowerment a real concern? If so what do we do about it? Human reserves? Zoos?
I do not have answers, but I know the questions are vastly more interesting than "what job will the AI not be able to do" wtf PLEASE
Taxing profits of companies that use AI probably. I really don't see other way, if AI starts replacing human work in large enough scale. In that situation, without welfare there will be soon nobody buying products and services, leading to an economic collapse.
I _am_ a craftsman - software, wood, and a few more domains. There is a lot of personal satisfaction I find in woodcraft through the motion and the exercise. I love that this is a luxury hobby instead of a personal necessity. The difference there is that if I take my time on personal necessity where the market isn't paying for it, I may take food out of my kids' mouths or lose the roof over their head. Luxury craft hobbies face only self-imposed pressures.
AI is letting me build similarly. I can continue to craft my Rust and my Python and my Typescript and my Fortran to my heart's content - and those skills help in the day to day - yet I'm also able to compete in the market and build things that were really infeasible before.
> How are you keeping your “human” addition to the loop valuable, is it through the time spent on the software craftsman hobby?
Yes, and, integrating it into my normal tasks and delivery. Some principles:
(1) I wouldn't worry so much about staying _ahead_ of the technology, rather, focus on the outcomes for yourself and the people you serve. That gives a more holistic and natural boundary when you research and adopt the technologies that help you get there.
(2) I'd also focus on adopting what works best, not what is latest and greatest. Tech regressions definitely happen[1], and you know your need the best.
(3) When quantifying, cost-benefit is typically focused on Benefit / Costs - 1 to give incremental lift. Unsurprisingly, if benefit is high and costs are higher, it might not be worthwhile to adopt!
[1] https://roderick.dev/writing/2026-08-28-obsessing-harnesses/ forgive a small bit of self promotion, but I'm researching this exact problem with my research group, about how to quantify solum benchmaxxing, tradefoff adoption, regression, and improvement for harnesses.
> I never took pleasure in craftsmanship or perfectionism, I just want things to work and then iterate on it with as little effort as possible.
The problem with this outlook (not with you personally) is that the increase in accessibility for you comes at a cost, but the way things work these days the cost is not paid by you but by someone else — someone you'll probably never even meet. The cost has been abstracted away from you and foisted onto somebody else against their will. This shows up as people adversely affected by local data centers (increased pollution, higher electricity prices), people displaced in the workforce (author of the article), people of the future who will not understand things because it's easier to skip understanding for now (students, early learners), and so many more.
It's very liberating — so long as you are given the ability to not think about the consequences for these other people, and the abstraction process by which AI companies are providing their services gives you that freedom by design. At the very least, it is something about which you perhaps ought to be wary.
That process is nothing new. That’s happened many times in history over and over. And in far more dangerous ways than not understanding how some complex piece of code keeps their favorite or most critical application running. At this point, people have long lost the ability to have even basic survival. How long would people last if they needed food or water? They have no idea on step one to achieving the basics. It’s all abstract to them, which includes us. That’s the loss that actually matters. Not that they know how their Amazon Fire TV works.
Disagree, in that humans are doing the same things they did in the dawn of time. Adapting to the environment and figuring out what it takes to thrive.
There are many things about our modern world which make less intuitive sense than the lives of hunter gatherers. People are trying to figure out how to survive in the conditions they are placed in.
Physical labour was weakened and then had to compete with machines, till we got lights out factories.
We were left with the service economy to find roles that allowed us to thrive. Now that is being threatened as well. It is unlikely that LLMs are going to make us all into entrepreneurs and capital owners.
Not to mention, the service sector required far fewer workers than manufacturing.
This isn't quite the same kind of moment we see over and over. It's not simply cars taking out horse drawn carriages.
The OP's point was about ignorance being bliss, but having adverse side effects. That's what I was responding to. I'm saying we long have lost the only part that matters, which was the self-sufficient farm.
It helps, but doesn't make a big difference if someone doesn't know what valves in an engine do. And 90% of the population probably does not.
Your point about adapting to basic material conditions under industrialization is something else. I wouldn't agree with what you're saying. It may not be your analogy, horse drawn to motorized carriages- but this is the cotton gin all over again. The only difference is we're now out of new industries generated out of the new technology to employ people. No more network admins needed, no more programmers needed, no more cotton gin repairmen are needed.
I agree in that the conditions are different with this one. But the process is the same we've seen over and over. This time there's just no newly created jobs out of this new revolution, 100 million legal and illegal immigrants flooding developed nations and more coming, and 50 years ago women entering the workforce expanding it 50% overnight. You're correct in that it's not going to work, but I see different reasons for it than you do. Things are going to have to change or Europe, the US and Canada are going to become slums like the rest of the world. And that process is going to be even faster than it normally would, because the ~50% population expansion consists of people that are used to slums.
You mean like all the benefits of industrialization? The real externalized human/environmental costs of our fast/cheap fashion, of our iPhones, of cars, of electricity, of agriculture?
I saw a video today, talking about how this is really the end goal of what we've been working towards for 200 years. Automation and scale and convenience uber alles. As structured it's not a good idea and it seems that Dr. Kaczynski wasn't wrong in diagnosis, only in the treatment. But here we are and we're pretty pot-committed, so I guess we have to see for ourselves what's on the other side.
Yes the fact that we have seen this pattern play out in the past and are very aware of all of the positive and negative effects it has should be sufficient to slow us down but naturally people are too selfish. The people who benefit will happily step over the graves of those of us who are fucked by the "benefits of industrialization" and then whoever survived will pat themselves on the back for a job well done while the rest of us rot
But there's no reason for us to be angry about it or resist it, of course
The only people who even somewhat successfully resisted industrialization are the Amish. Is that what we should be doing, forming religious communities that are increasingly isolated from the rest of humanity? Unable to contribute meaningfully to the discourse, but still subject to the externalities of the dominant paradigm?
Throwing shoes into the mechanism doesn't seem to have done anything but coin a new word. But I'm all ears! What other options do you see that could work at a larger-than-village scale?
Call me crazy but the tone of your writing doesn't inspire me with much confidence that you're actually even remotely receptive. I think you just want to argue
I'm not into it. Go ask Claude instead. It has more patience for this sort of ignorant attitude than I do.
You're crazy, I'm...not even arguing. You'll see that even in the course of this one thread that I've been quite ambivalent. And I've already talked with Claude about it plenty, and few ideas that feel workable in our present climate. I don't feel like I'm "ignorant" but then we never do, right? Would love some pointers to ideas. What you got? Communism? Georgism? UBI?
Shoot—if the true believers are right and there's ultimately never again going to be an economically viable justification for anyone without an MBA to have a single independent thought, maybe the Amish were onto something after all.
They at least have the notion that you've got a soul, and that it's a thing that should be tended to. A boss who has genuinely internalized the belief that the value of all human knowledge and expertise has gone to zero—such a man is unlikely to be similarly burdened in his assumptions about you.
First, I don't trust the elites to share in the wealth. I expect fuedalism to ensue.
Second, I think what is healthy for humans to yearn for is purpose and meaning, and convenience and idleness are almost counterproductive to that. Ok it's hard to argue with convenience, but nowhere in all of this has AI threatened to make my life more convenient by doing the chores for me, it just takes away fun creative tasks that I can get paid for.
> nowhere in all of this has AI threatened to make my life more convenient by doing the chores for me, it just takes away fun creative tasks that I can get paid for.
And this is, of course, the bitter irony. As that meme goes, I don't want it to write my prose so I can do the dishes, I want it to do the dishes so I can write prose.
I'm lucky though - as a hybrid engineer/manager, I've been able to lean away from the former and into the latter.
And I've come to notice that humans doing agentic work seem to need more emotional support per unit effort than those doing traditional engineering.
So there are opportunities there. I don't want to spend a second longer than I have to prompting machines - there is zero dopamine loop in that for me, I get more doing housework and at least that makes my wife happy - but I'm happy to support a few other humans engaged in that kind of work.
It's sad though. I used to love dreaming intricate machines into existence and then watching them come to "life", or at least actually start working. That dream seems dead for now, I hope it comes back but I won't hold my breath.
“I almost get physically ill when there is more code than I can keep in my head” resonates with me, but it is the exact reason that I enjoy working on better abstractions. Not in the “Javaesque” sense, as you call it, but in the mathematical sense.
I’m working intensively with LLMs to find out what they can and cannot do and for all the capabilities in there they remain terrible at compressing functionality into few concepts and as a result they produce incoherent (read Fred Brooks on coherent design!), failure-prone products. In other words: I expect that there will be good demand for people who refuse to let code grow beyond something they can keep in their head, even though the means by which one accomplishes this might be different than what you do now.
For my work in innovation/R&D the leaps are relevant but more or less orthogonal to what I’m talking about above. I think there is a limit to the consistency and quality that one can expect of software whose surface area scales linearly with the feature set, if that makes sense.
It is tempting to extrapolate the fast progress and conclude that everything will be automated soon, but it still appears to me that LLMs have a “spikey profile”: while very good in some areas, they fail completely in many others, with no evidence that this is only a matter of time.
> I get almost physically ill when I work on a project with more source code files or at least general architecture than I can keep in my head, so I don’t get anything out of expanded scope
While I sympathize with your loss, this was always going to prevent you from holding down a job, even as a pre-LLM "coder." The majority of us have to work on systems, not just single files or cleanly isolated programs we can hold in our head.
I don't think this statement implies they meant 'single files'? They could be talking about complex systems that they could fit into their head, and now they can't do that with new workflows.
Perhaps I didn't formulate this too well. Say, rustc is a gigantic program, but the parser alone, or the borrow checker alone, or the LLVM backend alone are small enough to work on individually, and from the perspective of any such unit all the others can be treated as black boxes, deliberately designed to have as small of a public API surface as reasonable and to be as predictable as possible. That's just architecture 101. With LLM code, I notice, such abstractions fall apart, and the interconnectedness, duplicated code, and unclear expectations make it impossible to reason about the result except as a giant lump. Of course, tech debt is nothing new, but at least it used to be held back by the physical inability to make progress once things get dire; with LLMs, this misery gets prolonged.
Yeah I feel this. My strongest passion in computing is simply learning how the machine and OS work. The code I would write would usually be experiments, not projects or tools.
I'm less pessimistic than the author though. There is always room for people who know what they are talking about. Take a deep breath.
Room where? You're obviously not going to hire someone for their knowledge alone in late 2026... ChatGPT probably knows more than you know in every domain. What questions could I ask you that ChatGPT wouldn't be able to answer?
You won’t hire someone to answer questions for you; you might hire someone to make decisions for you. And domain expertise is still very useful in both making good decisions and convincing other people to trust your decisions
I do wonder though about the optimizations within it, what could be the most optimal way to achieve such room (ie. knowing which questions to ask)
Yes, learning and tinkering is still really the greatest way to achieve that
but I think what I am talking about can be better simplified with the analogy of a gym: previously what used to be necessary (manual work/labour) but when most people got into information work, even then there was/is a need for it (physical work), then we saw the evolution of machines specifically designed to optimize for it and we got machines specifically designed for this training, which helped push people's body to their absolute limits.
I do wonder if an hyper-optimized environment of learning and for asking questions (or more so knowing the know how on which questions to ask), this whole process might be optimized for it and what that process might would look like is a source of curiosity to me.
Entirely agree with you, but I also lend some credence to the worry that capital owners and the managerial class might not want to pay a six-figure salary for "knowing the questions to ask".
I'd be lying if I said I hadn't spent any hours worrying about it. But on the other hand people pay for exactly that when it comes to law, accounting, actuaries, and whatever other white collar professions. I am nervous but optimistic for the time being.
They pay for tangible "deliverables" from those professions, too, not pure thought and judgment. One could probably argue that, as with programming, one has to have written a lot of code in order to think in code at a higher level, so to speak, although I can't say to what extent that's true in each of those domains.
However, the first part applies to programmers, too. A lot of the value of code _was_ simply in the fact that it was written, so you don't have to write it yourself. I'm not suggesting there isn't more to the value proposition, but the value destruction is there.
ChatGPT is a fantastic encyclopedia for knowledge retrieval and even is occasionally accurate!
It doesn't yet know when I brushed my teeth last, what specific foods in what quantities give me heartburn/indigestion, what that funky smell from my running shoes might be.
It can write pretty good code on a recursive loop when its provided a clear target. It can write better code when it has someone who understand architecture guiding it. It can review code reasonably well as well.
ChatGPT tied to robotics might even be able to do more interesting things!
It does pretty poor on highly specific knowledge where a RAG better supports -- something like Agent Search at GCP or AI Search at Cloudflare. But it can synthesize.
In effect, we've built an amazing library registry and need to up our librarian skills and the skills of people or systems that can use the information the librarian and their system can find.
ChatGPT doesn't actually know a thing, and will happily give you false information right alongside true information. Using an LLM to provide knowledge is a foolish choice.
One suggestion for the feeling that has been great for me. Finding a hobby where you can focus on sweating the details. Detach it from economic imperative (the core definition of a hobby, you dont make money from it). Ham radio, maker and micro electronics, woodworking, calligraphy, music. Of course there are more technically advanced solutions to the problem, that's not the point. The point is the effort and discovery.
> I'm less pessimistic than the author though. There is always room for people who know what they are talking about. Take a deep breath.
But what will their day to day look like? Meetings?
Previously, I'd have to work days undisturbed to get important stuff out of the door. There was effort involved to reach an elegant solution that fit business need.
Now I'm a meat bag pressing enter on a "recommended" option Claude already figured out was the best approach.
Fair, but the real question is what this person's manager thinks, as that tends to carry the day. And at the moment, there is an enormous gulf between what the managerial class believes LLMs can do and what people in the trenches know LLMs actually can and cannot do--not as a matter of current frontier capabilities, I might add, but more ontologically.
I wish that I could agree with you that "There is always room for people who know what they are talking about." I think that you are right in the long term. Eventually we will return to a world that values people who know what they are talking about.
In the short term, I have seen a lot of managers and other higher-ups talk about how we do not need to worry about low-level details anymore. In their minds, we are now all designers and architects, so we do not think about the small implementation details that ultimately do matter for performance and reliability.
People who know what they are talking about worry about all of the details from the big picture down to the small scales. We can still operate using abstractions like designers and architects, but we must know enough to choose the right abstractions that account for the concrete details properly. I've discussed this point earlier this year [1] using the tree swing diagram [2].
I was never the best programmer and never was to keen on building things or providing some value to users. I'm more interested in how systems work, especially computers and the OS, and so far, LLMs haven't taken that away from me. If programming and solving problems had been important to me, I'd probably have a problem right now. While I feel for OP, what interests him most—namely, understanding things and developing an intuition for them—is not a productive activity in the sense that it’s not about building or producing things. But the job of a software developer has always been exactly that and LLMs take an ongoing trend to the extreme. I think people like OP have no choice but to separate their personal interests from their job, as hard that may be.
Interesting. You don't feel like you were building an edge with your understanding of said systems or OS?
I'm very interested in systems as well, but being less sure about the future (on whether this is something I really need to think about, or whether I'll get opportunities to work much at this level), I started reading about such topics a fair bit less.
You act as if there's only two types of people, the ones who are competent and the ones who are not. But there are plenty of people who are competent at a certain task, which will no longer be needed soon. It would require extreme hubris to think that you are one of the few who is competent at some task that LLMs can categorically not perform.
This are a lot of parallelisms with LLMs, privacy and perfectionism as well.
I recently watched a movie which is about a young film director who suffers his whole film career because he is trying to make the perfect and the most scariest horror movie there is. While mediocre people with less brilliance and less expertise make better career and success than the protagonist because he is too stringent. Too adamant about things. This has stuck with me. I've read a ton of posts about how perfectionism kills. But to see the protagonists life get completely be screwed kind of hit me differently. I've suffered a lot on social life cos of me being adamant about privacy. The reality is, world moves on. Since then, am open to instagram, am open to less perfect things. More curious about LLMs.
This doesn't mean I stopped being a perfectionist or a privacy nerd or critical about LLM. But they've become my north stars. I work from within the environment than from outside of it. Life is better and positive since then.
I genuinely hope OP reads this and change his life accordingly. Change what we can. Do what YOU can NOW. It doesn't have to be binary. It's not black and white. I've read somewhere that "you suffer more in your mind than in reality". Take it easy. It was too much unnecessary burden on me and I am sure it is on your shoulders as well.
Before anybody panics about LLMs let's just take a deep breath, and see this tech for what it is.
It is a giant interpolation machine. It is very good at remixing stuff, but is is hapless when it comes to novel things.
Consider this: an llm was trained on physics, but the training data was cut in 1904. That is just a year before Special Relativity was published. The LLM was then shown papers of SR, GR, and Heisenberg's paper from 1925 that established quantum mechanics, and similar foundational papers of what we call "Modern Physics".
The LLM has systematically "disproved" all of them, and rejected as false.
So even if you show it a novel idea, it's still going to reject it.
It is by design limited to remix existing ideas.
The recent "novel" mathematical proofs are also just remixes. What I mean it uses two or more established math frameworks together to generate a viable bridge. The result is undeniably a new proof, but not a novel idea.
Even while I certainly don't identify with the same love of details, I do highly value strong engineering principles and even those are under heavy attack from the LLM onslaught - why engineer something fundamentally well at the start if there it is zero cost to fix it later when problems actually show up?
I still maintain some belief that the pendulum will swing back somewhat. We're going to see over time the problems that emerge from systems designed without deep technical oversight - and this will form a new class of expertise in its own right. It will likely still come back to people with an affinity for technical knowledge and principles based design, just in a different form.
> “why engineer something fundamentally well at the start if there it is zero cost to fix it later when problems actually show up?”
Because this is a myth. it is not true that there is zero cost to fix it. LLMs become less effective the more convoluted codebases become just like humans, if only at a different rate.
Is there something about an LLM that makes it incapable of simplifying a codebase? I have only seen that the slop jockeys who wield LLMs most ardently don't seem to care about that, and that older models were worse at everything, including that.
I try this really hard but it seems that getting an LLM to simplify a code base meaningfully is a much harder problem than getting it to output mostly functioning features very quickly.
They are great at adding but reducing takes much more hand-holding in my experience. Maybe this will improve, maybe it does not matter, maybe I am holding it wrong, I don't know.
I tend to think this is mostly because the training set has generally been "low quality code cranked out as fast as possible" and the goal has been "do more of that". After all, most code in general is mostly throwaway. And most frontier model labs are startups where code is short lived.
Different goals/context/training is all I think it takes to change this. Though yes, for now, I revel in my role as the one who can contribute a touch of elegance to the stupid robot's solution.
Edit: and yes, better models, but I think the Sol-generation are already good enough.
No. Coding agents are great at simplifying, they just need to be told to do it.
I often see agents skip opportunities for simplification when not explicitly prompted. I have mixed feeling about this, but for now I think it's probably for the best that they stick to the script versus take initiative for things they haven't been told to do.
> [...] I proudly called myself a coder as opposed to an engineer. In my eyes, this highlighted the way I focused on the details, performance optimization, knowing the intricacies of the language, and being able to explain how things work, as opposed to juggling Java-esque abstractions.
Ouch. There's an idea that I've seen a few times now that there are two key types of developers: developers who thrive on building products and solving problems through the existence of code, and developers who thrive on the process and the low-level puzzle of getting that code to work and then to work well.
The former are having a really great time right now. The latter are feeling justifiably threatened.
I am in the former group, and while I agree the prospects are not singularly bad and I see enormous amounts of work that will need to be done, I don't think I/we are having a great time. Working harder than ever under unrealistic expectations and general chaos from everones FUD. In my area the need for software is huge but there has never been no nearly enough money. Maybe we can finally build some of it.
I agree that the threat is more specific to the more detail oriented kind of person/role, though.
I feel that pain. My job involves a considerable amount of reverse engineering and software development, and I've always been interested in getting down to the lowest levels and figuring out what's actually going on.
LLMs are becoming remarkably competent at both of these skills. Not quite at expert levels yet but I expect it won't be long until this happens. I'm astounded at what they can do already, with the benefit of relentless, persistent effort on top of this.
How I've been using LLMs is twofold. Firstly, using chat mode to the effect of having technical documentation to converse with. Secondly, using agentic mode to develop tooling to help me with reverse engineering. This includes things like one-off scripts to analyse complex trees of structures, to modules that use the API of a framework I and others have developed, to prototype how we might want to extend it for specific features. I then write the final code myself in my own style, using the LLM prototype as a rough reference.
For now I think I've got a decent balance between using the LLM as a useful timesaving tool and continuing to understand the finer details for myself. I feel I have to draw a line at this point regardless of how competent the LLM becomes, otherwise I'll just be babysitting a black box, which almost anyone can do.
I'm not nearly as detail-oriented but I can certainly relate. The craft I've spent 20+ years mastering is disappearing and I'm not sure if I'll enjoy whatever replaces it. It's reassuring to know there are others who share the sorrow.
It's such a strange feeling. I have a similar amount of time invested as you. I'd always gravitated toward understanding how things work and bringing those insights back to whatever I worked on. Could be low level details, could be software architecture, or some obscure SQL. It wasn't that I knew everything, but that I could descend into the rabbit hole and re-emerge with something useful if needed.
Hard not to see it as tech killing competence in general, and cheering it on.
Kinda wish I'd gone to med school instead. Tech has only shown itself to be more unserious as time has gone on.
Having been working on a lot of low complexity code over the last few years I don't really sympathize with the author. I mainly use LLMs for the chores. And there are many many chores in software development. CRUD APIs, validation, yet another DB service, yet another script, minor version upgrades etc. Chores are also very straightforward to review. I do reserve the time to do normal engineering especially for the rare interesting algo and don't get this obsession with how everything must be agentic at all costs. Honestly seems like crypto propaganda all over again. If productivity "really" has gotten 10x doing some tasks without LLMs won't even put a dent in your average dev. output. What I do grieve is a lack of non-AI news. Might just stop following HN for a year or two and wait for the LLM spam to die off.
This reminds me a lot (mostly for worse) of the industrial revolution. The industrialization of textiles didn't help weavers weave better clothes. It displaced smaller, higher quality output with dramatically less varied, lower quality output in much greater quantities, more cheaply. It also dramatically undermined the relative autonomy of weavers and the control they exerted over the structure and details of their own workdays.
What I think we're likely to witness here, or at least what AI investors ultimately are hoping to see happen, is the displacement of code as we know it (often already sorely lacking in quality and craft) not by more of the same varieties of code, but a massive profusion of shittier, more homogenous code. It won't have to win by being better; it'll be able to do that by being cheaper alone. And we're frankly kidding ourselves if we think that doesn't mean a profound deskilling and potentially deprofessionalization across the whole class.
> This reminds me a lot (mostly for worse) of the industrial revolution. The industrialization of textiles didn't help weavers weave better clothes.
I don't think comparing it to the industrial revolution is appropriate, as the political and social conditions were completely different. I think you can compare the disruption that is introduced by artificial intelligence more with the deindustrialization of regions such as the Ruhrgebiet in Germany.
I agree but it's also better. On average for most programming tasks I think humans are as "defeated" as coders as we are as chess players.
The machines will not only be as good or better than you at the DB design, the business logic, the performance critical algorithms, the UX, the performance tweaks, the accessibility standards, security holes, browser compatibilities, laws and regulations and whatever else you need to make the whole solution.
It will also write user manuals in any language, and rewrite them when needed even on a friday evening. It absolutely will not stop, ever, until you are DE...wait, I mean DONE!
So the situation for coders is even worse than it was for the weavers. The machine delivers not only cheaper and faster, but also better. :-/
I think nearly all white collar office workers will be replaced eventually. For lots of jobs, the limitation is not the ability of current models, but lack of integration to existing systems. This will change quickly, as writing new systems and integrations is cheaper than ever, thanks to agentic programming.
If the job involves mostly working on a computer, it will be probably gone in 10-20 years.
You may be right that white collar work can be replaced but I don't think it will be. Current society can't function with a majority of the population unemployed.
It's a catch-22 for the companies as well, since white collar work is presumably done because a company has customers, and most of their customers are white collar workers. At least in the US and Europe.
I don't think any previous disruption was as destructive as this. Firstly it happens much faster and affects many more people at once, and secondly it doesn't seem to create any new jobs for the ones it replaces.
The industrial revolution took at least a century depending on how you count, and it created more jobs than it destroyed.
The introduction of computers obliterated whole office floors of employees at banks and insurance companies but it created even more work at companies that sold computers and software and consultant hours.
Ai takes millions of jobs and replaces them with a few thousand caretakers at megawatt datacenters. The workforce at Anthropic and OpenAI is comparable to a game development studio. If all they end up doing is reducing the workforce of JP Morgan by 10%, society still has a net loss of jobs.
That said, it's at least possible Ai will eventually end up creating a bunch of new work indirectly, by enabling people to do more than they ever imagined they could. One can hope.
In my opinion, LLMs are not competing with real programmers because they do different things.
The job of a programmer requires a lot of responsibility and understanding.
Using LLMs to write code does not help with that.
You may say that they do compete because companies treat them as the same thing and people need to make money, so the companies decide what is what.
That is true but the solution should not be to give in to the money, but instead to make the money behave correctly.
What we need to do is to fix the economy, which still assumes that products are physical and hasn't been adjusted for the digital reality we have now, let alone the AI.
Money was invented by humans, not discovered in nature, and we should therefore make it do what we need instead of letting it steer us the wrong way.
I've been very lucky that I love both sides, both the "programming" part and the "making things" part. Even then, it's been quite brutal coming to terms that the programming side of things is a chapter of my life that is basically over, at least professionally.
I'm trying to reinvent myself now and learn the other sides of the projects; how to monetize, how to promote my projects, how to "finish them", etc. I understand that's also changing radically since many people are trying the same thing, and with LLMs the market is changing in unpredictable ways, but that's also exciting! I can get so many more things done now that before I just didn't have the time or focus to finish.
I think understanding the details is still important. However, it moves toward the more central parts of the application, where the risk is higher and agentic workflows can’t be pushed as far. I think the author may benefit from specializing in those parts of the system where unattended agentic work is still too risky.
Your article matches my own intuition, and there's a case to be made for adjusting our architectural patterns to better compartmentalize those parts of the app we can let an agent go nuts on. For example, could we leave all of the UI to the agent? Or things like the MCP Server implementation of the app? I'm not quite sure where to draw the line yet. I'm quite comfortable leaving unit tests to the agent by now, but if it's user visible behavior, I still find the agent's work to be off somehow. Ymmv, I guess.
Yeah, I guess it is quite hard to tell where the line should be drawn, and we probably need to rely on human intuition and experience. One thing that the article left out that I have thought more of afterwards is that the classification would need to be relative to the enterprise as a whole. So if you are building a gimmick app for a birthday party you might just vibe code the whole thing, including its "core", but if you are a building business-critical sales system for a major company, the impact of something going wrong would rate the core at the upper end of the scale.
I think that, with the amount of vibecoded code of mediocre quality being produced, there will start to be a demand for "hand-made" software that someone took time to make as delightful as possible to use.
Demand from whom? I think a lot of people are pretty constantly observing that software quality in applications they use (or are forced to interact with) has been declining across the board for a while, and that this seems to have accelerated recently. The average lay understanding of this is "because AI" but it's probably a combination of sometimes being models producing sloppy code and sometimes being poor morale and management and product design in this industry that's essentially coming apart at the seams from the perspective of its workforce. I think it's uncontroversial to say that people already dislike this and wish for better software quality. For the most part, though, they either don't have or won't use any levers of market pressure for this. Their software choices are largely limited to what google or apple will allow for their phones, or what employers require them to use. I'll tell anyone who will listen that they should use FOSS where they can, but people really resist this idea even where it's extremely feasible and the tradeoffs are mostly familiarity (like their desktop OS). Consumers of software seem to partially think this way because they have been disempowered so thoroughly that they seldom have a choice
So as market pressure goes, that leaves employers. I do see the occasional oddball project that resists this wave, but "doing things correctly even if it takes longer" is not a value you're really allowed to have in an economy where the make or break factor for your business is usually getting investment capital, and capital is, as a population, probably the most all-in on LLMs of anyone, to the point where I believe they'd push for vibecoding even in instances where they can't find numbers that justify doing so.
A ton of people not in tech hate genAI so much that they say they'll, for example, not purchase a game if they know someone used it for any part of it, and yell about it online, and such, but games are pretty much the only consumer-facing software people make purchasing decisions about, so maybe that moves a needle there, but gamers failed to rally against microtransactions, DLC piecemealing, or even things like always-on DRM or revoking purchases that literally remove their ability to play their games, so I doubt that's going to materialize a change in something that could be more easily obfuscated in response to this pressure like the provenance of the software
Market pressures require at least a somewhat free market, and the overall american market for software is drastically distorted by various oligopsonies that by and large has a vested interest in LLMs (and specifically the corporate black box ones) being used for as much as possible
Yes, I think so too. Just like there is a demand for handmade objects like vases, cooking knives and beverages, which was the norm before the industrial revolution and has now become a thing of intrinsic value, provides they are of higher quality than their factory-made counterparts (I have a background in the spirits industry, where "small batch" and "handmade" have often been used to justify premium prices despite clearly lower quality. I've become a little more discerning since when I see those labels anywhere and don't take quality for granted).
We have tailors around the world, but Zara and other brands do the lion's share of business.
Automation in physical labour resulted in less work for physical labour. There are still some people producing hand crafted work, but the market doesn't need that many of them.
A much smaller group of people can serve the needs of an entire state.
Perhaps I'm just daft or slow, but I'm not 10x-ed by LLM usage. It's precisely because the details matter. (And yes, I read the article and it's lamenting the loss of low level machine-level details.) I read the LLM output, it slows me down. I challenge the LLM output assumptions, that slows me down. I stop to step away and think, it slows me down. I cannot run a bunch of simultaneous prompts and supply this same level of mental context to all of them, because my brain works best when I treat it as single-threaded. My experience with this approach to using an LLM has been, so far, positive.
What I have noticed as I've migrated to newer models is that the assumptions made are incorrect less often. But if I don't pay close attention wrong assumptions can still be made. Cross cutting concerns are lost, or written in such a way as to be useless.
So, the loss of details, to me, would be my own laziness in not performing due diligence.
Whatever your opinion of the current state, LLMs are seemingly improving exponentially. You remember where we were a year ago. We can't fathom what it will be like in five years. Maybe even hard to imagine three. Once it hits the point of diminishing return on ability, it will move to speed and cost optimization. And of course everything will get smaller and take less energy in the standard progression. When viewing as a snapshot in infancy we can see the holes. But it's essentially a solved problem that is snowballing now. Not that it won't create other problems. And very likely solve many others.
I think so. Although it is possible that it is being held back for safety reasons. The same has been true of CPUs and many other advances, but the timeframes were generally longer.
For a brief moment in history, it was cool to be a nerd. That era is over. The era of the nerds began when the IBM PC went mainstream in the 1980s. It peaked in the dot-com era, when, for the first time, large numbers of nerds got rich. That continued through the FAANG era.
Now it ends.
There will still be some nerd jobs. Some. Fewer over time. The future is not you telling an LLM what to do. That was the brief "prompt engineering" era. It's an system of LLMs and agents telling each other what to do. Most likely with a bro in charge.
Get used to sand kicked in your face. Or, to quote Orwell, "If you want a vision of the future, imagine a boot stamping on a human face – forever".
Ask someone who used to have a good union job what life is like now.
> “I didn’t care about practicality, building useful programs, or writing code per se: all I wanted is to understand how the machine works.”
Over the years, I’ve transitioned from building “beautiful” stuff to nowadays building stuff that works. I still want it to be perfect but now not for me but for the user. If I think it’s ugly, but the user wants it that way, then who am I to decide against it? They will have to use the software, not me. Seeing a user be happy with the software is super nice. Way more enjoyable than me just making stuff for myself.
Great article, and I 100% agree. I'd even go further than this, and say that the rise of AI has clarified my vague feeling that computing has been going wrong for a very long time. There's a famous article by David Chisnall with the subtitle "Your computer is not a fast PDP-11." [0] I believe it should be a fast PDP-11, and outside of specialized batch processing machines, we should sacrifice performance to make this possible.
Instead of cache, software-managed fast and slow memory spaces.
Instead of branch prediction, memory with multiple read ports/buses and software-managed parallel prefetch queues.
Instead of hardware speculative execution, VLIW.
Instead of automatic DRAM refresh, a hard-real-time OS handling the refresh timing.
I don't care that this would to make things on average slower and more expensive. Modern computers have tremendously fast average-case performance, but the software is still mostly laggy garbage. We sacrificed ease of understanding and didn't even get responsive software in return. I believe that if modern computers really were fast PDP-11s, we would not be in the situation we are now, where most programmers see nothing wrong with software taking some unpredictable human perceptible time to respond to inputs, even when simply processing text. I care more about worst-case performance than average-case performance.
As the article says, "Like a fisherman might feel one with a fishing rod, I treat the machine as a continuation of myself." A fishing rod always responds in zero milliseconds. A computer should do the same. You can say AI is qualitatively different because by embracing it we abandon even the possibility of understanding, but in practice we mostly abandoned understanding already. There's no practical way to count cycles any more.
Of course, most computer users don't care about this, so there's no commercial market for the kind of hardware I'm imagining, but I'd love to see the "fast PDP-11" approach taken to its limit. Let's make computers it's possible to completely understand.
I think there's opportunity to create a niche that fits the author. LLM-generated work has this problem where the details are flawed in a way that makes it good on the surface, and nowadays a bit deeper, but still inferior to the same work produced by a competent human. The dominance of low-level programmers over software could not last forever, but neither can the dominance of this use of LLMs: English is not an ideal programming language.
I've seen people praise broken LLM-generated software in ways they never would human written software that had the same issues. I think the dominance of LLMs will last simply because of the money and social inertia behind them and because people consider them inevitable, so it doesn't really matter how flawed the code they generate is there is faith that LLMs and the quality of what they generate will always improve, and that one simply has to accept it. That faith and tolerance isn't (and will never be) extended towards humans to the same degree.
LLMs aren’t going away, but even though people tolerate their imperfect code and design, there’s room for improvement. Especially because many other people don’t tolerate it.
There's no way back from here. Being able to write a program is just not worth as much as it was to the world and rewards and incentives are adjusting accordingly.
Imo, the best jobs for people who prefer understanding over building nowadays are those in IT security. Vulnerability research, pentesting, forensics / incident response, reverse engineering... - here the details still matter.
LLMs are also coming here ofc, but they don't unilaterally take away the interesting work.
We are taking away the ability for some very smart people to be engaged with the world in a way that is challenging and meaningful to them while building tools that allow one person to do the work of 10. Fill in the blanks if you want, but this is not good. We must quickly find out how to give people hope for the future.
I too am motivated by a desire to understand how the system works. I never got down to assembly or toy operating systems, but my recent wins have been rooted in an uncommon understanding of how compilers optimize, how CPUs cache and pipeline, and how TCP stacks queue and buffer.
I went through something similar when I worked started working for AWS in the pre-LLM era. I had to learn to let go of the desire and perceived need to fully understand the system because it was just too big
Indulge in the larping and you can laugh about yourself, its not that bad honestly. Breadth in topics helps to recognize patterns/common ideas, it is ok to let go.
I commiserated so much with this post. I feel like I got out of software at just the right time - folks like me that have an inherent need to understand the lower level details feel like this agentic coding world, where there is simply not enough time to even read the code, let alone understand it, is hell.
I left software and went into violin making and I couldn't be happier (though of course I'm extremely fortunate to have saved up enough in my software career to comfortably make the transition). In violin making a tenth of a millimeter is considered a lot and we endlessly stress over details like the corner shape and the f-holes. And while some of this nitpicking is certainly excessive, it serves more as proof to show that we're extremely careful with the details so that stuff that really matters, like tonal quality and playability, will also get enough detailed focus.
What a charming new career path! And you make an interesting point about signaling attention to detail giving a guarantee of sorts that the things that matter are covered as a matter of course.
Reminds me of a friend who would go straight to the restrooms for a quick visual inspection upon entering a restaurant: if those aren't clean, there's no reason to think the kitchen is.
> Hobbies still exist, but they don’t pay the bills, and increasingly retrocomputing and performance optimization are being infested by LLM fans that seek recognition rather than the experience, which sucks the fun out.
Isn't this whole post seeking...recognition? I am so confused at the metahypocrisy here. Why is it valid to want recognition for something when you do it, but not when someone who uses an LLM does it?
So because some people use Tinder, does this mean that nobody puts any effort into actually finding the right partner?
Said another way: is it impossible to use something which everybody has access to to make something artful?
Or I will try it a third way. Does the fact that people take bad pictures on their iPhones prevent other people from shooting whole professional movies on iPhones?
There's a great post I read on twitter on how marathons and Iron Man have come to be the new status signal. The argument was that people who grew up with privileges find it hard to show something they've personally worked for. Every other "achievement" could be attributed to something other than their hard work.
ex: getting a big seed round from a VC for your start up still may show that your parents had connections.
but marathons have this grindability and somewhat stable feedback loop.
> all I wanted is to understand how the machine works.
> [...]
> If an LLM can analyze the code and explain pointer provenance to you and babysit you until you get it, there is little value in expertise.
This sounds like the author wanted to understand not for the understanding itself but to get an edge.
One of my strongest motivations has always been the understanding (mostly of why a thing doesn't work like it should) and I have no trouble accepting AI assisted mode of acquiring understanding because I don't care if it's worth anything to anybody that I understand.
I draw pleasure from understanding. I don't build my value on understanding. I don't grieve anything. I'm elated that I have a virtual person smart enough to explain to me the things I'm interested in. Before I felt like I had too seek water in the vast desert full of dust and prickly things. Now I have plumbing and the same thirst.
> Last time I tried using an LLM for a pet project, I realized that the LLM would come to know more about it than pretty much any person I could show it to.
I was quite reluctant to show my own code to AI. I was doing greenfield experiments for months before I gave AI anything that contained any code that I was proud of.
But when I did, it understood it very well, better than any person I could show it would be able to. And extended it very well. My programs, even the most complex ones became way better and did more than I could ever hope to achieve myself.
Basically at this moment I had to conclude that LLMs might be better than a developer with 20 years of expeirience. This was more than half a year ago at this point.
at the beginning of the 20th C when ford implemented the moving factory line, experienced mechanics disliked the new way of doing things but did it because it payed well. they werent using a lot of their skill set and their job could be replaced relatively easily. many many industries in our current economic system will be facing this now. if you can tell me which ones are immune im all ears.
Yep it’s pretty depressing all around. Even when the truth is revealed about the output of an Llm (not quality, full of errors, made up details, nonsense code, etc), people are still claiming it as a better way of working because they had a chat with it. There is very little room for anyone not interested in slop.
I was recently replaced by a young developer and the only thing that keeps me smiling is that they still haven’t fixed the part of the application I raised concerns about (because the young dev decided to write on a fresh non-compatible stack even after my warnings). I hope eventually it leads to their own loss of career since that’s what they did to me. All of that to say that Llms have made people into over confident morons.
Like the old joke about alcohol not "turning" someone into a jerk, but instead revealing the jerk that's been hiding all along, I think the same is true for the idea that LLMs are "turning" people into overconfident morons. I don't believe these people are being changed, I think it's how they always were, and now it's easier to see.
Yes that is probably a better way of putting it. We are all overconfident morons until we learn things. Now society has subtracted knowledge share and gain from the equation.
My original manager left and my coworker was promoted. They immediately turned face away from the team. They fostered a hostile environment and made sure to not make decisions but instead let our team fight amongst themselves. Then they fired the other two team members without a reason and loaded all the work on to me. Then they would waver between I wasn’t working fast enough and “we can slow down if you need more time” for months while pushing back projects and deadlines because they failed to plan for any of those projects. I tried making amends and focusing on work and not the drama, but they wouldn’t have it. Then they started talking about hiring two new juniors for the team. Which I understood to mean they were going to replace me. When one of the juniors started that person was kept away from me and did not meet with me for any onboarding or collaboration. Instead talking to my manager only. Once this happened I still tried to be invested in the projects and pairing with the other new hire. Eventually though a deadline came and I had to explain why the code wasn’t ready when they dropped the new stack they built in private on me days before things were due.
I have no opposition to a new stack but our team already had 6 different projects, two of which were the previous teams next-gen projects. I didn’t want to increase the maintenance surface than we already had with 3 different wordpress sites, 2 nextjs next gen sites, 1 next gen site, and now the new guy’s next project built on vite.
They have a PoC of the new site they released for their semi-annual conferences. It does not work, looks pretty but does not work (essentially because vite has no server API).
So yes, it was an operating capital reduction measure or wage stagnation or whatever you want to call it. I’ve never had a manager that didn’t go to bat for me or passed blame for their failings onto me until that job. Apparently C-suite had developed a culture for pointing fingers.
> All of that to say that Llms have made people into over confident morons
My manager does not have a software background. Initially he used to come to me with an idea and we used to discuss on how we can technically implement it. He used to value what I had to say. Now he talks to copilot, come up with these grand ideas, dumps all that on our heads in a 30 min meeting and ask what do you think about it?
I think part of the grief is losing the way we learned to do something we loved. Most people care about what software does, not how we made it. The hard part is accepting that what makes the job satisfying for us isn’t always what makes the result useful to others.
It's great that she takes joy in his work, and sad that economics is pushing her to focus on different details with less joy. But the same can be said for a horse groom who loves her work being pushed to transition into a mechanic. Change sucks, but less than petrification.
“A creature who has spent his life creating one particular representation of his selfdom will die rather than become the antithesis of that representation”
― Frank Herbert, Dune Messiah
I agree with many perspectives in this thread. I empathize with OP. I’m scared about the future of my job and already feel it less fulfilling, despite being more productive than ever.
But I have one singular counterexample to most scary narratives and essays about LLMs writing software, which is my coworker who hardly uses LLMs at all. At least, he hardly uses them compared to me. He still writes most of his code by hand. He still greps around the codebase without claude code. Like he’s definitely using claude code, but only for like one-off specific tasks.
He’s a totally average developer, like everybody else on my team (including me). But he’s clearly more helpful than the rest of us. When people from other teams have questions about how something works, he’s always the first to respond. He’s always the one providing useful context in planning calls. He catches stuff in code review that I didn’t catch, and claude/copilot didn’t catch.
I think I’ve leaned too far into AI, partly because I’m a lazybones and am kind of burned out already. But there’s a stark contrast between me and my coworker that there didn’t used to be. I think the context rot is really setting in, and getting worse. So I think there’s still value in caring about the details
>> He catches stuff in code review that I didn’t catch, and claude/copilot didn’t catch.
This, I find completely unbelievable. Because we had (emphasis on had) seasoned engineers on the team who similarly eschewed AI tools and insisted on doing everything by hand in the manner you describe, well after the rest of the team adopted AI. Yet when it came to code reviews, even in parts of the codebase they were familiar with, the bugs they found often came down to nits, bike-shedding and opinion-based feedback (that they usually tried to frame as objective fact). They would also disagree with almost every AI finding, arguing that it was an unrealistic scenario or an edge case not worth worrying about.
Fundamentally, I don't think humans are going to be capable of providing high quality feedback on PRs authored by AI agents unless those PRs are fairly small in lines of code and volume. It's just way too much information and context for one person to keep in their head. I read a statistic that said the average lines of code a senior engineer can read and provide good feedback on is about 400 per hour, and that number goes down the more time they spend doing code reviews. So, to anyone who insists on trying to keep up with AI, I say: good luck.
> This, I find completely unbelievable.
You both have anecdotes. Anecdotes don’t “cancel” each other out.
Here’s a third one. In some of the code reviews I’ve encountered that AI gives a lot of feedback, it’s just providing noise. Things that should be ignored or when following the feedback causes more harm which requires more token to “fix” later on. That can also happen. Sometimes the thing it spits out goes against the common sense, and sometimes it works very well.
> So, to anyone who insists on trying to keep up with AI, I say: good luck.
This I agree with, for a different reason. It’s like trying to swim in a sea of honey and trash mix. It’s exhausting.
> Here’s a third one. In some of the code reviews I’ve encountered that AI gives a lot of feedback, it’s just providing noise
Something I've found fun is seeing how long it takes for an llm review tool to come back satisfied with a PR. Think 100 lines of code changed, nothing terribly significant, but also not trivial. I'll have a local Claude session setup to babysit the PR and wait for feedback, accept all the recommendations, push the change up and request a review. I cap the number of iterations at 10 just so I'm not blowing a stupid amount of money. I've yet to come up with a PR where the llm reviewer is satisfied with the changes and has _no feedback_.
So where's the reasonable cutoff point for llm based reviews?
Huh, I've had many times when `codex /review` comes back satisfied on the first shot, both with handwritten and LLM-assisted PRs.
We use only one round of LLM review, and have discussed as a team still assessing recommendations, not just accepting everything blindly. So somewhere in the (0,1] rounds of review. Sounds like our preferred ratio of human to LLM involvement is different than yours, though.
>> Here’s a third one. In some of the code reviews I’ve encountered that AI gives a lot of feedback, it’s just providing noise.
This is completely normal if you haven't written your own custom skill with instructions on what types of issues the AI should emphasize, which ones would be considered nits and which ones aren't a problem at all.
In our repos we use a classification system: blocker, should-fix and nit. Each one has specific definitions, criteria and examples encoded in the skill file. When the time comes to review a PR, agents invoke the skill, and frankly do a stellar job. A human then reads each finding, asks the AI follow-up questions and makes the final decision in terms of whether the finding goes in the PR review.
The reason I know this works is that we have one guy on the team who does not use this skill, and blindly throws his agents at PRs. And the results are exactly as you describe.
> This is completely normal if you haven't written your own custom skill with instructions on what types of issues the AI should emphasize, which ones would be considered nits and which ones aren't a problem at all.
"You're holding it wrong" :)
> "You're holding it wrong" :)
It's a general purpose tool. There are different ways of applying it, with different results.
> This is completely normal if you haven't written your own custom skill with instructions
This line of thinking comes from the assumption that LLM are somehow infallible and can’t be wrong, which is obviously not the case.
Writing skills and other magic incantations is the first thing that comes to mind of anyone who sees the review results for the first few times. What makes you think we didn’t do that?
Claude's code review skill, in particular, can find some good stuff. But it has some big blind spots around certain types of code. And it likes to come up with a lot of nits too—I think it's really really trained to try to always find between 2 and 8 things or somesuch. Good news is that it is very receptive to "nah" on the bikeshed ones and doesn't stick with them, but will stick with big issues. It'll probably bring up a few more nits though that it didn't bring up the first time!
But I can completely believe that someone who knows the code by heart would have a better signal to noise ratio on their reviews.
I'm trying to find the sweet spot because I've found some NASTY bugs Claude missed, and also had Claude find some nasty ones for me. And this is in codebases with tens-of-thousands of AI-generated lines of code + AI-driven reviews. So I want to bring both to the table.
The existence of some of these major "oh man that changes a lot of our assumptions" bugs that were only found because someone poked on the agent and said "I don't think you're paying enough attention to this" justifies that, IME.
And the better you are at pointing the agent at the truly-important parts, the better the agent's gonna be at finding shit you missed.
Claude's code review is a lot less interesting then getting Claude to reproduce the bugs it claims to find in code review, which has had an absurdly high hit rate for me.
The biggest problem I see with how a bunch of people use these tools is they go to them as an oracle, rather then letting them be plugged into and interactive with problem.
And it's in that later context that Claude is amazing: it can run tests and setup scenarios which would take days or get stuck in some weird problem loop. And then you can just say "okay, walk me through this problem" and see it yourself right there.
> The biggest problem I see with how a bunch of people use these tools is they go to them as an oracle, rather then letting them be plugged into and interactive with problem.
At work they have some scale of how "advanced" of an "AI engineer" you are.
IIRC, using the model interactively means you're stuck and "level 3." IIRC, level 5 (the best) is having some agent interview you about what to do, generate a story from that, then some other agent consumes the story and implements it, etc. I think you're supposed to check their work at each step, but that sounds inhuman and unfulfilling.
A lot of bugs are essentially that the code does something plausible correctly, but it's the wrong thing to do. People who are familiar with the codebase and its purpose can often spot those bugs. Those with less experience usually can't.
The issue is tacit knowledge, or implicit context. Most details are never written down. If you don't know them from experience, you have to guess. If you guess, you often guess wrong. And even if you know something from experience, you are often not aware of it, until you see something that violates it. So it's not possible for you to write it down in advance.
You can replace people with AI in the above, and nothing fundamentally changes.
As someone who owns a company:
Some holdouts excel at what they do to the point of retaining significant value, earnestly worried about being out of touch with what we do, some holdouts just suck and are bitter.
I deal with a lot of non-LLM users at work and quite often the conversation hits a dead end, where I'm like , ok but see, your app has this performance blockage due to your not having an index here - do some performance tests and you'll see (it was a hang caused by a FOR UPDATE locking the entire table due to lack of an index). And you can hear the pause (it's all over Slack) where they just aren't going there, because writing a performance suite for the issue in question would be a lot of effort to do by hand and in the "before times" would be a difficult undertaking to justify. Because they don't consider an LLM, a task they most certainly should be doing becomes a non starter. Never mind my own Claude had a whole plan ready to go to do this whole suite for them in about five minutes so they could study the impact of the index, but I really didn't want to just go ahead and do this all for them. At some point your non-LLM coworkers need to stare directly at work we'd never be willing to do before that's now trivial, and in fact is now part of the job.
Right, but performance testing has always been hard and LLMs are awful at it. So maybe your coworker was right?
I’m definitely on the “just use the clanker” end of the spectrum. But knowing when and is good. Constantly having to argue with people’s reposting of Claude’s idea of what’s wrong has left me burned out. At this point, if I have any idea about what’s going on and someone tells me “Claude says”, I will ignore them.
In this case, it sounds like you could have made a ten line repro that shows the problem. Why not just send that, something human interpretable?
What LLMs are you using? Just simply telling Sol 6.1, Opus 5.5, Fable or Astra to performance test something will get you a solid improvement in poorly optimized code.
Giving it a specific plan will get you a solid test harness.
And setting up an autoresearch system and running it overnight will get you expert level optimizations if you set the metric up right.
These things excel at performance optimizations.
Using everything modern and useful!
Performance testing has always had problems with isolation, mocking, covariance of services etc. I’ve just spent two weeks driving down latency across our framework, and autoresearch was definitely not a viable path. Most of these loops have these logarithmic, non-step change curves.
Just like with actual research, the real benefits came from me asking why is it like X and not like Y?
The original performance testing framework Claude created to bench our different versions against did not even mock high variance provider calls…
yes but you can use an llm to do the grunt work which still speeds up the process, you don't need to be like "computah speed this up", you can be like "computah, write me a profiling script using lldb to inspect this one hotpath and look for X, Y, and X" etc etc.
> Right, but performance testing has always been hard and LLMs are awful at it. So maybe your coworker was right?
LOL, you're making the same mistake they did. thinking "index" means "too much time spent fetching the rows". read again - it's a FOR UPDATE so the entire table gets locked and other processes get totally blocked.
> Constantly having to argue with people’s reposting of Claude’s idea of what’s wrong has left me burned out.
It wasn't just claude's idea, it was my idea too, the claude topic was that it would write a suite that proves the problem, in this case, very loud logging messages that were occurring for the customer when this quasi-deadlock situation occurred. it was not subtle.
> In this case, it sounds like you could have made a ten line repro that shows the problem.
no, it involved running a galera server and about four other services with a specific set of data conditions, again, read what I wrote, creating a proof of concept suite was not trivial to do by hand.
But why would you have to make the succinct suite by hand? Not what I was suggesting, I have gotten in the habit of sending extremely concise, human readable repro scripts made by Claude.
Partially because I can read and validate it actually shows what it claims to show, and partially because I expect people want to know what I’m telling them.
> it's a FOR UPDATE so the entire table gets locked and other processes get totally blocked.
You’d think they’d have found this issue out before now; if there’s no usable index for the predicate, non-locking reads would’ve also been slow.
Also, I look forward to the next update wherein your colleagues create an index, and then discover the joys of gap locking under REPEATABLE-READ.
i want them to turn off REPEATABLE READ also but that requires application changes so that it can be set up client side
This is me basically, I use LLMs on the browser for specific queries rather than you know, have it abstract my work into a black box...
> I think I’ve leaned too far into AI, partly because I’m a lazybones and am kind of burned out already.
I've been doing systems / backend programming since I was 10 (in C in those days), so I was burned out by the time I was 20, and I'm now 40. The temptation to trade on that knowledge in a very short-term way is strong, but I know where it leads -- to the rot you describe.
This is rotten but I'm secretly glad that Claude et al are metering by the token.
I'm not sure that folks realize that the purpose of software engineering is to program in a way that doesn't just function, but optimizes for future readability, maintainability, and behavioral change in line with product requirements.
There's a reason why programmers are not paid "by the line", and it's because LoC as an incentive structure is a disaster that leads to brittle and verbose slop code -- and we knew that even before LLMs.
So I'm glad that the (long-term) economics mediate against token-hogging software by making it literally more expensive to deal with.
I just hope that managerial types are smart enough to realize that "time to understand/upgrade/change a codebase" still matters, whether that's expressed in terms of SWE work hours or LLM tokens.
I would not bet on the managerial types responding to anything but (a) blunt monetary incentives and (b) the latest buzz from other people in their general professional category, e.g. at the country club.
This is one (of several) reason why many larger open source project ban or severely restrict the usage of LLMs. They want contributors to fully understand the changes they are making.
Recently we have received several bug reports with AI suggested fixes. They looked reasonable enough and seemed to resolve the issue at hand. I then took a deeper look and discovered that every single suggestion only hid the symptom but did not address the underlying issue. Applying the suggested fixes would have hurt our codebase, so I eventually had to reject all of them and write my own solutions. This was only possible because I'm deeply familiar with the codebase and the broader context. Someone with less knowledge would have probably just applied the LLM suggestions without much questioning. I find this rather worrying.
I guess in popular open source projects the stakes are just higher than in some proprietory software that will be replaced in a few years anyway. The irony, of course, is that LLMs have mostly been trained on open source code.
Also, some of the projects I'm involved in are over 20 years old. One even celebrated it's 30th anniversary. This means there is also the question of historical responsibility.
I think the ideal state is a team with a mix of programmer types. Some are detailed focused and anti-AI, some are AI maximalists, some use AI for architecture but review carefully, etc. Just as people use one LLM to review another LLM's output, there is value to diversity of thought, more than ever.
Where things go off the rails is making sweeping workflow changes for all developers. Eventually we will realize that LLMs have the same gaps of insight and hit the same local maxima. More than ever, diversity of thought is necessary when everyone is outsourcing a chunk of their thinking to a nondeterministic parrot that is somewhat deterministic in its problem-solving
>But I have one singular counterexample to most scary narratives and essays about LLMs writing software, which is my coworker who hardly uses LLMs at all
Nice, but that's not a counterexample that refutes the scare narratives about LLMs. That one that prove their point.
> When people from other teams have questions about how something works, he’s always the first to respond. He’s always the one providing useful context in planning calls. He catches stuff in code review that I didn’t catch, and claude/copilot didn’t catch.
Who is dealing with the situation where people like this always-helpful colleague is now sidelined by the lazy liars now that AI allows them to pose as proficient ?
Since they're very happy to suddenly have the ability to "solve" problems and are now marketing themselves across the floor while the knowledgeable doesn't do this because 1) he considers it's normal 2) he's still busy reading and learning instead of waving hands.
You explained exactly the person that I am as well. Same motivation, same inability to use stuff I don't fully understand, same way of learning things, same feeling of emptyiness after LLMs appeared. It's wild, and I do not have an answer either. I just try to adopt and use the agent as some form of new processor for logic. And invent my own language around it for the logic harness to jail and align it properly, which is the only interesting thing right now to me as it touches fundamental principles of logic, information theory, computer science - but everything else, like writing compilers for regular problems, writing programs, writing code, are all dead uninteresting to me now, even though I exactly know that other people struggle to get complex stuff out of LLMs (like seeing this Theo spending half a million dollar in tokens on a TypeScript compiler that I could build in like a month for 1/1000 of the price), but this doesn't give me as much really to attack it - and the reason is, because once I solve it and publish it, people can just steal the ideas, the energy that went into it (all the thousands of micro decisions), this was not possible before on the same scale and needed the same brain power. This inbalance pretty much makes it impossible to me to release anything anymore as open-source.
Maybe you can help me understand. What determines the flight level of understanding you need to function? Obviously you don’t need to know everything down to the last atom cluster (in objects), or down to every last line of assembly (in software). Why does a clean interface with a contract not suffice? What really distinguishes a low level library from a higher level one, in that sense?
Enough to build an appropriate mental model for a brain set up to tackle problems this way.
General question. How do y’all define this?
Working on platforms of sufficient scale, there’s a lot happening that’s out of your control. You can build the mental model around it, but it will contain a lot of black boxes where an abstraction hides details.
Generated code changes this, probably, but I’m curious by what degree.
For me at least I have to be able to believe I can understand any part of the stack if I want in reasonable effort. I would happily dive into semiconductor physics if I happen to want to (I'm a former physicist so the atom level I pretty much already learnt at school).
Honest question: What is preventing you from understanding any part of the stack now?
You could potentially ask an LLM to explain it, but I would venture a guess that wouldn't feel like the right source to help you. You could use the LLM to help you identify source material written by humans in order to learn anything new. It doesn't have to "do all the work for you".
Modern AI systems are powerful. They are not omnipotent or omniscient. Understanding the details is still valuable, especially if you want to push the frontier of any known field.
In any event, the situation isn't hopeless. At least not yet. :)
> You could potentially ask an LLM to explain it, but I would venture a guess that wouldn't feel like the right source to help you.
I don’t think this works, at least for me. Even on the 5.5 versions of Claude it’s still arduous to read at this point.
> You could use the LLM to help you identify source material written by humans in order to learn anything new. It doesn't have to "do all the work for you".
This probably depends on the shop, but humans aren’t writing docs anymore. That was the first thing to go, sadly.
I hear what you're saying. I often tweak the CLAUDE.md file to improve the quality of its output. It's an ongoing experiment.
As for "humans writing the docs", you raise a good point although it's not quite what I imagined when I wrote that line. I was thinking more about having the LLM/Agent create a list of verified output by humans with reputations as experts in whatever field interests you. This is important when pushing the boundaries of research, although it's overkill for wanting to know whether or not a new technology could be useful in your existing project (or the next one).
What use case did you have in mind when you brought up the docs situation? Sounds like you had some direct experience with that one.
I think a distinction is clearly emerging between docs intended for humans, and docs intended for agents. The latter is where all the Markdown-ridden slop should go; I'm not insulting humans with that.
> You could potentially ask an LLM to explain it
You can ask frontier models with all the bells, whistles, language servers etc to give you every example of X. And it gives you 12 examples and says that's all of them. When you know damn well there are at least 40 (but not exactly how many). So you say no, you know it has missed some, such as X23, and X27. So it goes away and comes back again and says yes, there are 41 X, here they are. How much digging should you do to see if its right?
I have many times gone looking myself to find that it has still missed some. Asked it to go check for those, to look harder it goes oopsie and says now im sure ive gotten all of them (has it?)
All this to say, I have been burned, repeatedly, multiple times a day, for the last year+. I still use these tools, but I truly cannot understand how some people treat them as oracles that know everything about our codebases
Excellent points. I agree that frontier models get things wrong all the time. They are NOT oracles. I believe that we need to encourage our peers to become sophisticated operators of these systems, instead of treating the output like Moses and the 10 Commandments. Perhaps we need more specialists, because the major AI labs lack the incentives to venture down the long tail of knowledge. Agents can be a piece of the learning puzzle, despite their imperfections. Again, thanks for your reply. It gave me lots to think about.
You need to define the goal in a way that you will trust the completion. If you are not sure how you yourself would verify that there are 41, then you are in trouble. Verification must be deterministic, or it's worthless.
What the large models do really well nowadays, is that they won't lie to you if your deterministic verification fails. If you tell an OpenAI or Anthropic model that they need to run a certain `grep` or search or whatever command to verify, then they will do it. I haven’t seen them lie about this for a year, and trust them in this.
Surely you can see that for basically every example of this sort of problem, fully defining a deterministic check is the same as finding them all?
Like you're telling me if I had a script that printed all X, and it's my responsibility to ensure it has no bugs, then the agent could tell me all X and I could trust it?
This is not helpful at all? I am capable of running scripts myself and using the output directly.
> fully defining a deterministic check is the same as finding them all
That’s like saying mathematics is worthless and we have to resort to finger counting?
No? It's like saying "why bother doing maths, a calculator can figure out the solution to any question you have if you just put the right equation in" there might be more to maths, it turns out. Most of it lying inside of finding "the right equation"
Sure, but if you yourself can intuit how to find all 41, why can’t a clanker?
Well, the word "intuit" has considerable salience here...
It sounds an awful lot like the halting problem.
In many case it is the sheer accidental complexity. I tried to get into Linux codebase and gosh it's so much harder than FreeBSD. And Chromium, LLVM... I don't believe it has to be that way. I use Common Lisp software (besides Emacs) written by human for anything I can and these have always been a joy to use or work with.
It seems the way industry is heading towards wrt LLM will make this even much, much worse.
Common Lisp, eh?
Y'know, the last AI hypecycle was loads more fun than this one is...
> Honest question: What is preventing you from understanding any part of the stack now?
Bringing this question out of the thread and back to the current moment...
the recurring answer now is "futility in the face of churn", I think.
It's the Mad Hatter's tea party, you sit down, you figure out how it works, and then poof a third of its gets overwritten and your past investment is significantly washed away by someone who absolutely didn't put the same amount of thought into what is replacing it.
Underrated observation, extremely trenchant.
A strict, formal, reproducible way to communicate with the machine.
A compiler is a rather predictable piece of software; reproducible builds are a thing. An LLM has approximate knowledge of many things, and approximate and fuzzy ways to do anything even moderately complex. This is great for research, ok for planning, and it sucks for execution. The fact that LLMs can write satisfactorily working code from high-level requests is a miracle, and, as with most miracles, we're likely not noticing something, being dazzled by the slight previously unseen.
> A compiler is a rather predictable piece of software
It's totally predictable, on purpose. It's a little hard to debug the output of a compiler when it produces a different output every time.
My comment wasn’t about LLM vs compiler, but about low level libraries vs high level libraries.
Not OP but similar type of brain here. Certain types of abstractions make me uncomfortable, the worst being "trust me bro" type web framework abstractions where there isn't a direct link between A and B, just a contract definition that says "A and B will integrate... somehow".
When an API says it takes something, I need to know the exact form of that "thing". Saying "you can give it this object" doesn't suit me because where are the edge cases, where are the interactions, how can I know for sure I'm giving it what it needs. The docs never tell you where to find the object def, then you spend 3 hours diving into the source code to understand it's just a two item struct or something.
LLMs introduced an explosion of complexity, suddenly code bases sprout out of nowhere, and there's no point in following all the different datapaths through because the guy who loves testing out the latest claude will just change everything in a few days anyway.
With low level programming, nearly everything is just raw data, aligned to meaning. I like to tell juniors confused about file types, that file types are a social construct, they're just a bag of bytes with some structure. Same thing applies with low level programming. You know what a byte is, you know the endianness, the signedness, you can feel comfort in knowing you're not missing anything, and then you build up from there seeing each block build upon the previous.
> I like to tell juniors confused about file types, that file types are a social construct, they're just a bag of bytes with some structure.
I always get confused about what the hiring landscape looks like. How is it that people are grinding leetcode or whatever just to get into places, but still have those kinds of gaps in fundamental understanding?
Because even prior to LLMs, “knows how to program” and “understands computers” could be disjoint. I worked with someone who didn’t understand how to find what was consuming their disk space, nor how to fix it, or most egregiously, that they needed to empty the Trash (MacOS) to actually reclaim the disk space.
I'm not in a field where leetcode is the deciding factor but there's similar gamified focuses. The idea being you can pick out self-motivated autodidacts with those kinds of challenges/experience in the challenges, then fill in the connective tissue later.
This was just one example of a capable intern who was tripped up by file types.
> No one confessed the Machine was out of hand. Year by year it was served with increased efficiency and decreased intelligence. The better a man knew his own duties upon it, the less he understood the duties of his neighbor, and in all the world there was not one who understood the monster as a whole. Those master brains had perished.
- E.M. Forster, _The Machine Stops_
Abstraction is terrific and terrifying. It is the shoulders of giants we build upon, but when it begins to scale nonlinearly I fear it endangers us as much as enraptures us.
I keep a print out of "The Machine Stops" on my bookshelf. It was hugely impactful.
> You know what a byte is, you know the endianness, the signedness, you can feel comfort in knowing you're not missing anything, and then you build up from there seeing each block build upon the previous.
IMO you’ve chosen a flight level you’re comfortable with (which is fine!) but there is much going on below the abstraction that lets you view a file as a bag of bytes.
I’m saying this as someone who uses SwiftUI and CoreBluetooth on a daily basis, and I have to trust these foundations just as you seem to trust the C compiler and a filesystem.
Not the person you are responding to, but for me I really like to have a general understanding of how things work under the covers, but then have confidence that the contracts between me and those lower layers are rock solid, and that's simply not the case with LLMs.
Take software. In college I took computer architecture and digital logic design courses, and I thought they were immensely valuable in understanding how computers actually work and what software is actually doing. Sure, modern chip design is obviously several orders of magnitude more complex that what I studied, but I understand the basic concepts, and more importantly I have faith that chip designers do understand the nitty gritty details. Moving up the stack, I also had to build a rudimentary compiler in college. Again, modern compilers are a lot more complex, but I know that if something breaks, there is an identifiable bug either in my code or the compiler (or maybe even the chip). And importantly, while I may not have the skills to debug all the layers, when someone explains the bug to me, I can understand it in context (e.g. I'm not a chip designer but I thoroughly understand how Spectre is exploited and mitigated).
LLMs are nothing like that. Not even their builders understand the low level details. They're inherently stochastic systems, so people get slightly different results every time they're run. There is no "clean interface with a contract". And perhaps most importantly, many programmers are still expected to be responsible for their code, even when AI agents are generating so much of it that it's impossible to understand (or even read) it all. That's the thing that really stresses me out, when I'm responsible for a system but I don't really understand how it works.
To me the reasoning of understanding all the things you use in a rock solid way is hard to grasp.
You just typed some text and hit send. You trust that the combination of letters that form words and the combination of words that form sentences, arrive somewhere in a list of comments? But do you understand how those bytes (utf8 or utf16 or..) are transmitted (which endianness, how are they packaged, does it use sentinels or length codes), where do they end up (database, plain text), how is the text organised (alphabetical, by data, by points...)? In fact you are not sure about any of those. Still you typed and hit send. So how is that much different from writing a prompt and hit send?
So first of all, when LLMs first came on the scene, I did want to understand them better. I read the Attention is All You Need paper, I did Karpathy's transformer course, etc. And I think this basic understanding of LLMs and further reinforcement techniques makes me understand better how to use LLMs, e.g. what their limitations are, etc.
But most importantly, there are very different qualifications in my head for things I just use and then get on with my day, and tools that are integral to things I am building. I take the bus but I don't really understand how a diesel engine works. But if I'm building it, I'm responsible for it. In fact, you brought up some networking issues in your comment. For a long time when I was a software engineer (primarily a web developer) I felt that my knowledge of network engineering was lacking, so I specifically took some courses in network engineering to better understand how my code interacted with the network. You also brought up text encodings. Once at my job I did a full, rabbit-hole deep dive into text encodings and localization because we had frequent bugs related to localization, and I still find a lot of developers misunderstand a bunch of the important details in localization (e.g. the difference between an encoding and a unicode code point).
But sure, I don't need to understand every minutia of detail at the atomic detail. But I really like to know that I could, and in the meantime I have a enough of an understanding to build a complete conceptual model in my head.
Now consider the case where I send you a message (in a language that's not english) and it doesn't render as text on your screen. Reasonably, because I understand how network protocols work, I can assume that it's not a little/big endian mixup between our systems - the HTTP request would not have worked, then, as utf-8 and utf-16 are incompatible (unlike the weird utf-8 ascii mix). With HN, I can open up developer tools see what encoding it is sent as over-the-wire, and then I can ask you to look at the encoding on your end. I can say "the vibecoded browser you use is trying to interpret this as utf-16 but hackernews only sends utf-8". I can dial down the root cause of the problem and then address it.
Contrast that to a situation where I ask an LLM to use a tool and it can only do it like 98% of the time. How do you root cause that. How do you fix it such that that doesn't happen again?
Also consider: occasionally your support agent gives people free plane tickets.
Yes, we've made a lot of progress towards LLMs being fairly good, and adversarial systems and such do work, but it is asymptotic approach to 100%, never actually 100%
> What determines the flight level of understanding you need to function?
The level where r and fl are seen as different letters?
Look, I know this comes off like I'm being an ass, which means I am being an ass, and I'm sorry. I also make many mistakes and need much forgiveness.
I'm also seeing many more innocent typos such as yours on HN. Does it matter? I don't know. Every other response to your question seemed to understand that you meant "right" instead of "flight", but that's also the kind of error, i.e. `if x=1` instead of `if x==1` which is easy to make but not always easy to catch visually when you are looking at the logic internal to the loop.
To me, bending "right" to "flight" reads like a fun way to clarify that the question is not about proficiency but about depth. Not a typo the way I read it.
This was actually helpful: I thought "flight level" was some new hip expression that I had not seen before. I was pondering what "flight" added there; is it like the hexagonal architecture that is not actually hexagonal?
But sure, "right" makes sense in the circumstances.
Same I assumed parent meant "flight level", like a plane flying over terrain at different altitudes, the closer the more detail you see.
I’m this type of person, for me it’s: can I confidently teach my mental model and understanding of the thing to another person.
Not the GP, but I think I have a similar urge to go deep in understanding details. I definitely find myself different than many peers who are more comfortable operating with ambiguity.
"A clean interface contract" is actually all I need to stop pulling the thread, but I find that is rare in large software systems. More typical is that the provided interface lacks details about edge cases, such that multiple behaviors could meet the interface. That's what makes me want to dive deeper and figure out what those cases are, what I think is the best behavior, and what the system actually does.
I have crippling imposter syndrome. Using AI really aggravates that.
Huge part of it. A big part of my idea of the negative impact of the internet in general is that it constantly exposes you to people who are doing the same things you love and are interested in, just way better and more effortless, alongside yet more people criticising even these golden gods for this or that failure you could only hope to reach.
It's an imposter syndrome machine, but one you could perhaps tune out because it wasn't really useful for much except entertainment. LLMs bring the experience of being followed around by that machine talking into your ear any time you have an issue or problem - you could just ask your fabulously talented friend to do it instead. And they are sadly tremendously useful so keeping that mental compartmentalisation is way harder
I think there is a basic human need to to be "the guy" everyone goes to when they need help with a specific thing. Where "everybody" is roughly a Dunbar's numbers worth of people, a tribe or a village if you will.
We've developed fabulously effective ways to wrench the fulfillment of this need away from a huge amount of people
I think programmers are frustrated in part because the code used to be our place to do our thinking, but now LLMs just buzz through the file changing thousands of lines and we can't keep up.
It's still valuable to deeply understand parts of a program, but we don't have any tooling that helps us do that. We just have to raw-dog it by thinking really really hard and remembering how all the code connects together.
I want a tool that gives programmers a place to record their thoughts. Developers need a place to draw and write, and also interleave blocks of code that automatically update to match the actual state of the code.
The closest thing I know to this is org-babel, part of Emacs, which allows you to push code blocks out of an org file into an actual source files, or pull them in from actual source files. This is mostly done manually by invoking functions called `tangle` and `detangle`.
I intend to investigate this further in Emacs, since I'm an Emacs user, but Emacs is never going to be the friendly UI we need to make this tooling common.
Yeah, I can relate to this. However, I haven't found it too difficult to adjust. I have found myself creating draft PRs, and then just sitting on them and thinking about it for a day or two before I even consider merging it. This lag time is the time that I used to spend typing it out and thinking as I went along, now that's happening later. I have closed more than a couple of my own PRs once I had time to consider them. I am rarely shocked when I wake up the next day, look at it, and think: "Eh, this change is not sufficient because it doesn't address X".
Yeah, this is the tough part. In order to write code that worked, you had to have some kind of mental model of it. Now that's not true.
Now, when someone sends a working PR in, even high quality and well tested, they may actually have no idea how it works.
Which, in my experience, means they sometimes cannot fix the bugs they've introduced.
No, indeed. They rely on LLMs to do that, and that necessarily adds a degree of entropy that will eventually cause the thing to vibrate apart, but much later, in the future. Meanwhile, the incentives are to fix (or "fix") the bug now.
I think that software engineering is finally entering the "regulations written in blood" era.
Oh yeah. The AI hype cultural moment will wear off, but we'll be stuck with the technical debt, cognitive debt and slop code, which has made it into critical production systems, for decades, probably.
The code--as long as you don't try to modify or evolve it, engendering further nondeterministic degradation--will mostly work, but 0.01% of the time it won't, and you'll never be able to predict when and where that'll be.
> now LLMs just buzz through the file changing thousands of lines and we can't keep up. It's still valuable to deeply understand parts of a program, but we don't have any tooling that helps us do that.
I do it differently, I focus on better recording what the user wanted, the so-called "user intent". To do this, I record all messages typed by the user since the start of the project, whether 3,000 or 10,000 messages. An LLM can churn through them in 10 minutes and derive a fresh, up-to-date interpretation from the raw data. This can be used to judge whether the implementation has diverged from the intent, or, in other words, to realign the code and tests. The messages the user writes are usually designs or corrections, a very rich, compact signal. If the user struggles with something, it could result in a tool, a skill, updates to the project docs, or new tests.
Yeah, "Intent-based UX" is evolving to address this challenge, but it's got some catching up to do AND is far from mainstream....
But a codebase is a state machine, and given the somewhat random style of LLM outputs, those amplify to an extent that the recorded intent needs to include the outputs too, in a way? Or are you basically doing high detail specs?
The workflow I use to still keep up with everything is to start coding by hand and only once I have a good idea how the rest is gonna look like and am bored I had off the rest of the pr to the LLM.
Could be just defining the methods without filling them but depending on the mood I code more by hand or less.
> It's still valuable to deeply understand parts of a program
Part of woe is that once you've reviewed, validated, and comprehended a piece... Later gets casually mangled by some other LLM-generated urgent change.
Yes to this. With the speed of ai code generation, the team has to decide not to rip things apart in every pr even though it is possible, since this destroys any hope of maintaining even a bit of understanding.
Some parties mean that making understanding irrelevant of the whole goal of ai driven development, though.
I feel like we also need better non-LLM driven ways (like better static analysis tools) to analyze LLM-driven changes. The way changes are presented in modern IDEs was designed around reviewing human-created changes and doesn’t really feel like it’s keeping up with presenting and validating what modern LLMs are doing.
I've been playing with often asking Claude to generate visualizations for me of what it's doing in the sense of diagrams of different types. Sometimes it's as simple as "show me what you're doing using an infographic". Othertimes I'll ask it for sequence or class diagrams or bipartite graphs if it's designing some sort of mapping. Bipartite graph is also very helpful for following the plan of a big branch rewrite or squash which I often do before making a PR to get rid of all those confusing in-between commits.
I find forcing it to visualize things immensely helpful. I'm usually studying git diffs but when working of a big feature or refactor that can just be too hard.
I've never been very pro "visual programming" and always hated UML et al, but part of me is starting to wonder if it's time for us to give it another serious go.
UML is not a terrible idea from a systems architecture point of view but UML is absolutely terrible at describing business logic. And in today’s age of CRUD apps and frameworks, for some devs, business logic is the entire problem to be solved.
What is “valid” input? What is the failure scenario at the boundary for the consumers of your application? How are exceptions in the business handled? All of these are questions that might have a somewhat obvious answer, but if your goal as a business is to do something radically different compared to your competition, the “obvious” answer might be the wrong one.
The usefulness of UML is highly reliant on the names you choose. And current LLMs are really, really bad at naming things. "The collector's refresh cycle has a bug: when the cache hydrates, the Cartesian grouping is misaligned" type nonsense - it absolutely will name a class "CartesianMisalignmentHandler" if you let it, good luck understanding what that is on a UML diagram
> I want a tool that gives programmers a place to record their thoughts. Developers need a place to draw and write, and also interleave blocks of code that automatically update to match the actual state of the code.
Sounds, like you already mention with org-mode or similar ones) like literate programming (https://en.wikipedia.org/wiki/Literate_programming) or jupyter notebook.
I think the solution is still code, just at a much higher level of abstraction. Maybe a start is kind of typed ADR or FSM that guides (constrains) the agents. I believe more type checking guarantees will be more and more important for agents.
I don't think the solution is code, because I still want a place where I can write my own chain-of-thought, without it having to rise to the level of "code". I just want to put my chicken-scratch drawings and diagrams somewhere. I just want a place to think that won't change out from under me.
> It's still valuable to deeply understand parts of a program, but we don't have any tooling that helps us do that. We just have to raw-dog it by thinking really really hard and remembering how all the code connects together
Which is frankly exhausting to do when you have to keep up with the rate of LLM changes
I can sling code at about 20x speed with an LLM, but I can only understand it well enough to support it at 5x speed and I can only make decisions that won't piss off the rest of the company at about 3x speed. My job as a software engineer is to therefore slow down to working merely 3x faster than before despite the extra headroom that the LLM gives me. Anybody can give into the seduction of new features poorly understood, to be a specialist means to bother spending the extra time.
Or at least that's the current model I'm playing with.
This is my dilemma as well currently, because there's no obvious place to draw that line. The boundaries are all subjectively defined.
I could change a whole UI completely in 30 minutes to something fundamentally better but then 30 people would all wake up and be upset they weren't consulted and need training for it. That training and consultation will take hours and hours. And probably generate feedback - some of it correct, some of it misguided - that needs to be human negotiated, taking more hours. The effective maximum rate of change is limited so dramatically more by other factors than the technical implementation that we have to completely redesign process now to cater to those factors.
We are in a weird space now because most of the process is still built around a presumption that technical implementation is a lot of work. The main reason to be upset that you weren't consulted about a change is because there's a presumption that you will be stuck with it - ie: it's a lot of work to change it back. But it isn't a lot of work, it's effectively free. All this is just living in inertia right now.
I've been handling it as a sort of voluntary A/B test.
A is what you're used to, B is what I recommend. If I can convince people to start using B instead, I can look at the metrics for A and conclude that it's effectively dead, and then I can remove it.
It's working out for me, but maybe not a fair comparison because I only have something like 15 users.
Yeah it's an interesting one - I have had the same thought process. If code is free, and I trust the tests and the review process, why not deploy a different branch to production for every user that wants one? it's only at the point where shared resources such as database schemas conflict that it becomes an issue, but a large slice of user requests don't even touch those. If something gets deployed broken in one branch, someone can flip branches and use the one that works. As long as the system maintains strongly enforced safety boundaries, a thousand roses can bloom outside of those boundaries.
It does beg the question where it all leads however ...
> But it isn't a lot of work, it's effectively free. All this is just living in inertia right now.
... but it isn't free. You're introducing a certain amount of entropy and drift every time you let the coding agent loose on it. There's a hidden cost of loss of cohesion that comes with changing anything and then changing it back, and while that cost exists with human developers, too, the pace at which they work and think limits the damage and the risks. LLMs just compound them, but the consequences are long-term, while the incentives are to do the thing now.
I've been having agents build knowledge graphs, they're a tremendous mess to start with, but I take the time to manually drag nodes around or group them in meaningful ways so that it's actually human-browsable. This is boring enough to create space for me to think in. It leads me to go on expeditions into the code which surface the missing details. It's also a nice way to communicate context to agents. Like, I can hide all but the relevant nodes from an agent before suggesting that it query the graph to understand which service references which other service via which api, which database tables are read/written by such an action, etc...
Curious, how do you do this? What tools are you using to build and manipulate the graphs, and how do you feed that context back to the agents? The manual organization part sounds particularly interesting.
Very much a work in progress, but: https://github.com/matrixmanatyrservice/knowledge-graph-edit...
I find that there are domains where LLMs are much faster and more skilled than I am, particularly in extremely well-documented but technical and complicated, but a lot of domains where they cannot do anything at all (mostly novel issues, weird architecture issue resolution, etc.).
Building a basic X11 window manager is almost a one shot prompt.
Modifying a UI toolkit to make it work with MSAA/IA2 is simply not possible.
There's a lot of room for deep work left... for now.
When you say this is simply not possible you sparked my interest. I would be curious to chat about your approach?
If I were trying to accomplish this particular goal I would first consider what the agent could see. In particular does it have an accessibility inspector of some kind? or even NVDA hooked up with NVDA Remote so that it can actually see the implicit a11y tree for the toolkit it is working on? My email is in my profile and I would love to chat about this.
> It's still valuable to deeply understand parts of a program, but we don't have any tooling that helps us do that. We just have to raw-dog it by thinking really really hard and remembering how all the code connects together.
I deeply relate to this. When engineers were writing all the code that meant every part was deeply understood by _someone_ on the team, and they could valuably contribute to maintenance and further development. It wasn’t perfect, people leave, people forget things, etc, but the overall coverage was high and valuable.
Now, every agent-produced MR introduces code that is deeply understood by _no one_. It’s the “original developer left five years ago” problem, but now growing on every single new piece of code. Reviewing doesn’t give you the same depth of understanding, and the continually increasing impulse is to just approve, maybe nudge it about some isolated enum types or something, but don’t take the time to understand it, just keep the train going.
But then what happens when something breaks and the cloud agents are down…
> It's still valuable to deeply understand parts of a program, but we don't have any tooling that helps us do that.
Doesn't the LLM do that, if you want it to? I do use it to write code, but the more striking ability it grants me is a means of understanding legacy code far faster. I can ask "what actually causes this branch to be taken" and it's usually right. Ok sometimes it's not right, but I'm not always right either even after I spend tens of minutes reading code.
It's also exceptionally good (i.e. fast) at looking through git history to figure out where/when a certain behavior originated, which can be difficult (time consuming) if code is continuously being refactored.
Sure you could use it to vibecode. I don't, rather the opposite, I understand my own changes better. But I still fear that I'm going to be obsolete as soon as it figures out what questions to ask. And I'm unwittingly training it to do that.
> But I still fear that I'm going to be obsolete as soon as it figures out what questions to ask.
Code and business requirements, outside of maybe very pedestrian CRUD apps, is diverse enough that I don't see that to be a realistic concern. A far bigger concern is that it may not matter whether they're asking the right questions, and that sufficient brute force can overcome any objections like 92% of the time--good enough for government work, good enough for the MBA frat boy who lords over you and always saw you as a needlessly expensive typist anyway...
To the extent that I set business requirements, it's me helping people with vague ideas make them more concrete. But that's not enough work per year to keep me on the payroll.
In my case the questions I'm talking about are lower level questions about the code that are steps along the way to achieving whatever higher level goal we've agreed on.
Even that requires a degree of thinking in code that is only really possible from having written a lot of code.
Agreed. Coding agents are an excellent tool for navigating an codebase to deeply understand the code (certainly better than grep!). My existential question is more about whether deeply understanding the code is worth doing at all. If your identity as a programmer was based around being the one who understood the code the best, why is that valuable when anyone can use the agents the same way?
The annoyance I have is that it isn't one of the other. I spend a lot of time thinking and fighting with whatever frontier model we're on today. I've seen people let LLMs make absolutely atrocious decisions and just click next and collect checks.
I just posted this morning about this type of engineering has secured us numerous customers and put some projects in our backlog that either need significant rework or at least a very close eye to see if their issues crop up.
IDK, the idea that we shouldn't be thinking is a worrying one. I still have to think a lot.
What I'm _mostly_ worried about is that the path to get to high performing senior is basically a burned bridge with our current training techniques, and I'm not sure we'll adapt before a brain-drain situation in the industry.
Not exactly what you asked for, but I now keep pencil and paper next to me, and that has been incredibly refreshing for brainstorming / mental processing
This piece is either a psyop or written by the victim of a psyop. I believe the former is more likely. It establishes for granted that LLMs produce more optimized code than performance-oriented humans do. This could not be further from the truth, and I think any human who writes low-level performance-oriented code knows this. It's not even remotely close to being close; LLM code is abysmal if you look at the details. I think the only way you could come to this misconception is if you were not a low-level programmer; certainly LLMs can produce more optimized code than whatever abominations JS devs do, although even this is not a given.
Take, for example, Claude Desktop and Claude Web. They recently bragged about reducing their first paint from 4500ms to 1000ms. For an interface that displays text and sends/receives HTTP chat requests for more text, let's remember. This is from a frontier company that can allocate infinite compute to the frontier models consumers don't even have access to. Let's not get into how it consumes gigabytes of memory. We wrote more efficient GUIs than this in the 80s with 128kb of RAM on a 4mhz CPU.
These despair pieces do not reflect reality in any form, and they're so far from reality that I believe this is more likely to be an article written intentionally to deceive people who don't know better than it is to be genuine. Performance engineer jobs are not going anywhere. LLMs are not generating better compilers nor better kernels than what exists. They're producing insanely inefficient CRUD garbage.
> Take, for example, Claude Desktop and Claude Web. They recently bragged about reducing their first paint from 4500ms to 1000ms. For an interface that displays text and sends/receives HTTP chat requests for more text, let's remember. This is from a frontier company that can allocate infinite compute to the frontier models consumers don't even have access to. Let's not get into how it consumes gigabytes of memory. We wrote more efficient GUIs than this in the 80s with 128kb of RAM on a 4mhz CPU.
Developer tolerance of low performing software has been a problem since before LLMs though. The whole industry seems to think O(seconds) is a perfectly acceptable amount of time to launch a program. For decades, as computers got more and more powerful developers tolerated proportionally poorer and poorer performance. There's almost no such thing as a "performance-oriented human" anymore outside of a few niche industries, and nobody is really producing and sharing much hand-optimized high-performing code anymore, so it's no surprise that LLMs trained on the Internet are not good at it either.
I think it's tied to the fact that many developers are given unreasonably capable systems (compared to end users) for running their software, or else exclusively test on small data sets or without considering resource limitations or real-world situations.
I've seen plenty of product demos that work fine with test data, but once you introduce real world things like: 200+ concurrent users that need to do more than just navigate to the 3 most easily demonstrated screens; application is hosted at a data center in another state; making that hosted system be a shared tenant; introducing data of real-world complexity; making the client system be a system spec'ed for a basic office worker 5 years ago; installing web filtering and other applications and not only running your one application.
Suddenly, loading N,000 records into a dynamic gridview table on a page load becomes a real bad idea, and the occasional needing to view logs or audit trails that reach N,000,000 records to load into that same dynamic gridview table means the site just times out.
It's a similar reason why you can sometimes find that you have to scroll right and left on a site. Well, that's because the dev has multiple 32-inch monitors in 4k or 8k, and they're not designing the interface for the 1080p laptop screen that most of their userbase actually has.
It's also no surprise that they are markedly worse than the already low status-quo. Just because it was bad before doesn't justify it getting worse.
There is one requirement which is more important than performance: Software should exist in reality, not in imagination.
You could dream all you want about how you would write better version of claude desktop. Fact is: you didn't. And you never will.
> You could dream all you want about how you would write better version of claude desktop. Fact is: you didn't. And you never will.
I already did, actually. I work in an LLM startup that produces small models for specialised purposes and I wrote our frontend interfaces, which are vastly superior to both Codex and Claude's interfaces. Unlike OpenAI and Anthropic, we are profitable, turning 8-digit revenue with zero outside investment. We have complete ownership, without tens~hundreds of billions in expenses and debt. Excellence in software still has a place in the world, even if the VC darlings get most of the attention, because at the end of the day consumers and enterprises alike will pay for software that truly works well.
Unless your frontend can be used instead of claude desktop you didn't built better claude desktop. You built something different.
I didn't said what you can't. I said you didn't.
It can be, and I personally use it with my Codex subscription as well. Model interchangeability in an interface is completely trivial.
> LLM code is abysmal if you look at the details
This is, unfortunately, false.
Yes, if you one-shot some code with an LLM, it can be terrible. But if you let it profile and optimize it, there is no obvious limit. LLMs have more patience to investigate performance issues and fix them than humans.
Again, I wish this wasn't so, but I see it in my job daily. There is code in my projects that is vastly faster because of LLM optimizations. Not only can they find more in less time, but they find things I and my co-workers would not have thought of.
I'll take your claim that I'm capable of writing a psyop piece as compliment :) Truth be told I'd rather be writing a psyop arguing the opposite point than dealing with these emotions.
To your main argument: I absolutely agree that LLMs are terrible at producing working code, or efficient code, and that they're incapable of solving lots of important problems. I've seen LLMs make embarrassing typos, patch vulnerabilities with differently vulnerable code, and go through the motions of optimization as if blindfolded.
That is, however, not the central matter here. IMO, at present what management thinks LLMs are capable off has a larger impact than what LLMs are actually capable off, and while I'm hoping that the market will regulate itself once more and more slop projects break down, that'll take time, and I'm not confident that LLMs won't improve sufficiently by that point that the most glaring mistakes will be fixed. Of course, new and non-obvious issues may still be present, and they may cause trouble at a later point, but again, that won't happen immediately and I think we'll just end up in this infinite loop for the time being.
I will also add that AI companies' claims affect the general public's perception of the acceptable level of software quality. If Anthropic says 1000ms is great, and other companies follow the same approach, people will consider that the norm and not demand better software. This enshittification has started a long time ago -- just look at how bloated Windows and the web are -- and I don't think it's going to end just because we know things can work better.
Taking a step back, I think it's really a question of how many people will understand the value of what people like you and I can deliver. That number has been falling bit by bit before the LLMpocalypse, but now it's just becoming abysmal.
I understand the fear that perception matters, and it does, which is why I take issue with articles like this and use terminology like 'psyop'. You are effectively harming your own cause when you write things like this:
> If anyone can point an LLM at slow code and it automatically finds a hot loop and uses a trick it found somewhere on the 'net to vectorize it, there is little point in hiring someone with a focus on that.
If you yourself are saying there is no point to hiring you because an LLM can do what you can do, when it actually can't, you are actively contributing to the perception you don't want to proliferate. And although I am financially set from my own work, I am also opposed to that perception proliferating because it is wrong, and the discourse around blatantly untrue things is extremely tiring. We need to bring perception closer to reality, not perpetuate the divergence of perception from reality. OpenAI and Anthropic have an extremely vested interest in influencing both industry and consumers to believe things about their products that are not true, because their dubious financial future is staked on people believing those things, but we don't need to help them along.
Yes, that's a good argument, thank you. You bring up a good point and I'll try to avoid making such claims in the future.
> LLMs are not generating better compilers nor better kernels than what exists. They're producing insanely inefficient CRUD garbage.
Exactly. People always talk about how LLMs can produce CRUD user-apps and then say, ok there's no more reason for humans to write code anymore.
These CRUD apps are the most trivial, simple things. The AI agents make inferior, bloated, unmaintainable, and unreliable versions of these simplest of things which have already been done to death.
There is a a whole other realm of programming innovative tools, performant systems, truly insightful solutions that people will need to keep working on. No AI agent swarm is creating the next FFMPEG, or coming up with and implementing the whole idea of using monads and do notation. They're not creating true progress (spam-solved math proofs have yet to hold out as solid and useful), only making half-baked, inferior copies of the patterns that are already out there.
Saying, "Some programming is being replaced by AI agents therefore all programming will be replaced by AI agents," is a big converse logic error.
Even if LLMs aren’t producing more performant code today, them solving frontier math problems (especially discovering new optimizations) suggests they’re close. You can algorithmically judge performance, and recent advancements have been in the algorithmically judgeable.
LLMs recently optimized integer multiplication and matrix multiplication beyond the known theoretical limits.
If you tell them to optimize and give them evals and targets, they will optimize. And they will be more thorough and diligent about it than you.
We're all going to have to cope with the fact that LLMs are now better at programming than us. It is professional irresponsibility to not use an LLM in 2026.
> We're all going to have to cope with the fact that LLMs are now better at programming than us. It is professional irresponsibility to not use an LLM in 2026.
As a categorical generalisation, this is absurd. Much depends on much, and the devil is in the details. In certain domains, this might be true, though the word "better" is doing a lot of work there. It is certainly not true in all domains; my consulting practice, where code is written by hand, is thriving, and my clients are mostly AI companies who have discovered the limits of "vibe coding" in this particular area.
Thank you, this is coming close to my own reaction to the article.
Folks reading this: none of this bullshit and hype is inevitable. You don't have to be delusionally enthusiastic about something just because a lot of people around you are.
Absolutely right! Honestly, I hate AI even though it COULD make me 10x more productive in what I do. I can think of a dozen tasks that AI could help me with.
Audio processing for instance: I process audio by hand, it's more of a rote task, and it takes me hours a week to do it. AI COULD give me what I want in probably one minute. One minute instead of one hour.
But firstly, I've built up my audio processing skill over years and I enjoy it. It's calming. It's not creative, thinking up new stuff-type work but it's calming. And secondly, I want to do things myself. I don't want to let a machine do everything so I can concentrate on the high level stuff.
In fact, what I've found is that my mind works best when I'm NOT concentrating on high-level stuff. When I just go about my tasks by hand.
Do I write code to save time? Yes I do. But I write the code by hand and I understand how things work from first principles, as far as possible of course.
So, I don't use AI. AI could take away hours of work for me and I don't use it because I hate it and I hate the idea it represents.
There is no study showing a 10x productivity improvement. There are a few studies showing a productivity decrease.
Your comment feels like it was written 18 months ago.
A vibe coded typescript compiler runs twice as fast as the one maintained by two dozen people led by some of the most brilliant language and compiler experts out there backed by thousands of open source contributors.
All of that by saying "here's the tests, implement it in rust".
> Your comment feels like it was written 18 months ago.
AI bros have been making the same claim for the last 3 years. It wasn't true then, it isn't true now, and it won't be true the next time either. You just aren't willing to admit the emperor has no clothes.
Previous poster stated ai can't do hard problems.
Yet there's a typescript compiler vibe coded, 100% compliant.
> It establishes for granted that LLMs produce more optimized code than performance-oriented humans do.
I didn't read the piece as claiming anything of the sort. I read it as claiming that employers don't care.
The author is well known around here and has demonstrated quite a bit of low-level technical proficiency; see previous submissions https://hn.algolia.com/?q=purplesyringa.moe .
On the one hand, the Claude code thing was indeed a weird brag, because they took shit performance and made it suck slightly less. It's not in the same ballpark as getting a 2% boost in an already highly optimized system (e.g. Google search results page lets say).
But it was also a tale of simply needing to tell the models what to care about. They built metrics (I'm sure they vibe-coded them) and then told the system to optimize itself to those metrics. And it sort of worked. Of course most LLM code is not performant by default, you still have to prod it to optimize itself. You can't one shot it yet. But nothing about the trajectory of this stuff tells me it won't get there some day soon.
>LLMs are not generating better compilers nor better kernels than what exists.
Not LLMs, but AI is inventing new hardware:
https://deepmind.google/blog/how-alphachip-transformed-compu...
I also thought that, and then I started pointing Claude at various projects and having it look for optimizations. The projects themselves were, of course, largely AI-generated. What I found was that simply asking it to improve performance could indeed help, but if I pointed out specific architectural issues - like storing massive graphs in a giant JSON blob - and then recommended a solution (normalize, store in SQLite, recursive CTEs to walk it), the performance ceiling went WAY up.
Now, you could argue that AI didn’t fix that, I told it what to fix, and it just wrote the code. That’s valid, I suppose. The view I’m coming around to is that LLMs do know how to write performant code, but their corpus is so full of garbage that you have to tell it explicitly what you want, which requires you to know how to spot the problems and solve them.
I will not make any claims that they can write kernels or compilers well, because I haven’t tried to do either of those, on my own or with an LLM.
Another anecdote: yesterday, I got tired of dealing with Mumble on my LAN (random audio issues on the Mac clients, poor echo cancellation, etc.) and asked Claude to build a replacement. I gave it a rough spec, including non-goals (private use only, so no encryption needed, and I don’t care about supporting a large number of clients), then told it to build it in Rust, supporting MacOS and Windows both natively. Two hours later, it worked. Not just kind of, it worked flawlessly on Macs and Windows, and the audio quality and echo cancellation was perfect. The only bug I found - which it fixed - was denormal numbers was causing relatively high CPU (~1/2 of a core) usage on Windows due to x86_64 handling of that. The binary is 5 MB. It ran its own echo cancellation training while writing it to tune parameters. It implemented RFC 2198 without me mentioning it (hell, I didn’t even know about it - it’s fascinating!). When I fed it back some logs, it saw that one client had higher latency than expected (meshed WiFi without a backhaul), and then proceeded to create a network simulator so it could test various latency and jitter scenarios to solve it. While doing so, it also determined that Windows was lying about its latency numbers by 25 msec, and addressed that.
So again, I think LLMs are capable of excellent work, you just have to know what you need to ask for.
Actually LLMs are creating better compilers than what exists. In 2 weekends I let a LLM write almost fully compliant re-targetable C23 compiler (except for a few C library related things that are worthless for its targets) with state of the art optimization for five 8 and 16-bit fairly different architectures. For PIC16F/18F it's slightly better than XC8. For 8051 it's waaay better at optimization than industry standard Keil C51, and of course sdcc. Dev process found several pretty startling miscompilations that XC8 is prone to. And it's tiny. Codebase is like 0.5 MiB with data file for all ~1100 PIC microcontrollers that normally take gigabytes in XC8 taking 350 KiB.
So it's optimized both on code/data size needed for the compiler, which is like 3 orders of magnitude smaller. It has better coverage of C23, and it produces smaller, faster and more correct code. :)
>>“I didn’t care about practicality, building useful programs, or writing code per se: all I wanted is to understand how the machine works.”
I like lifting heavy things and moving them around. In fact I like it so much it’s a massively effective buoy for my mental health. However, I don’t expect the economy to make space for me to move farm equipment around to make food and expect to get paid a living wage doing it.
Software like food is now a civilizational requirement and transient LLM crappiness notwithstanding, accessing well-built flexible plentiful software is a major unlock for humanity.
I’m happy now to go the gym and lift heavy things and let everyone have plentiful food grown by mechanized agriculture. I’m looking forward to do the same for my intellectual pursuits.
the problem is we refuse (americans) to let things that we need to be civilized to be in the public domained, "owned" by government and pushed into our "free" spaces.
Libraries are the last time americans agreed on basic principal that a public space with a public good is worth investing in everywhere.
aren't libraries nowadays serving as a dual purpose as day-shelters for homeless and mentally ill people?
Why is america so much against public services in general?
Honest: racism. Social services would benefit black people. Since 60s "integration" half the country has convinced themselves that cementing pools, literally, is better than letting black people integrate.
It comes in lots of flavors but it all is a facade against allowing black people benefits.
That's certainly honest, but isn't remotely accurate. I know plenty of people who are opposed to social services through the government (note the qualifier there), but are perfectly happy to have black people in their lives and communities. They simply believe that social services are best provided by private charity, not the government.
https://theconversation.com/the-forgotten-history-of-segrega...
Completely true. Absolutely hidden behind bullshit "welfare queens" and the rest.
Anyone who denies this history just likes the privelege that "business" interests generates.
Great sentiment about reserving intellectual heavy lifting to your personal life. I've always valued keeping enough in the tank for myself (and now my family) outside of work.
It seems in our profession there might be less satisfaction from work, but if it leaves me with more space to accomplish things in my own time, I think I prefer it.
If you do intellectual things only in your free time, well, working people don't have much free time. One of the perks of software development (and other LLM-impacted professions) for nerdy types is that it allowed them to do intellectual things all day, and even get paid for it. Now all those hours at work are no longer fulfilling.
> It seems in our profession there might be less satisfaction from work, but if it leaves me with more space to accomplish things in my own time, I think I prefer it.
I wonder why you expect to have more space to accomplish it. What happens when the managers realise that they can get more 3x, 5x, 10x, whatever x more software?
Also, let's briefly revisit the source of all economic value: scarcity. If you can kick your feet up more, you can't expect to be paid as much for it.
>food, physical fitness, health (obesity, life expectancy, etc)
Those are unfortunate examples. The US doesn't do them very well compared to other OECD countries.
> The US doesn't do them very well compared to other OECD countries.
Are you thinking Southeast Asian countries, or European, or what?
I could have done many different things as a career - I chose what I do because I love(d) it. I think many of us were raised believing that a job you love is not a job and we’re now grieving the loss of fulfillment that came along with doing something you love and getting paid for it. I spend far more time working for people I don’t know than I do with my family or my hobbies, and perhaps I was foolish enough to think I’d escaped from wasting my life doing something I despise. You are correct that we can all seek fulfillment outside of work, but for those of us that used to get it there it hurts, or maybe it’s just me.
I know things get worse before they get better - but some of us are at the point in our career where we likely won’t be around to see it get better again.
I think you're right. And no, it's not just you. You've tapped into something very central and animating about software as a craft, and the cognitive and psychological feedback that got most of those who are really good at it to be interested in it in the first place. I share your sense that we'll probably not be arounds to see what "better" looks like, if it ever even happens.
Personally speaking, I started my programming journey a long time ago, building stuff for DOS - one of the first-ish things I did was build a Windows-like GUI interface, which was quite functional given the circumstances, basically writing pixel colors to the framebuffer in C.
The whole thing was quite functional, and a few thousand lines total, and built a bit naively - the framework and the app were under 10k lines combined total.
Later I tried rebuilding it for Win32, and it ended up being more code (sans bespoke UI framework), and I'm not sure it was better, though I'm certain, the whole mass of code doing the thing was an order of magnitude more.
If I were to attempt building it in Electron, I could add 2-3 orders of magnitude to that easy, all for the same basic functionality.
All I'm saying is abstraction isn't really what it's cracked up to be.
True, but the DOS version was fixed resolution and had no internationalization support.
And probably didn't support partial redraws. A lot of GUI complexity comes from handling partial redraws.
It didn't (fully), but adding it wouldn't have been more than a days work. You have a hierarchy of enclosing layout rectangles, you take an invalidation rectangle, and you recursively intersect children and them draw them with the painters algorithm.
Vestiges of the system did exist, as there were scrollable panels and controls had an idea that they were not visible due to falling outside of their parent rect, and all drawing functions were aware of being clamped to a boundary box.
So I'd say some of the hard(ish) stuff was already done, and people did end up using it in production so it actual survived contact with a paying customer, which is saying something.
Partial redraws are mostly a waste of complexity at this point. It's much faster easier just to re-layout and re-draw the whole thing in a frame. It can be done in a millisecond if you're not beholden to the browser.
At this point, yes. In early Win32 days, absolutely worth it.
Why do you look forward to this happening to your intellectual pursuits?
If I grant you that cheap plentifull code will be a net boon to humanity, it's still normal to be unhappy that it's you specifically that will need to be ground-down in the cogs of progress. 5 years ago I also believed that the future could (and would!) be vastly better for many people, I just didn't know that betterment would be conditional on me losing the work I enjoy. In that sense LLM's are only a loss to me.
Many people feeling equanimous about this stuff are financially secure, later in their career or working at a manegerial level. That's fine, but at that point you're obviously not suffering the same pain as the author.
I think personal lament is different from organizing to stop what is good for civilization.
There is a lot of the latter happening so my comment remains relevant.
“I need to block abundance for all because I don’t feel safe with change”
is probably the most dangerous sentiment coursing through our civilization right now, and it’s coming now for me, and this is my rationalization from giving in to my baser instincts.
I’m imploring others to do the same
"For all" is a bit of a stretch. Abundance for a very select few. The rest remains unclear.
The few already have Abundance. I don’t care about them.
I’m talking housing, infrastructure, shipping, medical care, all critical services and sectors where fixing decades of lagging productivity will help the working class the most.
But AI is touted as the replacement for the working class? It’s TAM is “the combined wages and salaries of everyone below the C-suite” and it gets trillions of investment dollars, and letters of marque for copyright infringement and hacking, to pursue this market.
I mean, just look at the sequence of events you’re expecting here:
1. Ai companies achieve their stated goals
2. ???
3. Housing, infrastructure, medical care, etc get better for the working class
Are you the king of the underpants gnomes or something? How could it ever turn out this way? Why does anyone think it would? Am I taking crazy pills?
> AI companies achieve their stated goals
If those goals are fully eliminating need for human labor, then I agree it probably won't be good for most people. But that will probably take at least decades.
Anything short of that, and I think economy will be pretty similar to what it is now. You still need working class and need it to be productive, so you do need them to be reasonably happy, housed, healthy, and you need good infrastructure. With lower cost for all this, why wouldn't things improve, like all times throughout history?
Not parent but I could image an (utopian?) society in which AI/LLM helps us develop software and hardware that can help generating better and cheaper outputs in those fields. Not saying it's going to happen but it could be a possible outcome.
“Are you the king of the underpants gnomes or something?”
No I’m just at the frontlines of this so called “replacement” and all I’m seeing is people doing more with less with no possibility of replacement. I have no idea what all this marketing pablum about TAM replacement is. All I’m seeing is growing businesses serving more people with less resources.
Could it be that CEO’s of struggling businesses are lying about why they’re doing the layoffs? Why are we suddenly believing them on this one issue?
Who says that just because production becomes cheap anyone but the few will benefit from that? The few already control AI, what makes you think they will share its bounties? Why would they? The goodness of their hearts? The same guys that are sitting on their pile of gold like a dragon right now while countless die every day from things their resources could've fixed? What makes you think they'd suddenly change their behavior?
> “I need to block abundance for all because I don’t feel safe with change”
… is a pretty grotesque straw man, but sure, fight it if you want.
How are we establishing that this is good for civilisation?
Every technology revolution since the Gutenberg press has followed the same pathway? There is no evidence AI is any different. They had oligarchs back then, hell they had feudal lords backs then!
There are definitely transient upheavals as civilization adapts to the new norm and we can do much to reduce those effects.
But the end result is the same, more of everything made cheaper for the working class.
We are at the tail end of a 50 year productivity plateau and rising costs. We’re looking down the barrel of the first reduction in the QoL for our kids. I for one want to see what this tech has to offer.
I completely disagree with the way you frame this.
The "abundance" is not all positive valence. It is a flood of superficial good with an unmanaged ratio of negative byproduct mixed in.
Some of the "change" is not merely doing things a bit differently. The LLM flood is effectively attacking existing feedback and control mechanisms without any attempt to establish appropriate replacements.
I think there are several more dangerous sentiments coursing through civilization these days:
1. That people bear no moral responsibility to act in good faith, and the corollary that one can enjoy the fruits of production while externalizing all the liabilities.
2. That strategies like "move fast and break things" and "fake it until you make it" are universally applicable and appropriate, rather than only in the low-stakes entertainment/media/marketing fields where they flourished in recent decades.
3. That mere acquisition of capital gives one the right to perform N=1 experiments on global civilization, the economy, and the enviromment.
“The LLM flood is effectively attacking existing feedback and control mechanisms without any attempt to establish appropriate replacements.”
I think these are problems to be worked on and they are being worked on. The work just looks boring and will not make any newsfeeds anytime soon. Our systems are changing and adapting as we speak.
See my other comments as to why that sentiment is the most dangerous sentiment. It’s easy to point to the problem of oligarch’s or clearly labellable “bad actors” and incompetence.
But neighbors agitating to block housing, unions blocking productivity enhancing technologies? Much more difficult to treat these as a “problem” as they are just a mass of historically disenfranchised people protecting their interests. But they are doing wide damage, and that same sentiment is now coming to software developers.
What is civilization if not the amalgamation of people?
If sentiment around people is that they don't want this (and that seems to be the case, based on many many articles like the above, as well as opinion surveys), then who are you to tell them what's good for them?
People don't seem to want an improverishment of mind and soul in exchange for vague promises of some sort of other abundance.
Why are they being forced to that dubious trade?
> Why are they being forced to that dubious trade?
Because it's just the prisoner's dilemma in disguise. Most people don't really like the idea of AI, a lot of people especially outside of programming hate it, and I bet deep down inside a lot of programmers would prefer if AI never existed.
But it's easier to say that AI will bring great wonders because the alternative is acknowledging the reality - the diminishing returns of technology. And that brings a lot of cognitive dissonance if you're a programmer.
I'm not sure it maps well to game theory. I think it's more of a false dilemma.
There is the old adage in many academic fields that "progress happens one funeral at a time." It's an age-old, rueful take on how our own learning and adaptation proceeds within a collective society. It is a rendering of an objective truth seen at the intersection of evolutionary processes, memetics, and the human condition. It is not a call to action.
Sometimes, I think the most worrisome thing is the ever so slight possibility that some clever, naive upstart will hear this adage and, rather than ponder the lesson about patience and complex social systems, instead conclude that the short path to a lot of progress is a bunch of killing.
Even if we ignore the obvious psychopathy it takes to embrace such an idea, it is still fantastically myopic. Yes, in a hypothetical way it might happen... after the great chaos, some new civilization might emerge with an impressive growth spurt.
But, it is infantile fantasy to believe that such chaos can be applied in a goal-directed fashion, or that the perpetrator(s) can expect to survive it and enjoy the result. Nobody can control who nor what knowledge passes through the gauntlet, nor what direction it spins after that.
What troubles me most, perhaps, is that the current zeitgeist makes me think some people are oblivious to these caveats.
> What troubles me most, perhaps, is that the current zeitgeist makes me think some people are oblivious to these caveats.
Same here. "Are we all going crazy?" is the feeling I often have.
It wasn't programmers who brought us the idea that all problems, obstacles and goals can be conceptualised as an insufficiency of code, apps or gadgets, without any thought to politics, negative externalities, institutions, or philosophy.
That came from SV technocrats and associated capital owners.
Not even touching your caricature of the AI argument, but “most dangerous sentiment [in] civilization right now” is a crazy thing to say during the current global political zeitgeist.
This argument spans AI, housing, infrastructure, scaling medical access, the whole shebang of critical solutions to 21st century problems is held back to couch the discomfort of the few.
Whether it’s neighbors blocking housing, union bosses blocking port automation at the height of COVID, medical association’s controlling doctor quotas it’s the same sentiment, a fear of change.
I grant that a healthy distrust of the (capitalist) parties involved is fine but the reaction when given power is the same, veto: Stop everything now. Change is scary.
I see a different outcome.
- significant amount of money that used to be wages now paid to AI companies
- causing significant power shift to the owners of AI companies
- significant amount of people out of jobs, at the same time blue collar workers still have to work
- causing anger and resentment within society
- fueled by AI owners who will train their models to subtly argue in their favor
- protecting themselves with drones
- significant amount of countries simply go bankrupt or fall apart
- unable to let go of the basic capitalist mindset that cannot work when there simply is no available work for many people
> Why do you look forward to this happening to your intellectual pursuits?
Because he's arrived at the final stage of grief and is ready to move on.
Computer code has from its inception until today wholly been about automation and thus about taking people's jobs away.
Each individual who has ever worked as a programmer has been in the business of taking away several other people's jobs.
That's why people have little empathy for programmers specifically when their jobs are taken away now by AI.
That's a very, very narrow view of software. The firmware inside an internal combustion engine control unit did not take someone's job away. The software to assemble genomes from DNA fragments did take someone's job away. Nor did an MP3 codec, a game, or a search engine. All this stuff gave us more than we had before, it wasn't just automating existing capabilities.
Even when software has been used for automation it's been done to eliminate boring labour, not creative work. Eliminating jobs like switchboard operators or coal stokers is a good thing because those were unenjoyable and even dangerous jobs that nobody wants to do.
> The firmware inside an internal combustion engine control unit did not take someone's job away.
Of course it did. Cars and motorcycles used to need to be taken to the mechanics all the time. Now they just run and run without issue, thanks to what you mention.
> All this stuff gave us more than we had before
Absolutely. Just like all automation. It takes away jobs, but increases production. That's why it's worth it in the end.
> Even when software has been used for automation it's been done to eliminate boring labour, not creative work.
Yes, and now AI is eliminating the boring labour of programmers. Will they come to terms with the fact that their jobs are unenjoyable and nobody actually wants to do them, like the coal stokers and switchboard operators?
But I agree with you that there are some outliers within programming that go beyond automating jobs and processes. Like the examples you give.
Cars still need to be taken to mechanics all the time. In fact, I'd hazard a guess that there are far more mechanics now tab there were prior to ECUs.
> Yes, and now AI is eliminating the boring labour of programmers. Will they come to terms with the fact that their jobs are unenjoyable and nobody actually wants to do them, like the coal stokers and switchboard operators?
If it was just replacing the boring part there would be no problem. In fact, we could just use it to replace the boring bits and give ourselves more time to be creative and do the human part. The danger is it ends up replacing thinking completely, though.
I wonder if you've ever done a truly unpleasant job like those mentioned? Have you never written software that has made people really happy because it makes their job less unpleasant?
I've personally been working on software to help with cancer treatment for the past 6 years. You can't even say I'm taking away the jobs of undertakers because people will still die anyway and demand for healthcare is never going to decrease.
The enjoyable part of a job is receiving the salary. That's how it is for many or even most people.
> I wonder if you've ever done a truly unpleasant job like those mentioned?
I've had some of the worst jobs you could think of, and I was proud that I could make my own living and not depend on anybody else.
> In fact, we could just use it to replace the boring bits and give ourselves more time to be creative and do the human part.
That's the ideal outcome. However, there's limited demand for that. "Grunt work" is still what's needed mostly, whether done by man or machine.
> I've personally been working on software to help with cancer treatment for the past 6 years. You can't even say I'm taking away the jobs of undertakers because people will still die anyway and demand for healthcare is never going to decrease.
You probably took away potential jobs from administrators who would have done the things manually which your software does. Or if you're a better programmer than your peers, then you took away the jobs from the two programmers which would have been needed to do the same job as you do by yourself.
What I'm saying is that working as a programmer is about automation and efficiency and that means taking away jobs. Just like the steam machine and everything else we've automated. That's why nobody cries for programmers now that they are being out-automated themselves.
Can you put yourself in other people's shoes and see how it is offensive that tech workers now demand continued employment at comfortable jobs with high salaries, when there is no longer any demand for them? Instead of being grateful for having enjoyed such a good situation for many years while others haven't.
I fully expect my own job to be replaced by AI in the coming years. It's inevitable, and I can only be grateful for what I've been given and that I had the chance to enjoy a comfortable job while it lasted.
Honestly it just sounds like you're jaded after years of working meaningless tech jobs. It's not all like that. I've been working on improved early detection of cancer. Humans are totally incapable of detecting cancer that early; it's not taking automating any existing job. You can do good stuff with computers. It's not all about shovelling shit that people don't need, although all of big tech is, sadly, about that, of course.
I'm sorry that you think the enjoyable part of work is getting paid. Again, it's not all like that. A lot of people's jobs give them satisfaction from seeing jobs getting done that aren't easy. Nobody wants to be machine, we get joy from using our brains to solve problems.
The bad part about AI is it's replacing the need to think. I think everyone is going to get depressed when they've all forgotten how to think.
I don't work a tech job, and I'm enjoying my job and find it meaningful. But AI is already becoming capable of doing it, so it will be only a matter of time. What can I do, force customers to pay us to do something AI can do for "free" and just as well?
The enjoyable part of work getting paid was in reference to coal stokers and switchboard operators, these professionals you mentioned who were happier to be replaced.
> You can do good stuff with computers.
Of course! I'm not arguing for nor against automation and machine replacing man. What I'm saying is that programmers are the group who should be the last to complain, as that is what they've been doing to others since the beginning.
And many or even most of them realize this and do not complain about these new tools.
> I've been working on improved early detection of cancer. Humans are totally incapable of detecting cancer that early; it's not taking automating any existing job.
That sounds amazing and congratulations for doing it!
That and the fact that people void of any skills, coding or engineering ones, could still find a six figure job.
> Computer code has from its inception until today wholly been about automation and thus about taking people's jobs away.
No it hasn't. It's been about making bomb-ass simulations and cool games and stuff.
This is like saying the steam engine took people's jobs. It did. Industrialization created even more. This isn't a vouch for industrialization or capitalism but software has certainly enabled all kinds of new classes of creativity and opportunity.
Exactly! So while people would have empathy with people losing their jobs to a steam engine, would they have empathy with workers at the steam engine factory losing their jobs to an automatic riveting machine? Would they have empathy with a steam engine designer losing his job?
Programmers were all futurists, then the future came for their job.
Few years from now we'll be fighting to get a semi stable job that will pay like any other office job, and feel lucky we did.
I found that since LLMs can produce any code I want, I don't really feel the same drive to learn React or whatever is popular and trendy to make myself useful in a new job. Instead I feel like I have the space to play with something that I enjoy instead, like learning Z80 assembly and writing games for the Gameboy that I would have wanted as a kid. I think you're right that it feels just like going to the gym, intellectually.
Yes, but in terms of your marketability--even in a world with LLMs--it seems to me that learning React or whatever is popular and trendy is quite vital. You can't propose good architectures in /plan or review slop PRs in React without knowing React to a level of depth that could only come from having toyed with it, and thought in code.
It is still an open question though exactly how big the need will be to propose good architecture or review slop. I petsonally think it will still be important, but it will vary by application for sure.
Take some comfort, if you like, in the notion that LLMs are limited to emitting convolutions of their training, plus whatever is stuffed into context.
This metaphor does fall apart somewhat when you consider that farm tractors are not made from farmhand muscle fibers, whereas LLMs are in fact made out the stuff they’re rapidly replacing.
No, but I think you could tell a sufficiently compelling allegorical / metaphorical story about how farm tractors, in destroying the livelihood of farmhands, might as well have pried their muscle fibres out of their live bodies.
I meant more that you can build farm tractors whether or not you have farmhands; you cannot train LLMs without human text.
For sure. No, there's a tragically awful irony in the fact that the clankers run entirely on the (unpaid for) intellectual output and cognitive labour of humanity, white-collar professionals, academics, specialists and creatives, yet the idea is that these people are supposed to be obsoleted by the clankers.
> transient LLM crappiness notwithstanding
Bold of you to assume.
Can you show me something, that is not just a one-off or demonstration, that is well-built? Code that is a joy for humans to read? That is not a harness or anything like that, but something we wish we could have gotten made this well so easily before, and that we now have?
I want to be intrinsically motivated too, and I am a good bit of the time. But let’s not pretend intrinsic motivation is an infinite well. We can suffer intellectually from a lack of places to socialize our pursuits.
Francis Fukuyama's "megalothymia" seems relevant here, too.
> If anyone can point an LLM at slow code and it automatically finds a hot loop and uses a trick it found somewhere on the 'net to vectorize it, there is little point in hiring someone with a focus on that.
LLMs are not very good at performance issues unless you walk into it with a clear idea of the likely root cause and the bigger picture regarding actual hardware and desired customer experiences.
"Please make the code go faster"
vs
"I am noticing what appears to be contention between threads under workload A, B & C, but not with workload D".
These are completely different universes of capability and outcomes.
Even if an LLM can fight its way to the answer on its own, you can achieve a specific desired result much faster and with significantly lower risk if you are genuinely an expert.
I've seen a concrete example of this recently. I profiled the client's product "the hard way" and arrived at a change to a single line of code that would eliminate a mutex issue. One of the client's developers used the LLM and wound up with a change set that touched hundreds of files, but otherwise achieved approximately the same performance fix. The other developer even had my hint that it was a single file change and couldn't figure out how to do this despite prompting a leading edge model regarding this exact possibility over and over.
Taste and aesthetics apply to absolutely everything. Not just UI/UX design. Perhaps it is even more important that we care about the things that are invisible to the customer. It is certainly easier to forget about them or treat them like they don't matter as much.
Not my experience at all. I pointed frontier models at some PyTorch code, told it to make it faster, and it optimized it 10x fold.
You’re probably limiting the frontier models by being specific.
Not every optimisation is the same. LLMs can optimize code that is behind known practices, but won't usually invent new data structures or algorithms to solve a unique problem.
While it's unlikely for LLMs to implement patterns not present in their training, current training techniques absolutely can produce practices and data structures and algorithms that humans have never done before. Modern LLMs are not just trained on text. They are trained on computer use, including - at a high level - solving programming problems with code. They are not just rewarded for producing the most likely next token. They are rewarded for producing tokens that solve problems. Patterns and techniques can emerge from this that are not present in any human behavior.
They are rewarded for code compiling, thats about it. Thats why the code is terrible. Ive yet to look at a project made by an llm whos user swore this "frontier model is the one", where the code wasnt utter garbage. The heavy llm users dont care as long as it compiles.
Yes, but in some fashion, all the outputs are mathematical convolutions of the training, plus whatever is packed into context.
I'd be interested at which problem you passed to an (which?) LLM that they weren't able to solve?
The fact that you're pointing it to PyTorch code in the first place is being specific.
Pointing a frontier model to a 10 or 100MLoC codebase and saying "make this code fast, make no mistakes" doesn't work. As an experiment I recently tried this with a relative small (500KLoC) codebase and it got stuck on believing that the primary cause of slowdown was the database not using a connection pool. (Which was completely irrelevant for this specific code.)
Did you let it profile the code?
How large is your codebase?
I am sure people could find code such that an LLM can optimize it 10x fold. I have seen many types of code in my life (well written, horribly written, fast, slow, etc.).
I do feel there is a limit to LLM-s today. I did not try, but I doubt it will work if I would tell it "make me a web browser that is bug free, perfectly secure, works as efficient as possible on my architecture and has best UX for me personally".
Knowing where that limit is, is as hard as it always was knowing how fast a team of engineers was going to do a project.
> I do feel there is a limit to LLM-s today.
I felt there were limits 4 years ago. I couldn't get even an 8k context window.
It's starting to feel like the important gaps are the only ones left that need to be closed before there aren't any left. It also feels like next year they will start meaningfully closing.
> I did not try, but I doubt it will work if I would tell it "make me a web browser that is bug free, perfectly secure, works as efficient as possible on my architecture and has best UX for me personally".
I do feel there is a limit to human-s today. I did not try, but I doubt it would work if I asked literally any programmer I know "make me a web browser that is bug free, perfectly secure, works as efficient as possible on my architecture and has best UX for me personally".
Hell, I'm willing to bet they'd fail at this task even with an unconstrained snacks and kombucha budget. Humans have a long way to go. My job is safe.
The example provided covered both options.
In general the OP is right, the people who get the most value out of LLMs are veterans.
This doesnt even apply to his issue. What does PyTorch code have to do with complex concurrency or complex systems in general.
Theres lots of bad Pytorch code, just go ask george hotz. This isnt the magic you think it is. And nobody wants to hire the guy that just points llms at things and says make it faster. Things have value because talented humans make them. Its why a luxury coat is worth more than the linens that make it, or one from walmart made by a machine. This will 1000% apply to programmers. I think OP will be fine.
With how you presented this, it makes it sound like it was either a toy codebase or something outside of your domain already.
I don't know why but in Typescript when I tell an LLM to write code to check if a character is of a type, it often uses a whole Set() instead of just using a string and doing indexof. It's weird because not only should strings be faster, doing it with strings should also be the prevalent way in the dataset. Yet it uses a Set.
Grief is exactly what many engineers (not just programmers) are going through right now. They (we) are going through the process of coming to terms with the death of something we loved - not a transformation, but death - and figuring out what comes after that.
This isn't about having trouble adapting to change, because many engineers going through this are adapting just fine as far as others can observe, adopting LLMs, changing the way they work and whatnot.
The grief comes from either that new normal being something they don't identify with anymore, or that new normal being just... different. The former will inevitably prolong the grief, while the latter will eventually result in the grief subsiding (even though some sadness for what was lost will never really disappear).
We're being asked to adapt, but perhaps we should just accept that things are not going back to what they were, look around, and decide not to do the things we used to love in a new way that we cannot love. Others might not even notice we chose that path, and think we just "adapted".
Does this make sense?
> We're being asked to adapt, but perhaps we should just accept that things are not going back to what they were, look around, and decide not to do the things we used to love in a new way that we cannot love
I would love to take this path but unfortunately I have to make money to pay my bills and afford to eat. I don't know how I would afford to keep my home without continuing this career, as mangled as it is now thanks to AI
It doesn't have to mean abandoning this career. For example, if you used to program because you love the details and the control, doing the same with LLMs and pretend it is still about details and control will make you miserable.
But you might be able to choose to leave that to others, and fill some other role in the development process where you don't have to pretend.
It will still be with LLMs, though.
> But you might be able to choose to leave that to others, and fill some other role in the development process where you don't have to pretend.
That is abandoning the career.
Only for a very narrow definition of career.
Yes, but that other role is a change of career.
I think this is true for some programmers. For others like myself, the change and constant radical improvement is what we loved about technology in the first place. I'm essentially living the dream I had when I was 5 and saw Wargames for the first time. Sure, it was fun to program by hand but now we have AI, which allows us to do even more amazing things and we're very early in the curve there.
> Grief is exactly what many engineers (not just programmers) are going through right now. They (we) are going through the process of coming to terms with the death of something we loved - not a transformation, but death - and figuring out what comes after that.
Very well put.
A large part of that "what comes after" is grappling with the next hard question: after the death of the craft we loved, are we - our skills, our intuition, our problem solving - even needed anymore?
Even if we still are now, will there be a time when there also won't be a place for us?
I believe we're still needed, because AI has no "want", no intrinsic motivation, therefore no real sense of alignment with real-word goals. Without us humans in the loop, the industry would become self-drinking beer.
Whether or not the folks with the money agree with this is another issue...
> AI has no "want"
Have you asked it?
If you have to ask, it doesn't exist.
The new normal involves fewer and fewer humans in the loop. So it's not just that things are changing and we need to adapt, I think the world will be able to get by with a lot less labor (more capital though). It's not like we're losing a fun hobby, it's a living. It's ikigai but more importantly it's food in the table.
Some seem to think we'll just get 10x as much done. But I just don't think there's that much more stuff that actually needs doing. We won't build 10 Google Mapses, and there aren't 9 other apps that have the utility of Google Maps.
(Please debate me on this as I don't want to be right.)
We will build more small mods and variations. Ideally we won’t rebuild the codebase 10 times, but 10 different people would like their Google Maps to be slightly different.
You need to have millions of people using a complicated app in order to find and fix all the bugs, I.e. millions of people sort of share in/amortize the bug discovery load. This doesn't work if everyone has a unique complicated app, which is also sorta what happens if you just allow every UI thing or behavior to be controlled by a setting.
Ignoring that, I still don't think minor tweaks for my own Google Maps adds so much more value that you continue to pay developers the same amount you do now. That is, the value of personalized maps is not 10x generalized maps, so how do the economics keep working?
I also tend to believe that the market for SW developers will shrink. In Europe, the AI revolution is hitting at the same time as an economic crisis triggered by expensive energy which is in turn making companies cut costs / local positions and outsource to cheap locations.
The idea that more SW will be built is likely correct, but it might not be a well-paying job or be done in Europe at all.
This is the kind of person for whom AI is making the most negative change. I feel sad for them. For me, I love this new world. I never took pleasure in craftsmanship or perfectionism, I just want things to work and then iterate on it with as little effort as possible.
I find it a breath of fresh air to be able to tackle backlogged tech debt items simultaneously with business priorities in parallel and stuff like that.
That being said, I can't see this entire field existing in five years anymore. I'm hoping for at least two more years, but who knows?
This stuff is coming for all white collar, the barrier to entry is completely gone now. Maybe not the barrier to mastery (yet), but the bottom has fallen out.
I am not sure mastery every truly goes away. But it is given the chance to evolve.
Navier-Stokes…
... could never have had a proof attempt presented without the mathematicians setting the stage and working to verify the proof.
I think you might be viewing AI and humanity as a zero sum experiment. It's really not. Go read some David Brin (Existence is a good start). We don't know all the positive and negative aspects to come, but we aren't in a dark forest situation. Existentially, AI is here, what are we going to do with it?
I see sentiment like this (which is valid; it’s a different perspective), and then I look at my company’s current caseload of breaches and how most of the (insane) increase in business we’ve received is caused by poorly coded apps with obvious security issues, along with the inability of orgs to remediate those issues or adequately follow incidents because no one actually knows the applications anymore.
And I’m wondering if this isn’t the enormous amount of organizational debt from having security second to everything finally coming calling.
Presumably those poorly coded apps were written at least 6 months ago though... Enjoy it while it lasts.
Unfortunately for everyone, no.
I’ll give you an example of one that was written recently actually.
The initial compromise happened because the app explicitly did not verify auth claims when a specific string was in the ISS field. Well, fuzzers exist and are common.
The next issue was that once you’re in, there was no delineation between admin and regular users. Everyone had all privileges if they just made the calls.
Anyway, we did the usual post-remediation investigation and write up. The devs were of course using the latest models, as they were instructed, and the issue stemmed from a problem they’d been having integrating a specific company into their auth scheme.
Eventually, after many enumerations, the model opted to just skip auth altogether if that companies ISS was present. The devs, being in the habit of just accepting the changes did so and because of the nature of the code implemented nothing caught it in the pipeline.
This is sadly an incredibly common story and it won’t be fixed by models improving I don’t believe.
Not in security, but "vibe coding remediation"--that's the best way I can think to describe it--has been a booming business in my line of work (SIP/VoIP infrastructure engineering) as well.
How long it'll last, I can't say, only that before LLMs, the industry entered a phase of consolidation and quiescence that had me seriously worried about a fade into irrelevance. The delusions of businesspeople and the managerial class about what LLMs can do has fueled a very nice business renaissance, as they run into the limits but have committed to contracts, business models, etc.
I agree, and the field possibly not existing in 5 years is a big issue. Like, how are young people supposed to take a mortgage, start a family, or any other big commitments like that, if their whole education and work experience may be useless in a couple of years?
I don't care whether I'm writing code or reviewing LLM generated stuff, but the prospect of losing my job and having to survive on welfare for the rest of my life isn't nice.
From my perspective this is the thing that the people who have been talking about how good these damn things have gotten now were trying to get you to do all along. Understand that they're getting better, it doesn't seem to be stopping, and we really, really need to figure this part out ASAP.
What seems to happen though is it always gets pulled into a discussion of "But they can't X" or "but ma taste!" or the old generic canard "can't replicate what's not in the training data"
All I want is for people to see that yes, this is happening, accept it, then figure out what a good response would be to it. Instead we get everything from stochastic parrot parrots to "Dario is just marketing when he tries to warn us" to the old an thoughtless "But if you think it's bad, why are you doing it?"
Please.
I mean look at our response to climate change and then look at our response to COVID.
Change doesn't happen until we are at the absolute brink of IMMEDIATE catastrophe.
most of the people talking about how good they are have been slop jockeys. That doesn't feel like someone who's trying to look out for humanity.
If the market falls apart there is no solution except learning another job which isn’t (yet) doable by AI.
> except learning another job which isn’t (yet) doable by AI.
Why? Why are jobs necessary? Who needs to have them? Should we pay people to be stopgaps/just in case jobs in case the machine fails (probably?) -- who organizes that? Do we have a human economy and AI economy? How to keep them decoupled? Does this mean stamping provenance (who made what onto what?) should be a core of the future? Right now? What does that look like? Are there other things we can do to ensure we get the Banks future and not a shittier one? Is the Banks future a good one? Is disempowerment a real concern? If so what do we do about it? Human reserves? Zoos?
I do not have answers, but I know the questions are vastly more interesting than "what job will the AI not be able to do" wtf PLEASE
Where is the money for welfare coming from if tax from working people is drastically reduced?
Taxing profits of companies that use AI probably. I really don't see other way, if AI starts replacing human work in large enough scale. In that situation, without welfare there will be soon nobody buying products and services, leading to an economic collapse.
- Business priorities are potentially neverending so the expectations will just increase in relation to the increased capability.
And yeah, I agree, there is no bottom anymore.
I view it as a different layer of abstraction.
I _am_ a craftsman - software, wood, and a few more domains. There is a lot of personal satisfaction I find in woodcraft through the motion and the exercise. I love that this is a luxury hobby instead of a personal necessity. The difference there is that if I take my time on personal necessity where the market isn't paying for it, I may take food out of my kids' mouths or lose the roof over their head. Luxury craft hobbies face only self-imposed pressures.
AI is letting me build similarly. I can continue to craft my Rust and my Python and my Typescript and my Fortran to my heart's content - and those skills help in the day to day - yet I'm also able to compete in the market and build things that were really infeasible before.
I agree with this framing, but still trying to reconcile staying ahead of the curve without adopting full hype train or doomer mentality.
How are you keeping your “human” addition to the loop valuable, is it through the time spent on the software craftsman hobby?
Im in my early 30’s, and trying to stay ahead. I feel it was easier prior to LLM’s, and now its tough to even know where to focus skill building.
> How are you keeping your “human” addition to the loop valuable, is it through the time spent on the software craftsman hobby?
Yes, and, integrating it into my normal tasks and delivery. Some principles:
(1) I wouldn't worry so much about staying _ahead_ of the technology, rather, focus on the outcomes for yourself and the people you serve. That gives a more holistic and natural boundary when you research and adopt the technologies that help you get there.
(2) I'd also focus on adopting what works best, not what is latest and greatest. Tech regressions definitely happen[1], and you know your need the best.
(3) When quantifying, cost-benefit is typically focused on Benefit / Costs - 1 to give incremental lift. Unsurprisingly, if benefit is high and costs are higher, it might not be worthwhile to adopt!
[1] https://roderick.dev/writing/2026-08-28-obsessing-harnesses/ forgive a small bit of self promotion, but I'm researching this exact problem with my research group, about how to quantify solum benchmaxxing, tradefoff adoption, regression, and improvement for harnesses.
> I never took pleasure in craftsmanship or perfectionism, I just want things to work and then iterate on it with as little effort as possible.
The problem with this outlook (not with you personally) is that the increase in accessibility for you comes at a cost, but the way things work these days the cost is not paid by you but by someone else — someone you'll probably never even meet. The cost has been abstracted away from you and foisted onto somebody else against their will. This shows up as people adversely affected by local data centers (increased pollution, higher electricity prices), people displaced in the workforce (author of the article), people of the future who will not understand things because it's easier to skip understanding for now (students, early learners), and so many more.
It's very liberating — so long as you are given the ability to not think about the consequences for these other people, and the abstraction process by which AI companies are providing their services gives you that freedom by design. At the very least, it is something about which you perhaps ought to be wary.
That process is nothing new. That’s happened many times in history over and over. And in far more dangerous ways than not understanding how some complex piece of code keeps their favorite or most critical application running. At this point, people have long lost the ability to have even basic survival. How long would people last if they needed food or water? They have no idea on step one to achieving the basics. It’s all abstract to them, which includes us. That’s the loss that actually matters. Not that they know how their Amazon Fire TV works.
Disagree, in that humans are doing the same things they did in the dawn of time. Adapting to the environment and figuring out what it takes to thrive.
There are many things about our modern world which make less intuitive sense than the lives of hunter gatherers. People are trying to figure out how to survive in the conditions they are placed in.
Physical labour was weakened and then had to compete with machines, till we got lights out factories.
We were left with the service economy to find roles that allowed us to thrive. Now that is being threatened as well. It is unlikely that LLMs are going to make us all into entrepreneurs and capital owners.
Not to mention, the service sector required far fewer workers than manufacturing.
This isn't quite the same kind of moment we see over and over. It's not simply cars taking out horse drawn carriages.
The OP's point was about ignorance being bliss, but having adverse side effects. That's what I was responding to. I'm saying we long have lost the only part that matters, which was the self-sufficient farm. It helps, but doesn't make a big difference if someone doesn't know what valves in an engine do. And 90% of the population probably does not.
Your point about adapting to basic material conditions under industrialization is something else. I wouldn't agree with what you're saying. It may not be your analogy, horse drawn to motorized carriages- but this is the cotton gin all over again. The only difference is we're now out of new industries generated out of the new technology to employ people. No more network admins needed, no more programmers needed, no more cotton gin repairmen are needed.
I agree in that the conditions are different with this one. But the process is the same we've seen over and over. This time there's just no newly created jobs out of this new revolution, 100 million legal and illegal immigrants flooding developed nations and more coming, and 50 years ago women entering the workforce expanding it 50% overnight. You're correct in that it's not going to work, but I see different reasons for it than you do. Things are going to have to change or Europe, the US and Canada are going to become slums like the rest of the world. And that process is going to be even faster than it normally would, because the ~50% population expansion consists of people that are used to slums.
You mean like all the benefits of industrialization? The real externalized human/environmental costs of our fast/cheap fashion, of our iPhones, of cars, of electricity, of agriculture?
I saw a video today, talking about how this is really the end goal of what we've been working towards for 200 years. Automation and scale and convenience uber alles. As structured it's not a good idea and it seems that Dr. Kaczynski wasn't wrong in diagnosis, only in the treatment. But here we are and we're pretty pot-committed, so I guess we have to see for ourselves what's on the other side.
Yes the fact that we have seen this pattern play out in the past and are very aware of all of the positive and negative effects it has should be sufficient to slow us down but naturally people are too selfish. The people who benefit will happily step over the graves of those of us who are fucked by the "benefits of industrialization" and then whoever survived will pat themselves on the back for a job well done while the rest of us rot
But there's no reason for us to be angry about it or resist it, of course
The only people who even somewhat successfully resisted industrialization are the Amish. Is that what we should be doing, forming religious communities that are increasingly isolated from the rest of humanity? Unable to contribute meaningfully to the discourse, but still subject to the externalities of the dominant paradigm?
As if the only possible two options to how society can operate are "Amish" or "Hyper-extracting wealth from labour"
Throwing shoes into the mechanism doesn't seem to have done anything but coin a new word. But I'm all ears! What other options do you see that could work at a larger-than-village scale?
Call me crazy but the tone of your writing doesn't inspire me with much confidence that you're actually even remotely receptive. I think you just want to argue
I'm not into it. Go ask Claude instead. It has more patience for this sort of ignorant attitude than I do.
You're crazy, I'm...not even arguing. You'll see that even in the course of this one thread that I've been quite ambivalent. And I've already talked with Claude about it plenty, and few ideas that feel workable in our present climate. I don't feel like I'm "ignorant" but then we never do, right? Would love some pointers to ideas. What you got? Communism? Georgism? UBI?
We don't even have to go that far. Why don't we start with "capitalism that takes meaningful antitrust action against overly entrenched corporations"?
Maybe "capitalism with more substantial taxes for large corporations and the wealthy and fewer loopholes"? Can we try either of those?
Shoot—if the true believers are right and there's ultimately never again going to be an economically viable justification for anyone without an MBA to have a single independent thought, maybe the Amish were onto something after all.
They at least have the notion that you've got a soul, and that it's a thing that should be tended to. A boss who has genuinely internalized the belief that the value of all human knowledge and expertise has gone to zero—such a man is unlikely to be similarly burdened in his assumptions about you.
First, I don't trust the elites to share in the wealth. I expect fuedalism to ensue.
Second, I think what is healthy for humans to yearn for is purpose and meaning, and convenience and idleness are almost counterproductive to that. Ok it's hard to argue with convenience, but nowhere in all of this has AI threatened to make my life more convenient by doing the chores for me, it just takes away fun creative tasks that I can get paid for.
> nowhere in all of this has AI threatened to make my life more convenient by doing the chores for me, it just takes away fun creative tasks that I can get paid for.
And this is, of course, the bitter irony. As that meme goes, I don't want it to write my prose so I can do the dishes, I want it to do the dishes so I can write prose.
> First, I don't trust the elites to share in the wealth. I expect fuedalism to ensue.
They will share just enough so people are content enough not to riot. Keeping the masses at bay will mean they get to build even more wealth.
When enough people stop being able to buy food is when revolution happens.
This resonates with me. Hard.
I'm lucky though - as a hybrid engineer/manager, I've been able to lean away from the former and into the latter.
And I've come to notice that humans doing agentic work seem to need more emotional support per unit effort than those doing traditional engineering.
So there are opportunities there. I don't want to spend a second longer than I have to prompting machines - there is zero dopamine loop in that for me, I get more doing housework and at least that makes my wife happy - but I'm happy to support a few other humans engaged in that kind of work.
It's sad though. I used to love dreaming intricate machines into existence and then watching them come to "life", or at least actually start working. That dream seems dead for now, I hope it comes back but I won't hold my breath.
“I almost get physically ill when there is more code than I can keep in my head” resonates with me, but it is the exact reason that I enjoy working on better abstractions. Not in the “Javaesque” sense, as you call it, but in the mathematical sense.
I’m working intensively with LLMs to find out what they can and cannot do and for all the capabilities in there they remain terrible at compressing functionality into few concepts and as a result they produce incoherent (read Fred Brooks on coherent design!), failure-prone products. In other words: I expect that there will be good demand for people who refuse to let code grow beyond something they can keep in their head, even though the means by which one accomplishes this might be different than what you do now.
Hope that there is some solace in this.
That's the state now. Look at the leaps that were made just in the last few months.
For my work in innovation/R&D the leaps are relevant but more or less orthogonal to what I’m talking about above. I think there is a limit to the consistency and quality that one can expect of software whose surface area scales linearly with the feature set, if that makes sense.
It is tempting to extrapolate the fast progress and conclude that everything will be automated soon, but it still appears to me that LLMs have a “spikey profile”: while very good in some areas, they fail completely in many others, with no evidence that this is only a matter of time.
There haven't been any.
The AI bros do keep saying that... next model bro. I really feel the AGI in this one.
> I get almost physically ill when I work on a project with more source code files or at least general architecture than I can keep in my head, so I don’t get anything out of expanded scope
While I sympathize with your loss, this was always going to prevent you from holding down a job, even as a pre-LLM "coder." The majority of us have to work on systems, not just single files or cleanly isolated programs we can hold in our head.
I don't think this statement implies they meant 'single files'? They could be talking about complex systems that they could fit into their head, and now they can't do that with new workflows.
Perhaps I didn't formulate this too well. Say, rustc is a gigantic program, but the parser alone, or the borrow checker alone, or the LLVM backend alone are small enough to work on individually, and from the perspective of any such unit all the others can be treated as black boxes, deliberately designed to have as small of a public API surface as reasonable and to be as predictable as possible. That's just architecture 101. With LLM code, I notice, such abstractions fall apart, and the interconnectedness, duplicated code, and unclear expectations make it impossible to reason about the result except as a giant lump. Of course, tech debt is nothing new, but at least it used to be held back by the physical inability to make progress once things get dire; with LLMs, this misery gets prolonged.
Yeah I feel this. My strongest passion in computing is simply learning how the machine and OS work. The code I would write would usually be experiments, not projects or tools.
I'm less pessimistic than the author though. There is always room for people who know what they are talking about. Take a deep breath.
Room where? You're obviously not going to hire someone for their knowledge alone in late 2026... ChatGPT probably knows more than you know in every domain. What questions could I ask you that ChatGPT wouldn't be able to answer?
You won’t hire someone to answer questions for you; you might hire someone to make decisions for you. And domain expertise is still very useful in both making good decisions and convincing other people to trust your decisions
Know what to ask is about as important as the answer. You can't do that very well without domain knowledge.
I'm not sure how it plays out in 5 or 10 years, but that's how it is now.
The room comes from recognizing that, in many many domains, you don't even know the questions to ask.
Beautifully said.
I do wonder though about the optimizations within it, what could be the most optimal way to achieve such room (ie. knowing which questions to ask)
Yes, learning and tinkering is still really the greatest way to achieve that
but I think what I am talking about can be better simplified with the analogy of a gym: previously what used to be necessary (manual work/labour) but when most people got into information work, even then there was/is a need for it (physical work), then we saw the evolution of machines specifically designed to optimize for it and we got machines specifically designed for this training, which helped push people's body to their absolute limits.
I do wonder if an hyper-optimized environment of learning and for asking questions (or more so knowing the know how on which questions to ask), this whole process might be optimized for it and what that process might would look like is a source of curiosity to me.
A relevant video which talks about similar topics: Bodybuilding for the mind: https://www.youtube.com/watch?v=o0DtxUJ6rAc
Entirely agree with you, but I also lend some credence to the worry that capital owners and the managerial class might not want to pay a six-figure salary for "knowing the questions to ask".
I'd be lying if I said I hadn't spent any hours worrying about it. But on the other hand people pay for exactly that when it comes to law, accounting, actuaries, and whatever other white collar professions. I am nervous but optimistic for the time being.
They pay for tangible "deliverables" from those professions, too, not pure thought and judgment. One could probably argue that, as with programming, one has to have written a lot of code in order to think in code at a higher level, so to speak, although I can't say to what extent that's true in each of those domains.
However, the first part applies to programmers, too. A lot of the value of code _was_ simply in the fact that it was written, so you don't have to write it yourself. I'm not suggesting there isn't more to the value proposition, but the value destruction is there.
Maybe people will be hired for the question they can actually ask and not for the raw knowledge they have
The point of the knowledge is that it helps you ask the right questions, not so much the ability to answer them.
Knowledge has been available just by asking Google for decades now. The LLM makes it easier but it's a difference of degree not of kind
Until the models are 100% reliable knowledge will be required in order to quickly spot issues and work efficiently with the model to address them.
ChatGPT is a fantastic encyclopedia for knowledge retrieval and even is occasionally accurate!
It doesn't yet know when I brushed my teeth last, what specific foods in what quantities give me heartburn/indigestion, what that funky smell from my running shoes might be.
It can write pretty good code on a recursive loop when its provided a clear target. It can write better code when it has someone who understand architecture guiding it. It can review code reasonably well as well.
ChatGPT tied to robotics might even be able to do more interesting things!
It does pretty poor on highly specific knowledge where a RAG better supports -- something like Agent Search at GCP or AI Search at Cloudflare. But it can synthesize.
In effect, we've built an amazing library registry and need to up our librarian skills and the skills of people or systems that can use the information the librarian and their system can find.
ChatGPT doesn't actually know a thing, and will happily give you false information right alongside true information. Using an LLM to provide knowledge is a foolish choice.
One suggestion for the feeling that has been great for me. Finding a hobby where you can focus on sweating the details. Detach it from economic imperative (the core definition of a hobby, you dont make money from it). Ham radio, maker and micro electronics, woodworking, calligraphy, music. Of course there are more technically advanced solutions to the problem, that's not the point. The point is the effort and discovery.
That would be cool, given an ample income stream of free money to support this indulgence...
> I'm less pessimistic than the author though. There is always room for people who know what they are talking about. Take a deep breath.
But what will their day to day look like? Meetings?
Previously, I'd have to work days undisturbed to get important stuff out of the door. There was effort involved to reach an elegant solution that fit business need.
Now I'm a meat bag pressing enter on a "recommended" option Claude already figured out was the best approach.
> Now I'm a meat bag pressing enter on a "recommended" option Claude already figured out was the best approach.
And how long can that last? We’re expensive meat bags…
I couldn't possibly predict but I just doubt things will be as bad as everyone thinks, they never are.
Denial Anger [Bargaining] Depression Acceptance
> Now I'm a meat bag pressing enter on a "recommended" option Claude already figured out was the best approach.
If you are constantly thinking claudes approach is the best then perhaps you were not that good of an engineer to start with.
lmao
Fair, but the real question is what this person's manager thinks, as that tends to carry the day. And at the moment, there is an enormous gulf between what the managerial class believes LLMs can do and what people in the trenches know LLMs actually can and cannot do--not as a matter of current frontier capabilities, I might add, but more ontologically.
I wish that I could agree with you that "There is always room for people who know what they are talking about." I think that you are right in the long term. Eventually we will return to a world that values people who know what they are talking about.
In the short term, I have seen a lot of managers and other higher-ups talk about how we do not need to worry about low-level details anymore. In their minds, we are now all designers and architects, so we do not think about the small implementation details that ultimately do matter for performance and reliability.
People who know what they are talking about worry about all of the details from the big picture down to the small scales. We can still operate using abstractions like designers and architects, but we must know enough to choose the right abstractions that account for the concrete details properly. I've discussed this point earlier this year [1] using the tree swing diagram [2].
[1] https://news.ycombinator.com/item?id=46422597
[2] https://en.wikipedia.org/wiki/Tree_swing_cartoon
I was never the best programmer and never was to keen on building things or providing some value to users. I'm more interested in how systems work, especially computers and the OS, and so far, LLMs haven't taken that away from me. If programming and solving problems had been important to me, I'd probably have a problem right now. While I feel for OP, what interests him most—namely, understanding things and developing an intuition for them—is not a productive activity in the sense that it’s not about building or producing things. But the job of a software developer has always been exactly that and LLMs take an ongoing trend to the extreme. I think people like OP have no choice but to separate their personal interests from their job, as hard that may be.
Interesting. You don't feel like you were building an edge with your understanding of said systems or OS?
I'm very interested in systems as well, but being less sure about the future (on whether this is something I really need to think about, or whether I'll get opportunities to work much at this level), I started reading about such topics a fair bit less.
You act as if there's only two types of people, the ones who are competent and the ones who are not. But there are plenty of people who are competent at a certain task, which will no longer be needed soon. It would require extreme hubris to think that you are one of the few who is competent at some task that LLMs can categorically not perform.
> There is always room for people who know what they are talking about. Take a deep breath.
In the long run, I'm certain you're correct. In fact, "vibe coding remediation" has been a big business boon for us.
But the capital owners and managerial class can remain irrational far longer than experts can remain solvent...
This are a lot of parallelisms with LLMs, privacy and perfectionism as well.
I recently watched a movie which is about a young film director who suffers his whole film career because he is trying to make the perfect and the most scariest horror movie there is. While mediocre people with less brilliance and less expertise make better career and success than the protagonist because he is too stringent. Too adamant about things. This has stuck with me. I've read a ton of posts about how perfectionism kills. But to see the protagonists life get completely be screwed kind of hit me differently. I've suffered a lot on social life cos of me being adamant about privacy. The reality is, world moves on. Since then, am open to instagram, am open to less perfect things. More curious about LLMs.
This doesn't mean I stopped being a perfectionist or a privacy nerd or critical about LLM. But they've become my north stars. I work from within the environment than from outside of it. Life is better and positive since then.
I genuinely hope OP reads this and change his life accordingly. Change what we can. Do what YOU can NOW. It doesn't have to be binary. It's not black and white. I've read somewhere that "you suffer more in your mind than in reality". Take it easy. It was too much unnecessary burden on me and I am sure it is on your shoulders as well.
Before anybody panics about LLMs let's just take a deep breath, and see this tech for what it is.
It is a giant interpolation machine. It is very good at remixing stuff, but is is hapless when it comes to novel things.
Consider this: an llm was trained on physics, but the training data was cut in 1904. That is just a year before Special Relativity was published. The LLM was then shown papers of SR, GR, and Heisenberg's paper from 1925 that established quantum mechanics, and similar foundational papers of what we call "Modern Physics".
The LLM has systematically "disproved" all of them, and rejected as false.
So even if you show it a novel idea, it's still going to reject it.
It is by design limited to remix existing ideas.
The recent "novel" mathematical proofs are also just remixes. What I mean it uses two or more established math frameworks together to generate a viable bridge. The result is undeniably a new proof, but not a novel idea.
People with novel ideas will always be needed.
Hey, interesting take, could you cite some specifics on the LLM and experiment you’re referring to?
Do you have a citation for this?
That's more of a straw giant than a straw man at this point.
Even while I certainly don't identify with the same love of details, I do highly value strong engineering principles and even those are under heavy attack from the LLM onslaught - why engineer something fundamentally well at the start if there it is zero cost to fix it later when problems actually show up?
I still maintain some belief that the pendulum will swing back somewhat. We're going to see over time the problems that emerge from systems designed without deep technical oversight - and this will form a new class of expertise in its own right. It will likely still come back to people with an affinity for technical knowledge and principles based design, just in a different form.
> “why engineer something fundamentally well at the start if there it is zero cost to fix it later when problems actually show up?”
Because this is a myth. it is not true that there is zero cost to fix it. LLMs become less effective the more convoluted codebases become just like humans, if only at a different rate.
Is there something about an LLM that makes it incapable of simplifying a codebase? I have only seen that the slop jockeys who wield LLMs most ardently don't seem to care about that, and that older models were worse at everything, including that.
I try this really hard but it seems that getting an LLM to simplify a code base meaningfully is a much harder problem than getting it to output mostly functioning features very quickly.
They are great at adding but reducing takes much more hand-holding in my experience. Maybe this will improve, maybe it does not matter, maybe I am holding it wrong, I don't know.
What models are you using?
Mostly Claude code so Opus and Fable in recent versions.
It is not that they cannot simplify or refactor, but understanding how a codebase can reasonably be tidied up seems hard for them.
I tend to think this is mostly because the training set has generally been "low quality code cranked out as fast as possible" and the goal has been "do more of that". After all, most code in general is mostly throwaway. And most frontier model labs are startups where code is short lived.
Different goals/context/training is all I think it takes to change this. Though yes, for now, I revel in my role as the one who can contribute a touch of elegance to the stupid robot's solution.
Edit: and yes, better models, but I think the Sol-generation are already good enough.
No. Coding agents are great at simplifying, they just need to be told to do it.
I often see agents skip opportunities for simplification when not explicitly prompted. I have mixed feeling about this, but for now I think it's probably for the best that they stick to the script versus take initiative for things they haven't been told to do.
> [...] I proudly called myself a coder as opposed to an engineer. In my eyes, this highlighted the way I focused on the details, performance optimization, knowing the intricacies of the language, and being able to explain how things work, as opposed to juggling Java-esque abstractions.
Ouch. There's an idea that I've seen a few times now that there are two key types of developers: developers who thrive on building products and solving problems through the existence of code, and developers who thrive on the process and the low-level puzzle of getting that code to work and then to work well.
The former are having a really great time right now. The latter are feeling justifiably threatened.
I am in the former group, and while I agree the prospects are not singularly bad and I see enormous amounts of work that will need to be done, I don't think I/we are having a great time. Working harder than ever under unrealistic expectations and general chaos from everones FUD. In my area the need for software is huge but there has never been no nearly enough money. Maybe we can finally build some of it.
I agree that the threat is more specific to the more detail oriented kind of person/role, though.
"...are being infested by LLM fans that seek recognition rather than the experience, which sucks the fun out"
Part of the all-encompassing thief-of-joy grey goo is definitely the oafish, tactless footsoldiers.
> I first became familiar with computing when I saw the history scene in Tron: Legacy
Thanks for making me feel old
Screenshot of Solaris x86 too.
I feel that pain. My job involves a considerable amount of reverse engineering and software development, and I've always been interested in getting down to the lowest levels and figuring out what's actually going on.
LLMs are becoming remarkably competent at both of these skills. Not quite at expert levels yet but I expect it won't be long until this happens. I'm astounded at what they can do already, with the benefit of relentless, persistent effort on top of this.
How I've been using LLMs is twofold. Firstly, using chat mode to the effect of having technical documentation to converse with. Secondly, using agentic mode to develop tooling to help me with reverse engineering. This includes things like one-off scripts to analyse complex trees of structures, to modules that use the API of a framework I and others have developed, to prototype how we might want to extend it for specific features. I then write the final code myself in my own style, using the LLM prototype as a rough reference.
For now I think I've got a decent balance between using the LLM as a useful timesaving tool and continuing to understand the finer details for myself. I feel I have to draw a line at this point regardless of how competent the LLM becomes, otherwise I'll just be babysitting a black box, which almost anyone can do.
I'm not nearly as detail-oriented but I can certainly relate. The craft I've spent 20+ years mastering is disappearing and I'm not sure if I'll enjoy whatever replaces it. It's reassuring to know there are others who share the sorrow.
It's such a strange feeling. I have a similar amount of time invested as you. I'd always gravitated toward understanding how things work and bringing those insights back to whatever I worked on. Could be low level details, could be software architecture, or some obscure SQL. It wasn't that I knew everything, but that I could descend into the rabbit hole and re-emerge with something useful if needed.
Hard not to see it as tech killing competence in general, and cheering it on.
Kinda wish I'd gone to med school instead. Tech has only shown itself to be more unserious as time has gone on.
Software isn't disappearing - Code is. The craft is more craft than ever and more powerful.
Your job will probably disappear, if it involves creating software.
Having been working on a lot of low complexity code over the last few years I don't really sympathize with the author. I mainly use LLMs for the chores. And there are many many chores in software development. CRUD APIs, validation, yet another DB service, yet another script, minor version upgrades etc. Chores are also very straightforward to review. I do reserve the time to do normal engineering especially for the rare interesting algo and don't get this obsession with how everything must be agentic at all costs. Honestly seems like crypto propaganda all over again. If productivity "really" has gotten 10x doing some tasks without LLMs won't even put a dent in your average dev. output. What I do grieve is a lack of non-AI news. Might just stop following HN for a year or two and wait for the LLM spam to die off.
This reminds me a lot (mostly for worse) of the industrial revolution. The industrialization of textiles didn't help weavers weave better clothes. It displaced smaller, higher quality output with dramatically less varied, lower quality output in much greater quantities, more cheaply. It also dramatically undermined the relative autonomy of weavers and the control they exerted over the structure and details of their own workdays.
What I think we're likely to witness here, or at least what AI investors ultimately are hoping to see happen, is the displacement of code as we know it (often already sorely lacking in quality and craft) not by more of the same varieties of code, but a massive profusion of shittier, more homogenous code. It won't have to win by being better; it'll be able to do that by being cheaper alone. And we're frankly kidding ourselves if we think that doesn't mean a profound deskilling and potentially deprofessionalization across the whole class.
> This reminds me a lot (mostly for worse) of the industrial revolution. The industrialization of textiles didn't help weavers weave better clothes.
I don't think comparing it to the industrial revolution is appropriate, as the political and social conditions were completely different. I think you can compare the disruption that is introduced by artificial intelligence more with the deindustrialization of regions such as the Ruhrgebiet in Germany.
>It won't have to win by being better
I agree but it's also better. On average for most programming tasks I think humans are as "defeated" as coders as we are as chess players.
The machines will not only be as good or better than you at the DB design, the business logic, the performance critical algorithms, the UX, the performance tweaks, the accessibility standards, security holes, browser compatibilities, laws and regulations and whatever else you need to make the whole solution.
It will also write user manuals in any language, and rewrite them when needed even on a friday evening. It absolutely will not stop, ever, until you are DE...wait, I mean DONE!
So the situation for coders is even worse than it was for the weavers. The machine delivers not only cheaper and faster, but also better. :-/
I think nearly all white collar office workers will be replaced eventually. For lots of jobs, the limitation is not the ability of current models, but lack of integration to existing systems. This will change quickly, as writing new systems and integrations is cheaper than ever, thanks to agentic programming.
If the job involves mostly working on a computer, it will be probably gone in 10-20 years.
You may be right that white collar work can be replaced but I don't think it will be. Current society can't function with a majority of the population unemployed.
It's a catch-22 for the companies as well, since white collar work is presumably done because a company has customers, and most of their customers are white collar workers. At least in the US and Europe.
> Current society can't function with a majority of the population unemployed.
I think that argument could have been made at any major conjuncture of creative destruction throughout history, if "employed" is construed broadly.
I don't think any previous disruption was as destructive as this. Firstly it happens much faster and affects many more people at once, and secondly it doesn't seem to create any new jobs for the ones it replaces.
The industrial revolution took at least a century depending on how you count, and it created more jobs than it destroyed.
The introduction of computers obliterated whole office floors of employees at banks and insurance companies but it created even more work at companies that sold computers and software and consultant hours.
Ai takes millions of jobs and replaces them with a few thousand caretakers at megawatt datacenters. The workforce at Anthropic and OpenAI is comparable to a game development studio. If all they end up doing is reducing the workforce of JP Morgan by 10%, society still has a net loss of jobs.
That said, it's at least possible Ai will eventually end up creating a bunch of new work indirectly, by enabling people to do more than they ever imagined they could. One can hope.
I agree. I was asking a devil's advocacy kind of question, to be clear.
In my opinion, LLMs are not competing with real programmers because they do different things. The job of a programmer requires a lot of responsibility and understanding. Using LLMs to write code does not help with that.
You may say that they do compete because companies treat them as the same thing and people need to make money, so the companies decide what is what. That is true but the solution should not be to give in to the money, but instead to make the money behave correctly.
What we need to do is to fix the economy, which still assumes that products are physical and hasn't been adjusted for the digital reality we have now, let alone the AI. Money was invented by humans, not discovered in nature, and we should therefore make it do what we need instead of letting it steer us the wrong way.
I've been very lucky that I love both sides, both the "programming" part and the "making things" part. Even then, it's been quite brutal coming to terms that the programming side of things is a chapter of my life that is basically over, at least professionally.
I'm trying to reinvent myself now and learn the other sides of the projects; how to monetize, how to promote my projects, how to "finish them", etc. I understand that's also changing radically since many people are trying the same thing, and with LLMs the market is changing in unpredictable ways, but that's also exciting! I can get so many more things done now that before I just didn't have the time or focus to finish.
I think understanding the details is still important. However, it moves toward the more central parts of the application, where the risk is higher and agentic workflows can’t be pushed as far. I think the author may benefit from specializing in those parts of the system where unattended agentic work is still too risky.
Wrote a post some time ago on how we'd be helped by segmenting and ranking the domains of our systems so we can be deliberate about where we stop short of full automation: https://ljtn.github.io/epiq/blog/cost-of-cognitive-debt.html
Your article matches my own intuition, and there's a case to be made for adjusting our architectural patterns to better compartmentalize those parts of the app we can let an agent go nuts on. For example, could we leave all of the UI to the agent? Or things like the MCP Server implementation of the app? I'm not quite sure where to draw the line yet. I'm quite comfortable leaving unit tests to the agent by now, but if it's user visible behavior, I still find the agent's work to be off somehow. Ymmv, I guess.
Yeah, I guess it is quite hard to tell where the line should be drawn, and we probably need to rely on human intuition and experience. One thing that the article left out that I have thought more of afterwards is that the classification would need to be relative to the enterprise as a whole. So if you are building a gimmick app for a birthday party you might just vibe code the whole thing, including its "core", but if you are a building business-critical sales system for a major company, the impact of something going wrong would rate the core at the upper end of the scale.
I think that, with the amount of vibecoded code of mediocre quality being produced, there will start to be a demand for "hand-made" software that someone took time to make as delightful as possible to use.
Demand from whom? I think a lot of people are pretty constantly observing that software quality in applications they use (or are forced to interact with) has been declining across the board for a while, and that this seems to have accelerated recently. The average lay understanding of this is "because AI" but it's probably a combination of sometimes being models producing sloppy code and sometimes being poor morale and management and product design in this industry that's essentially coming apart at the seams from the perspective of its workforce. I think it's uncontroversial to say that people already dislike this and wish for better software quality. For the most part, though, they either don't have or won't use any levers of market pressure for this. Their software choices are largely limited to what google or apple will allow for their phones, or what employers require them to use. I'll tell anyone who will listen that they should use FOSS where they can, but people really resist this idea even where it's extremely feasible and the tradeoffs are mostly familiarity (like their desktop OS). Consumers of software seem to partially think this way because they have been disempowered so thoroughly that they seldom have a choice
So as market pressure goes, that leaves employers. I do see the occasional oddball project that resists this wave, but "doing things correctly even if it takes longer" is not a value you're really allowed to have in an economy where the make or break factor for your business is usually getting investment capital, and capital is, as a population, probably the most all-in on LLMs of anyone, to the point where I believe they'd push for vibecoding even in instances where they can't find numbers that justify doing so.
A ton of people not in tech hate genAI so much that they say they'll, for example, not purchase a game if they know someone used it for any part of it, and yell about it online, and such, but games are pretty much the only consumer-facing software people make purchasing decisions about, so maybe that moves a needle there, but gamers failed to rally against microtransactions, DLC piecemealing, or even things like always-on DRM or revoking purchases that literally remove their ability to play their games, so I doubt that's going to materialize a change in something that could be more easily obfuscated in response to this pressure like the provenance of the software
Market pressures require at least a somewhat free market, and the overall american market for software is drastically distorted by various oligopsonies that by and large has a vested interest in LLMs (and specifically the corporate black box ones) being used for as much as possible
Yes, I think so too. Just like there is a demand for handmade objects like vases, cooking knives and beverages, which was the norm before the industrial revolution and has now become a thing of intrinsic value, provides they are of higher quality than their factory-made counterparts (I have a background in the spirits industry, where "small batch" and "handmade" have often been used to justify premium prices despite clearly lower quality. I've become a little more discerning since when I see those labels anywhere and don't take quality for granted).
The issue is how much demand.
We have tailors around the world, but Zara and other brands do the lion's share of business.
Automation in physical labour resulted in less work for physical labour. There are still some people producing hand crafted work, but the market doesn't need that many of them.
A much smaller group of people can serve the needs of an entire state.
I think you overestimate how many users actually care that something is mediocre or not, as long as it gets the job done.
Perhaps I'm just daft or slow, but I'm not 10x-ed by LLM usage. It's precisely because the details matter. (And yes, I read the article and it's lamenting the loss of low level machine-level details.) I read the LLM output, it slows me down. I challenge the LLM output assumptions, that slows me down. I stop to step away and think, it slows me down. I cannot run a bunch of simultaneous prompts and supply this same level of mental context to all of them, because my brain works best when I treat it as single-threaded. My experience with this approach to using an LLM has been, so far, positive.
What I have noticed as I've migrated to newer models is that the assumptions made are incorrect less often. But if I don't pay close attention wrong assumptions can still be made. Cross cutting concerns are lost, or written in such a way as to be useless.
So, the loss of details, to me, would be my own laziness in not performing due diligence.
Whatever your opinion of the current state, LLMs are seemingly improving exponentially. You remember where we were a year ago. We can't fathom what it will be like in five years. Maybe even hard to imagine three. Once it hits the point of diminishing return on ability, it will move to speed and cost optimization. And of course everything will get smaller and take less energy in the standard progression. When viewing as a snapshot in infancy we can see the holes. But it's essentially a solved problem that is snowballing now. Not that it won't create other problems. And very likely solve many others.
Exponentially?
I think so. Although it is possible that it is being held back for safety reasons. The same has been true of CPUs and many other advances, but the timeframes were generally longer.
For a brief moment in history, it was cool to be a nerd. That era is over. The era of the nerds began when the IBM PC went mainstream in the 1980s. It peaked in the dot-com era, when, for the first time, large numbers of nerds got rich. That continued through the FAANG era. Now it ends.
There will still be some nerd jobs. Some. Fewer over time. The future is not you telling an LLM what to do. That was the brief "prompt engineering" era. It's an system of LLMs and agents telling each other what to do. Most likely with a bro in charge.
Get used to sand kicked in your face. Or, to quote Orwell, "If you want a vision of the future, imagine a boot stamping on a human face – forever".
Ask someone who used to have a good union job what life is like now.
> “I didn’t care about practicality, building useful programs, or writing code per se: all I wanted is to understand how the machine works.”
Over the years, I’ve transitioned from building “beautiful” stuff to nowadays building stuff that works. I still want it to be perfect but now not for me but for the user. If I think it’s ugly, but the user wants it that way, then who am I to decide against it? They will have to use the software, not me. Seeing a user be happy with the software is super nice. Way more enjoyable than me just making stuff for myself.
Great article, and I 100% agree. I'd even go further than this, and say that the rise of AI has clarified my vague feeling that computing has been going wrong for a very long time. There's a famous article by David Chisnall with the subtitle "Your computer is not a fast PDP-11." [0] I believe it should be a fast PDP-11, and outside of specialized batch processing machines, we should sacrifice performance to make this possible.
Instead of cache, software-managed fast and slow memory spaces.
Instead of branch prediction, memory with multiple read ports/buses and software-managed parallel prefetch queues.
Instead of hardware speculative execution, VLIW.
Instead of automatic DRAM refresh, a hard-real-time OS handling the refresh timing.
I don't care that this would to make things on average slower and more expensive. Modern computers have tremendously fast average-case performance, but the software is still mostly laggy garbage. We sacrificed ease of understanding and didn't even get responsive software in return. I believe that if modern computers really were fast PDP-11s, we would not be in the situation we are now, where most programmers see nothing wrong with software taking some unpredictable human perceptible time to respond to inputs, even when simply processing text. I care more about worst-case performance than average-case performance.
As the article says, "Like a fisherman might feel one with a fishing rod, I treat the machine as a continuation of myself." A fishing rod always responds in zero milliseconds. A computer should do the same. You can say AI is qualitatively different because by embracing it we abandon even the possibility of understanding, but in practice we mostly abandoned understanding already. There's no practical way to count cycles any more.
Of course, most computer users don't care about this, so there's no commercial market for the kind of hardware I'm imagining, but I'd love to see the "fast PDP-11" approach taken to its limit. Let's make computers it's possible to completely understand.
[0] https://queue.acm.org/doi/10.1145/3212477.3212479
Yep, its incredibly painful. The entire world has lost its mind
I think there's opportunity to create a niche that fits the author. LLM-generated work has this problem where the details are flawed in a way that makes it good on the surface, and nowadays a bit deeper, but still inferior to the same work produced by a competent human. The dominance of low-level programmers over software could not last forever, but neither can the dominance of this use of LLMs: English is not an ideal programming language.
I've seen people praise broken LLM-generated software in ways they never would human written software that had the same issues. I think the dominance of LLMs will last simply because of the money and social inertia behind them and because people consider them inevitable, so it doesn't really matter how flawed the code they generate is there is faith that LLMs and the quality of what they generate will always improve, and that one simply has to accept it. That faith and tolerance isn't (and will never be) extended towards humans to the same degree.
LLMs aren’t going away, but even though people tolerate their imperfect code and design, there’s room for improvement. Especially because many other people don’t tolerate it.
isn't the person that did the tron typography visuals a regular here?
cool to see it come full circle and see another person thrown into the industry by the work of another forum member.
There's no way back from here. Being able to write a program is just not worth as much as it was to the world and rewards and incentives are adjusting accordingly.
Imo, the best jobs for people who prefer understanding over building nowadays are those in IT security. Vulnerability research, pentesting, forensics / incident response, reverse engineering... - here the details still matter. LLMs are also coming here ofc, but they don't unilaterally take away the interesting work.
It feels like a delicate psychosis. I can understand it, accepting a change is very very hard for me too.
We are taking away the ability for some very smart people to be engaged with the world in a way that is challenging and meaningful to them while building tools that allow one person to do the work of 10. Fill in the blanks if you want, but this is not good. We must quickly find out how to give people hope for the future.
I too am motivated by a desire to understand how the system works. I never got down to assembly or toy operating systems, but my recent wins have been rooted in an uncommon understanding of how compilers optimize, how CPUs cache and pipeline, and how TCP stacks queue and buffer.
I went through something similar when I worked started working for AWS in the pre-LLM era. I had to learn to let go of the desire and perceived need to fully understand the system because it was just too big
Indulge in the larping and you can laugh about yourself, its not that bad honestly. Breadth in topics helps to recognize patterns/common ideas, it is ok to let go.
The background reads like a strong Caltech admissions essay. Just sharing my irrelevant observation.
I commiserated so much with this post. I feel like I got out of software at just the right time - folks like me that have an inherent need to understand the lower level details feel like this agentic coding world, where there is simply not enough time to even read the code, let alone understand it, is hell.
I left software and went into violin making and I couldn't be happier (though of course I'm extremely fortunate to have saved up enough in my software career to comfortably make the transition). In violin making a tenth of a millimeter is considered a lot and we endlessly stress over details like the corner shape and the f-holes. And while some of this nitpicking is certainly excessive, it serves more as proof to show that we're extremely careful with the details so that stuff that really matters, like tonal quality and playability, will also get enough detailed focus.
What a charming new career path! And you make an interesting point about signaling attention to detail giving a guarantee of sorts that the things that matter are covered as a matter of course.
Reminds me of a friend who would go straight to the restrooms for a quick visual inspection upon entering a restaurant: if those aren't clean, there's no reason to think the kitchen is.
The same thing with me. I cannot really take something for granted in maths if it's not an axiom
> Hobbies still exist, but they don’t pay the bills, and increasingly retrocomputing and performance optimization are being infested by LLM fans that seek recognition rather than the experience, which sucks the fun out.
Isn't this whole post seeking...recognition? I am so confused at the metahypocrisy here. Why is it valid to want recognition for something when you do it, but not when someone who uses an LLM does it?
People want recognition when doing something hard that took time, effort and dedication.
Training a year, and running a marathon feels more worthy of recognition than driving 42km in a car from the start to the finish.
While I don't empathize with the defeatist tone of the post. I do empathize with this part.
Good thing that programming with LLMs takes time, effort an dedication then!
not really? you have people doing it with their voice while driving..
So because some people use Tinder, does this mean that nobody puts any effort into actually finding the right partner?
Said another way: is it impossible to use something which everybody has access to to make something artful?
Or I will try it a third way. Does the fact that people take bad pictures on their iPhones prevent other people from shooting whole professional movies on iPhones?
your message was "Good thing that programming with LLMs takes time, effort an dedication then!"
In answer to that message: taking bad pictures on an iphone is not something celebrate or recognize no.
There's a great post I read on twitter on how marathons and Iron Man have come to be the new status signal. The argument was that people who grew up with privileges find it hard to show something they've personally worked for. Every other "achievement" could be attributed to something other than their hard work.
ex: getting a big seed round from a VC for your start up still may show that your parents had connections.
but marathons have this grindability and somewhat stable feedback loop.
EDIT: https://x.com/aporia9n/status/2085413571568222443
> all I wanted is to understand how the machine works.
> [...]
> If an LLM can analyze the code and explain pointer provenance to you and babysit you until you get it, there is little value in expertise.
This sounds like the author wanted to understand not for the understanding itself but to get an edge.
One of my strongest motivations has always been the understanding (mostly of why a thing doesn't work like it should) and I have no trouble accepting AI assisted mode of acquiring understanding because I don't care if it's worth anything to anybody that I understand.
I draw pleasure from understanding. I don't build my value on understanding. I don't grieve anything. I'm elated that I have a virtual person smart enough to explain to me the things I'm interested in. Before I felt like I had too seek water in the vast desert full of dust and prickly things. Now I have plumbing and the same thirst.
Maybe I'll build a Turing machine out of beer cans as a way to grieve my loss.
> Last time I tried using an LLM for a pet project, I realized that the LLM would come to know more about it than pretty much any person I could show it to.
I was quite reluctant to show my own code to AI. I was doing greenfield experiments for months before I gave AI anything that contained any code that I was proud of.
But when I did, it understood it very well, better than any person I could show it would be able to. And extended it very well. My programs, even the most complex ones became way better and did more than I could ever hope to achieve myself.
Basically at this moment I had to conclude that LLMs might be better than a developer with 20 years of expeirience. This was more than half a year ago at this point.
> and performance optimization are being infested by LLM fans that seek recognition rather than the experience
The death of every sub culture in a sentence.
I don't know. There's always neurology and IP law.
at the beginning of the 20th C when ford implemented the moving factory line, experienced mechanics disliked the new way of doing things but did it because it payed well. they werent using a lot of their skill set and their job could be replaced relatively easily. many many industries in our current economic system will be facing this now. if you can tell me which ones are immune im all ears.
Humanity itself progressed because people specialised and one doesn't need to know about the entire supply chain of their hamburger to eat it.
A good programmer or a good knowledge worker knows how to work with lossy details.
Yep it’s pretty depressing all around. Even when the truth is revealed about the output of an Llm (not quality, full of errors, made up details, nonsense code, etc), people are still claiming it as a better way of working because they had a chat with it. There is very little room for anyone not interested in slop.
I was recently replaced by a young developer and the only thing that keeps me smiling is that they still haven’t fixed the part of the application I raised concerns about (because the young dev decided to write on a fresh non-compatible stack even after my warnings). I hope eventually it leads to their own loss of career since that’s what they did to me. All of that to say that Llms have made people into over confident morons.
Like the old joke about alcohol not "turning" someone into a jerk, but instead revealing the jerk that's been hiding all along, I think the same is true for the idea that LLMs are "turning" people into overconfident morons. I don't believe these people are being changed, I think it's how they always were, and now it's easier to see.
:/ The celebration of loss of rigor does seem like revealed preference.
Yes that is probably a better way of putting it. We are all overconfident morons until we learn things. Now society has subtracted knowledge share and gain from the equation.
Eh, but so what? Even if everyone really was a jerk, something holding them back from revealing it was still valuable.
How did this come around? the young developer was just faster overall? or were they cheaper?
My original manager left and my coworker was promoted. They immediately turned face away from the team. They fostered a hostile environment and made sure to not make decisions but instead let our team fight amongst themselves. Then they fired the other two team members without a reason and loaded all the work on to me. Then they would waver between I wasn’t working fast enough and “we can slow down if you need more time” for months while pushing back projects and deadlines because they failed to plan for any of those projects. I tried making amends and focusing on work and not the drama, but they wouldn’t have it. Then they started talking about hiring two new juniors for the team. Which I understood to mean they were going to replace me. When one of the juniors started that person was kept away from me and did not meet with me for any onboarding or collaboration. Instead talking to my manager only. Once this happened I still tried to be invested in the projects and pairing with the other new hire. Eventually though a deadline came and I had to explain why the code wasn’t ready when they dropped the new stack they built in private on me days before things were due.
I have no opposition to a new stack but our team already had 6 different projects, two of which were the previous teams next-gen projects. I didn’t want to increase the maintenance surface than we already had with 3 different wordpress sites, 2 nextjs next gen sites, 1 next gen site, and now the new guy’s next project built on vite.
They have a PoC of the new site they released for their semi-annual conferences. It does not work, looks pretty but does not work (essentially because vite has no server API).
So yes, it was an operating capital reduction measure or wage stagnation or whatever you want to call it. I’ve never had a manager that didn’t go to bat for me or passed blame for their failings onto me until that job. Apparently C-suite had developed a culture for pointing fingers.
> All of that to say that Llms have made people into over confident morons
My manager does not have a software background. Initially he used to come to me with an idea and we used to discuss on how we can technically implement it. He used to value what I had to say. Now he talks to copilot, come up with these grand ideas, dumps all that on our heads in a 30 min meeting and ask what do you think about it?
"Sounds plausible, boss!"
I think part of the grief is losing the way we learned to do something we loved. Most people care about what software does, not how we made it. The hard part is accepting that what makes the job satisfying for us isn’t always what makes the result useful to others.
LLMs are a multiplier. If the author is reading this,
You're freaking out over no big deal
It's great that she takes joy in his work, and sad that economics is pushing her to focus on different details with less joy. But the same can be said for a horse groom who loves her work being pushed to transition into a mechanic. Change sucks, but less than petrification.
The author is a woman, not sure why you assumed they identifed as he/him.
Probably because there is no bio or name on this page and the author mentions their girlfriend. Seems an easy error to make
"Petrification" still sucks less than enshittification. Most of the so-called progress from AI is making the world worse for the average person.
“A creature who has spent his life creating one particular representation of his selfdom will die rather than become the antithesis of that representation” ― Frank Herbert, Dune Messiah