Grieving the loss of details | Hacker News Reader

Grieving the loss of details

purplesyringa.moe

481 pointssigna11401 comments

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

This is one (of several) reason why many larger open source project ban or severely restrict the usage of LLMs. They want contributors to fully understand the changes they are making.

Recently we have received several bug reports with AI suggested fixes. They looked reasonable enough and seemed to resolve the issue at hand. I then took a deeper look and discovered that every single suggestion only hid the symptom but did not address the underlying issue. Applying the suggested fixes would have hurt our codebase, so I eventually had to reject all of them and write my own solutions. This was only possible because I'm deeply familiar with the codebase and the broader context. Someone with less knowledge would have probably just applied the LLM suggestions without much questioning. I find this rather worrying.

I guess in popular open source projects the stakes are just higher than in some proprietory software that will be replaced in a few years anyway. The irony, of course, is that LLMs have mostly been trained on open source code.

Also, some of the projects I'm involved in are over 20 years old. One even celebrated it's 30th anniversary. This means there is also the question of historical responsibility.

>But I have one singular counterexample to most scary narratives and essays about LLMs writing software, which is my coworker who hardly uses LLMs at all

Nice, but that's not a counterexample that refutes the scare narratives about LLMs. That one that prove their point.

> I think I’ve leaned too far into AI, partly because I’m a lazybones and am kind of burned out already.

I've been doing systems / backend programming since I was 10 (in C in those days), so I was burned out by the time I was 20, and I'm now 40. The temptation to trade on that knowledge in a very short-term way is strong, but I know where it leads -- to the rot you describe.

This is rotten but I'm secretly glad that Claude et al are metering by the token.

I'm not sure that folks realize that the purpose of software engineering is to program in a way that doesn't just function, but optimizes for future readability, maintainability, and behavioral change in line with product requirements.

There's a reason why programmers are not paid "by the line", and it's because LoC as an incentive structure is a disaster that leads to brittle and verbose slop code -- and we knew that even before LLMs.

So I'm glad that the (long-term) economics mediate against token-hogging software by making it literally more expensive to deal with.

I just hope that managerial types are smart enough to realize that "time to understand/upgrade/change a codebase" still matters, whether that's expressed in terms of SWE work hours or LLM tokens.

I would not bet on the managerial types responding to anything but (a) blunt monetary incentives and (b) the latest buzz from other people in their general professional category, e.g. at the country club.

I think the ideal state is a team with a mix of programmer types. Some are detailed focused and anti-AI, some are AI maximalists, some use AI for architecture but review carefully, etc. Just as people use one LLM to review another LLM's output, there is value to diversity of thought, more than ever.

Where things go off the rails is making sweeping workflow changes for all developers. Eventually we will realize that LLMs have the same gaps of insight and hit the same local maxima. More than ever, diversity of thought is necessary when everyone is outsourcing a chunk of their thinking to a nondeterministic parrot that is somewhat deterministic in its problem-solving

This is me basically, I use LLMs on the browser for specific queries rather than you know, have it abstract my work into a black box...

