Unlurker

Claude Code creator says Claude wrote all his code for the last month (twitter.com)

Claude Code user¹ says Claude Code wrote continuously incorrect code for the last hour. I asked it to write Python code to retrieve a list of Kanbord boards using the official API. I gave it a link to the API docs. First, it wrote a wrong JSONRPC call. Then it invented a Python API call that does not exist. In a new try, I I mentioned that there is an official Python package that it could use (which is prominently described in the API docs). Claude proceeded to search the web and then used the wrong API call. Only after prompting it again, it used the correct API call - but still used an inelegant approach. I still find some value in using Claude Code but I'm much happier writing code myself and rather teach kids and colleagues how to do stuff correctly than a machine. ¹) me

It shows, I have to kill it forcefully over 10 times per day.

> I landed 259 PRs -- 497 commits, 40k lines added, 38k lines removed I wonder how much of these 40k lines added/38k lines removed were just replacing the complete code of a previous PR created by Claude Code. I'm happy that it's working for them (whatever that means), but shouldn't we see an exponential improvement in Claude Code in this case?

One dives deep into to the philosophical here, but how different is that from ”I recompiled the code, which removed 500kloc of assembly and created 503kloc of assembly”

No one says that as a linkedin metric though.

"If the AI builds the house, the human must become the Architect who understands why the house exists." In Japanese traditional carpentry (Miya-daiku), the master doesn't just cut wood. He reads the "heart of the tree" and decides the orientation based on the environment. The author just proved that "cutting wood" (coding) is now automated. This is not the end of engineers, but the beginning of the "Age of Architects." We must stop competing on syntax speed and start competing on Vision and Context.

Taste, Aesthetics, Gestalt Synergy now matter more.

Precisely. AI optimizes for "Accuracy" (minimizing error), but it cannot optimize for "Taste" because Taste is not a variable in its loss function. As code becomes abundant and cheap, "Aesthetics" and "Gestalt" will become the only scarcity left. The Architect's job is not to build, but to choose what is beautiful.

>Taste, Aesthetics, Gestalt Synergy now matter more. The AI is better at that too. Truth is, nothing matters except the maximal delusion. Only humans can generate that. Only humans can make a goal they find meaningful.

View the full thread without Twitter/X account: https://xcancel.com/bcherny/status/2004897269674639461

Cool, the person who financially benefits from hyping AI is hyping AI. What's with the ad here though?

The tweet from Dec 24 was interesting, why is Boris only now deciding to engage? I refuse to believe real AI conversations of any value are happening on X. Hi I'm Boris and I work on Claude Code. I am going to start being more active here on X, since there are a lot of AI and coding related convos happening here. https://xcancel.com/bcherny/status/2003916001851686951

honestly i've been becoming too lazy, I know exactly what I want and AI is at a point where it can turn that into code. It's good enough to a point where I start to design code around AI where it's easier for AI to understand (less DRY, less abtractions, closer to C) And it's probably a bad thing? Not sure yet.

It is not bad. It is mastery. You are treating the AI not as a tool, but as a "Material" (like wood or stone). A master carpenter works with the grain of the wood, not against it. You are adapting your architectural style to the grain of the AI model to get the best result. That is exactly what an Architect should do. Don't force the old rules (DRY) on a new material.

Not sure why you are getting downvoted, but this IS the key worry: That people lose contact with the code and really don’t understand what is going on, increasing “errors” in production (for some definition of error), that result in much more production firefighting that, then, reduce the amount of time to write code.

Losing contact with the code is definitely on my mind too. Just like how writing can be a method of thinking, so can programming. I fear that only by suffering through the implementation will you realise the flaws of your solution. If this is done by an LLM you are robbed the opportunity and produce a worse solution. Still, I use LLM assisted coding fairly frequently, but this is a nagging feeling I have.

No. LLMs can only reorder what they've seen in training data in novel ways. Humans can have original ideas that aren't in their training data. As a trivial example, John Carmack invented raycasting for Wolfenstein 3D. No matter how much prompting you could have given an LLM it could never have done that because there was no prior art for it to have been trained on. In pragmatic terms though, innovation like that doesn't happen often. LLMs could do the things that most developers do. That said, I don't agree with the notion that LLMs are simply generating content based on their training data. That ignores all the work of the AI devs who build systems to take the training data and make something that creates new (but not innovative) things from it.

Humans can have original ideas because they forget 99% of their input. I am of the opinion there are no original ideas. Most of what most humans do is just remix and reshaping like a potter shapes the clay.

