41–50 of 108 posts
> witr is successful if users trust it during incidents. > This project was developed with assistance from AI/LLMs [...] supervised by a human who occasionally knew what he was doing. This seems contradictory to me.
> witr is successful if users trust it during incidents. > This project was developed with assistance from AI/LLMs [...] supervised by a human who occasionally knew what he was doing. This seems contradictory to me.
The last bit > supervised by a human who occasionally knew what he was doing. seems in jest but I could be wrong. If omitted or flagged as actual sarcasm I would feel a lot better about the project overall. As long as you’re auditing the LLM’s outputs and doing a decent code review I think it’s reasonable to trust this tool during incidents. I’ll admit I did go straight to the end of the readme to look for this exact…
Earlier quoted context omitted.
The last bit > supervised by a human who occasionally knew what he was doing. seems in jest but I could be wrong. If omitted or flagged as actual sarcasm I would feel a lot better about the project overall. As long as you’re auditing the LLM’s outputs and doing a decent code review I think it’s reasonable to trust this tool during incidents. I’ll admit I did go straight to the end of the readme to look for this exact…
If you're capable of auditing the LLM’s outputs and doing a decent code review then you don't need an LLM.
Earlier quoted context omitted.
If you're capable of auditing the LLM’s outputs and doing a decent code review then you don't need an LLM.
Nobody who was writing code before LLMs existed "needs" an LLM, but they can still be handy. Procfs parsing trivialities are the kind of thing LLMs are good at, although apparently it still takes a human to say "why not using an existing library that solves this, like https://pkg.go.dev/github.com/prometheus/procfs "
Have you tried it? Procfs trivialities is exactly the kind of thing where an LLM will hallucinate something plausible-looking.
Fixing LLM hallucinations takes more work and time than just reading manpages and writing code yourself.
A quick note on scope: this is not meant to replace existing monitoring or observability tools. It’s designed for those moments when you SSH into a box and need to quickly understand “why is this running” without digging through configs, cron jobs, or service trees manually. Happy to answer questions or adjust direction based on feedback.
This is very clever. I've often needed to figure out what some running process was actually for (e.g. because it just started consuming a lot of some limited resource) but it never occurred to me that one could have a tool to answer that question. Well done. --- Edit: Ah, ok, I slightly misunderstood - skimmed the README too quickly. I thought it was also explaining what the process did :D Still a clever tool, but th…
Earlier quoted context omitted.
The last bit > supervised by a human who occasionally knew what he was doing. seems in jest but I could be wrong. If omitted or flagged as actual sarcasm I would feel a lot better about the project overall. As long as you’re auditing the LLM’s outputs and doing a decent code review I think it’s reasonable to trust this tool during incidents. I’ll admit I did go straight to the end of the readme to look for this exact…
If you're capable of auditing the LLM’s outputs and doing a decent code review then you don't need an LLM.
There's nothing wrong for a software engineer about using LLMs as an additional tool in his toolbox. The problem arises when people stops doing software engineering because they believe the LLM is doing the engineering for them.
However, I can’t use it in a production business environment for the same reasons other users mentioned earlier. A Debian or RPM package would be fantastic.
Earlier quoted context omitted.
Nobody who was writing code before LLMs existed "needs" an LLM, but they can still be handy. Procfs parsing trivialities are the kind of thing LLMs are good at, although apparently it still takes a human to say "why not using an existing library that solves this, like https://pkg.go.dev/github.com/prometheus/procfs "
> Procfs parsing trivialities are the kind of thing LLMs are good at Have you tried it? Procfs trivialities is exactly the kind of thing where an LLM will hallucinate something plausible-looking. Fixing LLM hallucinations takes more work and time than just reading manpages and writing code yourself.
Earlier quoted context omitted.
This is very clever. I've often needed to figure out what some running process was actually for (e.g. because it just started consuming a lot of some limited resource) but it never occurred to me that one could have a tool to answer that question. Well done. --- Edit: Ah, ok, I slightly misunderstood - skimmed the README too quickly. I thought it was also explaining what the process did :D Still a clever tool, but th…
Looking up the binary in the package management system would also provide another source of useful information. Of course this would dramatically increase the complexity but would, I think, be useful. If you could look it up using APT/dpkg first, that would be lovely :-)
Earlier quoted context omitted.
> Procfs parsing trivialities are the kind of thing LLMs are good at Have you tried it? Procfs trivialities is exactly the kind of thing where an LLM will hallucinate something plausible-looking. Fixing LLM hallucinations takes more work and time than just reading manpages and writing code yourself.
Claude code can read manpages too