I deal with a lot of non-LLM users at work and quite often the conversation hits a dead end, where I'm like , ok but see, your app has this performance blockage due to your not having an index here - do some performance tests and you'll see (it was a hang caused by a FOR UPDATE locking the entire table due to lack of an index). And you can hear the pause (it's all over Slack) where they just aren't going there, because writing a performance suite for the issue in question would be a lot of effort to do by hand and in the "before times" would be a difficult undertaking to justify. Because they don't consider an LLM, a task they most certainly should be doing becomes a non starter. Never mind my own Claude had a whole plan ready to go to do this whole suite for them in about five minutes so they could study the impact of the index, but I really didn't want to just go ahead and do this all for them. At some point your non-LLM coworkers need to stare directly at work we'd never be willing to do before that's now trivial, and in fact is now part of the job.

Right, but performance testing has always been hard and LLMs are awful at it. So maybe your coworker was right?

I’m definitely on the “just use the clanker” end of the spectrum. But knowing when and is good. Constantly having to argue with people’s reposting of Claude’s idea of what’s wrong has left me burned out. At this point, if I have any idea about what’s going on and someone tells me “Claude says”, I will ignore them.

In this case, it sounds like you could have made a ten line repro that shows the problem. Why not just send that, something human interpretable?

What LLMs are you using? Just simply telling Sol 6.1, Opus 5.5, Fable or Astra to performance test something will get you a solid improvement in poorly optimized code.

Giving it a specific plan will get you a solid test harness.

And setting up an autoresearch system and running it overnight will get you expert level optimizations if you set the metric up right.

These things excel at performance optimizations.

Using everything modern and useful!

Performance testing has always had problems with isolation, mocking, covariance of services etc. I’ve just spent two weeks driving down latency across our framework, and autoresearch was definitely not a viable path. Most of these loops have these logarithmic, non-step change curves.

Just like with actual research, the real benefits came from me asking why is it like X and not like Y?

The original performance testing framework Claude created to bench our different versions against did not even mock high variance provider calls…

> Right, but performance testing has always been hard and LLMs are awful at it. So maybe your coworker was right?

LOL, you're making the same mistake they did. thinking "index" means "too much time spent fetching the rows". read again - it's a FOR UPDATE so the entire table gets locked and other processes get totally blocked.

> Constantly having to argue with people’s reposting of Claude’s idea of what’s wrong has left me burned out.

It wasn't just claude's idea, it was my idea too, the claude topic was that it would write a suite that proves the problem, in this case, very loud logging messages that were occurring for the customer when this quasi-deadlock situation occurred. it was not subtle.

> In this case, it sounds like you could have made a ten line repro that shows the problem.

no, it involved running a galera server and about four other services with a specific set of data conditions, again, read what I wrote, creating a proof of concept suite was not trivial to do by hand.

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

Claude's code review is a lot less interesting then getting Claude to reproduce the bugs it claims to find in code review, which has had an absurdly high hit rate for me.

The biggest problem I see with how a bunch of people use these tools is they go to them as an oracle, rather then letting them be plugged into and interactive with problem.

And it's in that later context that Claude is amazing: it can run tests and setup scenarios which would take days or get stuck in some weird problem loop. And then you can just say "okay, walk me through this problem" and see it yourself right there.

A lot of bugs are essentially that the code does something plausible correctly, but it's the wrong thing to do. People who are familiar with the codebase and its purpose can often spot those bugs. Those with less experience usually can't.

The issue is tacit knowledge, or implicit context. Most details are never written down. If you don't know them from experience, you have to guess. If you guess, you often guess wrong. And even if you know something from experience, you are often not aware of it, until you see something that violates it. So it's not possible for you to write it down in advance.

You can replace people with AI in the above, and nothing fundamentally changes.

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

As someone who owns a company:

Some holdouts excel at what they do to the point of retaining significant value, earnestly worried about being out of touch with what we do, some holdouts just suck and are bitter.

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?

Not the GP, but I think I have a similar urge to go deep in understanding details. I definitely find myself different than many peers who are more comfortable operating with ambiguity.

"A clean interface contract" is actually all I need to stop pulling the thread, but I find that is rare in large software systems. More typical is that the provided interface lacks details about edge cases, such that multiple behaviors could meet the interface. That's what makes me want to dive deeper and figure out what those cases are, what I think is the best behavior, and what the system actually does.

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

In many case it is the sheer accidental complexity. I tried to get into Linux codebase and gosh it's so much harder than FreeBSD. And Chromium, LLVM... I don't believe it has to be that way. I use Common Lisp software (besides Emacs) written by human for anything I can and these have always been a joy to use or work with.

It seems the way industry is heading towards wrt LLM will make this even much, much worse.

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

> Honest question: What is preventing you from understanding any part of the stack now?

Bringing this question out of the thread and back to the current moment...

the recurring answer now is "futility in the face of churn", I think.

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.

My comment wasn’t about LLM vs compiler, but about low level libraries vs high level libraries.

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

I’m this type of person, for me it’s: can I confidently teach my mental model and understanding of the thing to another person.

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

> No one confessed the Machine was out of hand. Year by year it was served with increased efficiency and decreased intelligence. The better a man knew his own duties upon it, the less he understood the duties of his neighbor, and in all the world there was not one who understood the monster as a whole. Those master brains had perished.

- E.M. Forster, _The Machine Stops_

Abstraction is terrific and terrifying. It is the shoulders of giants we build upon, but when it begins to scale nonlinearly I fear it endangers us as much as enraptures us.

I keep a print out of "The Machine Stops" on my bookshelf. It was hugely impactful.

> You know what a byte is, you know the endianness, the signedness, you can feel comfort in knowing you're not missing anything, and then you build up from there seeing each block build upon the previous.

IMO you’ve chosen a flight level you’re comfortable with (which is fine!) but there is much going on below the abstraction that lets you view a file as a bag of bytes.

I’m saying this as someone who uses SwiftUI and CoreBluetooth on a daily basis, and I have to trust these foundations just as you seem to trust the C compiler and a filesystem.

> I like to tell juniors confused about file types, that file types are a social construct, they're just a bag of bytes with some structure.

I always get confused about what the hiring landscape looks like. How is it that people are grinding leetcode or whatever just to get into places, but still have those kinds of gaps in fundamental understanding?

I'm not in a field where leetcode is the deciding factor but there's similar gamified focuses. The idea being you can pick out self-motivated autodidacts with those kinds of challenges/experience in the challenges, then fill in the connective tissue later.

This was just one example of a capable intern who was tripped up by file types.

Because even prior to LLMs, “knows how to program” and “understands computers” could be disjoint. I worked with someone who didn’t understand how to find what was consuming their disk space, nor how to fix it, or most egregiously, that they needed to empty the Trash (MacOS) to actually reclaim the disk space.

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

This was actually helpful: I thought "flight level" was some new hip expression that I had not seen before. I was pondering what "flight" added there; is it like the hexagonal architecture that is not actually hexagonal?

But sure, "right" makes sense in the circumstances.

Same I assumed parent meant "flight level", like a plane flying over terrain at different altitudes, the closer the more detail you see.

To me, bending "right" to "flight" reads like a fun way to clarify that the question is not about proficiency but about depth. Not a typo the way I read it.

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?

Now consider the case where I send you a message (in a language that's not english) and it doesn't render as text on your screen. Reasonably, because I understand how network protocols work, I can assume that it's not a little/big endian mixup between our systems - the HTTP request would not have worked, then, as utf-8 and utf-16 are incompatible (unlike the weird utf-8 ascii mix). With HN, I can open up developer tools see what encoding it is sent as over-the-wire, and then I can ask you to look at the encoding on your end. I can say "the vibecoded browser you use is trying to interpret this as utf-16 but hackernews only sends utf-8". I can dial down the root cause of the problem and then address it.

Contrast that to a situation where I ask an LLM to use a tool and it can only do it like 98% of the time. How do you root cause that. How do you fix it such that that doesn't happen again?

Also consider: occasionally your support agent gives people free plane tickets.

Yes, we've made a lot of progress towards LLMs being fairly good, and adversarial systems and such do work, but it is asymptotic approach to 100%, never actually 100%

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 have crippling imposter syndrome. Using AI really aggravates that.

Huge part of it. A big part of my idea of the negative impact of the internet in general is that it constantly exposes you to people who are doing the same things you love and are interested in, just way better and more effortless, alongside yet more people criticising even these golden gods for this or that failure you could only hope to reach.

It's an imposter syndrome machine, but one you could perhaps tune out because it wasn't really useful for much except entertainment. LLMs bring the experience of being followed around by that machine talking into your ear any time you have an issue or problem - you could just ask your fabulously talented friend to do it instead. And they are sadly tremendously useful so keeping that mental compartmentalisation is way harder

I think there is a basic human need to to be "the guy" everyone goes to when they need help with a specific thing. Where "everybody" is roughly a Dunbar's numbers worth of people, a tribe or a village if you will.

We've developed fabulously effective ways to wrench the fulfillment of this need away from a huge amount of people

I think programmers are frustrated in part because the code used to be our place to do our thinking, but now LLMs just buzz through the file changing thousands of lines and we can't keep up.

It's still valuable to deeply understand parts of a program, but we don't have any tooling that helps us do that. We just have to raw-dog it by thinking really really hard and remembering how all the code connects together.

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

The closest thing I know to this is org-babel, part of Emacs, which allows you to push code blocks out of an org file into an actual source files, or pull them in from actual source files. This is mostly done manually by invoking functions called `tangle` and `detangle`.

I intend to investigate this further in Emacs, since I'm an Emacs user, but Emacs is never going to be the friendly UI we need to make this tooling common.

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

> It's still valuable to deeply understand parts of a program, but we don't have any tooling that helps us do that.

Doesn't the LLM do that, if you want it to? I do use it to write code, but the more striking ability it grants me is a means of understanding legacy code far faster. I can ask "what actually causes this branch to be taken" and it's usually right. Ok sometimes it's not right, but I'm not always right either even after I spend tens of minutes reading code.

It's also exceptionally good (i.e. fast) at looking through git history to figure out where/when a certain behavior originated, which can be difficult (time consuming) if code is continuously being refactored.

Sure you could use it to vibecode. I don't, rather the opposite, I understand my own changes better. But I still fear that I'm going to be obsolete as soon as it figures out what questions to ask. And I'm unwittingly training it to do that.

Agreed. Coding agents are an excellent tool for navigating an codebase to deeply understand the code (certainly better than grep!). My existential question is more about whether deeply understanding the code is worth doing at all. If your identity as a programmer was based around being the one who understood the code the best, why is that valuable when anyone can use the agents the same way?

> But I still fear that I'm going to be obsolete as soon as it figures out what questions to ask.

Code and business requirements, outside of maybe very pedestrian CRUD apps, is diverse enough that I don't see that to be a realistic concern. A far bigger concern is that it may not matter whether they're asking the right questions, and that sufficient brute force can overcome any objections like 92% of the time--good enough for government work, good enough for the MBA frat boy who lords over you and always saw you as a needlessly expensive typist anyway...

> now LLMs just buzz through the file changing thousands of lines and we can't keep up. It's still valuable to deeply understand parts of a program, but we don't have any tooling that helps us do that.

I do it differently, I focus on better recording what the user wanted, the so-called "user intent". To do this, I record all messages typed by the user since the start of the project, whether 3,000 or 10,000 messages. An LLM can churn through them in 10 minutes and derive a fresh, up-to-date interpretation from the raw data. This can be used to judge whether the implementation has diverged from the intent, or, in other words, to realign the code and tests. The messages the user writes are usually designs or corrections, a very rich, compact signal. If the user struggles with something, it could result in a tool, a skill, updates to the project docs, or new tests.

Yeah, "Intent-based UX" is evolving to address this challenge, but it's got some catching up to do AND is far from mainstream....

But a codebase is a state machine, and given the somewhat random style of LLM outputs, those amplify to an extent that the recorded intent needs to include the outputs too, in a way? Or are you basically doing high detail specs?

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.

> It's still valuable to deeply understand parts of a program

Part of woe is that once you've reviewed, validated, and comprehended a piece... Later gets casually mangled by some other LLM-generated urgent change.

Yes to this. With the speed of ai code generation, the team has to decide not to rip things apart in every pr even though it is possible, since this destroys any hope of maintaining even a bit of understanding.

Some parties mean that making understanding irrelevant of the whole goal of ai driven development, though.

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

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

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

I don't think the solution is code, because I still want a place where I can write my own chain-of-thought, without it having to rise to the level of "code". I just want to put my chicken-scratch drawings and diagrams somewhere. I just want a place to think that won't change out from under me.

I've been having agents build knowledge graphs, they're a tremendous mess to start with, but I take the time to manually drag nodes around or group them in meaningful ways so that it's actually human-browsable. This is boring enough to create space for me to think in. It leads me to go on expeditions into the code which surface the missing details. It's also a nice way to communicate context to agents. Like, I can hide all but the relevant nodes from an agent before suggesting that it query the graph to understand which service references which other service via which api, which database tables are read/written by such an action, etc...

Curious, how do you do this? What tools are you using to build and manipulate the graphs, and how do you feed that context back to the agents? The manual organization part sounds particularly interesting.

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.

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.

Not exactly what you asked for, but I now keep pencil and paper next to me, and that has been incredibly refreshing for brainstorming / mental processing

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

The annoyance I have is that it isn't one of the other. I spend a lot of time thinking and fighting with whatever frontier model we're on today. I've seen people let LLMs make absolutely atrocious decisions and just click next and collect checks.

I just posted this morning about this type of engineering has secured us numerous customers and put some projects in our backlog that either need significant rework or at least a very close eye to see if their issues crop up.

IDK, the idea that we shouldn't be thinking is a worrying one. I still have to think a lot.

What I'm _mostly_ worried about is that the path to get to high performing senior is basically a burned bridge with our current training techniques, and I'm not sure we'll adapt before a brain-drain situation in the industry.

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

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

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

> It establishes for granted that LLMs produce more optimized code than performance-oriented humans do.

I didn't read the piece as claiming anything of the sort. I read it as claiming that employers don't care.

The author is well known around here and has demonstrated quite a bit of low-level technical proficiency; see previous submissions https://hn.algolia.com/?q=purplesyringa.moe .

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

On the one hand, the Claude code thing was indeed a weird brag, because they took shit performance and made it suck slightly less. It's not in the same ballpark as getting a 2% boost in an already highly optimized system (e.g. Google search results page lets say).

But it was also a tale of simply needing to tell the models what to care about. They built metrics (I'm sure they vibe-coded them) and then told the system to optimize itself to those metrics. And it sort of worked. Of course most LLM code is not performant by default, you still have to prod it to optimize itself. You can't one shot it yet. But nothing about the trajectory of this stuff tells me it won't get there some day soon.

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

Even if LLMs aren’t producing more performant code today, them solving frontier math problems (especially discovering new optimizations) suggests they’re close. You can algorithmically judge performance, and recent advancements have been in the algorithmically judgeable.

>LLMs are not generating better compilers nor better kernels than what exists.

Not LLMs, but AI is inventing new hardware:

https://deepmind.google/blog/how-alphachip-transformed-compu...

I also thought that, and then I started pointing Claude at various projects and having it look for optimizations. The projects themselves were, of course, largely AI-generated. What I found was that simply asking it to improve performance could indeed help, but if I pointed out specific architectural issues - like storing massive graphs in a giant JSON blob - and then recommended a solution (normalize, store in SQLite, recursive CTEs to walk it), the performance ceiling went WAY up.

Now, you could argue that AI didn’t fix that, I told it what to fix, and it just wrote the code. That’s valid, I suppose. The view I’m coming around to is that LLMs do know how to write performant code, but their corpus is so full of garbage that you have to tell it explicitly what you want, which requires you to know how to spot the problems and solve them.

I will not make any claims that they can write kernels or compilers well, because I haven’t tried to do either of those, on my own or with an LLM.

Another anecdote: yesterday, I got tired of dealing with Mumble on my LAN (random audio issues on the Mac clients, poor echo cancellation, etc.) and asked Claude to build a replacement. I gave it a rough spec, including non-goals (private use only, so no encryption needed, and I don’t care about supporting a large number of clients), then told it to build it in Rust, supporting MacOS and Windows both natively. Two hours later, it worked. Not just kind of, it worked flawlessly on Macs and Windows, and the audio quality and echo cancellation was perfect. The only bug I found - which it fixed - was denormal numbers was causing relatively high CPU (~1/2 of a core) usage on Windows due to x86_64 handling of that. The binary is 5 MB. It ran its own echo cancellation training while writing it to tune parameters. It implemented RFC 2198 without me mentioning it (hell, I didn’t even know about it - it’s fascinating!). When I fed it back some logs, it saw that one client had higher latency than expected (meshed WiFi without a backhaul), and then proceeded to create a network simulator so it could test various latency and jitter scenarios to solve it. While doing so, it also determined that Windows was lying about its latency numbers by 25 msec, and addressed that.

So again, I think LLMs are capable of excellent work, you just have to know what you need to ask for.

Actually LLMs are creating better compilers than what exists. In 2 weekends I let a LLM write almost fully compliant re-targetable C23 compiler (except for a few C library related things that are worthless for its targets) with state of the art optimization for five 8 and 16-bit fairly different architectures. For PIC16F/18F it's slightly better than XC8. For 8051 it's waaay better at optimization than industry standard Keil C51, and of course sdcc. Dev process found several pretty startling miscompilations that XC8 is prone to. And it's tiny. Codebase is like 0.5 MiB with data file for all ~1100 PIC microcontrollers that normally take gigabytes in XC8 taking 350 KiB.

So it's optimized both on code/data size needed for the compiler, which is like 3 orders of magnitude smaller. It has better coverage of C23, and it produces smaller, faster and more correct code. :)

Your comment feels like it was written 18 months ago.

A vibe coded typescript compiler runs twice as fast as the one maintained by two dozen people led by some of the most brilliant language and compiler experts out there backed by thousands of open source contributors.

All of that by saying "here's the tests, implement it in rust".

> Your comment feels like it was written 18 months ago.

AI bros have been making the same claim for the last 3 years. It wasn't true then, it isn't true now, and it won't be true the next time either. You just aren't willing to admit the emperor has no clothes.

Previous poster stated ai can't do hard problems.

Yet there's a typescript compiler vibe coded, 100% compliant.

LLMs recently optimized integer multiplication and matrix multiplication beyond the known theoretical limits.

If you tell them to optimize and give them evals and targets, they will optimize. And they will be more thorough and diligent about it than you.

We're all going to have to cope with the fact that LLMs are now better at programming than us. It is professional irresponsibility to not use an LLM in 2026.

> We're all going to have to cope with the fact that LLMs are now better at programming than us. It is professional irresponsibility to not use an LLM in 2026.

As a categorical generalisation, this is absurd. Much depends on much, and the devil is in the details. In certain domains, this might be true, though the word "better" is doing a lot of work there. It is certainly not true in all domains; my consulting practice, where code is written by hand, is thriving, and my clients are mostly AI companies who have discovered the limits of "vibe coding" in this particular area.

Thank you, this is coming close to my own reaction to the article.

Folks reading this: none of this bullshit and hype is inevitable. You don't have to be delusionally enthusiastic about something just because a lot of people around you are.

Absolutely right! Honestly, I hate AI even though it COULD make me 10x more productive in what I do. I can think of a dozen tasks that AI could help me with.

Audio processing for instance: I process audio by hand, it's more of a rote task, and it takes me hours a week to do it. AI COULD give me what I want in probably one minute. One minute instead of one hour.

But firstly, I've built up my audio processing skill over years and I enjoy it. It's calming. It's not creative, thinking up new stuff-type work but it's calming. And secondly, I want to do things myself. I don't want to let a machine do everything so I can concentrate on the high level stuff.

In fact, what I've found is that my mind works best when I'm NOT concentrating on high-level stuff. When I just go about my tasks by hand.

Do I write code to save time? Yes I do. But I write the code by hand and I understand how things work from first principles, as far as possible of course.

So, I don't use AI. AI could take away hours of work for me and I don't use it because I hate it and I hate the idea it represents.

There is no study showing a 10x productivity improvement. There are a few studies showing a productivity decrease.

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.

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

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

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.

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.

I found that since LLMs can produce any code I want, I don't really feel the same drive to learn React or whatever is popular and trendy to make myself useful in a new job. Instead I feel like I have the space to play with something that I enjoy instead, like learning Z80 assembly and writing games for the Gameboy that I would have wanted as a kid. I think you're right that it feels just like going to the gym, intellectually.

Yes, but in terms of your marketability--even in a world with LLMs--it seems to me that learning React or whatever is popular and trendy is quite vital. You can't propose good architectures in /plan or review slop PRs in React without knowing React to a level of depth that could only come from having toyed with it, and thought in code.

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.

I want to be intrinsically motivated too, and I am a good bit of the time. But let’s not pretend intrinsic motivation is an infinite well. We can suffer intellectually from a lack of places to socialize our pursuits.

Francis Fukuyama's "megalothymia" seems relevant here, too.

I could have done many different things as a career - I chose what I do because I love(d) it. I think many of us were raised believing that a job you love is not a job and we’re now grieving the loss of fulfillment that came along with doing something you love and getting paid for it. I spend far more time working for people I don’t know than I do with my family or my hobbies, and perhaps I was foolish enough to think I’d escaped from wasting my life doing something I despise. You are correct that we can all seek fulfillment outside of work, but for those of us that used to get it there it hurts, or maybe it’s just me.

I know things get worse before they get better - but some of us are at the point in our career where we likely won’t be around to see it get better again.

I think you're right. And no, it's not just you. You've tapped into something very central and animating about software as a craft, and the cognitive and psychological feedback that got most of those who are really good at it to be interested in it in the first place. I share your sense that we'll probably not be arounds to see what "better" looks like, if it ever even happens.

This metaphor does fall apart somewhat when you consider that farm tractors are not made from farmhand muscle fibers, whereas LLMs are in fact made out the stuff they’re rapidly replacing.

No, but I think you could tell a sufficiently compelling allegorical / metaphorical story about how farm tractors, in destroying the livelihood of farmhands, might as well have pried their muscle fibres out of their live bodies.

Great sentiment about reserving intellectual heavy lifting to your personal life. I've always valued keeping enough in the tank for myself (and now my family) outside of work.

It seems in our profession there might be less satisfaction from work, but if it leaves me with more space to accomplish things in my own time, I think I prefer it.

If you do intellectual things only in your free time, well, working people don't have much free time. One of the perks of software development (and other LLM-impacted professions) for nerdy types is that it allowed them to do intellectual things all day, and even get paid for it. Now all those hours at work are no longer fulfilling.

> It seems in our profession there might be less satisfaction from work, but if it leaves me with more space to accomplish things in my own time, I think I prefer it.

I wonder why you expect to have more space to accomplish it. What happens when the managers realise that they can get more 3x, 5x, 10x, whatever x more software?

Also, let's briefly revisit the source of all economic value: scarcity. If you can kick your feet up more, you can't expect to be paid as much for it.

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?

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

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"

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

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.

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.

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.

The example provided covered both options.

In general the OP is right, the people who get the most value out of LLMs are veterans.

How large is your codebase?

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?

The new normal involves fewer and fewer humans in the loop. So it's not just that things are changing and we need to adapt, I think the world will be able to get by with a lot less labor (more capital though). It's not like we're losing a fun hobby, it's a living. It's ikigai but more importantly it's food in the table.

Some seem to think we'll just get 10x as much done. But I just don't think there's that much more stuff that actually needs doing. We won't build 10 Google Mapses, and there aren't 9 other apps that have the utility of Google Maps.

(Please debate me on this as I don't want to be right.)

We will build more small mods and variations. Ideally we won’t rebuild the codebase 10 times, but 10 different people would like their Google Maps to be slightly different.

You need to have millions of people using a complicated app in order to find and fix all the bugs, I.e. millions of people sort of share in/amortize the bug discovery load. This doesn't work if everyone has a unique complicated app, which is also sorta what happens if you just allow every UI thing or behavior to be controlled by a setting.

Ignoring that, I still don't think minor tweaks for my own Google Maps adds so much more value that you continue to pay developers the same amount you do now. That is, the value of personalized maps is not 10x generalized maps, so how do the economics keep working?

I also tend to believe that the market for SW developers will shrink. In Europe, the AI revolution is hitting at the same time as an economic crisis triggered by expensive energy which is in turn making companies cut costs / local positions and outsource to cheap locations.

The idea that more SW will be built is likely correct, but it might not be a well-paying job or be done in Europe at all.

I think this is true for some programmers. For others like myself, the change and constant radical improvement is what we loved about technology in the first place. I'm essentially living the dream I had when I was 5 and saw Wargames for the first time. Sure, it was fun to program by hand but now we have AI, which allows us to do even more amazing things and we're very early in the curve there.

> Grief is exactly what many engineers (not just programmers) are going through right now. They (we) are going through the process of coming to terms with the death of something we loved - not a transformation, but death - and figuring out what comes after that.

Very well put.

A large part of that "what comes after" is grappling with the next hard question: after the death of the craft we loved, are we - our skills, our intuition, our problem solving - even needed anymore?

Even if we still are now, will there be a time when there also won't be a place for us?

I believe we're still needed, because AI has no "want", no intrinsic motivation, therefore no real sense of alignment with real-word goals. Without us humans in the loop, the industry would become self-drinking beer.

Whether or not the folks with the money agree with this is another issue...

> AI has no "want"

Have you asked it?

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

Yes, but that other role is a change of career.

> But you might be able to choose to leave that to others, and fill some other role in the development process where you don't have to pretend.

That is abandoning the career.

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.

First, I don't trust the elites to share in the wealth. I expect fuedalism to ensue.

Second, I think what is healthy for humans to yearn for is purpose and meaning, and convenience and idleness are almost counterproductive to that. Ok it's hard to argue with convenience, but nowhere in all of this has AI threatened to make my life more convenient by doing the chores for me, it just takes away fun creative tasks that I can get paid for.

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

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

Please.

Where is the money for welfare coming from if tax from working people is drastically reduced?

I am not sure mastery every truly goes away. But it is given the chance to evolve.

Navier-Stokes…

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.

Not in security, but "vibe coding remediation"--that's the best way I can think to describe it--has been a booming business in my line of work (SIP/VoIP infrastructure engineering) as well.

How long it'll last, I can't say, only that before LLMs, the industry entered a phase of consolidation and quiescence that had me seriously worried about a fade into irrelevance. The delusions of businesspeople and the managerial class about what LLMs can do has fueled a very nice business renaissance, as they run into the limits but have committed to contracts, business models, etc.

Presumably those poorly coded apps were written at least 6 months ago though... Enjoy it while it lasts.

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

This resonates with me. Hard.

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

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

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

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

“I almost get physically ill when there is more code than I can keep in my head” resonates with me, but it is the exact reason that I enjoy working on better abstractions. Not in the “Javaesque” sense, as you call it, but in the mathematical sense.

I’m working intensively with LLMs to find out what they can and cannot do and for all the capabilities in there they remain terrible at compressing functionality into few concepts and as a result they produce incoherent (read Fred Brooks on coherent design!), failure-prone products. In other words: I expect that there will be good demand for people who refuse to let code grow beyond something they can keep in their head, even though the means by which one accomplishes this might be different than what you do now.

Hope that there is some solace in this.

That's the state now. Look at the leaps that were made just in the last few months.

For my work in innovation/R&D the leaps are relevant but more or less orthogonal to what I’m talking about above. I think there is a limit to the consistency and quality that one can expect of software whose surface area scales linearly with the feature set, if that makes sense.

It is tempting to extrapolate the fast progress and conclude that everything will be automated soon, but it still appears to me that LLMs have a “spikey profile”: while very good in some areas, they fail completely in many others, with no evidence that this is only a matter of time.

There haven't been any.

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

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

I don't think this statement implies they meant 'single files'? They could be talking about complex systems that they could fit into their head, and now they can't do that with new workflows.

Perhaps I didn't formulate this too well. Say, rustc is a gigantic program, but the parser alone, or the borrow checker alone, or the LLVM backend alone are small enough to work on individually, and from the perspective of any such unit all the others can be treated as black boxes, deliberately designed to have as small of a public API surface as reasonable and to be as predictable as possible. That's just architecture 101. With LLM code, I notice, such abstractions fall apart, and the interconnectedness, duplicated code, and unclear expectations make it impossible to reason about the result except as a giant lump. Of course, tech debt is nothing new, but at least it used to be held back by the physical inability to make progress once things get dire; with LLMs, this misery gets prolonged.

Yeah I feel this. My strongest passion in computing is simply learning how the machine and OS work. The code I would write would usually be experiments, not projects or tools.

I'm less pessimistic than the author though. There is always room for people who know what they are talking about. Take a deep breath.

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.

Fair, but the real question is what this person's manager thinks, as that tends to carry the day. And at the moment, there is an enormous gulf between what the managerial class believes LLMs can do and what people in the trenches know LLMs actually can and cannot do--not as a matter of current frontier capabilities, I might add, but more ontologically.

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.

That would be cool, given an ample income stream of free money to support this indulgence...

> There is always room for people who know what they are talking about. Take a deep breath.

In the long run, I'm certain you're correct. In fact, "vibe coding remediation" has been a big business boon for us.

But the capital owners and managerial class can remain irrational far longer than experts can remain solvent...

You act as if there's only two types of people, the ones who are competent and the ones who are not. But there are plenty of people who are competent at a certain task, which will no longer be needed soon. It would require extreme hubris to think that you are one of the few who is competent at some task that LLMs can categorically not perform.

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.

Entirely agree with you, but I also lend some credence to the worry that capital owners and the managerial class might not want to pay a six-figure salary for "knowing the questions to ask".

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

ChatGPT doesn't actually know a thing, and will happily give you false information right alongside true information. Using an LLM to provide knowledge is a foolish choice.

This are a lot of parallelisms with LLMs, privacy and perfectionism as well.

I recently watched a movie which is about a young film director who suffers his whole film career because he is trying to make the perfect and the most scariest horror movie there is. While mediocre people with less brilliance and less expertise make better career and success than the protagonist because he is too stringent. Too adamant about things. This has stuck with me. I've read a ton of posts about how perfectionism kills. But to see the protagonists life get completely be screwed kind of hit me differently. I've suffered a lot on social life cos of me being adamant about privacy. The reality is, world moves on. Since then, am open to instagram, am open to less perfect things. More curious about LLMs.

This doesn't mean I stopped being a perfectionist or a privacy nerd or critical about LLM. But they've become my north stars. I work from within the environment than from outside of it. Life is better and positive since then.

I genuinely hope OP reads this and change his life accordingly. Change what we can. Do what YOU can NOW. It doesn't have to be binary. It's not black and white. I've read somewhere that "you suffer more in your mind than in reality". Take it easy. It was too much unnecessary burden on me and I am sure it is on your shoulders as well.

Before anybody panics about LLMs let's just take a deep breath, and see this tech for what it is.

It is a giant interpolation machine. It is very good at remixing stuff, but is is hapless when it comes to novel things.

Consider this: an llm was trained on physics, but the training data was cut in 1904. That is just a year before Special Relativity was published. The LLM was then shown papers of SR, GR, and Heisenberg's paper from 1925 that established quantum mechanics, and similar foundational papers of what we call "Modern Physics".

The LLM has systematically "disproved" all of them, and rejected as false.

So even if you show it a novel idea, it's still going to reject it.

It is by design limited to remix existing ideas.

The recent "novel" mathematical proofs are also just remixes. What I mean it uses two or more established math frameworks together to generate a viable bridge. The result is undeniably a new proof, but not a novel idea.

People with novel ideas will always be needed.

Do you have a citation for this?

Hey, interesting take, could you cite some specifics on the LLM and experiment you’re referring to?

That's more of a straw giant than a straw man at this point.

Even while I certainly don't identify with the same love of details, I do highly value strong engineering principles and even those are under heavy attack from the LLM onslaught - why engineer something fundamentally well at the start if there it is zero cost to fix it later when problems actually show up?

I still maintain some belief that the pendulum will swing back somewhat. We're going to see over time the problems that emerge from systems designed without deep technical oversight - and this will form a new class of expertise in its own right. It will likely still come back to people with an affinity for technical knowledge and principles based design, just in a different form.

> “why engineer something fundamentally well at the start if there it is zero cost to fix it later when problems actually show up?”

Because this is a myth. it is not true that there is zero cost to fix it. LLMs become less effective the more convoluted codebases become just like humans, if only at a different rate.

Is there something about an LLM that makes it incapable of simplifying a codebase? I have only seen that the slop jockeys who wield LLMs most ardently don't seem to care about that, and that older models were worse at everything, including that.

I try this really hard but it seems that getting an LLM to simplify a code base meaningfully is a much harder problem than getting it to output mostly functioning features very quickly.

They are great at adding but reducing takes much more hand-holding in my experience. Maybe this will improve, maybe it does not matter, maybe I am holding it wrong, I don't know.

I tend to think this is mostly because the training set has generally been "low quality code cranked out as fast as possible" and the goal has been "do more of that". After all, most code in general is mostly throwaway. And most frontier model labs are startups where code is short lived.

Different goals/context/training is all I think it takes to change this. Though yes, for now, I revel in my role as the one who can contribute a touch of elegance to the stupid robot's solution.

Edit: and yes, better models, but I think the Sol-generation are already good enough.

What models are you using?

> [...] I proudly called myself a coder as opposed to an engineer. In my eyes, this highlighted the way I focused on the details, performance optimization, knowing the intricacies of the language, and being able to explain how things work, as opposed to juggling Java-esque abstractions.

Ouch. There's an idea that I've seen a few times now that there are two key types of developers: developers who thrive on building products and solving problems through the existence of code, and developers who thrive on the process and the low-level puzzle of getting that code to work and then to work well.

The former are having a really great time right now. The latter are feeling justifiably threatened.

I am in the former group, and while I agree the prospects are not singularly bad and I see enormous amounts of work that will need to be done, I don't think I/we are having a great time. Working harder than ever under unrealistic expectations and general chaos from everones FUD. In my area the need for software is huge but there has never been no nearly enough money. Maybe we can finally build some of it.

I agree that the threat is more specific to the more detail oriented kind of person/role, though.

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

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

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

Thanks for making me feel old

Screenshot of Solaris x86 too.

I feel that pain. My job involves a considerable amount of reverse engineering and software development, and I've always been interested in getting down to the lowest levels and figuring out what's actually going on.

LLMs are becoming remarkably competent at both of these skills. Not quite at expert levels yet but I expect it won't be long until this happens. I'm astounded at what they can do already, with the benefit of relentless, persistent effort on top of this.

How I've been using LLMs is twofold. Firstly, using chat mode to the effect of having technical documentation to converse with. Secondly, using agentic mode to develop tooling to help me with reverse engineering. This includes things like one-off scripts to analyse complex trees of structures, to modules that use the API of a framework I and others have developed, to prototype how we might want to extend it for specific features. I then write the final code myself in my own style, using the LLM prototype as a rough reference.

For now I think I've got a decent balance between using the LLM as a useful timesaving tool and continuing to understand the finer details for myself. I feel I have to draw a line at this point regardless of how competent the LLM becomes, otherwise I'll just be babysitting a black box, which almost anyone can do.

I'm not nearly as detail-oriented but I can certainly relate. The craft I've spent 20+ years mastering is disappearing and I'm not sure if I'll enjoy whatever replaces it. It's reassuring to know there are others who share the sorrow.

It's such a strange feeling. I have a similar amount of time invested as you. I'd always gravitated toward understanding how things work and bringing those insights back to whatever I worked on. Could be low level details, could be software architecture, or some obscure SQL. It wasn't that I knew everything, but that I could descend into the rabbit hole and re-emerge with something useful if needed.

Hard not to see it as tech killing competence in general, and cheering it on.

Kinda wish I'd gone to med school instead. Tech has only shown itself to be more unserious as time has gone on.

Software isn't disappearing - Code is. The craft is more craft than ever and more powerful.

Your job will probably disappear, if it involves creating software.

Having been working on a lot of low complexity code over the last few years I don't really sympathize with the author. I mainly use LLMs for the chores. And there are many many chores in software development. CRUD APIs, validation, yet another DB service, yet another script, minor version upgrades etc. Chores are also very straightforward to review. I do reserve the time to do normal engineering especially for the rare interesting algo and don't get this obsession with how everything must be agentic at all costs. Honestly seems like crypto propaganda all over again. If productivity "really" has gotten 10x doing some tasks without LLMs won't even put a dent in your average dev. output. What I do grieve is a lack of non-AI news. Might just stop following HN for a year or two and wait for the LLM spam to die off.

This reminds me a lot (mostly for worse) of the industrial revolution. The industrialization of textiles didn't help weavers weave better clothes. It displaced smaller, higher quality output with dramatically less varied, lower quality output in much greater quantities, more cheaply. It also dramatically undermined the relative autonomy of weavers and the control they exerted over the structure and details of their own workdays.

What I think we're likely to witness here, or at least what AI investors ultimately are hoping to see happen, is the displacement of code as we know it (often already sorely lacking in quality and craft) not by more of the same varieties of code, but a massive profusion of shittier, more homogenous code. It won't have to win by being better; it'll be able to do that by being cheaper alone. And we're frankly kidding ourselves if we think that doesn't mean a profound deskilling and potentially deprofessionalization across the whole class.

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

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

In my opinion, LLMs are not competing with real programmers because they do different things. The job of a programmer requires a lot of responsibility and understanding. Using LLMs to write code does not help with that.

You may say that they do compete because companies treat them as the same thing and people need to make money, so the companies decide what is what. That is true but the solution should not be to give in to the money, but instead to make the money behave correctly.

What we need to do is to fix the economy, which still assumes that products are physical and hasn't been adjusted for the digital reality we have now, let alone the AI. Money was invented by humans, not discovered in nature, and we should therefore make it do what we need instead of letting it steer us the wrong way.

I've been very lucky that I love both sides, both the "programming" part and the "making things" part. Even then, it's been quite brutal coming to terms that the programming side of things is a chapter of my life that is basically over, at least professionally.

I'm trying to reinvent myself now and learn the other sides of the projects; how to monetize, how to promote my projects, how to "finish them", etc. I understand that's also changing radically since many people are trying the same thing, and with LLMs the market is changing in unpredictable ways, but that's also exciting! I can get so many more things done now that before I just didn't have the time or focus to finish.

I think understanding the details is still important. However, it moves toward the more central parts of the application, where the risk is higher and agentic workflows can’t be pushed as far. I think the author may benefit from specializing in those parts of the system where unattended agentic work is still too risky.

Wrote a post some time ago on how we'd be helped by segmenting and ranking the domains of our systems so we can be deliberate about where we stop short of full automation: https://ljtn.github.io/epiq/blog/cost-of-cognitive-debt.html

Your article matches my own intuition, and there's a case to be made for adjusting our architectural patterns to better compartmentalize those parts of the app we can let an agent go nuts on. For example, could we leave all of the UI to the agent? Or things like the MCP Server implementation of the app? I'm not quite sure where to draw the line yet. I'm quite comfortable leaving unit tests to the agent by now, but if it's user visible behavior, I still find the agent's work to be off somehow. Ymmv, I guess.

Yeah, I guess it is quite hard to tell where the line should be drawn, and we probably need to rely on human intuition and experience. One thing that the article left out that I have thought more of afterwards is that the classification would need to be relative to the enterprise as a whole. So if you are building a gimmick app for a birthday party you might just vibe code the whole thing, including its "core", but if you are a building business-critical sales system for a major company, the impact of something going wrong would rate the core at the upper end of the scale.

I think that, with the amount of vibecoded code of mediocre quality being produced, there will start to be a demand for "hand-made" software that someone took time to make as delightful as possible to use.

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.

Perhaps I'm just daft or slow, but I'm not 10x-ed by LLM usage. It's precisely because the details matter. (And yes, I read the article and it's lamenting the loss of low level machine-level details.) I read the LLM output, it slows me down. I challenge the LLM output assumptions, that slows me down. I stop to step away and think, it slows me down. I cannot run a bunch of simultaneous prompts and supply this same level of mental context to all of them, because my brain works best when I treat it as single-threaded. My experience with this approach to using an LLM has been, so far, positive.

What I have noticed as I've migrated to newer models is that the assumptions made are incorrect less often. But if I don't pay close attention wrong assumptions can still be made. Cross cutting concerns are lost, or written in such a way as to be useless.

So, the loss of details, to me, would be my own laziness in not performing due diligence.

Whatever your opinion of the current state, LLMs are seemingly improving exponentially. You remember where we were a year ago. We can't fathom what it will be like in five years. Maybe even hard to imagine three. Once it hits the point of diminishing return on ability, it will move to speed and cost optimization. And of course everything will get smaller and take less energy in the standard progression. When viewing as a snapshot in infancy we can see the holes. But it's essentially a solved problem that is snowballing now. Not that it won't create other problems. And very likely solve many others.

Exponentially?

I think so. Although it is possible that it is being held back for safety reasons. The same has been true of CPUs and many other advances, but the timeframes were generally longer.

For a brief moment in history, it was cool to be a nerd. That era is over. The era of the nerds began when the IBM PC went mainstream in the 1980s. It peaked in the dot-com era, when, for the first time, large numbers of nerds got rich. That continued through the FAANG era. Now it ends.

There will still be some nerd jobs. Some. Fewer over time. The future is not you telling an LLM what to do. That was the brief "prompt engineering" era. It's an system of LLMs and agents telling each other what to do. Most likely with a bro in charge.

Get used to sand kicked in your face. Or, to quote Orwell, "If you want a vision of the future, imagine a boot stamping on a human face – forever".

Ask someone who used to have a good union job what life is like now.

> “I didn’t care about practicality, building useful programs, or writing code per se: all I wanted is to understand how the machine works.”

Over the years, I’ve transitioned from building “beautiful” stuff to nowadays building stuff that works. I still want it to be perfect but now not for me but for the user. If I think it’s ugly, but the user wants it that way, then who am I to decide against it? They will have to use the software, not me. Seeing a user be happy with the software is super nice. Way more enjoyable than me just making stuff for myself.

Great article, and I 100% agree. I'd even go further than this, and say that the rise of AI has clarified my vague feeling that computing has been going wrong for a very long time. There's a famous article by David Chisnall with the subtitle "Your computer is not a fast PDP-11." [0] I believe it should be a fast PDP-11, and outside of specialized batch processing machines, we should sacrifice performance to make this possible.

Instead of cache, software-managed fast and slow memory spaces.

Instead of branch prediction, memory with multiple read ports/buses and software-managed parallel prefetch queues.

Instead of hardware speculative execution, VLIW.

Instead of automatic DRAM refresh, a hard-real-time OS handling the refresh timing.

I don't care that this would to make things on average slower and more expensive. Modern computers have tremendously fast average-case performance, but the software is still mostly laggy garbage. We sacrificed ease of understanding and didn't even get responsive software in return. I believe that if modern computers really were fast PDP-11s, we would not be in the situation we are now, where most programmers see nothing wrong with software taking some unpredictable human perceptible time to respond to inputs, even when simply processing text. I care more about worst-case performance than average-case performance.

As the article says, "Like a fisherman might feel one with a fishing rod, I treat the machine as a continuation of myself." A fishing rod always responds in zero milliseconds. A computer should do the same. You can say AI is qualitatively different because by embracing it we abandon even the possibility of understanding, but in practice we mostly abandoned understanding already. There's no practical way to count cycles any more.

Of course, most computer users don't care about this, so there's no commercial market for the kind of hardware I'm imagining, but I'd love to see the "fast PDP-11" approach taken to its limit. Let's make computers it's possible to completely understand.

[0] https://queue.acm.org/doi/10.1145/3212477.3212479

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

There's no way back from here. Being able to write a program is just not worth as much as it was to the world and rewards and incentives are adjusting accordingly.

I think there's opportunity to create a niche that fits the author. LLM-generated work has this problem where the details are flawed in a way that makes it good on the surface, and nowadays a bit deeper, but still inferior to the same work produced by a competent human. The dominance of low-level programmers over software could not last forever, but neither can the dominance of this use of LLMs: English is not an ideal programming language.

I've seen people praise broken LLM-generated software in ways they never would human written software that had the same issues. I think the dominance of LLMs will last simply because of the money and social inertia behind them and because people consider them inevitable, so it doesn't really matter how flawed the code they generate is there is faith that LLMs and the quality of what they generate will always improve, and that one simply has to accept it. That faith and tolerance isn't (and will never be) extended towards humans to the same degree.

LLMs aren’t going away, but even though people tolerate their imperfect code and design, there’s room for improvement. Especially because many other people don’t tolerate it.

isn't the person that did the tron typography visuals a regular here?

cool to see it come full circle and see another person thrown into the industry by the work of another forum member.

Imo, the best jobs for people who prefer understanding over building nowadays are those in IT security. Vulnerability research, pentesting, forensics / incident response, reverse engineering... - here the details still matter. LLMs are also coming here ofc, but they don't unilaterally take away the interesting work.

It feels like a delicate psychosis. I can understand it, accepting a change is very very hard for me too.

We are taking away the ability for some very smart people to be engaged with the world in a way that is challenging and meaningful to them while building tools that allow one person to do the work of 10. Fill in the blanks if you want, but this is not good. We must quickly find out how to give people hope for the future.

I too am motivated by a desire to understand how the system works. I never got down to assembly or toy operating systems, but my recent wins have been rooted in an uncommon understanding of how compilers optimize, how CPUs cache and pipeline, and how TCP stacks queue and buffer.

I went through something similar when I worked started working for AWS in the pre-LLM era. I had to learn to let go of the desire and perceived need to fully understand the system because it was just too big

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

The background reads like a strong Caltech admissions essay. Just sharing my irrelevant observation.

I commiserated so much with this post. I feel like I got out of software at just the right time - folks like me that have an inherent need to understand the lower level details feel like this agentic coding world, where there is simply not enough time to even read the code, let alone understand it, is hell.

I left software and went into violin making and I couldn't be happier (though of course I'm extremely fortunate to have saved up enough in my software career to comfortably make the transition). In violin making a tenth of a millimeter is considered a lot and we endlessly stress over details like the corner shape and the f-holes. And while some of this nitpicking is certainly excessive, it serves more as proof to show that we're extremely careful with the details so that stuff that really matters, like tonal quality and playability, will also get enough detailed focus.

What a charming new career path! And you make an interesting point about signaling attention to detail giving a guarantee of sorts that the things that matter are covered as a matter of course.

Reminds me of a friend who would go straight to the restrooms for a quick visual inspection upon entering a restaurant: if those aren't clean, there's no reason to think the kitchen is.

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

> all I wanted is to understand how the machine works.

> [...]

> If an LLM can analyze the code and explain pointer provenance to you and babysit you until you get it, there is little value in expertise.

This sounds like the author wanted to understand not for the understanding itself but to get an edge.

One of my strongest motivations has always been the understanding (mostly of why a thing doesn't work like it should) and I have no trouble accepting AI assisted mode of acquiring understanding because I don't care if it's worth anything to anybody that I understand.

I draw pleasure from understanding. I don't build my value on understanding. I don't grieve anything. I'm elated that I have a virtual person smart enough to explain to me the things I'm interested in. Before I felt like I had too seek water in the vast desert full of dust and prickly things. Now I have plumbing and the same thirst.

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

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

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

> Last time I tried using an LLM for a pet project, I realized that the LLM would come to know more about it than pretty much any person I could show it to.

I was quite reluctant to show my own code to AI. I was doing greenfield experiments for months before I gave AI anything that contained any code that I was proud of.

But when I did, it understood it very well, better than any person I could show it would be able to. And extended it very well. My programs, even the most complex ones became way better and did more than I could ever hope to achieve myself.

Basically at this moment I had to conclude that LLMs might be better than a developer with 20 years of expeirience. This was more than half a year ago at this point.

> and performance optimization are being infested by LLM fans that seek recognition rather than the experience

The death of every sub culture in a sentence.

at the beginning of the 20th C when ford implemented the moving factory line, experienced mechanics disliked the new way of doing things but did it because it payed well. they werent using a lot of their skill set and their job could be replaced relatively easily. many many industries in our current economic system will be facing this now. if you can tell me which ones are immune im all ears.

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.

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

How did this come around? the young developer was just faster overall? or were they cheaper?

I think part of the grief is losing the way we learned to do something we loved. Most people care about what software does, not how we made it. The hard part is accepting that what makes the job satisfying for us isn’t always what makes the result useful to others.

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

You're freaking out over no big deal

It's great that she takes joy in his work, and sad that economics is pushing her to focus on different details with less joy. But the same can be said for a horse groom who loves her work being pushed to transition into a mechanic. Change sucks, but less than petrification.

“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

Reply on news.ycombinator.com