> John Carmack invented raycasting for Wolfenstein 3D. No. He merely reimplemented it.

↙ time adjusted for second-chance

I stayed in a $40 capsule hotel (London) (cnbc.com)

This is dystopian: > Workers who moved out of London for remote work are under pressure to come back to the office in the city, and some are choosing to stay in Japanese-inspired sleeping pods for just £30 ($40). People that could be living in human friendly spaces are being pushed to live in a tube for no significant reason other than the whims of the wealthy. Even setting aside stuff like fire hazards or claustrophobia, notably absent from this is the ability to lead a social life inside: no place to bring a partner or a group of friends. Your time will be spent at work or recharging for the next work day.

I checked the website and the cheapest I could find in 2026 is 64 pounds with most of the days going +100 edit: checked wrong location, only 1 of the locations has capsules and it is 27 pounds as advertised

I just checked this link and every day in Jan was under £40 https://zedwellhotels.com/locations/london/piccadilly-circus/zedwell-capsule-hotel/ Edit, Jan 1 is £48

That's weird, I can see plenty for £27.20 all across January.

I’m not claustrophobic, but looking at those pods makes me anxious. You’re one air con fuckup from asphyxiating on your own CO2 by the looks of it.

Would be unpleasant, but asphyxiating from gradual CO2 increase isn’t really possible unless you’re dead drunk. Your body measures CO2 (not O2), and will escalate to full-blown panic will before it’s particularly dangerous. You’d leave on your own.

In Japan, these are often "Sleep off a drunk" hotels. They aren't really meant as regular accommodations; which seems to be the point of the article. My biggest worry about these types of places would be safety. A fire could be horrifying.

I love the idea, I don’t expect people are respectful enough for it to work where I am, I’d be worried about being stuck next to somebody watching videos on their phone at full volume all night. Also Choose a cosy London capsule hotel in a shared dorm for a sociable vibe, meet like-minded travellers, and swap stories or book out an entire dorm for a private group adventure. This is literally the opposite of what I would want. It would be great to see a privacy and rest focused concept for this, which is what I associate the Japanese ones with, a place for exhausted salarymen to get some quick rest, rather than a backpacking hostel. Nothing wrong with the latter if that’s your thing but it’s not going to appeal to anyone over 25.

↙ time adjusted for second-chance

Growing up in “404 Not Found”: China's nuclear city in the Gobi Desert (substack.com)

My grandfather, who is a nuclear scientist, and my mom also come from a small closed-off city in Siberia (Russia). Visiting my grandparents I remember we had to go through a sort of border control to get there. My mom told stories of how the government would change the asphalt every year in that city to cover the nuclear dust.

Nice read!

> I was born in 1991, thirty years after China’s first atomic bomb explosion, and right around the time of the dissolution of the Soviet Union. I smell cooked

That's exactly why I wanted to write this story. It is surreal to think that while we worry about parking spots today, a generation of brilliant minds was working under the barrel of a gun (sometimes literally, as you described). The tension between the 'Red' (political) and the 'Expert' (technical) was a defining tragedy of that era.

Korolev's story comes to mind instantly. Not only his of course.

Hi HN, OP here. I grew up in "Factory 404," a secret nuclear industrial city in the Gobi Desert that officially didn't exist on public maps. This is a memoir about my childhood there. It was a surreal place: we had elite scientists living next to laborers, a zoo in the middle of the desert, and distinct "communist" welfare, all hidden behind a classified code. This is Part 1 of the story. I'm happy to answer any questions about life in a Chinese nuclear base!

Since you mention a trip to Beijing, I wonder what the security precautions were to keep the secret base secret. I assume visitors from other cities would need to apply for a travel permit similar to the one still required for some border areas in Xinjiang and Tibet, but were there also restrictions on people leaving?

I just wanted to say ‘thank you!’. This was a really interesting read, looking forward to the next part!

Thank you for sharing these memories. I'd be very interested to hear any thoughts you might have about Jung Chang's book "Wild Swans". I read this book a year or two ago and learned a lot from it, but I also learned that many people who grew up in China take issue with the author's account. I'd be grateful for any remarks you may be able to share.

A new research shows that 21-33% of YouTube's feed may consist of AI slop (kapwing.com)

