Calavar

I believe they mean GPU threads. Plenty of cuda files in their repository.

Your sarcasm is misplaced because yes, this has unironically been true for large chunks of Latin American history.

- Argentinians in particular are over 60% of Italian descent.

- The richest man in Mexico was born to Lebanese immigrants.

- The chief military leader of the Chilean war of independence was born to an Irish immigrant.

- Peru had a president who was born to Japanese immigrants.

These countries have all, at various times, had an influx of overseas immigrants whose birthright citizen children rose to high stations in society.

If you're looking for international precedent, this is an old vs. new world issue. Birthright citizenship is rare in the old world, but it is the default for the Americas. Canada, most of Latin America, and a decent part of the Caribbean have birthright citizenship.

I did look up numbers before I made that claim:

From Yahoo Finance

GME Jan 1, 2016: $7.09, $5.49 adjusted (accounting for dividend disbursements)

GME Jan 1, 2026: $20.09

266% or 365% return depending on how you count dividends. 365% for GME vs. 306% for S&P 500 over the same period (also using adjusted for dividend numbers).

GME also beat the S&P 500 over the past 10 years. Is this evidence that Ryan Cohen is a business genius?

Tesla has been a meme stock for about five years now, maybe more. Its valuation correlates with Musk's abilities as a showman and media figure, not a businessman.

I consider myself AI skeptical-ish and I detest when people defend LLMs with "it's user error, prompt better," but in this case it actually is user error.

If you want a particular implementation approach, you need to specify not only the features you want, but the implementation strategy at least at a high level. This could be as simple as adding "use pywikibit" or "use relevant packages from pypi" to the end of your prompt. Or you could seed your project with some manually writtem scaffolding, including a pyproject.toml

While LLMs do tend have NIH syndrome by default, I think this is a good default. I'd much rather have tight control over when and how to include external dependencies as opposed to letting a prompt fire for 40 minutes, and coming back to find 2 GB of newly installed node packages with a dependency tree 300 levels deep.

> But it’s getting harder and harder to define a task that humans beat LLMs on. On pretty much any easily quantifiable test of knowledge or reasoning, the machines win.

Quite to the contrary, I think it's extremely trivial to find a task where humans beat LLMs.

For all the money that's been thrown at agentic coding, LLMs still produce substantially worse code than a senior dev. See my own prior comments on this for a concrete example [1].

These trivial failure cases show that there are dimensions to task proficiency - significant ones - that benchmarks fail to capture.

> Is medical diagnosis one of these high judgement tasks?

Situational. I would break diagnosis into three types:

1. The diagnosis comes from objective criteria - laboratory values, vital signs, visual findings, family history. I think LLMs are likely already superior to humans in this case.

2. The diagnosis comes from "chart lore" - reading notes from prior physicians and realizing that there is new context now points to a different diagnosis. (That new context can be the benefit of hindsight into what they already tried and failed and/or new objective data). LLMs do pretty good at this when you point them at datasets where all the prior notes were written by humans, which means that those humans did a nontrivial part of the diagnostic work. What if the prior notes were written by LLMs as well? Will they propagate their own mistakes forward? Yet to be studied in depth.

3. The diagnosis comes from human interaction - knowing the difference between a patient who's high as a bat on crack and one who's delirious from infection; noticing that a patient hesitates slightly before they assure you that they've been taking all their meds as prescribed; etc. I doubt that LLMs will ever beat humans at this, but if LLMs can be proven to be good at point 2, then point 3 alone will not save human physicians.

[1] https://news.ycombinator.com/threads?id=Calavar#47891432

I disagree, I use metaprogramming in application code quite regularly, although I tend to limit myself to a single construct (instance_eval) because I find that makes things more manageable.

In my opinion the main draw of Ruby is that it's kind of Lisp-y in the way you can quickly build a metalanguage tailored to your specific problem domain. For problems where I don't need metaprogramming, I'd rather use a language that is statically typed.

I'm writing a compiler. When I have Claude write a new feature, I have validate that suite against a test suite of ~200 tiny programs.

I have a shell script that automates this. If all tests pass, the shell script prints "200/200 passing" with very little token spend. If only 190/200 pass, the shell script reports the names of every test that failed, and now Claude does a process of

1) run the compiler binary -> 2) get assembly output and inspect for obvious errors -> 3) assemble -> 4) verify that the assembler did not report errors -> 5) run test binary, connect with gdb, and find the issue -> 6) edit the compiler source -> 7) recompile the compiler -> 8) back to 1

multiplied by 10 for the 10 failing tests. This eats up tokens very quickly. I realize that not every use case is going to look like this. But if I didn't have Claude verify against the test suite, then I'd be getting regressions left and right, and then what's the point?

