I do get a lot of value out of a project wide system prompt that gets automatically addded (Cursor has that built in). For a while I kept refining it when I saw it making incorrect assumptions about the codebase. I try to keep it brief though, about 20 bullet points.
Not the case with GPT-5 I’d say. Sonnet 4 feels a lot like this, but the coding and agency of it is still quite solid and overall IMO the best coder. Gemini2.5 to me is most helpful as a research assistant. It’s quite good together with google search based grounding.
GPT-5 is pretty decent nowadays, but Claude 4 Sonnet is superior in most cases. GPT beats it in cost and usable context window when something quite complex comes up to plan top-down.
What I find interesting is how much opinions vary on this. Open a different thread and people will seem to have consensus on GPT or Gemini being superior.
Well, last I checked Claude's webchat UI doesn't have LaTeX rendering for output messages which is extremely annoying.
On the other hand, I wish ChatGPT had GitHub integration in Projects, not just in Codex.
I've also had Claude Sonnet 4.0 Thinking spew forth incorrect answers many times for complex problems involving some math (with incapability to write a former proof sometimes), whereas ChatGPT 5 Thinking gives me correct answers with formal proof.
I think it depends on the domain. For example, GPT-5 is better for frontend, React code, but struggles with niche things like Nix. Claude's UI designs are not as pretty as GPT-5's.
This is also pretty subjective. I’m a power user of both and tend to prefer Claude’s UI about 70-80% of the time.
I often would use Claude to do a “make it pretty” pass after implementation with GPT-5. I find Claude’s spatial and visual understanding when dealing with frontend to be better.
I am sure others will have the exact opposite experience.
My experience is exactly opposite. Claude excelling in ui, and react. While gpt5 being better on really niche stuff, migth just be me better at caching when gpt5 halucinates as opposed to the claude4 hallucinations.
But after openai started gatekeeping all their new decent models in the api, i will happily refuse to buy more credits, and rather use foss models from other providers (I wish claude had proper no log policies).
I never implied it's useless. I don't have scientific data to back this up either, this is just my personal "feeling" from a couple hundred hours I've spent working with these models this year: GPT-5 seems a bit better at top-down architectural work, while Sonnet is better at the detail coding level. In terms of usable context window, again from personal experience so far, to me GPT-5 has somewhat of an edge.
Agreed. My experience is GPT5 is significantly better at large-scale planning & architecture (at least for the kind of stuff I care about which is strongly typed functional systems), and then Sonnet is much better at executing the plan. GPT5 is also better at code reviews and finding subtle mistakes if you prompt it well enough, but not totally reliable. Claude Code fills its context window and re-compacts often enough that I have to plan around it, so I'm surprised it's larger than GPT's.
Hypotethetically speaking, there could be a design office in Switzerland for these features that charges a crazy amount in IP
rights for every car sold by VW anywhere in the world.
Macs can run Windows just fine, through Parallels. It’s more efficient at doing so than most ARM based windows machines on sale still. And I found software compatibility with Windows 11 for ARM to be a non issue nowadays.
I can't tell you how much I disagree with this take.
Microsoft's AMD64 emulator is slow and buggy compared to Rosetta, and you will need it a lot more, too. Many apps will need to rely on this, including programs many users will immediately try to use, like Visual Studio. Neither Visual Studio nor its compilers support running on an ARM host; it does seem to basically work, but is slow, which is not good considering Visual Studio is already not particularly fast. It will even display a message box warning you that it is not supported during setup, so you couldn't miss it (note that this applies to the Visual Studio compilers needed by Python and Node for installing packages with C extensions). MSys2 gave me a lot of trouble, too; the setup just doesn't seem to work on ARM64. Chocolatey often installs AMD64 or x86 binaries on ARM instead of native ones; sometimes native ones don't exist anyways. Third party thing that needs to load a kernel module? Don't bet on there being an ARM64 build of it; sometimes there is, sometimes there isn't. WinFSP has a build, many hardware drivers I've looked at don't seem to (don't laugh: you can pass through USB devices, there is sense in installing actual hardware drivers.) I just set up a fresh copy of Parallels on an M3 Mac a couple months ago, I'm stopping now to be terse, this paragraph could easily be much longer. It would suffice to say that basic Windows software usage is a lot worse on Parallels than a native Windows AMD64 machine. Very useful, sure. At parity, oh no. Not close.
That's just the basics though. For GPU, Parallels does do some D3D11 translation which is (a lot!) better than nothing, but you are not getting native performance, you are not getting Vulkan support, and you are certainly not getting ROCm or CUDA or anything equivalent, so actually a lot of apps that practically need GPU acceleration are not going to be usable anyways. Even if a video game would run, anti-piracy and anti-cheat measures in lots of modern games detect and block users using VM software, not that you can expect that all of the games you want to run would even work anyways on ARM; plenty of games are known to be unstable and some don't work at all. There are other side effects of trying to do actual gaming in VMs in general, but I really think this gets the point across: Windows games and multimedia are significantly worse in Parallels than on a native machine.
Parallels filesystem bridging is impractical, it's not fast enough and it is buggy, i.e. running Bazel on bridged files will not work. This means you need to copy stuff back and forth basically all the time if you want to work on stuff natively but then test on Windows. Maybe this is partly Window's fault, but in any case it would suffice to say that workflows that involve Windows will be a lot clunkier than they would be on a native Windows machine.
I think these conclusions, that a native Windows machine would be a lot better for doing Windows things than a Mac running Parallels, is actually pretty obvious and self-evident, but reading what you said might literally give someone the opposite impression, that there is little reason to possibly want to run Windows. This is just misleading. Parallels is a great option as a last resort or to fill a gap, but if you have anything that regularly requires you to use Windows software or test on Windows, Parallels is not a very serious option. It may be cheaper than two machines in fiat currency, but probably not in sanity.
I don't know you, so I can't and won't, based on a single post, accuse you of being a fanboy. However, this genre of retort is a serious issue with fanboyism. It's easy to say "Windows? just use VMs!", but that's because for some people, actually just using Windows is probably not a serious option they would consider anyways; if the VM didn't work for a use case they'd back up and reconsider almost anything else before they reconsider their choice of OS or hardware vendor, but they probably barely need (if at all) a VM with Windows anyways. If this feels like a personal attack, I'd like to clarify that I am describing myself. I will not use Windows. I don't have a bare metal Windows machine in my house, and I do my best to limit Windows usage in VMs, too. Hell, I will basically only use macOS under duress these days, I'm not a fan of the direction it has gone either.
Still, I do not go around telling people that they should just go switch to Linux if they don't like Windows, and that Virtualbox or Wine will solve all of their problems, because that's probably not true and it's downright dishonest when deep down I know how well the experience will go. The honest and respectful thing to tell people about Linux is that it will suck, some of the random hardware you use might not work, some of your software won't work well under Wine or VMs, and you might spend more time troubleshooting. If they're still interested even after proper cautioning, chances are they'll actually go through with it and figure it out: people do not need to be sold a romantic vision, if anything they need the opposite, because they may struggle to foresee what kinds of problems they might run into. Telling people that virtual machines are a magic solution and you don't have to care about software compatibility is insane, and I say that with full awareness that Parallels is better than many of the other options in terms of user friendliness and out of the box capabilities.
I think the same thing is fair to do for macOS. With macOS there is the advantage that the entire experience is nicer as long as everything you want to do fits nicely into Apple's opinionated playbook and you buy into Apple's ecosystem, but I rarely hear people actually mention those latter caveats. I rarely hear people mention that, oh yeah, a lot of cool features I use only work because i use Apple hardware and services throughout my entire life, and your Android phone might not work as well, especially not with those expensive headphones I think you should get for your Mac. Fanboys of things have a dastardly way of only showing people the compelling side of things and leaving out the caveats. I don't appreciate this, and I think it ultimately has an overtone of thinking you know what someone wants better than they do. If someone is really going to be interested in living the Mac life, they don't need to be mislead to be compelled.
The main problem in this environment is IMO: how does a junior become a senior, or even a bad junior become a good junior. People aren't learning fundamentals anymore beyond what's taught, and all the rest of 'trade knowledge' is now never experienced, people just trust that the LLM has absorbed it sufficiently. Engineering is all about trade-offs. Failing to understand why from 10 possible ways of achieving something, 4 are valid contenders and possible 1-2 are best in the current scenario, and even the questions to ask to get to that answer, is what makes a senior.
I think the solution becomes clearer - juniors need to worry less about knowing how to program in a void, since the LLM can handle most of that, but care more about how to produce code that doesn't break things, that doesn't have unintended 2nd order effects, that doesn't add unneeded complexity, etc.
In my experience I see juniors come out of college who can code in isolation as well as me or better. But the difference between jr/sr is much more about integration, accuracy and simplicity than raw code production. If LLMs remove a lot of the hassle of code production I think that will BENEFIT the other elements, since those things will be much more visible.
Personally, I think juniors are going to start emerging with more of a senior mindset. If you don't have to sweat uploading tons of programming errata to your brain you can produce more code abd more quickly need to focus on larger structural challenges. That's a good thing! Yes, they will break large codebases but they have been soing that forever, if given the chance. The difference now is they will start doing that much sooner.
The LLM is the coding tool, not the arbiter of outcome.
A human’s ability to assess, interrogate, compare, research, and develop intuition are all skills that are entirely independent of the coding tool. Those skills are developed through project work, delivering meaningful stuff to someone who cares enough to use it and give feedback (eg customers), making things go whoosh in production, etc etc.
This is a XY problem and the real Y are galaxy brains submitting unvalidated and shoddy work that make good outcomes harder rather than easier to reach.
Exactly the same has been said over and over again, ever since CUDA took off for scientific computing around 2010. I don’t really understand why 15 years later AMD still hasn’t been able to copy the recipy, and frankly it may be too late now with all that mindshare in NVIDIA’s software stack.
The Top500 is an irrelevant comparison; of course AMD is going to give direct support to single institutions that give them hundreds of millions of dollars and help make their products work acceptably. They would be dead if they didn't. Nvidia also does the same thing to their major clients, and yet they still make their products actually work day 1 on consumer products, too.
Nvidia of course has a shitload more money, and they've been doing this for longer, but that's just life.
> smaller systems
El Capitan is estimated to cost around $700 million or something with like 50k deployed MI300 GPUs. xAI's Colossus cluster alone is estimated to be north of $2 billion with over 100k GPUs, and that's one of ~dozens of deployed clusters Nvidia has developed in the past 5 years. AI is a vastly bigger market in every dimension, from profits to deployments.
Besides sibling comment, HPC labs are the kind of customers that get hardware companies to fly in engineers when there is a problem bringing down the compute cluster.
presumably that in HPC you can dump enough money into individual users to make the platform useful in a way that is impossible in a more horizontal market. in HPC it used to be fairly common to get one of only 5 machines with processor architecture that had never existed before, dump a bunch of energy into making it work for you, and then throw it all out in 6 years.
It's just not easy. Even if AMD was willing to invest in the required software, they would need a competitive GPU architecture to make the most of it. It's a lot easier to split 'cheap raster' and 'cheap inference' into two products, despite Nvidia's success.
