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.
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.
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?
>> 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.
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?
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 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
> 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.
> 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.
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.
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.
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.
>>“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.
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.
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.
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.
Every technology revolution since the Gutenberg press has followed the same pathway? There is no evidence AI is any different.
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.
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?
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.
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.
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.
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.
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.
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.
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?
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.
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.
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.
> 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?
> 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…
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...
> 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.
> 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.
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.
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.
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".
> 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.
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.
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.
> 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.
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.
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.
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.
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".
> 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.
> 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.
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.
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.
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.
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 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".
> 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...
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.
> 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.
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 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.
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.
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.
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 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?"
... 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.
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.
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.
> 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.
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.
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.
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.
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.
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'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.
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 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.
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?
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.
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.
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
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.
“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.
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.
No offense but this person seems either incredibly autistic or mentally ill.
> I don’t see myself as a programmer who is also an expert in a niche area; I see myself as exclusively a low-level coder,
> 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.
We're no longer in an age where this kind of aggressive specialization makes a lot of sense. And, honestly, that's a good thing. The best thing is to have T-shaped knowledge. Go deep in a few areas, shallow in many.
> A human being should be able to change a diaper, plan an invasion, butcher a hog, conn a ship, design a building, write a sonnet, balance accounts, build a wall, set a bone, comfort the dying, take orders, give orders, cooperate, act alone, solve equations, analyze a new problem, pitch manure, program a computer, cook a tasty meal, fight efficiently, die gallantly. Specialization is for insects.
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.
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.
> 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'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 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'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.
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.
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.
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.
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
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.
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.
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.
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 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.
> 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.
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.
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.
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 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
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.
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.
> 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?
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.
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.
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.
> 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?
>> 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.
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?
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
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
> 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.
> 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.
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.
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.
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.
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.
>>“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.
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
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?
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.
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.
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.
"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?
> “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.
> 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.
> 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.
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.
That and the fact that people void of any skills, coding or engineering ones, could still find a six figure 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.
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.
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.
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.
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.
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?
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.
> transient LLM crappiness notwithstanding
Bold of you to assume.
>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 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.
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.
> 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?
Yeah, "Intent-based UX" is evolving to address this challenge, but it's got some catching up to do AND is far from mainstream....
> 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…
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.
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...
> 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.
> 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.
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.
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.
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".
> 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.
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.
> 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.
> 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.
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.
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.
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.
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".
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.
> 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.
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.
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.
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.
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.)
With how you presented this, it makes it sound like it was either a toy codebase or something outside of your domain already.
How large is your codebase?
The example provided covered both options.
In general the OP is right, the people who get the most value out of LLMs are veterans.
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?
> 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...
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.
> 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.
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 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.
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.
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.
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 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.
Where is the money for welfare coming from if tax from working people is drastically reduced?
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.
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.
- 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.
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.
> 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.
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.
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.
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.
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.
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'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
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 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.
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?
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.
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.
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
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.
Maybe people will be hired for the question they can actually ask and not for the raw knowledge they have
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.
“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.
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.
> I first became familiar with computing when I saw the history scene in Tron: Legacy
Thanks for making me feel old
"...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.
No offense but this person seems either incredibly autistic or mentally ill.
> I don’t see myself as a programmer who is also an expert in a niche area; I see myself as exclusively a low-level coder,
> 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.
We're no longer in an age where this kind of aggressive specialization makes a lot of sense. And, honestly, that's a good thing. The best thing is to have T-shaped knowledge. Go deep in a few areas, shallow in many.
> A human being should be able to change a diaper, plan an invasion, butcher a hog, conn a ship, design a building, write a sonnet, balance accounts, build a wall, set a bone, comfort the dying, take orders, give orders, cooperate, act alone, solve equations, analyze a new problem, pitch manure, program a computer, cook a tasty meal, fight efficiently, die gallantly. Specialization is for insects.
-Robert A. Heinlein
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.
>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.
> 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'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 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'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.
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.
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.
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).
I think you overestimate how many users actually care that something is mediocre or not, as long as it gets the job done.
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.
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
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.
That's more of a straw giant than a straw man at this point.
Do you have a citation for this?
Hey, interesting take, could you cite some specifics on the LLM and experiment you’re referring to?
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.
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.
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 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.
Yep, its incredibly painful. The entire world has lost its mind
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.
> 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
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.
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.
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
The same thing with me. I cannot really take something for granted in maths if it's not an axiom
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
https://discuss.google.dev/t/trusted-automation-with-google-...
Maybe I'll build a Turing machine out of beer cans as a way to grieve my loss.
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.
LLMs are a multiplier. If the author is reading this,
You're freaking out over no big deal
> 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.
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.
> 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!"
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.
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
"Petrification" still sucks less than enshittification. Most of the so-called progress from AI is making the world worse for the average person.
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