The whole codebase (tests included) is less than 15k lines, so I don't think that's the issue. No MCPs. CLAUDE.md about 1.5k lines.

I'm skeptical of that reasoning because the original C wasn't too clean or performant either. For example emit.c from an earlier commit [1]

It writes a separate call to emit_raw for each line, even though there many successive calls to emit_raw before it runs into any branching or other dynamic logic. What if you change this

    emit_raw(ctx, "#include <stdio.h>\n");
    emit_raw(ctx, "#include <stdlib.h>\n");
    emit_raw(ctx, "#include <string.h>\n");
    emit_raw(ctx, "#include <math.h>\n");
    // And on for dozens more lines

to this

    emit_raw(ctx,
        "#include <stdio.h>\n"
        "#include <stdlib.h>\n"
        "#include <string.h>\n"
        "#include <math.h>\n"
        // And on for dozens more lines
    );

That would leave you with code that is just as readable, but only calls the emit function once, leading to a smaller and faster binary. Again, this is a trivial change to the code, but Claude struggles to get there.

[1] https://github.com/matz/spinel/blob/aba17d8266d72fae3555ec91...

I know this is tangential to your overall point, but did really they murder everyone in the room? I was under the impression that a few Venezuelan generals kidnapped Maduro themselves, left him at a predetermined point for US forces to pick up, and had their soldiers fire some small arms into the air to make a token show of resistance. There's no way the US would have flown a slow-moving convoy of helicopters into a hostile city unless they knew a priori that Venezuelan air defense missile batteries would be ordered to stand down.

spinel_codegen.rb is an eldritch horror. I always get spaghetti code like this when using Claude, and I've been wondering if I'm doing something wrong. Now I see an application that looks genuinely interesting (not trivial slop) written by someone I consider to be a top notch programmer, and the code quality is still pretty garbage in some places.

For example infer_comparison_type() [1]. This is far from the worst offender - it's not that hard to read - but what's striking here that there is a better implementation that's so simple and obvious and Claude still fails to get there. Why not replace this with

    COMPARISON_TYPES = Set.new(["<", ">", "<=", ">=", "==", "!=", "!"])

    def infer_comparison_type(mname)
      if COMPARISON_TYPES.include?(mname)
          "bool"
      else 
        ""
      end
      # Or even better, strip the else case
      # (Which would return nil for anything not in the set)
    end

This would be shorter, faster, more readable, and more easily maintainable, but Claude always defaults to an if-return, if-return, if-return pattern. (Even if-else seems to be somewhat alien to Claude.) My own Claude codebases are full of that if-return crap, and now I know I'm not alone.

Other files have much better code quality though. For example, most of the lib directory, which seems to correspond to the ext directory in the mainline Ruby repo. The API is clearly inspired by MRI ruby, even though the implementation differs substantially. I would guess that Matz prompted Claude to mirror parts of the original API and this had a bit of a regularizing effect on the output.

[1] https://github.com/matz/spinel/blob/98d1179670e4d6486bbd1547...

What sorts of instructions?

It's interesting how variable people's experiences seem to be.

Personally, I tend to get crap quality code out of Claude. Very branchy. Very un-DRY. Consistently fails to understand the conventions of my codebase (e.g. keeps hallucinating that my arena allocator zero initializes memory - it does not). And sometimes after a context compaction it goes haywire and starts creating new regressions everywhere. And while you can prompt to fix these things, it can take an entire afternoon of whack-a-mole prompting to fix the fallout of one bad initial run. I've also tried dumping lessons into a project specific skill file, which sometimes helps, but also sometimes hurts - the skill file can turn into a footgun if it gets out of sync with an evolving codebase.

In terms of limits, I usually find myself hitting the rate limit after two or three requests. On bad days, only one. This has made Claude borderline unusable over the past couple weeks, so I've started hand coding again and using Claude as a code search and debugging tool rather than a code generator.

It's really hard to cry victim about others misrepresenting Trump's motives for the Iran war as oil, oil, oil when the US did in fact launch a military attack on a country - within the last six months - where the subsequent negotiated agreement on oil rights was quite literally described by the White House press secretary as "the president’s control of Venezuela’s oil" [1] and just a few weeks later the president held a public, televised conference with Chevron and ExxonMobil executives in the White House where he pitched them on investing in the Venezuelan oil industry [2]

[1] https://www.wsj.com/business/energy-oil/trump-venezuela-oil-...

[2] https://youtu.be/sD4x6T-u4XY

> we're seeing an explosion of brand-new high-polish OSS apps this year

