I use LLMs to write "secondary" code. Things like deployment scripts, autoformatters, Github Actions, Dockerfiles or Kubernetes config. Stuff that isn't strictly part of the main web project, but is still valuable to have. I use LLMs there because

a) those tend to be boilerplate, and LLMs are great for boilerplate, and

b) code quality doesn't really matter too much, and

c) those tend to be written in languages that you may not be well-versed in, since they usually aren't in the "primary" language of the project

I've found that I rely most heavily on LLMs when:

1. I'm developing a utility package that's easily testable and I'm certain of the interface. I'll write the interface for the package in my editor, then ask an LLM to generate unit tests. Then, I'll sketch out the function calls/structure of the package and get an LLM to fill out the rest.

2. I'm bug bashing and want to quickly check if the bug is obvious. I'll feed a description of the behavior into GPT/Claude along with the relevant code (generally as little code as possible to prevent listicle-type responses that are irrelevant).

3. I'm adding code that follows an established pattern within the codebase -- for example, adding a new API handler that involves generating an OpenAPI path + component snippet, an http handler, and a few database methods. This is when copilots are particularly useful.

4. I'd like a sanity check for issues in a complex bit of code I've written.

I find these mirror the tasks you'd typically hand off to a less experienced dev on the team -- these are things that require validation based on knowledge that you already have, and the validation is more efficient than doing it yourself.

I started using AI for: documentation unknown APIs quickly without having to scour the Internet for examples and improving documentation. You can send it a few paragraphs and have AI re-write it for you.

I don't use AI to generate code that I already know how to write, or code that I don't know how to write. I use it for that weird gray area of things I SHOULD know, but can't immediately conjure off the top of my head nor find good documentation on. Generally, my process is:

0 - Try to write the code myself, using LSP hints as needed

1 - Read the primary source (man page, documentation, textbook) to find an answer. Upside is that I learn something about related topics along the way by skimming the table of contents

2 - Consult stack overflow/google. This has become less and less useful, as both of those resources have become flooded with garbage info and misleading blog posts in the last several years.

3 - Pull out the AI copilot and ask it for help, while sharing what I already know and what I think the shape of the solution will be.

4 - Actively seek help - talk to colleagues, post a question on a relevant forum, etc...

Is this perfect? No, I've wasted hours in the worst case with an answer that the copilot thought was correct, but was not. But on balance, I'd say that it has saved me many days worth of time in the last year, usually in the form of research and knowledge discovery. It's much faster to test out a bunch of potential solutions when the copilot is writing most of the code and I just tweak a few relevant parameters.

I've been using all the time I've saved on mundane programming by studying computer science from first principles. As someone without a CS degree, I am acutely aware of my gaps in knowledge about theoretical computer science. I consider myself a halfway-decent programmer at this point, so I don't find that filling my head with more and more syntax and esoteric rules about frameworks to be helpful. I'd rather learn what the basis is for all those rules, and reconstruct them myself as needed.

I also have a lot more confidence to branch out from my moneytree (web dev) and try my hand at other areas of programming, like embedded development, messaging, and language theory. This field is endlessly fascinating, and I selfishly want to learn and try it all. So far in my career, I've spent most of it in web dev, but have also been able to test the waters of embedded development for a year, and interesting "back-end" services for another year or so. I even had the confidence to start my own company with a friend, realizing that I could actually shoulder most of the development burden early on if I strategically rely on AI to prompt me through implementation details which I'm not quite an expert in.

This is my strategy for ensuring longevity in this career. I'll admit I'm only on year 8 of programming professionally, but I hope this is the correct attitude to have.