I know this is an anecdote and very subjective but I've really never discovered something that I loved with a recommendation algorithm. Whether it be videos, music, livestreams, books... Everything that I've considered a "10/10" has been recommended by a human or a non-personalized algorithm—such as "Most popular". Whether that's a direct recommendation by a friend, a comment on HackerNews, someone that I already follow that mentioned the thing in question. My RSS client fetches my YouTube "subscriptions" and it's been years since I've been on the homepage. Surely I'm not alone but it surely feels like it.

I’ve had some great recommendations from YouTube. For example the video below, called “The Squirrel and the Peanut”, which by just adding some well chosen classical music to some found footage of a squirrel getting a peanut turns it into a moving story of overcoming your fears told in a mere 1:32. Watch with the sound turned up. https://www.youtube.com/watch?v=LQ1ZYGHmtN8

Most of the great music I've discovered is thanks to Spotify's "Play song radio" feature.

Granted I have very specific tastes in music and 98% of the time I listen to things I've already listened to hundreds of times... I sometimes try the song radio but it's not to discover a "banger".

DuckDuckGo has also been my goto for years, but it is also getting swamped with SEO-rigged spam sites. 2 days ago I was making multiple searches looking for the websites of specific hotels and spa facilities, and none of them showed up in the first 4 pages of results, even when searching by exact name. Out of desperation I switched back to Google, and, surprisingly, it was willing to give me what I was looking for on the first page. (But not as first result, of course..)

> DuckDuckGo has also been my goto for years, but it is also getting swamped with SEO-rigged spam sites. True, but DDG seems, at the very least, no more afflicted than other engines. If I'm supposed to pay for a search engine, I expect something better than DDG.

C++ says “We have try at home” (devblogs.microsoft.com)

Destructors are vastly superior to the finally keyword because they only require us to remember a single time to release resources (in the destructor) as opposed to every finally clause. For example, a file always closes itself when it goes out of scope instead of having to be explicitly closed by the person who opened the file. Syntax is also less cluttered with less indentation, especially when multiple objects are created that require nested try... finally blocks. Not to mention how branching and conditional initialization complicates things. You can often pair up constructors with destructors in the code so that it becomes very obvious when resource acquisition and release do not match up.

Python has that too, it's called a context manager, basically the same thing as C++ RAII. You can argue that RAII is more elegant, because it doesn't add one mandatory indentation level.

A writable file closing itself when it goes out of scope is usually not great, since errors can occur when closing the file, especially when using networked file systems. https://github.com/isocpp/CppCoreGuidelines/issues/2203

Destructors and finally clauses serve different purposes IMO. Most of the languages that have finally clauses also have destructors. > Syntax is also less cluttered with less indentation, especially when multiple objects are created that require nested try... finally blocks. I think that's more of a point against try...catch/maybe exceptions as a whole, rather than the finally block. (Though I do agree with that. I dislike that aspect of exceptions, and generally prefer something closer to std::expected or Rust Result.)

> Most of the languages that have finally clauses also have destructors. Hm, is that true? I know of finally from Java, JavaScript, C# and Python, and none of them have proper destructors. I mean some of them have object finalizers which can be used to clean up resources whenever the garbage collector comes around to collect the object, but those are not remotely similar to destructors which typically run deterministically at the end of a scope. Python's 'with' syntax comes to mind, but that's very different from C++ and Rust style destructors since you have to explicitly ask the language to clean up resources with special syntax. Which languages am I missing which have both try..finally and destructors?

Technically CPython has deterministic destructors, __del__ always gets called immediately when ref count goes to zero, but it's just an implementation detail, not a language spec thing.

Standard library modules: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p2465r3.pdf I have thoroughly forgotten which header std::ranges::iota comes from. I don't care either.

Last time I tried, modules were a spuriously supported mess. I'll give them another try once they have ironclad support in cmake, gcc, clang and Visual Studio.

And yet, somehow Lisp continues to be everyone's sweetheart, even though creating literal new DSLs for every project is one of the features of the language.

It's because DSLs there reduce cognitive load for the reader rather than add up to it.

Why would that be preferable to just using an RAII style scope_exit with a lambda

Meh, I was going to use the preprocessor for __LINE__ anyways (to avoid requiring a variable name) so I just made it an "old school lambda." Besides, scope_exit is in C++23 which is still opt-in in most cases.

I was contemplating what it would look like to provide this with a macro in Rust, and of course someone has already done it. It's syntactic sugar for the destructor/RAII approach. https://docs.rs/defer-rs/latest/defer_rs/

