Yes, good name and I also feel that was a major inflection point. Up until then I found all AI models to be terrible at programming, with the difference between GPT o3, Sonnet 4 and every other model since GPT-3 being just the exact flavor of terrible they were.
November 2025, with Opus 4.5, was the first time I was impressed by an LLM doing something non-trivial with a reasonably good level of quality.
Yes, and Qwen 3.8 27b is a similar inflection point for local, although I wouldn't claim it's quite as good as Opus 4.5 it is genuinely useful. Whether that actually matters will depend on whether it ever becomes the most cost-effective tool for the job, but it's impressive as all heck
Yeah before Qwen 3.8 27b all local LLMs did feel like not very smart chat completion models. You would hit the limits of their intelligence all the time. Chatting with Qwen 3.8 is night and day, and it can do some pretty damn good coding and agentic work for its size. IMO its better than where frontier labs were at about 18 months ago, which is mind-blowing for a small locally hosted model.
I love displays from space vehicles and nuclear plants for the same reason. Data and controls organized in a dense but presumably highly usable manner. And it covers the more specific view of an expert in a particular subsystem, as well as the higher level view of those responsible for the whole system.
I remember seeing glances of the Mission Control screens during the Apollo and early shuttle program - two screens and two channel selectors where the programming would be a screenful of real-time data rendered in the adjacent RTCC (real time compute center, or something like that) and captured by slow-scan CCTV cameras and piped to the consoles as TV signals.
> Many of us, deep down, are driven more by the joy of making things, solving problems, and seeing people use what we built than by the act of coding itself. After all, many of us decided we wanted to be developers before learning to code, just to create video games or websites. The desire came before the code.
This is a big disconnect that I think has been at the root of many different reactions to LLMs lately. Here on HN I see a lot of "I hate what LLMs did to programming" and equally a lot of "LLMs are awesome, I've never had a better time". I think the disconnect is between people who build software for the end result (having users, the joy of completing a thing, etc) versus building it for the process itself (architecting, coding, debugging).
I'm mainly the kind who enjoys the process. I think of an awesome startup job I had that solved real problems for real customers including some really big firms, but I can't honestly say I ever cared about those problems or the customers. I loved the job because it was technically challenging with a lot of freedom, and the customers were great because they were a source of new interesting details to solve, as well as confirmations that the previous solutions worked.
As such LLMs make me sad because they effectively replace a lot of what I like doing. Doing a refactor to support a new feature, digging through the code to try and understand a bug. One of my strengths as a developer, I think, is that I am fast at familiarizing myself with unfamiliar codebases. That's also a somewhat redundant skill as Claude can answer "how does feature X work in this code" in a small fraction of the time it'd take me.
A few years ago (before the LLM craze) I moved to game dev as my main job, which makes a lot of this easier because I actually care about the end product and the customers (players), so that's a whole new layer of satisfaction in addition to the usual technical one.
Which isn't to say that it's all bad. I've used Claude to get a few things done where I mainly care about the final result and not the process. There was one such project I wanted to get done, I'd had the idea and the data for five or six years, but I found that the implementation would be time consuming, often manual work and much of it involving the kind of tech I don't really enjoy. So I never worked on that but last month, I did the whole thing in a few days with Claude and got exactly the result I wanted.
I've been seeing things the exact same way. There are those that want the end product as fast as possible and there are those that love the process and the struggle of getting there. The former group is the ones telling the latter group that they'll be left behind.
This can't be the first time you're seeing such use of Я? It's very commonly used in Western typography / graphic design as a symbol to invoke associations with Russia. It's not being used as a Cyrillic letter, it's being used a "think of Russia" and people unfamiliar with Cyrillic will mentally associate it with R so TETЯIS is easily read as "tetris". Even if yes, people familiar with the alphabet find it harder because the first reaction to Я is to in fact read it correctly.
Same with Σ being used as a "think of Greece" symbol that people from Latin-script languages are expected to process as E, leading to "brilliant" designs in GRΣΣK. Or how the Chinese character 山 would remind a Russian speaker of Ш so ПО山ЛИ would be easy to read.
I'm in game dev but I also have very poor abilities for mentally operating on visual or geometrical data. I'm normally far away from the graphics parts but sometimes I take a look and shaders are by far the least intuitive type of code to me. I've learned enough about what shaders do to sort of parse the simple ones, but anything with shaders definitely feels like working against my brain's natural tendencies.
However, protective equipment is taken seriously and then shoes stay on. Here in Sweden, of course ordinarily all shoes are taken off (for 8-9 months of every year they're wet and dirty) but if workers come in to do some work, they keep their shoes on because they're protective equipment. If you're having them come during a particularly dirty time of the year, you may want to cover your floor with newspapers or give them shoe covers.
I also suspect comments are very much tied to how Claude reasons because not only are they bad comments, I can't get rid of them. Commenting is the one area in which I've been unable to get Claude to respect any rules. It can follow code conventions I prefer, it can do other things, but it can't keep the comment volume down.
My CLAUDE.md has rules about not including any redundant comments in the code that are obvious from the code itself. I reiterate that occasionally while working. It's absolutely disregarded and any Claude-written code is full of comments. Some of them are simply redundant, like "Collect Foos and pass them to the requested sink" on a function that's void CollectFoos(IFooSink sink). But worse, many comments include in the moment reasoning like "added parameter bar because we can no longer use the frob to automatically derive bar". That's stuff for a commit message, or just a mental note, and absolutely not for comments.
I haven't found any way to stop Claude from doing these, so I have to tell Claude afterwards to clean the comments up. Which it does, making a note in memory to comment less, and it still does the exact same thing next time.
> Commenting is the one area in which I've been unable to get Claude to respect any rules.
Exactly my experience! Since the release of Opus 5, no amount of instructions helps. In CLAUDE.md, in a separate file, in memory, as brief bullets, as long detailed guides, with reasoning from medium to max — nothing.
Even worse, recently, after getting another opus in a tiny bugfix session, I prompted directly, "drop the comments from the current code changes" — Claude instead just slightly trimmed them. I couldn't believe my eyes.
I have a relatively low bar for prose, could live with some junk. But Claude's comments are _poisonous_. They always require maintenance, instantly become out of sync with the actual code, and are a token black hole — for all agents, but especially for Claude itself.
Gave up and canceled Anthropic subscription yesterday. To my taste, it has become unusable for coding.
> Even worse, recently, after getting another opus in a tiny bugfix session, I prompted directly, "drop the comments from the current code changes" — Claude instead just slightly trimmed them. I couldn't believe my eyes.
For me, Claude knows how I want the comments due to all the memories and CLAUDE.md, so funnily it's now enough with even a brief groan from me like "Come on, the comments" and then Claude goes through its recent additions and fixes comments quite well per my long-term instructions. But only ever during an extra pass that I initiate, never during the initial writing of the code.
> But worse, many comments include in the moment reasoning like "added parameter bar because we can no longer use the frob to automatically derive bar". That's stuff for a commit message, or just a mental note, and absolutely not for comments.
I've noticed this a lot, and before your remark I couldn't put my finger on what was wrong. Now I know: Claude is writing its thought processes and maybe parts of the conversation it had with you as comments in the code!
I always end up manually trimming those comments, which is cumbersome.
It also loves to reference internal notes and scratch docs that never go into source control, so a reader will have no idea what it’s talking about. For example:
// load_tree() loads the binary tree with data, but only the recently updated data, not all data (INTERNAL_NOTES.md section 4)
Ok but nobody reading the source code knows what this doc is. You don’t have to cite it.
I wouldn't generalize Europe like that, our differences in the normal schedule are massive from north to south.
Here in Sweden, it's a morning culture. Blue collar workers often start work at 7, daycare is open from 6 in the morning for parents with early jobs, dinner is at 18 or even 17 for people. At 22, most places are closed including supermarkets and restaurant kitchens. Lunch for the vast majority of working people is at noon.
That is totally different to a country like Spain, where you see families - with kids! - start dinner at 21 or later. In Sweden people would say it's strange not to have your kids in bed by then. Lunch is at 14, cities are full of life until midnight every day.
A large part of that is probably due to daylight hours. A big chunk of Sweden is dark by 16 for the winter half of the year. During November-January there's minimal light and it's gone by 15.
> Even if you deeply into tinkering, 1 can be an insanely exciting and rewarding step: for example "how could an abstraction look like in which 2-4 become trivial special cases for many classes of programming problems?".
Yes, but I think there's really two different definitions of point 1. It's "figure out what non-software problem you can solve with software" vs "figure out what technical problem to solve".
As the tinkering type, I also find 1 very rewarding but using the latter definition. Exploring a sizable code base and finding the part that, if simplified, cascades to a lot more simplification, that's very exciting. Figuring out what problem some companies or people have that could be solved? Very hard, very unexciting, not rewarding.
> Yes, but I think there's really two different definitions of point 1. It's "figure out what non-software problem you can solve with software" vs "figure out what technical problem to solve".
In my opinion these variants are not very different:
For example keep in mind that physics is basically a descipription of the software that runs reality, which automatically gives you are huge portfolio of potential problems. :-)
For mechanical engineering, observe that the advances in 3D printing and home CNC milling mean that a lot of problems that were previously in the domain of mechanical engineering now become partly software problems.
Or for more "human" problems: If you are very trained in mathematics, you start to see mathematical structures in a lot of "more human" problems (or areas that are not associated with "software") basically all the time. If you find these mathematical structures that you see interesting, it is often possible to turn them into software.
Thus, "figure out what non-software problem you can solve with software" vs "figure out what technical problem to solve" is rather a litle bit like "in mathematics: do you prefer analysis or algebra?" - yes, they (often) represent a different style of thinking and many mathematicians do have their preferences, but in the end both analysis and algebra is mathematics.
--
So, I disagree with your point
> Figuring out what problem some companies or people have that could be solved? Very hard, very unexciting, not rewarding.
In my opinion the boring part is not finding or solving problems that companies or people have. As I wrote: after some time, you often start to see highly interesting, often very novel mathematical patterns in these problems (of course not always, but it is not an uncommon situation). Why are these patterns often so novel and interesting? A heuristic answer in my opinion is: if they weren't, someone would typically already have implemented them in software. :-)
The really annoying part is rather convincing the people/company of your solution (which can be considered to be part of step "5) You ship/deploy/publish the program. This means you see people be happy users and/or you get paid for it and so on.").
Yes, it's a very well written, touching tribute and I think it's all the more touching when you're familiar enough with Wolfram's writings to notice the contrast here.
It's one of the most beautiful things I've ever read in my entire life. The reader departs both fallen in love with Elise and tragically heartbroken. Excuse me while I go cry some more in the laundry room, collect myself and annoy my wife with a huge hug.
November 2025, with Opus 4.5, was the first time I was impressed by an LLM doing something non-trivial with a reasonably good level of quality.
reply