Here are the top ways I've found AI helps me the most, which I believe aren't emphasised enough.

1. Understanding new complex code bases

One of the best ways I've noticed AI has helped me in my day-to-day role as a software engineer is that it's just so much easier to understand a new codebase now. Whether that's for onboarding to a new project or just because I need to navigate a new part of the stack to add a feature for myself, the friction assocaited with being able to be productive is just so much lower.

For instance, I've had situations where I'm working on some service, which after multiple hops communicates with some backed e.g. a logging service, and I want to trace all the potential paths that might make it from my service to the backend I care about e.g.

Without AI you can use tools like tracing, but that only shows you which path was executed, not all the possible ones. There are also some static analysis tools that are useful for certain languages, but they're not exhaustive and rarely work well across services implemented in different languaged e.g. a Python service calling a C++ service.

With AI, I can typically get a good result at the level of detail I care about for the job at hand with a single prompt e.g. "Give me all possible codepaths that start at function/class A and end in service Z. Enumerate each path and list each of the functions that gets called in the chain." And that's usually good enough!

"But doesn't it hallucinate?"

Sometimes. But it still makes my job easier, because I can easily verify when it's done so and, just by providing a set of possible paths, it's limited my search space by orders of magnitude.

"Doesn't it miss some paths?"

Again: sometimes. But again: it's still far easier to do the job if 90% of it has been done and only needs to be verified.

The point isn't that I can now be lazy and trust the output 100%. It's just the fact that I can now focus 20% of my energy on verifying an output from an LLM (which is less daunting and provides equal value) and the remaining 80% can be used for parts that it might have missed and actually understanding the system at a high level.

2. Creating short courses on particular topics

Another area that has been a game changer for me has been in creating short educational courses for topics that I'm not that familiar with e.g. my own text-based Udemy type courses. I've used Claude Code for this extensively.

Something as simple as: "Create a 10-15 part course for me on LLMs, which includes some background on how they were discovered, how they're trained, fine-tuning methods and computation bottlenecks. Each chapter should build on previous chapters and at the end of each chapter there should be a short quiz." This can yield amazing results, and you can iterate on the style as you go through the course.

I've done a few of these until now and at the end of each chapter I ask it to save progress and to use my questions during the chapter to change its approach to presenting the content over time. For instance, if for some chapters it presented the math a bit superficially, I might tell it to include more worked examples or to test me more on actual calculations to ensure I've fully understood.

This has made it far more accessible and enjoyable for me to learn topics at a moderate depth that previously might have felt daunting.

3. Your patient, no-ego brainstorming partner

This is probably what I've gotten the most value from, personally. When I want to design a new system or some API, I present the problem I'm trying to solve to my favourite LLM of the week and ask it to come up with 3-5 different options for the solution, taking into account various constraints and it usually does a great job. That's amazing in and of itself. But my favourite part about this is that we can then discuss each of the options in detail (and I can provide it with options it hadn't thought about - I am still useful) and we can really dive deep into the trade-offs.

What really makes this great, though, is that the LLM has no ego and, when I'm working with it, neither do I. That's not to be underestimated. I've been a manager for part of my career and I've seen how important it is for team members to feel psychologically safe. But it's also a property that's built over time as team members gain trust with one another and learn to be vulnerable with each other. It isn't necessarily a given when you start working with new cross-functional partners. Of course, for seasoned software engineers, it's a bit easier to feel comfortable in their skin. But for more junior colleagues, it's likely not always the case (I know that for me it wasn't).

Some people don't want to ask questions because they fear that the answers are obvious (even though in most cases they're not) or because they don't want to waste someone else's time. But with an LLM, that's not a problem at all. You can ask "why?" 15 times and get a fundamental understanding for the reason something should be (or likely was) designed some way without worrying about how it makes you look or what more important jobs the LLM has to do, instead of explaining trivial design choices to you. For me this has been an incredible useful resource.