My favorite use-case for AI is writing logs

> The amount of cognitive overhead in this deceptively simple log is several levels deep: you have to first stop to type logger.info (or is it logging.info? I use both loguru and logger depending on the codebase and end up always getting the two confused.) Then, the parentheses, the f-string itself, and then the variables in brackets. Now, was it your_variable or your_variable_with_edits from five lines up? And what’s the syntax for accessing a subset of df.head again?

What you're describing is called: programming. This can't be serious. What about the cognitive overhead of writing a for loop? You have to remember what's in the array you're iterating over, how that array interacts with maybe other parts of the code base, and oh man, what about those pesky indices! Does it start at 0 or 1? I can't take it! AI save me!

The thing I like here is that it runs locally. I use Vim keyword completion[1] a lot for next-word completion. It does a broadly similar sort of "look at surrounding code to offer good suggestions" thing (no LLM stuff, of course). It's wrong often, but it's useful enough that it saves me time overall, I feel.

So, this sounds to me like an expanded version of that, more or less.

I think I'd prefer an AI future with lots of little focused models running locally like this rather than the "über models in the cloud" approach. Or at least having such options is nice.

[1] https://vim.fandom.com/wiki/Any_word_completion

There's also omni-completion, a bit more advanced: https://vim.fandom.com/wiki/Omni_completion

Tab autocomplete in Cursor is surprisingly good at guessing what I want to log when I type slog.Info. I’m enjoying that time save.

I agree with K&R about debuggers: when writing services that you need to debug in prod, you live and die by your logs. That said, sometimes an interactive debugger is faster than adding logs, like when you’re not sure about the precise call stack that leads to a given point, or there’s a bunch of stuff you need to keep track of and adding logs for all of it is tedious. But pretty quickly you can hit a point where you’re wasting more time in the debugger than it would’ve taken to add those logs…

Usually, people use AI for reading logs, looking for interesting events or patterns. That goes way back. Microsoft was using it to classify and group similar crash dumps back in the 1990s.

Rust lets you write a default debug print for each struct, and will generate one if asked. So you don't have to write out all the fields yourself. That's enough to do the annoying part of the job.

Automates a tedious, time-consuming task. Easy to catch and correct failures. Love it. My only concern is (other than maybe verbosity) is of my log writing moments are opportunities to briefly reflect on what I have written, and maybe catch problems early.

On the one hand writing logs can be tedious. Essentially logs are breadcrumbs signifying when significant state changes have logically taken place. From what I've seen, logs are added after every few lines and I always fantasized about creating a language where logging is "automatic".

On the other hand, writing logs is a skill worth mastering. Wrote too many and when a service crashes you have to shift through lots of noise and potentially miss the signal. I once went down a rabbit hole trying to root cause an issue in a Gunicorn application that had custom health check logic in it. An admin worker would read health check state from a file that worker threads wrote to. Sometimes a race condition would occur, in which an error log would be emitted. The thing was, this error wasn't fatal and was a red herring for why the service actually crashed. Of instead it would have been logged at the debug level a lot of time would have been saved.

Fine let LLMs write code but take logging seriously!!!

An example of the output would be very helpful

The use of AI for this seems somewhat overkill, one could just use a language and environment that is aware of whether `logger` or `logging` is available, and what variables are in scope. We have tools that allow us to treat programming as more than guessing the next character at random. Rather they allow you to offload tracking this context to the machine in a reliable way, typed languages and auto complete.

I do wonder if this is part of the divide in how useful one finds LLMs currently. If you're already using languages which can tell you what expressions are syntactically valid while you type rather than blowing up at runtime the idea a computer can take some of the cognitive overhead is less novel.

Programmer apparently never learned about "import ... as" syntax, adopts fuzzy LLM autocomplete instead. News at 11

An aside, but it’s quite unfortunate that logger.info and logging.info are automatically linkified because of the .info TLD in this case. I don’t recommend clicking on those links.

This is interesting, I like the way jetbrains is using the local models for auto completion.

Do you know if there's a similar solution for vscode?

I appreciate how the author highlighted the python domain-specific tricks like dropping imports and rewriting tabs/spaces. It's good to be reminded that even with "large" language models you can get better results with quality over quantity.

Python programmers, don't use f-strings for your logs.

    # yes
    logger.info("Super log %s", var)
    # no
    logger.info(f"Super log {var}")

Tangential, but making the logs understandable by the LLM is also very useful

This tracks with how I've been doing my debug logs.

I ask the model to create tons of logs for a specific function and make sure there's an emoji in the beginning to make it unique (I know HN hates emojis).

Best thing of all, I can just say delete all logs with emojis and my patch is ready. Magical usage of LLMs

I'd like to consult the HN hive mind on an tangential point.

Does anyone else here dislike loguru on appearance? I don't have a well-articulated argument for why I don't like it, but it subconsciously feels like a tool that is not sharp enough.

Was looking for evidence, either way, honestly. The author is using loguru here and I've run into it for a number of production deployments.

Anyone have experiences to share?

Loguru sucks very badly! I would advise you not to use it. It is like trying to not do like everyone else, but still doing in a terribly wrong way ...

For example the backtrace try to be cooler for display but are awful, and totally not appropriate to pipe in monitoring systems like Sentry.

In the same way, as you can see in the article, that is the only logging library that doesn't accept the standard %-string syntax to use instead its own shitty syntax based on format.

I once wrote a simple python program that logged all execution, self inspected code and printed code and variables as output.

Then I learned why programs don't do that by default.

Not to be snarky, but when you become more experienced you will figure out that logging is just writing to permanent storage, one of the most basic blocks of programming, you don't need a dependency for that, writing to disk should be as natural as breathing air, you can do print("var",var). That's it.

If you are really anal you can force writing to a file with a print argument or just a posix open and write call. No magic, no remembering, no blogpost. Just done, and next.

AOP solved this 30 years ago, though.

[dead]

> My favorite use-case for AI is writing logs

You mean like this?

    [2025-07-17 18:05] Pallet #3027 stacked: Coast‐live oak, 16" splits, 0.22 cord.
    [2025-07-17 18:18] Moisture check → 14 % (prime burning condition).
    [2025-07-17 18:34] Special request tagged: “Larina—aromatic madrone, please!”
    [2025-07-17 18:59] Squirrel incident logged: one (1) cheeky Sciurus griseus absconded with wedge.

    Base-10 (log10) handy values
    --------------------------------
    x        log10(x)
    ------------------
    2        0.3010
    e        0.4343
    10       1.0000
    42       1.6232
    1000     3.0000
    1e6      6.0000