Depending on which social bubble one is into, people are drawn to letting LLMs do everything. Latest tools promise to fully configure or even manage entire server setups. While that sounds amazing (and I want to try it out some time) that approach has some downsides:
- Loss of control: I don’t really know what’s happening under the hood. If something breaks, I’m left in the dark.
- Loss of Learning: I want to know / learn how and why things (don’t) work.
- Digital Sovereignty: Relying on an external connection is creating a hard dependency that I want to avoid. And hosting my own LLM isn’t an option as my mini PC doesn’t have the RAM or power for that.
So, while these tools are impressive, they’re not for me — at least not now or not in my private useacse of maintaining my main home-server.
But, that’s no reason to not leverage it at all!
Learning by Watching
Over the weekend, I stumbled upon a stupid issue: I was testing some new services on my mini PC, and at some point, things just stopped working. No clear error, no obvious misconfiguration — just a frustrating dead end. I was about to give up and reset all the config to my last checkpoint (which was – quite long back) when I decided to try something different:
I gave Mistral Vibe access to my system — but not control.
So what I did:
- I started Mistral Vibe in my
/optdirectory where all my services are configured (configs, docker-compose.yaml, …). - I described the issue like “This service isn’t working as expected. What could be wrong?”
In hindsight, I should have been more precise and add “Explain in each step why you are checking this and what you learned from the outcome for the next step“. - And then I started the (hopefully) fixing session. Mistral asked at every command if it is allowed to be executed once or always in this session. I always allowed “once” because
- I wanted to be sure it’s not going mad!
- I wanted to learn WHAT it was doing (and had I instructed properly, I could have read WHY …) and make up my mind about how the error was narrowed down by it – remember: I had run out of ideas myself already.
- I wanted to see the outcome
Together ee went through docker logs, checked running processes, connected to the shells in the contianer checking the inside-out connectivity and iterated through possible causes. And at each step, I asked myself:
- Why are we running this command?
- What information does it give us?
- How does this help narrow down the problem?
- DOES IT BREAK ANYTHING?
In the end, Mistral identified a conflicting configuration — one I had overlooked, and even if I had seen it, I wouldn’t have had a clue which of the values would take precedence over the other …
In the end, the service started working, and I had a clear summary of what went wrong. Luckily I didn’t have to ask a “give me a summary what went wrong” but it did it by itself. And I had learned a couple of ways to debug such scenarios.
Learn, Not Just Fix
This experience was prette new to me! The trick wasn’t to blindly trust the LLM or fully hand over control. Instead, it was about using the LLM as a learning partner by:
- Giving it context (logs and configs)
- Staying in the loop by executing commands one after the other, with enough time for me to understand what was going on.
- Learning from the process by watching the possibilities.
Honestly: my past experiences with Linux debugging withLLMs were … well .. disastrous at best. But I never gave them enough context and this problem had a good scope because it HAD to be one of the config files in this directory and not some system setting SOMEWHERE else. – So there was also a good amount of paranoia involved as well.
But this time and this way, it went well, I learned something, it worked, I have not created a dependency …
And each time I allowed to read a .env file, I noted it to change all credentials n this file afterwards … Even if I pay my subscription and learning from is disallowed .. Mistakes can happen everywhere. Better be safe than sorry.
