remexre

more like silk than capacitors

if, again, your model is that RSI will be beneficial, why wouldn't making it available to all unlock more benefit globally than not doing that

this is not hard to repro, just use a system prompt that doesn't mention the model name.

that said, if they bootstrapped with opus 4.6 convo sft data they had sitting around... so what?

Vibecoding $x gives you pretty much the understanding of "someone else did $x," which seems unsurprising to me. There's a lot of usecases for code where "someone else did $x" is a perfectly fine way to accomplish $x! There are also many cases where "someone else did $x" is not a substitute for "I did $x."

"I want a tmux theme that fits with my existing zsh and neovim themes." Is it useful to me to learn how tmux themes work? Eh, marginally maybe? I'm personally kinda hoping I'm not using tmux in 10 years, so probably not.

"I'm writing code for work, where a bad correctness bug would be very expensive." If I'm pulling in someone else's code, I /better/ be auditing that code.

Like, this seems like the obvious framing and a useful heuristic? Maybe the problem is the subject of "vibecoded" is usually "I vibecoded this with Claude," not "Claude vibecoded this with me?" IDK

i'm not using software for this if this is off the top of my head, and it's the sort of thing that, at scale, hurts the forgotten author and their students

(work at a CL shop; mostly SBCL users, but maybe 1/3 of people are die-hard ACL fans)

Make your parser call back into your lexer, so it can pass state to it; make the set of type names available to it.

    x = tokenize(input)
    i = 0
    do {
      finish, x = layers(x)
    } while(!finish && i++ < t_max);
    output = lm_head(x)

In the same way that non-hygienic macros in a Lisp-2 with a CL-style package system are a local optimum, many non-obvious design choices in the Common Lisp type system and CLOS make SLIME "just work" in almost every case.

see, this seems like something that's nice to actually put into the types; a Ptr<Foo> is a real pointer that all the normal optimizations can be done to, but cannot be null or otherwise invalid, and UnsafePtr makes the compiler keep its distance and allows whatever tricks you want.