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.

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.

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.

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

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

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

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.

Indulge in the larping and you can laugh about yourself, its not that bad honestly. Breadth in topics helps to recognize patterns/common ideas, it is ok to let go.

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

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.

This resonates with me. Hard.

I'm lucky though - as a hybrid engineer/manager, I've been able to lean away from the former and into the latter.

And I've come to notice that humans doing agentic work seem to need more emotional support per unit effort than those doing traditional engineering.

So there are opportunities there. I don't want to spend a second longer than I have to prompting machines - there is zero dopamine loop in that for me, I get more doing housework and at least that makes my wife happy - but I'm happy to support a few other humans engaged in that kind of work.

It's sad though. I used to love dreaming intricate machines into existence and then watching them come to "life", or at least actually start working. That dream seems dead for now, I hope it comes back but I won't hold my breath.

> “I 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 first became familiar with computing when I saw the history scene in Tron: Legacy

Thanks for making me feel old

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.

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

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

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.

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.

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

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

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

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.

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.

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

> I want a tool that gives programmers a place to record their thoughts. Developers need a place to draw and write, and also interleave blocks of code that automatically update to match the actual state of the code.

Sounds, like you already mention with org-mode or similar ones) like literate programming (https://en.wikipedia.org/wiki/Literate_programming) or jupyter notebook.

I think the solution is still code, just at a much higher level of abstraction. Maybe a start is kind of typed ADR or FSM that guides (constrains) the agents. I believe more type checking guarantees will be more and more important for agents.

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

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.

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.

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

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

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

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

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

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

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

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.

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?

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.

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

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.