I've been meaning to put together a collection of a few different ways in which I've integrated LLMs into my workflow since they were introduced. Today I finally managed to carve out time to actually do this writeup.
The usual disclaimers apply here: this is how I am using them so your mileage may vary, this is a subset of how I'm using them, and everything in this blog post is subject to change over the next few months (weeks?). Also, this post is about what I'm using LLMs for and not how I'm using them. Let's go.
1. Improving my written German communication
German is my second language (well actually, my third language). While I think my German is fairly good, writing formal emails is where I sometimes struggle.
It also happens that part of my job includes communicating with some of our company's clients to do some requirements gathering. And one thing that I really don't want to do is to make mistakes when exchanging emails with them, because I have this (maybe irrational?) fear that making grammatical mistakes in such communication may cost our company some ARR. It hasn't happened so far, but I guess you never know.
LLMs are really good at this. Checking grammar is one thing, but what I'm really looking for here is to improve the overall tone of the email. I usually write a first draft of the email myself, paste it into Gemini, and iterate from there. Somehow Gmail's native "polish" functionality has never given me good results.
I should mention that this only works because my German is good enough that I can judge the LLM's output.
2. Writing boilerplate code
Programming is another situation where I've been incorporating LLMs more and more.
One good example is writing boilerplate code. Over the past couple of years I've worked
a lot with Django and Django REST Framework when building backend APIs. Building CRUD
API endpoints for objects in the database tends to be a lot of boilerplate code. You
have to write the model definition, then a ViewSet, then associated access policies,
the JSON serializer, the URL routing entry, and finally the test cases.
If you've done this once, doing it over and over again starts feeling like a chore, almost like a waste of time.
Just yesterday, I wanted to build out a CRUD endpoint for a specific table, that would've taken me probably a couple of hours if I had to build it out by hand. But I pointed Claude at the model definition (which I had written by hand) and asked it to do everything else so there's an API accessible at a specific endpoint, and it took all of 5 minutes to get it done.
I find this to be an extremely valuable time save.
3. Working on complementary skills
My main area of focus is developing backend software and infrastructure components. While I'm reasonably comfortable with writing half-decent UI code, that's not my core skill.
It turns out, LLMs are good-ish at it! And good-ish is much better than my level of skill in this area.
For instance, one website I maintain is ATproto Alternatives. When I started out, I used Tailwind CSS and Daisy UI to build the initial version. Almost immediately, it was obvious that it's built by someone who has basically no idea what good UI looks like. It looked like the stereotypical "designed by a backend developer" website.
A few days ago, I pointed GLM 5.1 (via OpenCode Go) at the project's codebase and asked it to give me a few different ideas of how the UI of this project can be improved. It gave me a few different directions, and I asked it to prototype all three. I then reviewed all three branches and merged the one that I liked the most, which was fun! This was a very good example of an LLM complementing my skillset.
This was a quick (non-exhaustive) list of what I'm using LLMs for. The field is changing extremely quickly, so as I wrote earlier, there's a strong chance that this blog post would look a lot different in just a few months.
All in all, I'm having fun with this new technology and I'm really curious to see what the landscape will look like in a year!