Don't worry, we'll get there soon enough.
HN user
dilap
lucky number (lambda f: f(f))(lambda y: lambda f: f(lambda n: y(y)(f)(n)))(lambda f: lambda n: f(n-1) + f(n-2) if n > 2 else 1)(7)
Have you tried iterating on style feedback in AGENTS.md? I've been reasonably successful using this to get it to output code in a terse, non-defensive style that matches my hand-written code.
Reload should fix (did for me).
Doesn't look minified, just very dense, almost like progcomp code. First time I've seen an LLM spit out that style of code, I'm impressed!
It's just Claudeslop. It's everywhere. An epidemic. If you're familiar it stands out instantly. (Would you let someone else talk for you? In real life? Like open up your mouth and let a TTS system spit out the sounds and pick the words? No? Then you shouldn't do the same thing with writing!)
Why Codex GPT-5.5 High instead of Extra High, I wonder?
Yeah, it has a tendency to default to "smallest local hack that will work" and code as defensively as possible.
BUT I have had great success using AGENTS.md and becoming better at prompting to get it to not be like this.
Basic approach in AGENTS.md: don't code defensively, yada yada, we have a validation layer at X, no need to check for anything behind that layer. Works well.
An approach I've found helpful when prompting: What would be the best architecture for this change? If you say "do X" it'll tend to just do the hackiest, shortest path thing. If you say, "what's the best way to do X?" it will think more holistically.
That said, who knows, maybe when it's PHP it just really wants to hack ;-)
(Also, yes, you still need to review the code -- it will still do stupid things, so you can't just be pure hands off w/o ending up with quality degredations. The same is true of humans too though in my experience...)
Personally I don't find this to be true anymore! It's not always great and does still will often tend towards unneeded complexity (especially if not pushed a bit), but I often find GPT 5.5 writing code I would have written myself. This was very much not true with earlier models (who make something that worked, but I'd always have to rewrite to make it "good code").
way easier to work on a focussed c codebase you own than a mature unwieldy c++ codebase you don't. but it's fine, people will take that work and port to llamacpp and everyone wins.
(the ux of ds4 is fantastic too -- it's dead-easy to get a known-good model, great quant. llamacpp you're much more hacking in the wilderness, w/ many many knobs.)
FWIW, I've found Codex with GPT-5.4 to be better than Opus-4.6; I would say it's at least worth checking out for your use case.
Deepseek R1 was a publically-available, MoE model that was getting a ton of attention before llama4. Llama4 didn't get much attention because it wasn't good.
i use a an auto-layout tool, so having windows stacked on top of each other is super-common for me, and the fact that they all peak thru each other (like the screenshot in the blog) looking absolutely terrible drives me crazy
I wish I could remember the details -- I know I got annoyed with things being slow and when I got a new computer decided to go the no-homebrew route. I'm using nix, and it seems fine so far, but I also really don't understand it at all, which is a little concerning. :-)
Horses for courses, but I've stopped using brew 'cuz it's too slow, so this might bring me back!
Edit: no, it won't...
I thought this was parody until the last sentence.
I still remember the very first time I saw an emoji -- just an old-school dumb phone, and my friend sent me a message with an emoji, which the phone, amazingly, was able to display. I had no idea such a capability even existed, and wondered for a second if I was dreaming.
Welllll I'm not so sure that phrase is well-suited for your intended meaning, then. (Also, tangentially, I think could argue thinking models w/ the elided thought prelude satisfy "having hidden state where it first forms an opinion.")
Ha, thanks!
I don't know for a fact, but I'd bet a few digits of cold hard cash it's a SwiftUI rewrite that is to blame. (Any1 in the know want to chime in?)
And yeah, it's terrible. Apple doesn't make good apps anymore.
(This is part of why I think electron does so well -- it's not as good as a really good native app [e.g. Sublime Text], but it's way better than the sort of default whatever you'll get doing native. You get a lot of niceness that's built into the web stack.)
The fundamental nature of the model is that it consumes tokens as input and produces token probabilities as output, but there's nothing inherently "predictive" about it -- that's just perspective hangover from the historical development of how LLMs were trained. It is, fundamentally, I think, a general-purpose thinking machine, operating over the inputs and outputs of tokens.
(With this perspective, I can feel my own brain subtly oferring up a panoply of possible responses in a similar way. I can even turn up the temperature on my own brain, making it more likely to decide to say the less-obvious words in response, by having a drink or two.)
(Similarly, mimicry is in humans too a very good learning technique to get started -- kids learning to speak are little parrots, artists just starting out will often copy existing works, etc. Before going on to develop further into their own style.)
That description is really only fair for base models†. Something like Opus 4.6 has all kinds of other training on top of that which teach it behaviors beyond "predict most probable token," like problem-solving and being a good chatbot.
(†And even then is kind of overly-dismissive and underspecified. The "most probable word" is defined over some training data set. So imagine if you train on e.g. mathematicians solving problems... To do a good job at predicting [w/o overfitting] your model will have to in fact get good at thinking like a mathematician. In general "to be able to predict what is likely to happen next" is probably one pretty good definition of intelligence.)
I think you'd be much better served by writing something rough that maintains your own voice!
The problems aren't bugs; they're consequences of design decisions that may have made sense a decade ago, but don't align with how JavaScript developers write code today.
I'm not here to disparage the work that came before — I'm here to start a conversation about what can potentially come next.
Terrible LLM-slop style. Is Mr Snell letting an LLM write the article for him or has he just appropriated the style?
Leadership matters!
Well sure, but lots of big companies have all the resources in the world and can't execute. Google really did turn things around in an impressive way.
Haven't used Linux in forever, but middle-click to paste was like the one thing that consistently worked everywhere. So it makes some sense that someone want to break it somewhere. With enough fingers meddling all conventions are broken. Wisdom of the crowds. Democracy.
(Actually I have been playing with Omarchy recently a tiny bit, inspired by the absolutely devestatingly bad macOS update. Initial tire-kicking was very positive. They had a "universal copy-paste" feature that still seemed WIP at the time...i.e. didn't work everywhere...)
It's neat!
Suggestionms:
A version where you actually need to find sets -- "have two, find third" is way too easy.
Monospaced font -- it's too hard visually to see difference in word length right now, w/o counting letters.
I read about 4 paragraphs of the blog post, it does not at all read like it was written by ChatGPT!
Some people are perhaps overly focussed on superficial things like em-dashes. The real tells for ChatGPT writing are more subtle -- a tendency towards hyperboly (it's not A, it's [florid restatment of essentially A] B!), a certain kind of rhythym, and frequently a kind of hard to describe "emptiness" of claims.
(LLMs can write in mang styles, but this is the sort of "kid filling out the essay word count" style you get in chatgpt etc by default.)
Yeah, by design, of course, but I still think it's bad (& there are plenty of ways to scare grandma without lying to her, if you really need to do that).
In general I'd contend that the mindest which leads you to believe "we need to lie to our users because they are dumb" isn't conducive to making good software.