> There's no way someone that works with real code all day could spent an honest few weeks with a tool like Claude and come away calling it "hype". someone might still not prefer it, or it's not for them, but to claim it's "hype", that's not possible.
I've tried implementing features with Claude Code Max and if I had let that go on for a week instead of just a couple of days I would've lost a week's worth of work (it was pretty immediately obvious that it was too slow at doing pretty much everything, and even the slightest interaction with the LLM caused very long round-trips that would add additional time, over and over and over again). It's possible people simply don't do the kind of things I do. On the extreme end of that, had I spent my days making CRUD apps I probably would've thought it was magic and a "game changer"... But I don't.
I actually don't have a problem believing that there are people who basically only need to write 25% of their code now; if all you're doing for work is gluing together libraries and writing boilerplate then of course an LLM is going to help with that, you're probably the 1000th person that day to ask for the same thing.
The one part I would say LLMs seem to help me with is medium-depth questions about DirectX12. Not really how to use it, but parts of the API itself. MSDN is good for learning about it, but I would concede that LLMs have been useful for just getting more composite knowledge of DX12.
P.S.:
I have found that very short completions, 1-3 lines, is a lot more productive for me personally than any kind of "generate this feature", or even function-sized generation. The reason is likely that LLMs just suck at the things I do, but they can figure out that a pattern exists in the pretty immediate context and just spit out that pattern with some context clues nearby. That remains my best experience with any and all LLM-assisted coding. I don't use it often because we don't allow LLMs for work, but I have a keybind for querying for a completion when I do side projects.
my current job /role combinations has me working in a variety of projects which feature tasks to be done in: Python/SQLAlchemy (which I maintain), Go, k8s, Ansible, Bash, Groovy, Java, Typescript, javascript, etc. If I'm doing an architecture-intensive thing in SQLAlchemy, obviously I'm not going to say "Claude here go do this feature for me". I will have it do things like write change notes (where I'll write out the changelog in the convoluted and overly technical way I can do in 10 seconds, and it produces something presentable and readable from it), set up test cases, and sometimes I will give it very specific instructions for a large refactoring that has a predictable pattern (basically, instead of me figuring out a complex search and replace or doing it manually). For stuff I do in Ansible and especially Groovy (a horrible language which heavily resists being lintable), these are very simple declarative playbooks or Jenkins pipeline jobs, I use Claude heavily to write out directives and such because it will do so without syntax errors and without me having to google every individual pattern or directive; it's much easier to check what it writes and debug from there. But I'm also not putting Claude in charge in these places, it's doing the boring stuff for me and doing it a lot faster and without my having to spend cognitive overhead (which is at a premium when you're in your late 50s like me).
> The one part I would say LLMs seem to help me with is medium-depth questions about DirectX12. Not really how to use it, but parts of the API itself. MSDN is good for learning about it, but I would concede that LLMs have been useful for just getting more composite knowledge of DX12.
see there you go, I have things like this I have to figure out many times per week. so many of them are one-off things I really dont need to learn deeply at the moment (like TypeScript). It's also very helpful to bounce off ideas, like when I need to achieve something in the Go/k8s realm, it can sanity check how I'm approaching a problem and often suggest other ways that I would not have considered (which it knows because it's been trained on millions of tech blogs).
> A whole new class of problems just became solvable.
This is almost by definition not really true. LLMs spit out whatever they were trained on, mashed up. The solutions they have access to are exactly the ones that already exist, and for the most part those solutions will have existed in droves to have any semblance of utility to the LLM.
If you're referring to "mass code output" as "a new class of problem", we've had code generators of differing input complexity for a very long time; it's hardly new.
So what do you really mean when you say that a new class of problems became solvable?
In Swedish the G wouldn't be silent so it wouldn't really be all that much like "wonderful"; "vanderfugel" is the closest thing I could come up with for how I'd pronounce it with some leniency.
They will spend less time on PRs from LLM spammers like you (for anyone who wonders, just Google his username and check the PRs made to OCaml/Zig/Julia), so if anything they freed up resources.
I think it's probably a great filter for getting people who are actually interested in contributing. Lowering the bar for contribution hasn't really turned out to be useful in any real sense, in my experience.
GitHub (or any repo host) is/was pretty much the only thing I care about when looking at people's applications, because it's the only thing that has anything to do with incontrovertible reality. I certainly don't give a shit about whether or where you went to university and it's unlikely that I value your tenure at some company highly unless I know the people in that company.
> In a follow-up discussion, I committed the "sins" of referring to him as a man, and saying things like he is not a woman, and there are only two sexes.
Sincere question: Why were you not able to just think "Oh, ok, some people do this and feel this way." and then just move on? I'm not sure why these particular things needed to be discussed.
> Yes, and the US system is the envy of the world and is responsible for the overwhelming majority of wealth generated in the US over the past few decades.
Can you elaborate on this a bit? It's very easy to read uncharitably without further elaboration and reads pretty delusional as is.
OpenGL is fine, it has the same issues now it had before but none of it really comes from "old age" or being deprecated in any way. It's not as debuggable and much harder to get good performance out of than the lower level APIs but beyond that it's still great.
Honestly, starting out with OpenGL and moving to DX12 (which gets translated to Vulkan on Linux very reliably) is not a bad plan overall; DX12 is IMO a nicer and better API than Vulkan while still retaining the qualities that makes it an appropriate one once you actually want control.
Edit:
I would like to say that I really think one ought to use DSA (Direct State Access) and generally as modern of a OpenGL usage as one can, though. It's easy to get bamboozled into using older APIs because a lot of tutorials will do so, but you need to translate those things into modern modern OpenGL instead; trust me, it's worth it.
Actual modern OpenGL is not as overtly about global state as the older API so at the very least you're removing large clusters of bugs by using DSA.
I've found it has less idiosyncrasies, is slightly less tedious in general and provides a lot of the same control, so I don't really see much of an upside to using Vulkan. I don't love the stupid OO-ness of DX12 but I haven't found it to have much of an adverse effect on performance so I've just accepted it.
On top of that you can just use a much better shading language (HLSL) with DX12 by default without jumping through hoops. I did set up HLSL usage in Vulkan as well but I'm not in love with the idea of having to add decorators everywhere and using a 2nd class citizen (sort of) language to do things. The mapping from HLSL to Vulkan was also good enough but still just a mapping; it didn't always feel super straight forward.
(Edit: To spell it out properly, I initially used GLSL because I'm used to it from OpenGL and had previously written some Vulkan shaders, but the reason I didn't end up using GLSL is because it's just very, very bad in comparison to HLSL. I would maybe use some other language if everything else didn't seem so overwrought.)
I don't hate Vulkan, mind you, I just wouldn't recommend it over DX12 and I certainly just prefer using DX12. In the interest of having less translation going on for future applications/games I might switch to Vulkan, though, but still just write for Win32.
I've tried implementing features with Claude Code Max and if I had let that go on for a week instead of just a couple of days I would've lost a week's worth of work (it was pretty immediately obvious that it was too slow at doing pretty much everything, and even the slightest interaction with the LLM caused very long round-trips that would add additional time, over and over and over again). It's possible people simply don't do the kind of things I do. On the extreme end of that, had I spent my days making CRUD apps I probably would've thought it was magic and a "game changer"... But I don't.
I actually don't have a problem believing that there are people who basically only need to write 25% of their code now; if all you're doing for work is gluing together libraries and writing boilerplate then of course an LLM is going to help with that, you're probably the 1000th person that day to ask for the same thing.
The one part I would say LLMs seem to help me with is medium-depth questions about DirectX12. Not really how to use it, but parts of the API itself. MSDN is good for learning about it, but I would concede that LLMs have been useful for just getting more composite knowledge of DX12.
P.S.:
I have found that very short completions, 1-3 lines, is a lot more productive for me personally than any kind of "generate this feature", or even function-sized generation. The reason is likely that LLMs just suck at the things I do, but they can figure out that a pattern exists in the pretty immediate context and just spit out that pattern with some context clues nearby. That remains my best experience with any and all LLM-assisted coding. I don't use it often because we don't allow LLMs for work, but I have a keybind for querying for a completion when I do side projects.