Do you mind sharing a few examples?

It's not an insightful statement right now, but it was at the peak of cloud hype ca. 2010, when "the cloud" often used in a metaphorical sense. You'd hear things like "it's scalable because it's in the cloud" or "our clients want a cloud based solution." Replacing "the cloud" in those sorts of claims with "another person's computer" showed just how inane those claims were.

I still don't understand why Theil and Karp decided to name their surveillance tech company after a device that is best known for being used by an evil dark lord to decieve and corrupt. It's like the Mitchell and Webb skit "are we the baddies" except they're the ones who designed the uniforms with skulls on them.

This is a good point. It is not humanly possible to verify every claim you read from every source.

Ideally, you should independently verify claims that appear to be particularly consequential or particularly questionable on the surface. But at some point you have to rely on heuristics like chain of trust (it was peer reviewed, it was published in a reputable textbook), or you will never make forward progress on anything.

> If they couldn't do anything that gave an appearance of a conflict

This time I won't say maybe - that's a straw man.

I never said Cantor shouldn't be able to do anything that even gives the appearance of a conflict. Or anything even close to that really.

As you said yourself further up the thread, investments of investment bank employees are highly regulated. And not only employees themselves, but also their immediate family members.

Yet that same level of legal regulation doesn't apply to immediate relatives of government officials. We've seen frequently with spouses and children of congressmen, and now we're seeing it with the son of a cabinet member. Yes, this may technically be legal, but legal does not equate to just and desirable. This reads to me like a serious loophole in the law that needs to be closed.

> In this case, the idea that Cantor can't do something because the former head is now in a government job is crazy. No one "in the business" thinks Cantor is suddenly hobbled.

That's not the idea, and it almost seems like a straw man to be honest. The actual idea is that the current head of Cantor can't do something because he's a direct relative of a high ranking government official whose powers and job duties present a conflict of interest for this specific set of transactions.

It looks like a screenshot from the Claude desktop app, so I don't think the author is trying to disguise the AI origin of the marerial

I know you qualified your assertion of three patients an hour with general practice, but there are plenty of specialty practices where six patients an hour is common. Dermatology and ophthalmology clinics often run at that pace (at least in the US). Some surgical clinics can run at that pace for follow up visits (not for initial visits)

The average American says US healthcare spending, which is 3x to 20x that of other OECD countries on a per capita basis, is way too high.

The average American also thinks they should be provided testing and procedures that their insurance deems medically unnecessary.

Try to reconcile these two beliefs. (Hint: It's impossible)

I agree that not all nudity is porn - nudity is porn if the primary intent of that nudity is sexual gratification. When the nudity in question was a Playboy magazine centerfold, the primary intent is fairly obvious.

It could once upon a time: https://www.bellard.org/tcc/tccboot.html

It can't do that today though. Linux uses C11 features and also many GCC extensions that tcc doesn't implement.

I'm not sure I'd call agents an army of juniors. More like a high school summer intern who has infinite time to do deep dives into StackOverflow but doesn't have nearly enough programming experience yet to have developed a "taste" for good code

In my experience, agentic LLMs tend to write code that is very branchy with cyclomatic complexity. They don't follow DRY principles unless you push them very hard in that direction (and even then not always), and sometimes they do things that just fly in the face of common sense. Example of that last part: I was writing some Ruby tests with Opus 4.6 yesterday, and I got dozens of tests that amounted to this:

   x = X.new
   assert x.kind_of?(X)

This is of course an entirely meaningless check. But if you aren't reading the tests and you just run the test job and see hundreds of green check marks and dozens of classes covered, it could give you a false sense of security

Claude already knows who the characters Frodo, Sam, and Gollum are, what their respective character traits are, and how they interacted with each other. This isn't the same as writing something new.

I think that's overstating it.

JustHTML is a success in large part because it's a problem that can be solved with 4 digit LOC. The whole codebase can sit in an LLM's context at once. Do LLMs scale beyond that?

I would classify both FastRender and Opus C compiler as interesting failures. They are interesting because they got a non-negligible fraction of the way to feature complete. They are failures because they ended with no clear path for moving the needle forward to 80% feature complete, let alone 100%.

From the original article:

> The resulting compiler has nearly reached the limits of Opus’s abilities. I tried (hard!) to fix several of the above limitations but wasn’t fully successful. New features and bugfixes frequently broke existing functionality.

From the experiments we've seen so far it seems that a large enough agentic code base will inevitably collapse under its own weight.

Sure, maybe it's tricky to coerce an LLM into spitting out a near verbatim copy of prior data, but that's orthoginal to whether or not the data to create a near verbatim copy exists in the model weights.