I faced a related dilemma when I finished my CS degree: to work as a full-stack dev or to work on more foundational technology (and actually use what I learned in my degree). My experience is that the "foundational technology" area is more "research-oriented", which means you get to work on projects where LLM's don't help that much: writing code in languages that have little data in the LLM's training corpus, coming up with performance benchmarking approaches unique for your application, improving a workload's throughput with insights derived from your benchmarking results and your ingenuity, etc. Had I gone down the full-stack path, I think I'd be worried now.

> I don't want to use LLMs for writing code because it's one of the things I enjoy the most in life

I think LLM's are really good for the "drudge work" when you're coding. I always say it's excellent for things where the actual task is easy but the bottleneck is how fast you can type.

As an example I had a project where I was previously extracting all strings in the UI into an object. For a number of reasons I wanted to move away from this but this codebase is well over 50k LOC and I have probably 5k lines of strings. Doing this manually would have been very tedious and would have taken me quite some time so I leveraged AI to help me and managed to refactor all the strings in my app in a little over an hour.

Exactly. This is the use case that companies should be improving. The AGI marketing hype is a distraction.

Are you using it for other things? I think you can write code without it but it’s so good for research and stack overflow replacement.

Last night I used it to look through some project in an open source code base in a language I’m not familiar with to get a report on how that project works. I wanted to know what are its capabilities and integrations with these other specialized tools, because the documentation is so limited. It saved me time and didn’t help me write code. Beyond that it’s good for asking really stupid questions about complex topics that you’d get roasted on for stack overflow.

Do you use compilers? Linker loaders? Web bundlers? Linters and formatters? Code gen for or from schema? Image editors? Memory safe or garbage collected languages?

Then you already use levers to build code.

LLMs are a new kind of tool. They’re weird and probabilistic and only sometimes useful. We don’t yet know quite how and when to use them. But they seem like one more lever for us to wield.

I think the probabilistic nature is a huge divider. It requires a complete different way of working and it's understandable that people have trouble switching from one to the other (easier for experienced devs, in my experience, but still makes you switch to code reviewer mode too often).

I think there will always be jobs out there that don't demand you write code with an LLM, just the same that most jobs don't demand you use vim or emacs or LSP-based autocomplete as part of your workflow.

You don't have to go with the flow. I took a step back from AI tech because a lot of startups in that field come with extra cultural baggage that doesn't sit well with me.

Treat them as resources for remembering/exploring code libraries and documentation. For example, I needed to import some JSON files as structs into Unreal Engine. Gemini helped me to quickly identify the classes UE has for working with JSON.

Have a side project where you control the entire experience and let your main job bend to the beast.

> Does anyone have advice for maintaining this feeling but also going with the flow and using LLMs to be more productive

Coding with LLMs brought me so much more joy coding. Not always, but it is getting better. Sometimes is quite frustrating, but when you have some good idea, explain it well and get the model to generate the code the way you would code or even better and you can use it to build new things faster, that's magical. Many devs are having this experience, some earlier, some now, some later. But for sure I would not say that using LLMs to code made it less enjoyable.