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

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.

>>“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.

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.

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.

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.

> 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.

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?

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.

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.

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 get almost physically ill when I work on a project with more source code files or at least general architecture than I can keep in my head, so I don’t get anything out of expanded scope

While I sympathize with your loss, this was always going to prevent you from holding down a job, even as a pre-LLM "coder." The majority of us have to work on systems, not just single files or cleanly isolated programs we can hold in our head.

“I 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.

"...are being infested by LLM fans that seek recognition rather than the experience, which sucks the fun out"

Part of the all-encompassing thief-of-joy grey goo is definitely the oafish, tactless footsoldiers.

> I first became familiar with computing when I saw the history scene in Tron: Legacy

Thanks for making me feel old

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.

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 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

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.

> “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.

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.

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 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.

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.

The same thing with me. I cannot really take something for granted in maths if it's not an axiom

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.

> 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?

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.

Yep, its incredibly painful. The entire world has lost its mind

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

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.

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

Maybe I'll build a Turing machine out of beer cans as a way to grieve my loss.

LLMs are a multiplier. If the author is reading this,

You're freaking out over no big deal

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.

> 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.

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.

[dead]

[flagged]

[dead]

I'll introduce the concept of Hobbies for those who crave the details. Hours spent in the basement/attic/office/garage/workdesk sweating the details in an inefficient and un-economic way. Learning music, painting figurines, woodworking, playing with microelectronics, making sculptures, model aircraft, ham radio. Offline things, intentionally far away from the frontier that bring joy, depth of understanding, and are intentionally not going to be gobbled up by an LLM.

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.