Posted by signa11 4 days ago
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, 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.
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. So I want to bring both to the table.
And the better you are at pointing the agent at the truly-important parts, the better the agent's gonna be at finding shit you missed.
You both have anecdotes. Anecdotes don’t “cancel” each other out.
Here’s a third one. In some of the code reviews I’ve encountered that AI gives a lot of feedback, it’s just providing noise. Things that should be ignored or when following the feedback causes more harm which requires more token to “fix” later on. That can also happen. Sometimes the thing it spits out goes against the common sense, and sometimes it works very well.
> So, to anyone who insists on trying to keep up with AI, I say: good luck.
This I agree with, for a different reason. It’s like trying to swim in a sea of honey and trash mix. It’s exhausting.
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?
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.
You could potentially ask an LLM to explain it, but I would venture a guess that wouldn't feel like the right source to help you. You could use the LLM to help you identify source material written by humans in order to learn anything new. It doesn't have to "do all the work for you".
Modern AI systems are powerful. They are not omnipotent or omniscient. Understanding the details is still valuable, especially if you want to push the frontier of any known field.
In any event, the situation isn't hopeless. At least not yet. :)
You can ask frontier models with all the bells, whistles, language servers etc to give you every example of X. And it gives you 12 examples and says that's all of them. When you know damn well there are at least 40 (but not exactly how many). So you say no, you know it has missed some, such as X23, and X27. So it goes away and comes back again and says yes, there are 41 X, here they are. How much digging should you do to see if its right?
I have many times gone looking myself to find that it has still missed some. Asked it to go check for those, to look harder it goes oopsie and says now im sure ive gotten all of them (has it?)
All this to say, I have been burned, repeatedly, multiple times a day, for the last year+. I still use these tools, but I truly cannot understand how some people treat them as oracles that know everything about our codebases
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.
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.
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.
When an API says it takes something, I need to know the exact form of that "thing". Saying "you can give it this object" doesn't suit me because where are the edge cases, where are the interactions, how can I know for sure I'm giving it what it needs. The docs never tell you where to find the object def, then you spend 3 hours diving into the source code to understand it's just a two item struct or something.
LLMs introduced an explosion of complexity, suddenly code bases sprout out of nowhere, and there's no point in following all the different datapaths through because the guy who loves testing out the latest claude will just change everything in a few days anyway.
With low level programming, nearly everything is just raw data, aligned to meaning. I like to tell juniors confused about file types, that file types are a social construct, they're just a bag of bytes with some structure. Same thing applies with low level programming. You know what a byte is, you know the endianness, the signedness, you can feel comfort in knowing you're not missing anything, and then you build up from there seeing each block build upon the previous.
Working on platforms of sufficient scale, there’s a lot happening that’s out of your control. You can build the mental model around it, but it will contain a lot of black boxes where an abstraction hides details.
Generated code changes this, probably, but I’m curious by what degree.
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.
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?
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 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.
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.
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
The "abundance" is not all positive valence. It is a flood of superficial good with an unmanaged ratio of negative byproduct mixed in.
Some of the "change" is not merely doing things a bit differently. The LLM flood is effectively attacking existing feedback and control mechanisms without any attempt to establish appropriate replacements.
I think there are several more dangerous sentiments coursing through civilization these days:
1. That people bear no moral responsibility to act in good faith, and the corollary that one can enjoy the fruits of production while externalizing all the liabilities.
2. That strategies like "move fast and break things" and "fake it until you make it" are universally applicable and appropriate, rather than only in the low-stakes entertainment/media/marketing fields where they flourished in recent decades.
3. That mere acquisition of capital gives one the right to perform N=1 experiments on global civilization, the economy, and the enviromment.
There are definitely transient upheavals as civilization adapts to the new norm and we can do much to reduce those effects.
But the end result is the same, more of everything made cheaper for the working class.
We are at the tail end of a 50 year productivity plateau and rising costs. We’re looking down the barrel of the first reduction in the QoL for our kids. I for one want to see what this tech has to offer.
I’m talking housing, infrastructure, shipping, medical care, all critical services and sectors where fixing decades of lagging productivity will help the working class the most.
I mean, just look at the sequence of events you’re expecting here:
1. Ai companies achieve their stated goals
2. ???
3. Housing, infrastructure, medical care, etc get better for the working class
Are you the king of the underpants gnomes or something? How could it ever turn out this way? Why does anyone think it would? Am I taking crazy pills?
If those goals are fully eliminating need for human labor, then I agree it probably won't be good for most people. But that will probably take at least decades.
Anything short of that, and I think economy will be pretty similar to what it is now. You still need working class and need it to be productive, so you do need them to be reasonably happy, housed, healthy, and you need good infrastructure. With lower cost for all this, why wouldn't things improve, like all times throughout history?
No I’m just at the frontlines of this so called “replacement” and all I’m seeing is people doing more with less with no possibility of replacement. I have no idea what all this marketing pablum about TAM replacement is. All I’m seeing is growing businesses serving more people with less resources.
Could it be that CEO’s of struggling businesses are lying about why they’re doing the layoffs? Why are we suddenly believing them on this one issue?
… is a pretty grotesque straw man, but sure, fight it if you want.
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.
Because he's arrived at the final stage of grief and is ready to move on.
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.
No it hasn't. It's been about making bomb-ass simulations and cool games and stuff.
Even when software has been used for automation it's been done to eliminate boring labour, not creative work. Eliminating jobs like switchboard operators or coal stokers is a good thing because those were unenjoyable and even dangerous jobs that nobody wants to do.
Of course it did. Cars and motorcycles used to need to be taken to the mechanics all the time. Now they just run and run without issue, thanks to what you mention.
> All this stuff gave us more than we had before
Absolutely. Just like all automation. It takes away jobs, but increases production. That's why it's worth it in the end.
> Even when software has been used for automation it's been done to eliminate boring labour, not creative work.
Yes, and now AI is eliminating the boring labour of programmers. Will they come to terms with the fact that their jobs are unenjoyable and nobody actually wants to do them, like the coal stokers and switchboard operators?
But I agree with you that there are some outliers within programming that go beyond automating jobs and processes. Like the examples you give.
The whole thing was quite functional, and a few thousand lines total, and built a bit naively - the framework and the app were under 10k lines combined total.
Later I tried rebuilding it for Win32, and it ended up being more code (sans bespoke UI framework), and I'm not sure it was better, though I'm certain, the whole mass of code doing the thing was an order of magnitude more.
If I were to attempt building it in Electron, I could add 2-3 orders of magnitude to that easy, all for the same basic functionality.
All I'm saying is abstraction isn't really what it's cracked up to be.
I 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.
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.
Libraries are the last time americans agreed on basic principal that a public space with a public good is worth investing in everywhere.
Why is america so much against public services in general?
It comes in lots of flavors but it all is a facade against allowing black people benefits.
Bold of you to assume.
Those are unfortunate examples. The US doesn't do them very well compared to other OECD countries.
Are you thinking Southeast Asian countries, or European, or what?
It's still valuable to deeply understand parts of a program, but we don't have any tooling that helps us do that. We just have to raw-dog it by thinking really really hard and remembering how all the code connects together.
I want a tool that gives programmers a place to record their thoughts. Developers need a place to draw and write, and also interleave blocks of code that automatically update to match the actual state of the code.
The closest thing I know to this is org-babel, part of Emacs, which allows you to push code blocks out of an org file into an actual source files, or pull them in from actual source files. This is mostly done manually by invoking functions called `tangle` and `detangle`.
I intend to investigate this further in Emacs, since I'm an Emacs user, but Emacs is never going to be the friendly UI we need to make this tooling common.
I 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.
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 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.
Now, when someone sends a working PR in, even high quality and well tested, they may actually have no idea how it works.
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.
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.
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.
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.
Could be just defining the methods without filling them but depending on the mood I code more by hand or less.
Which is frankly exhausting to do when you have to keep up with the rate of LLM changes
Or at least that's the current model I'm playing with.
I could change a whole UI completely in 30 minutes to something fundamentally better but then 30 people would all wake up and be upset they weren't consulted and need training for it. That training and consultation will take hours and hours. And probably generate feedback - some of it correct, some of it misguided - that needs to be human negotiated, taking more hours. The effective maximum rate of change is limited so dramatically more by other factors than the technical implementation that we have to completely redesign process now to cater to those factors.
We are in a weird space now because most of the process is still built around a presumption that technical implementation is a lot of work. The main reason to be upset that you weren't consulted about a change is because there's a presumption that you will be stuck with it - ie: it's a lot of work to change it back. But it isn't a lot of work, it's effectively free. All this is just living in inertia right now.
A is what you're used to, B is what I recommend. If I can convince people to start using B instead, I can look at the metrics for A and conclude that it's effectively dead, and then I can remove it.
It's working out for me, but maybe not a fair comparison because I only have something like 15 users.
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.
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'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.
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.
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.
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.
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".
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.
> 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.
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.
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 said what you can't. I said you didn't.
LLMs are not very good at performance issues unless you walk into it with a clear idea of the likely root cause and the bigger picture regarding actual hardware and desired customer experiences.
"Please make the code go faster"
vs
"I am noticing what appears to be contention between threads under workload A, B & C, but not with workload D".
These are completely different universes of capability and outcomes.
Even if an LLM can fight its way to the answer on its own, you can achieve a specific desired result much faster and with significantly lower risk if you are genuinely an expert.
I've seen a concrete example of this recently. I profiled the client's product "the hard way" and arrived at a change to a single line of code that would eliminate a mutex issue. One of the client's developers used the LLM and wound up with a change set that touched hundreds of files, but otherwise achieved approximately the same performance fix. The other developer even had my hint that it was a single file change and couldn't figure out how to do this despite prompting a leading edge model regarding this exact possibility over and over.
Taste and aesthetics apply to absolutely everything. Not just UI/UX design. Perhaps it is even more important that we care about the things that are invisible to the customer. It is certainly easier to forget about them or treat them like they don't matter as much.
You’re probably limiting the frontier models by being specific.
I do feel there is a limit to LLM-s today. I did not try, but I doubt it will work if I would tell it "make me a web browser that is bug free, perfectly secure, works as efficient as possible on my architecture and has best UX for me personally".
Knowing where that limit is, is as hard as it always was knowing how fast a team of engineers was going to do a project.
I felt there were limits 4 years ago. I couldn't get even an 8k context window.
It's starting to feel like the important gaps are the only ones left that need to be closed before there aren't any left. It also feels like next year they will start meaningfully closing.
I do feel there is a limit to human-s today. I did not try, but I doubt it would work if I asked literally any programmer I know "make me a web browser that is bug free, perfectly secure, works as efficient as possible on my architecture and has best UX for me personally".
Hell, I'm willing to bet they'd fail at this task even with an unconstrained snacks and kombucha budget. Humans have a long way to go. My job is safe.
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.
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.)
In general the OP is right, the people who get the most value out of LLMs are veterans.
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.
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.
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?
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?
Whether or not the folks with the money agree with this is another issue...
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
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.
The problem with this outlook (not with you personally) is that the increase in accessibility for you comes at a cost, but the way things work these days the cost is not paid by you but by someone else — someone you'll probably never even meet. The cost has been abstracted away from you and foisted onto somebody else against their will. This shows up as people adversely affected by local data centers (increased pollution, higher electricity prices), people displaced in the workforce (author of the article), people of the future who will not understand things because it's easier to skip understanding for now (students, early learners), and so many more.
It's very liberating — so long as you are given the ability to not think about the consequences for these other people, and the abstraction process by which AI companies are providing their services gives you that freedom by design. At the very least, it is something about which you perhaps ought to be wary.
I 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.
But there's no reason for us to be angry about it or resist it, of course
I'm not into it. Go ask Claude instead. It has more patience for this sort of ignorant attitude than I do.
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.
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 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.
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.
Change doesn't happen until we are at the absolute brink of IMMEDIATE catastrophe.
I think you might be viewing AI and humanity as a zero sum experiment. It's really not. Go read some David Brin (Existence is a good start). We don't know all the positive and negative aspects to come, but we aren't in a dark forest situation. Existentially, AI is here, what are we going to do with it?
And I’m wondering if this isn’t the enormous amount of organizational debt from having security second to everything finally coming calling.
I’ll give you an example of one that was written recently actually.
The initial compromise happened because the app explicitly did not verify auth claims when a specific string was in the ISS field. Well, fuzzers exist and are common.
The next issue was that once you’re in, there was no delineation between admin and regular users. Everyone had all privileges if they just made the calls.
Anyway, we did the usual post-remediation investigation and write up. The devs were of course using the latest models, as they were instructed, and the issue stemmed from a problem they’d been having integrating a specific company into their auth scheme.
Eventually, after many enumerations, the model opted to just skip auth altogether if that companies ISS was present. The devs, being in the habit of just accepting the changes did so and because of the nature of the code implemented nothing caught it in the pipeline.
This is sadly an incredibly common story and it won’t be fixed by models improving I don’t believe.
And yeah, I agree, there is no bottom anymore.
I _am_ a craftsman - software, wood, and a few more domains. There is a lot of personal satisfaction I find in woodcraft through the motion and the exercise. I love that this is a luxury hobby instead of a personal necessity. The difference there is that if I take my time on personal necessity where the market isn't paying for it, I may take food out of my kids' mouths or lose the roof over their head. Luxury craft hobbies face only self-imposed pressures.
AI is letting me build similarly. I can continue to craft my Rust and my Python and my Typescript and my Fortran to my heart's content - and those skills help in the day to day - yet I'm also able to compete in the market and build things that were really infeasible before.
How are you keeping your “human” addition to the loop valuable, is it through the time spent on the software craftsman hobby?
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.
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.