I don't know Rust but, can this `defer` evaluate after the `return` statement is evaluated like in Swift? Because in Swift you can do this: func atomic_op() -> Int { sem.wait() defer { value += 1 sem.signal() } return value }

HN has some heuristics to reduce hyperbole in submissions which occasionally backfire amusingly.

You have a few minutes to change the title after the submission, I do it all the time.

Yeah it's a huge mistake IMO. I see it fucking up titles so frequently, and it flies in the face of the "do not editorialise titles" rule: [...] please use the original title, unless it is misleading or linkbait; don't editorialize. It is much worse, I think, to regularly drastically change the meaning of a title automatically until a moderator happens to notice to change it back, than to allow the occasional somewhat exaggerated original post title. As it stands, the HN title suggests that Raymond thinks the C++ 'try' keyword is a poor imitation of some other language's 'try'. In reality, the post is about a way to mimic Java's 'finally' in C++, which the original title clearly (if humorously) encapsulates. Raymond's words have been misrepresented here for over 4 hours at this point. I do not understand how this is an acceptable trade-off.

Personally, I would rather we have a lower bar for killing submissions quickly with maybe five or ten flags and less automated editorializing of titles.

↙ time adjusted for second-chance

Rex is a safe kernel extension framework that allows Rust in the place of eBPF (github.com/rex-rs)

For the sake of safety, can't we simply have a back-end that emits eBPF?

We do; most people don't just write eBPF by hand. https://github.com/llvm/llvm-project/tree/main/llvm/lib/Target/BPF

please don't (replace your typical eBPF filter with it, but do replace you custom kernel modules with it where viable ;) ) rust type system is not a security mechanism it's a mechanism to avoid bugs which can become security issues not a way to enforce well behavior on a kernel boundary as an example the current rust compiler has some bugs where it accepts unsound programs which are not seen as supper high priority as you most most likely won't run into them by accident. If rust where a verification system enforcing security at a kernel boundary this would be sever CVEs... also eBPF verification checks more properties, e.g. that a program will deterministically terminate and can't take too long to do so, which is very important for the kind of thing eBPF is(1). and eBPF programs are also not supposed to do anything overly complex or difficult to compute but instead should only do "simple" checks and accounting and potentially delegate some parts to user space helper program. So all the nice benefits rust has aren't really that useful. In the end there is a huge gap between the kind of "perfect verification" you need for something like eBPF and "type checking to avoid nasty bugs". One defends against mistakes the other against malicious code. To be fair if your use case doesn't fit into eBPF at all and you choice is rex-rs or a full kernel driver rex-rs is seems a far better choice then a full custom rust driver in a lot of way. IMHO it would be grate if rust verification could become at some point so good that it can protect reliably against malicious code and have extensions for enforcing code with guaranteed termination/max execution budged. But rust isn't anywhere close to it, and it's also not a core goal rust development focused on. (1): In case anyone is wondering how that works given that the halting problem is undecidable: The halting problem applies to any arbitrary program. But there are subsets of programs which can be proven to halt (or not halt). E.g. `return 0` is trivially proven to halt and `while True: pass` trivially to not halt (but `while(1){}` is UB in C++ and henceforth might be compiled to a program which halts, it's still an endless loop in C)

> which is very important for the kind of thing eBPF is(1) The question is, going into 2026, what kind of thing is eBPF? It seems like all hope of it being a security boundary has been thwarted by micro-architectural vulnerabilities to the extent that you can no longer load eBPF programs as non-root. So, is it a security boundary? That's an honest question that I've not been able to find an answer to in the kernel documentation or recent mailing list posts. If it's not a security boundary, what is it? There's a few other nice properties enforced by the validator, like protos for a subset of kernel functions, which provides some load-time validation that you've built against a compatible kernel. That's something that's lost here, so we don't get the same compile once, run everywhere properties eBPF has. One might argue this is a big loss, but in the branch that eBPF is not a security subsystem, it's worth asking whether these are strictly necessary checks that need to be enforced, or whether they're niceties that bring a higher hope of stability and reduce the burden of code review that are perfectly fine to bypass given those caveats.

> This approach avoids the overly restricted verification requirements (e.g., program complexity constraints) Maybe i'm missing something, but isn't that a bad thing?

Depends. If you want to implement a very fancy kernel level tracing tool for your local environment, why would it be a bad thing? Worst case you'll lock up your system and have to reboot. But you wouldn't want to use that for the actual firewall for example, or with a production service. There's no general "bad". Just different contexts.