[59nadir]

> 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.

[zzzeek]

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).