[HN Gopher] My favorite use-case for AI is writing logs
___________________________________________________________________
My favorite use-case for AI is writing logs
Author : todsacerdoti
Score : 242 points
Date : 2025-07-17 23:38 UTC (23 hours ago)
(HTM) web link (newsletter.vickiboykis.com)
(TXT) w3m dump (newsletter.vickiboykis.com)
| cosmicgadget wrote:
| 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.
| specproc wrote:
| Yeah, the areas AI has provided real value to me are the simple
| things: logging, docstrings and cli stuff being the best
| examples.
|
| I can throw up a basic sketch, focusing on the code, and get it
| to add the quality stuff after.
| interroboink wrote:
| 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 "uber 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
| spiralcoaster wrote:
| > 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!
| BoiledCabbage wrote:
| > What you're describing is called: programming.
|
| Is that the part of programming that you enjoy? Remembering
| logger vs logging?
|
| For me I enjoyed the technical chalenges, the design, solving
| customer problems all of that.
|
| But in the end, focus on the parts you love.
| okayishdefaults wrote:
| This is a sign that the user hasn't taken the time to set up
| their tools. You should be able to type log and have it tab
| complete because your editor should be aware of the context
| you're in. You don't need a fuzzy problem solver to solve
| non-fuzzy problems.
| bitpush wrote:
| > user hasn't taken the time to set up their tools
|
| The user, infact, has setup a tool for the task - an "AI
| model", unless you're saying one tool is better than
| others.
| sodality2 wrote:
| Then it's a real bad case of using the LLM hammer
| thinking everything is a nail. If you're truly using
| transformer inference to auto fill variables when your
| LSP could do that with orders of magnitude less power
| usage, 100% success rate (given it's parsed the source
| tree and knows exactly what variables exist, etc), I'd
| argue that that tool _is_ better.
|
| Of course LLMs can do a lot more than variable
| autocomplete. But all of the examples given are things
| that are removing cognitive overhead that probably won't
| exist after a little practice doing it yourself.
| chrisweekly wrote:
| This. Set up your dev env and pay attention to details
| and get it right. Introducing probabilistic codegen
| before doing that is asking for trouble before you even
| really get started accruing tech debt.
| bitpush wrote:
| You say "probabilistic" as if some kind of gotcha. The
| binary rigidness is merely an illusion that computers put
| up. At every layer, there's probabilistic events going
| on.
|
| - Your hot path functions get optimized,
| probabilistically
|
| - Your requests to a webserver are probabilistic, and
| most of the systems have retries built in.
|
| - Heck, 1s and 0s operate in a range, with error bars
| built in. It isnt really 5V = 1 and 0V = 0.
|
| Just because YOU dont deal with probabilistic events
| while programming in rust, or python doesnt mean it is
| inherently bad. Embrace it.
| sodality2 wrote:
| We're comparing this to an LSP or intellisense type of
| system, how exactly are these probabilistic? Maybe they
| crash or get a memory leak every once in a while but
| that's true of any software including an inference
| engine... I'm much more worried about the fact that I
| can't guarantee that if I type in half of a variable
| name, that it'll know exactly what i'm trying to type. It
| would be like preparing to delete a line in vim and it
| predicts you want to delete the next three. Even if you
| do 90% of the time, you have to verify its output. It's
| nothing like a compiler, spurious network errors, etc
| (which still exist even with another layer of LLM on
| top).
| AdieuToLogic wrote:
| >> Introducing probabilistic codegen ...
|
| > Just because YOU dont deal with probabilistic events
| while programming in ...
|
| Runtime events such as what you enumerate are unrelated
| to "probabilistic codegen" the GP references, as
| "codegen" is short for "code generation" and in this
| context identifies an implementation activity.
| bitpush wrote:
| The scheduler that puts your program on a CPU works
| probabilistically. There are no rigid guarentees of
| workloads in Linux. Those only exist in real time
| operating systems.
| AdieuToLogic wrote:
| > The scheduler that puts your program on a CPU works
| probabilistically. There are no rigid guarentees of
| workloads in Linux. Those only exist in real time
| operating systems.
|
| Again, the post to which you originally replied was about
| code generation when _authoring_ solution source code.
|
| This has nothing to do with Linux, Linux process
| scheduling, RTOS[0], or any other _runtime_ concern, be
| it operating system or otherwise.
|
| 0 - https://en.wikipedia.org/wiki/Real-
| time_operating_system
| motorest wrote:
| > _This. Set up your dev env and pay attention to details
| and get it right. Introducing function declarations
| before knowing what assembly instructions you need to
| generate is asking for trouble before you even really get
| started accruing tech debt._
|
| Old heads cling to their tools and yell at kids walking
| on lawns, completely unaware that the world already
| changed right under their noses.
| wizzwizz4 wrote:
| We _know_ the "world has changed": that's why we're
| yelling. The Luddites yelled when factories started
| churning out cheap fabric that'd barely last 10 years,
| turning what was once a purchase into a subscription. The
| villagers of Capel Celyn yelled when their homes were
| flooded to provide a reservoir for the Liverpool
| Corporation - a reservoir used for drinking water, in
| which human corpses lie.
|
| This change is good for some people, but it isn't good
| for _us_ - and I suspect the problems we 're raising the
| alarm about also affect you.
| bayesianbot wrote:
| Honestly, I've used a fully set up Neovim for the past
| few years, and I recently tried Zed and its "edit
| prediction," which predicts what you're going to modify
| next. I was surprised by how nice that felt -- instead of
| remembering the correct keys to surround a word or line
| with quotes, I could just type either quotation mark, and
| the edit prediction would instantly suggest that I could
| press Tab to jump to the location for the other quote and
| add it. And not only for surrounding quotes, it worked
| with everything similar with the same keys and workflow.
|
| Still prefer my neovim, but it really made me realize how
| much cognitive load all the keyboard shortcuts and other
| features add, even if they feel like muscle memory at
| this point.
| scubbo wrote:
| I have seen people suggesting that it's OK that our
| codebase doesn't support deterministically auto-adding
| the import statement of a newly-referenced class "because
| AI can predict it".
|
| I mean, sure, yes, it can. But drastically less
| efficiently, and with the possibility of errors. Where
| the problem can be easily soluble, why not pick the
| solution that's just...right?
| motorest wrote:
| > Then it's a real bad case of using the LLM hammer
| thinking everything is a nail. If you're truly using
| transformer inference to auto fill variables when your
| LSP could do that with orders of magnitude less power
| usage, 100% success rate (given it's parsed the source
| tree and knows exactly what variables exist, etc), I'd
| argue that that tool is better.
|
| I think you're clinging onto low-level thinking, whereas
| today you have tools at your disposal that allow you to
| easily focus on higher level details while eliminating
| the repetitive work required by, say, the shotgun surgery
| of adding individual log statements to a chain of
| function calls.
|
| > Of course LLMs can do a lot more than variable
| autocomplete.
|
| Yes, they can.
|
| Managing log calls is just one of them. LLMs are a tool
| that you can use in many, many applications. And it's
| faster and more efficient than LSPs in accomplishing
| higher level tasks such as "add logs to this
| method/methods in this class/module". Why would anyone
| avoid using something that is just there?
| lmm wrote:
| In my experience consistency from your tools is really
| important, and AI models are worse at it than the more
| traditional solutions to the problem.
| rendaw wrote:
| I don't want to wade into the debate here, but by "their
| tools" GP probably meant their existing tools (i.e.
| before adding a new tool), and by "a fuzzy problem
| solver" was referring to an "AI model".
| paulmooreparks wrote:
| I know old timers who think auto-completion is a sign of a
| lazy programmer. The wheel keeps turning....
| motorest wrote:
| > This is a sign that the user hasn't taken the time to set
| up their tools.
|
| You are commenting a blog post on how a user set up his
| tools. It's just that it's not _your_ tool that is being
| showcased.
|
| > You should be able to type log and have it tab complete
| because your editor should be aware of the context you're
| in.
|
| ...or, hear me out, you don't have to. Think about it. If
| you have a tool that you type "add logs" and it's aware of
| best practices, context, and your own internal usage... I
| mean, why are you bothering with typing "log" at all?
| anon22981 wrote:
| To be perfectly fair saying "it's aware of the best
| practices, context and internal usage" is very
| misleading. It's aware none of those (as it is not
| "aware" of anything), and that is perfectly clear when it
| produces nonsensical results. Often the results are fine,
| but I see nonsensical results often enough in my more LLM
| dependant coworkers' PRs.
|
| I'm not saying not to use them, but you putting it like
| that is very dishonest and doesn't represent the actual
| reality of it. It doesn't serve anyone but the vendors to
| be a shill about LLMs.
| oneeyedpigeon wrote:
| I mean, "add logs" is twice as much work as "logs". I
| suspect you're implying a lot more, but you haven't
| really explained what you're referring to.
| goosejuice wrote:
| Or the user works with user-hostile tools. Some stacks,
| cloud providers, etc are absolutely horrible to use.
|
| There are many people out there that have absolutely no
| idea how horrible or great they have it.
| viraptor wrote:
| Tab complete what? No LSP will complete context-appropriate
| message and parameters without writing any of it. "What did
| the user want to log here" is inherently a fuzzy problem.
| oneeyedpigeon wrote:
| And a chatbot can consistently work out what I want to
| log faster than I can?
| viraptor wrote:
| Most of the time, yes. Since you refer to this as
| chatbot, I'm guessing you don't have much experience with
| things like cursor completion - give it a go before
| you're too negative.
| theshrike79 wrote:
| The LLM is just Intellisense on literal steroids.
|
| It can infer the correct logging setup from the rest of the
| project and add the most logical values to it automatically
| andy99 wrote:
| I like building stuff - I mean like construction,
| renovations. I like figuring out how I need to frame
| something, what order, what lengths and angles to cut.
| Obviously I like making something useful, but the mechanics
| are fun too.
| oneeyedpigeon wrote:
| I agree. This is like asking a carpenter "do you like
| sawing a plank of wood or do you like designing and
| creating a finished piece of work?" The answer is "both"--
| the low-level details may look tedious to those who don't
| have a true love for the work, but it's just a context
| switch to another deeply enjoyable aspect of the work as a
| whole.
| morkalork wrote:
| I actually take pride in the logs I write because I write
| good ones with exactly the necessary context to efficiently
| isolate and solve problems. I derive a little bit of
| satisfaction from closing bugs faster than my colleagues who
| write poor logs.
| noisy_boy wrote:
| > Is that the part of programming that you enjoy? Remembering
| logger vs logging?
|
| No but genuinely like writing informative logs. I have been
| in production support roles and boy does the lack of good
| logging (or barely any logs at all!) suck. I prefer print
| style debugging and want my colleagues on the support side to
| have the same level of convenience.
|
| Not to mention the advantages of being able to search through
| past logs for troubleshooting and analysis.
| sodapopcan wrote:
| > Is that the part of programming that you enjoy? Remembering
| logger vs logging?
|
| If you're proficient in a programming language then you don't
| need to remember these things, you just do it, much like
| spoken language.
| simonw wrote:
| I find there is a limit to the number of programming
| languages I can stay actively proficient in at any given
| time.
|
| I am using a much wider range of languages now that I have
| LLM assistance, because I am no longer incentivized to
| stick to a small number that are warm in my mental cache.
| MangoToupe wrote:
| Really? At some point syntax became kind of a vague sense
| of color on top of the data flow, which is ultimately the
| same in any language. I don't even recall what it means
| to be proficient in one language versus another--surely
| most career programmers can ramp up on any given syntax
| or runtime in a relatively short period of time. The hard
| part is laying out the data flow.
|
| Granted, AI can definitely ease that ramp-up time at the
| cost of lengthening it.
| kaibee wrote:
| > At some point syntax became kind of a vague sense of
| color on top of the data flow
|
| Thank you for this analogy.
| viraptor wrote:
| You still get to be proficient in an environment. I've
| got around 10 projects open in different Cursor windows.
| Logging in each of them is one or more of: logger.info,
| log.info, echo, eventLog.WriteEntry, console.log, syslog,
| printf, active_span&.set_tag, puts, rollbar.info, ...
| (and more)
|
| It's not the ramp up time. There's no problem with
| learning yet another one. There's a problem with
| remembering them all as you switch between the projects.
| Most of the time LLM will know exactly what to use, how,
| and what data I want to log. Which will take way less
| time than me rediscovering how a specific project I
| haven't seen in weeks does things.
| bubblyworld wrote:
| This isn't a language thing, it's a project thing. Language
| things I can do fluently (like the example of a for loop in
| the OP comment... lol). But I work on so many different
| projects that it's impossible to keep this kind of
| dependency context fresh in my head. And I think that's
| fine? I'm more than happy to delegate that kind of stuff.
| AdieuToLogic wrote:
| >> What you're describing is called: programming.
|
| > Is that the part of programming that you enjoy? Remembering
| logger vs logging?
|
| If a person cannot remember what to use in order to define
| their desired solution logic (how do I make a log statement
| again?), then they are unqualified to implement same.
|
| > But in the end, focus on the parts you love.
|
| Speaking only for myself, I love working with people who
| understand what they are doing when they do it.
| pyridines wrote:
| It's not unreasonable to briefly forget details like that,
| especially when you're dealing with a multi-language
| codebase where "how do I make a log statement?" requires a
| different pattern in each one.
| AdieuToLogic wrote:
| > It's not unreasonable to briefly forget details like
| that, especially when you're dealing with a multi-
| language codebase where "how do I make a log statement?"
| requires a different pattern in each one.
|
| You make my point for me.
|
| When I wrote: ... I love working with
| people who understand what they are doing when they
| do it.
|
| This is not a judgement about coworker ability, skill, or
| integrity. It is instead a desire to work with people who
| ensure they have a reasonable understanding of what they
| are about to introduce into a system. This includes
| coworkers who reach out to team members in order achieve
| said understanding.
| bowsamic wrote:
| It's not about focussing on what you love but about basic
| competence and being able to deal with simple programming
| problems
| MangoToupe wrote:
| Enjoying any part of this seems a little odd to me. The
| enjoyable part is using the thing you built. Regardless,
| programming (remembering logger vs logging, syntax,
| debugging) is certainly the easier end of things.
| endymion-light wrote:
| Yeah - a lot of these complaints feel like what I heard very
| early in my career about how you shouldn't learn python. The
| C learning I did was still useful, but I appreciate not
| artisanally crafting all my memory management by hand so that
| I can ship something that i've created faster
| eulgro wrote:
| I definitely would never use Python in production. But it
| remains an amazing tool for prototyping and writing quick
| dirty scripts.
|
| I can reasonably expect Python to be installed on every
| Linux system, the debugging experience is amazing (e.g.
| runtime evaluation of anything), there's a vast amount of
| libraries and bindings available, the amount of
| documentation is huge and it's probably the language LLMs
| know best.
|
| If there were two languages I would suggest anyone to start
| with, it would be C and Python. One gives a comprehensive
| overview of low-level stuff, the other gives you actual
| power to do stuff. From there on you can get fancy and
| upgrade to more advanced languages.
| endymion-light wrote:
| Oh 100%, there's definitely an important trade-off, and
| it's important to know. But there was definitely a
| cultural disdain and judgment for "why are you using
| python to create a simple side project - C is superior".
|
| It's still important to know both, and especially when I
| began working on aspects like multithreading I found my
| basis in C helped me learn far easier, but i'm definitely
| more supportive of the ship it mindset.
|
| It's better to have a bad side project online than have
| none - you learn far more creating things then never
| making things, and if you need LLMs and Python to do
| that, fine!
|
| I think it depends on how you approach these tools,
| personally I still quite focus on learning general,
| repeatable concepts from LLMs as i'm an idiot who needs
| different terms repeated 50 times in similar ways to
| understand them properly!
| theshrike79 wrote:
| Programmers love to pretend their crap needs to handle
| FFANG loads to give them an excuse to overengineer :)
|
| In many many cases Python will be perfectly fine until
| you hit absolutely massive loads, and even then you can
| optimise the hot path with something else while keeping
| the rest as is.
| dakiol wrote:
| If you remove all the tiny details that you detest because
| you think you should better spend your time on the "important
| stuff", be careful; you may wake up one day and not care
| enough about anything because you have been discarding stuff
| bit by bit.
| viraptor wrote:
| It could happen! https://youtu.be/y1aSqZ23ydk
| xdfgh1112 wrote:
| For me it's the opposite, I know exactly how to write log
| lines. It's just tedious. AI auto completes pretty much what I
| would have written.
| lmm wrote:
| If it's really that tedious and mechanical, there should be a
| code-level affordance for it (e.g. a macro, or something like
| https://github.com/lancewalton/treelog). Code is read more
| than it's written, and code that can be autocompleted isn't
| worth reading.
| danielbln wrote:
| That's just a different type of automation. We can argue
| all day about determinism and repeatability, but at the end
| of tue day we are all in the business of automation. We are
| arguing about the specifics.
| lmm wrote:
| > That's just a different type of automation. We can
| argue all day about determinism and repeatability, but at
| the end of tue day we are all in the business of
| automation. We are arguing about the specifics.
|
| Why choose to use something unreliable instead of using
| or writing something reliable? Isn't reliability the
| whole point of automation in the first place?
|
| And I think it's fairly widely accepted that you
| shouldn't check compiled binaries or generated code into
| your source control, you should check in the
| configuration that generates it and work with that. (Of
| course this presupposes that your generator is reliable)
| btown wrote:
| One of the things I love about computing and computer science
| is how the wide variety of tools available, built over multiple
| generations, provide people with the leverage to bring their
| highly complex ideas to life. No matter how they work best,
| they can use those tools as a way to keep their mind focused on
| larger goals with broader context without yak shaving every
| hole punched in a punchcard.
|
| You see a person whose conception of programming is different
| from yours; I see a person who's finding joy in the act of
| creating computer programs, and who will be able to bring even
| more of their ideas to life than they would have beforehand.
| That's something to celebrate, I think.
| nbbaier wrote:
| Well said!
| gopalv wrote:
| > who will be able to bring even more of their ideas to life
| than they would have beforehand.
|
| This is the core part of what's changing - the most important
| people around me used to be "People who know how".
|
| We're slowly shifting to "Knowing what you want" is beating
| the Know-how.
|
| People without any know-how are able to experiment because
| they know what they want and can keep saying "No, that's not
| what I want" to a system which will listen to them for
| without complaining supplying the know-how.
|
| From my perspective, my decades of accumulating know-how is
| entirely pointless and wiped away in the last 2 years.
|
| Adapt or fall behind, there's no way to ignore AI and hope it
| passes by without a ripple.
| anon7000 wrote:
| I agree at least a little bit, but let's be honest: the
| history of software engineering is a history of higher and
| higher levels of abstraction wrapping the previously
| levels.
|
| So part of this is just another abstraction. But another
| part, which I agree with, is that abstracting _how you
| learn shit_ is not good. For me, I use AI in a way that
| helps me learn more and accomplish more. I deliberately
| don't cede my thinking process away, and I deliberately try
| to add more polish and quality since it helps me do it in
| less time. I don't feel like my know-how is useless --
| instead, I'm seeing how valuable it is to know shit when a
| junior teammate is opening PRs with critical mistakes
| because they don't know any better (and aren't trying to
| learn)
| oldenlessons wrote:
| I like to read books on computers from the 70s and 80s.
| No trite analogies, just hard facts and diagrams. And
| explanations that start from scratch, requiring no
| previous knowledge - because there was none.
|
| The thing about these layers of abstraction is that they
| add load and thus increase the demand for people and
| teams and organizations that command these lower levels.
| The idea that, on a systemic level, higher abstraction
| levels can diminish the importance, size, complexity or
| expertise needed overall or even keep it at current
| levels is entirely misguided.
|
| As we add load on top, the base has to become stronger
| and becomes more important, not less.
| Cthulhu_ wrote:
| This is a good point. However, the base is relatively
| narrow; there are many, many more people working in the
| popular frameworks and languages like e.g. React or Java
| or what have you than there are people who work on the
| fundamentals and have that low level understanding. And
| I'm afraid people at that level are going to become rare.
|
| It's not hopeless though, it feels like that in the past
| decade, some of the smartest minds working at the lower
| levels of abstractions have come up with great new
| technologies. New programming languages that push the
| envelope of performance and security while maintaining
| good developer experience, great advancements in
| microchip technologies, that kinda thing.
|
| It's important to maintain access to universities and
| higher education, where people who have the interest and
| mindset can learn and become part of this base that
| powers the greater software market.
| oldenlessons wrote:
| I don't know. People working in web frameworks might be
| more visible, and more numerous than people working more
| low level stuff. But I don't think the latter is rarefied
| atmosphere at all. There are today several times more
| people working on those base levels than 10 or 20 years
| ago and I expect the trend to continue.
|
| Sure, they will enable even more people proportionally to
| not think about those low level systems. But my argument
| is that the need for that low level expertise has always
| expanded and will keep expanding.
|
| Automation entails tonnes of complexity that need to be
| managed. It doesn't just evaporate. More automatic
| systems will demand more people and teams to learn low
| level systems in great detail and at high levels of
| accuracy.
| goosejuice wrote:
| > From my perspective, my decades of accumulating know-how
| is entirely pointless and wiped away in the last 2 years.
|
| I find this very difficult to believe, but I have no idea
| what you do. I'm a generalist and this isn't even close to
| true for me with state of the art llms.
| oldenlessons wrote:
| Nothing has served me better over the past few decades
| than accumulating ever more detailed and accurate
| knowledge of what it is exactly that computers do under
| the hood.
|
| All the layers of abstraction are well intended and often
| useful. But they by no means eliminate the need to
| understand in detail the hard facts underlying computer
| engineering if you want to build performant and reliable
| software.
|
| You can trade that off at different rates for different
| circumstances but the notion that you can do away
| entirely with the need to know these details has never
| been true.
|
| More people being enabled to think less about these
| details necessitates more expertise to exist to support
| them, never less.
| raffraffraff wrote:
| I've found that if you're a novice coder you don't know
| what to ask for.
|
| Your decades of experience are probably a bit like mine:
| you sense the cause of a problem in an almost psychic way,
| based on knowledge of the existing codebase, the person who
| wrote the last update, the "smell" of the problem. I've
| walked into a major incident, looked at a single alert on a
| dashboard, and almost with a smile on my face identified
| the root cause immediately. It's decades of knowledge that
| allow to know what to ask for.
|
| Same with vibe coding: I've been having tremendous fun with
| it but occasionally a totally weird failure will occur,
| something that "couldn't happen" if you wrote it yourself.
| Like, you realise that the AI didn't refactor your code
| when you added the last feature, so it added "some tiny
| thing" to three separate functions. Then over several
| refactors it only updated one of those "tiny things", so
| now that specific feature only breaks in very specific
| cases.
|
| Or let's say you want to get it to write something that AI
| seems to have problems with. Example, assemble and manage a
| NAS array using mdadm. I've been messing with that recently
| and Google Gemini has lost the whole array twice, and
| utterly failed to figure out how to rename an array device
| name. It's a hoot. Just to see if it would ever figure it
| out I kept going. Pages and pages of over-and-back,
| repeating the same mistakes, missing the obvious. Maybe
| it's been trained on 10 years of Muppets online giving
| terrible advice on how to manage mdadm?
| johnisgood wrote:
| > I've found that if you're a novice coder you don't know
| what to ask for.
|
| And this is the reason for why I think I am productive
| with LLMs, and why people who know nothing about the
| underlying concepts are not going to be as productive.
| theshrike79 wrote:
| I've had the ... pleasure of working with outsourced
| talent for 20 years and I think it gives me an edge with
| LLMs
|
| Both will never push back or say no and will just rush
| headlong into implementing - something. They will use 57
| libraries when stdlib will do and make convoluted
| hierarchies when a simple functional program is enough.
|
| But both can produce very good results if you have
| predetermined limits, acceptance criteria and a proper
| plan and spec.
|
| Then you iterate in "sprints" and check the results after
| each one and challenge their output.
| johnisgood wrote:
| Yeah, in case of LLMs, I have never been told something
| is a bad idea, I had to point it out why it is a bad
| idea.
| fakedang wrote:
| As a counterexample, there's someone who vibe-coded a
| subscription adult website complete with payments and
| stuff, while having zero computer science experience
| while living in an RV. I can't find the link now,
| although last I saw on X, she was complaining about being
| blocked by trad finance after Bill Ackman's campaign.
|
| So yeah, it's absolutely possible. From personal
| experience, I was able to implement a basic scan and go
| application complete with payment integrations without
| going through a single piece of documentation.
|
| As long as you're ready to jostle for a bit in
| frustration with an AI, you can make something
| monetizable once you've identified an underserved market.
| theshrike79 wrote:
| Gemini CLI is like a fresh self taught coder on massive
| amounts of cocaine and adderall.
|
| Just last night I asked it to create a project plan as
| markdown files. It started writing to disk and I tabbed
| out to watch Squid Game
|
| When I came back it was 80% through implementation and
| was trying to fix some weird python async issue in a loop
| over and over again. I never told it to implement
| anything. But it will always - ALWAYS - rush into
| implementation unless you tell it not to with ALL CAPS.
|
| Google really needs to add a Claude style explicit plan
| mode for it...
|
| I interrupted it, gave the error to Claude Code, which
| fixed it in one go.
| oldenlessons wrote:
| What you are talking about here is accidental vs essential
| complexity as described by Brooks in the 80s.
|
| Your claim that LLMs do away entirely with accidental
| complexity and manage essential complexity for you is not
| supported by reality. Adding these tools to workflows adds
| a tonne of accidental complexity, and they still cannot
| shield you from all the essential complexity because they
| are often wrong.
|
| There have been endless noise made over semantics but the
| plain fact is that LLMs render output that is incongruent
| with reality very often. And now we are trying to remedy it
| with what amounts to expert systems.
|
| There is no silver bullet. You have to painstakingly get
| rid of accidental complexity and tackle essential
| complexity in order to build complex and useful systems.
|
| I don't understand what's so abhorrent about it that people
| invent layers and layers of accidental complexity trying to
| avoid facing simple facts. We need to understand computers
| and domains with high accuracy to build any useful software
| and that's how it's always been and how it's always gonna
| be.
|
| There is no silver bullet.
| bravetraveler wrote:
| Calling aptitude _" yak shaving"_ is certainly something to
| consider
| _alternator_ wrote:
| Yeah, it's also surprising because the user really shouldn't be
| using f-strings for logging since they get interpolated whether
| or not the log level is set to INFO. This is more important
| when the user is writing say, debug logs that run inside hot
| loops, which will incur a significant performance penalty by
| converting lots of data to its string representation.
|
| But sure, vibe away.
| blibble wrote:
| yep, putting user input into the message to be interpolated
| is asking for trouble
|
| in C this leads to remote code execution (%n and friends)
|
| in java (with log4j) this previously lead to remote code
| execution (despite being memory safe)
|
| why am I not surprised the slop generator suggests it
| astrange wrote:
| Format strings are very useful, so I'd suggest fixing the
| language to let you use them. You don't have to live with it
| interpreting them too early!
|
| Even better, you should be interpreting them at time of
| reading the log, not when writing it. Makes them a lot
| smaller.
| WD-42 wrote:
| The thing is, the logging calls already accept variable
| arguments that do pretty much what people use f-string in
| logging calls for already, except better. People see
| f-string, they like f-string, and they end up in logs,
| that's really all there is to it.
| yuliyp wrote:
| > you should be interpreting them at time of reading the
| log
|
| This reminds me of a fun interaction in browser devtools:
| you can log a complex struct to the console. The browser
| does not copy the entire nested structure when you do so
| immediately, meaning that if someone mutates that struct
| after it was logged, the value you see depends on when you
| expanded the nested struct.
| d0mine wrote:
| f""-strings for logging is an example of "practicality beats
| purity"
|
| Yes, f""-strings may be evaluated unnecessarily (perhaps,
| t-strings could solve it). But in practice they are too
| convenient. Unless profiler says otherwise, it may be ok to
| use them in many circumstances.
| jackblemming wrote:
| Heh, I get to totally dunk on this guy by calling him a
| vibe coder for not using lazy evaled string interpolation.
|
| Wait a second.. If I do ANY ACTUAL engineering and log out
| the time savings, it's completely negligible and just makes
| the code harder to read?
|
| It is complete insanity to me that literally every piece of
| programming literature over the past sixty years has been
| drilling the concept about code readability over unncessary
| optimizations and yet still I constantly read completely
| backwards takes like this.
| hiAndrewQuinn wrote:
| Having strong opinions on technical errata makes you
| sound smart and like you know what you're doing to the
| people who might want to hire you. Saying "I didn't
| bother to optimize this because it doesn't affect our
| bottom line" can be so easily reinterpreted as "I'm
| incompetent and never even thought about this angle in
| the first place". The OP has chosen an effective middle
| ground to communicate that they're serious about their
| work.
| _alternator_ wrote:
| Yeah, so like I said, it's not a problem, until it is. The
| gist of the article is that "LLMs let me add a lot of
| useful debugging messages to my logs", that's great, I use
| them for log messages too, but not with f-strings.
|
| The footgun is there. Hot-loop debug logging can cost a ton
| with f-strings, and an LLM can just as easily use the
| standard log formatting without this problem. Few people
| use a profiler prior to a production bug (or just end up
| with eye popping autoscaling bills).
|
| Shrug. I guess everyone can learn for themselves if it's a
| problem for them. But I've been there; it would be nice if
| the tools did better with best practices.
| 2muchcoffeeman wrote:
| Good news. You can get AI to refactor this sort of stuff away
| easily.
| webstrand wrote:
| I can totally write the logging code myself, but its tedious
| formatting the log messages "nicely". In my experience AI will
| write a nice log message and capture relevant variables
| automatically, unlike handwritten statements where I inevitably
| have to make a second pass to include a critical value I
| missed.
| skydhash wrote:
| I think we need to abandon this idea of writing code like a
| scribe copying a book. There's a plethora of tools ready to
| help you take advantage of the facts
|
| - that the code itself is an interlinked structure (LSPs and
| code navigation),
|
| - that the syntax is simple and repetitive (snippets and
| generators),
|
| - that you are using a very limited set of symbols (grep,
| find and replace, contextual docs, completion)
|
| - and that files are a tools for organization (emacs and vim
| buffers, split layout in other editors)
|
| Your editor should be a canvas for your thinking, not an
| assembly line workspace where you only type code out.
| phendrenad2 wrote:
| Yes but cognitive load is a real thing. Being free to not think
| about the proper format to log some generic info about the
| state of the program might seem like a small thing, but
| remember, that frees up your mind to hold other concerns. See
| well-trodden research that the human mind can hold roughly
| three to five meaningful items in working memory at once. When
| in the flow of programming, you probably have a complicated
| unconscious process of kicking things out of working memory and
| re-acquiring them by looking at the code in front of you. I
| think the author is correctly observing that they are getting
| the benefit of not having to evict something from their mental
| cache to remember how logging works for this particular project
| (especially egregious if you work on 10 codebases and they each
| use a different logger).
| fleebee wrote:
| How often do we print debug something that isn't just a
| single variable? I have defined a macro in my editor that
| expands into a nicely formatted logger call when I type "dbg"
| and the variable name. I can do it without thinking or losing
| focus.
|
| On the other hand, if I used an LLM to guess what I wanted to
| get logged (as the author did), I'd have to read and verify
| the LLMs output. That's cognitive overhead I normally
| wouldn't have.
|
| Maybe I'm missing something, but I just don't find myself in
| situations where I only vaguely know what I want to debug and
| would benefit from an LLM guessing what that could be.
| phendrenad2 wrote:
| Everyone's process if different, and by the way that
| applies to much simpler things, like peeling an apple. Ask
| 10 people to do something and they'll do it 10 different
| ways. And through the magic of availability heuristic, your
| comment was almost inevitable.
| conradev wrote:
| The author clearly dislikes writing logging code enough to put
| the work into creating a fine-tuned model for the purpose.
|
| I thought "making tools to automate work" was one of the key
| uses of a computer but I might be wrong
| bigstrat2003 wrote:
| One thing that has become abundantly clear from the AI craze is
| how many people - who do programming for a living - really
| don't like programming. I don't really understand why they got
| into the field; to be honest, it seems kind of like someone who
| doesn't like playing the guitar embarking on a career as a
| guitarist. But regardless of the reasons they seem to be pretty
| happy for a chance to not have to program any more.
| a_bonobo wrote:
| Do you like 'solving problems' or do you like 'getting into
| the weeds'? Both are valid, and both are common uses of
| programming.
|
| When I was younger, I loved 'getting into the weeds'. 'Oh,
| the audio broke? That gives me a great change to learn more
| about ALSA!'. Now that I'm older, I don't want to learn more
| about ALSA, I've seen enough. I'm now more in camp 'solving
| problems', I want the job done and the task successfully
| finished to a reasonable level of quality, I don't care which
| library or data structure was particularly used to get the
| job done. (both camps obviously overlap, many issues require
| getting into the weeds)
|
| In this framework, the _promise_ of AI is great for camp
| 'solving problems' (yes yes hallucinations etc.), but
| horrible for camp 'getting into the weeds'. From your framing
| you sound like you're from camp 'getting into the weeds', and
| that's fine too. But I can't say camp 'solving problems'
| doesn't like programming. Lot of carpenters out there who
| like to build things without caring what their hammer does.
| paulmooreparks wrote:
| Exactly this. I still "get into the weeds" without AI if I
| really need to dig into learning something new or if I want
| to explore some totally new idea (LLMs don't really do
| "totally new"). If I'm debugging a CRUD app, though... eh,
| it's sunny outside and I only have a couple more hours of
| daylight, so, AI it is.
| astrange wrote:
| I spent a very long time getting into the weeds to learn
| everything about computer architecture, because at the time
| it seemed like it was the only way to do it and I wanted to
| have a career. In the meantime social media / cloud hosting
| / StackOverflow were invented, it became much easier for
| people to write online, and it turned out I didn't need to
| do any of that because the actual authors have all
| explained themselves on it.
|
| Though, doing this is still the right way to learn how to
| debug things!
|
| nb I actually just realized I never understood a specific
| bit of image processing math after working on ffmpeg for
| years, asked a random AI, and got a perfectly clear
| explanation of it.
| skydhash wrote:
| I like solving problem. But I also want the problem to stay
| solved. And if I happen to see a common pattern between
| problems, then I build a solution generator.
|
| Maybe because I don't think in terms of code. I just have
| this mental image that is abstract, but is consistent. Code
| is just a tool to materialize it, just like words are a
| tool to tell a story. By the time I'm typing anything, I'm
| already fully aware of my goals. Designing and writing are
| two different activities.
|
| Reading LLMs code is jarring because it changes the pattern
| midway. Like an author smashing the modern world and middle
| earth together. It's like writing an urban fantasy and
| someone keeps interrupting you with some hard science-
| fiction ideas.
| Dilettante_ wrote:
| >I'm now more in camp 'solving problems', I want the job
| done and the task successfully finished to a reasonable
| level of quality
|
| To split the definitions one step further: That actually
| sounds not like you 'enjoy solving problems'(the process),
| but rather you 'enjoy not having the problem anymore'(the
| result).
|
| Meaning you don't like programming for itself(anymore?),
| but merely see it as a useful tool. Implying that your life
| would be no less rich if you had a magical button that
| completely bypassed the activity.
|
| I don't think someone who would stop doing it if given the
| chance can be said to "like programming", and certainly not
| in the way GP means.
| yunwal wrote:
| AI is not "a magical button" though. It's another tool to
| solve the problem, that allows you to get a bit less into
| the weeds (sometimes, until it messes up), essentially by
| giving you a bunch of reasonable default behavior.
| simonw wrote:
| One thing that has become abundantly clear from the AI craze
| is how many people who do programming for a living are
| actively hostile to fascinating new applications of computer
| science that open up entirely new capabilities and ways of
| working.
| probably_wrong wrote:
| I think you're painting with too wide a brush.
|
| Someone may say, like in this post, "AI makes my work
| easier", and that may be a valid point.
|
| Someone else may say "AI has made my work much harder" [1],
| and that's a valid point too.
|
| It may very well be that we'll find a place in the middle,
| but in the meantime it seem disingenuous to me to accept
| one side without acknowledging that the other is making
| valid points too.
|
| [1] https://news.ycombinator.com/item?id=44558665
| patates wrote:
| They are apparently also hostile to the people who just
| want to get things done. I may not love woodworking but I
| may still want to build my own damn boat.
|
| I personally love programming but I don't disrespect people
| who are in it because they need to be or even just feel
| like they need to be.
| sneak wrote:
| I love programming, but 90% of it is crappy toil due to
| language or tool design. I especially hate about 90% of the
| stuff one has to do to work around bad design decisions when
| writing significant amounts of python or javascript.
|
| Disliking toil is not the same as disliking programming.
| closewith wrote:
| Most software developers work in software because it's well
| paid and much easier to break into than other similarly paid
| jobs.
|
| Most software developers never write software outside of
| education or employment. That's completely normal.
|
| Even most recreational programming is to solve a problem.
| Very few developers write software for the pleasure of it and
| would happily use a magical "solve my problem" button
| instead.
|
| This is also true for all employers and customers.
|
| Honestly, it sounds to me that you fundamentally
| misunderstand the industry in which you work.
| gonzalohm wrote:
| Why would you work in a field that you have no interest in?
| Seems like a good way to get depressed
| closewith wrote:
| Most people work to support themselves and their
| families. Software's no different.
|
| Pay and conditions in software are so much higher than
| any vocation that it attracts many people who would never
| program recreationally. If that's not you and you are
| overjoyed to be able to write software everyday, that's
| fine. But you should recognise that you're in a tiny
| minority of developers.
| latexr wrote:
| > I don't really understand why they got into the field; to
| be honest
|
| Money. Startup hype. Thinking they'll be the next Zuckerberg
| (as if that'd be a good thing).
| viraptor wrote:
| > it seems kind of like someone who doesn't like playing the
| guitar embarking on a career as a guitarist
|
| Do you like playing guitar or do you like putting pressure on
| the correct length of the string at the specific distance
| from the fret?
|
| Do you like programming, or do you like manually typing out
| all the trivial details of each separate line? I've not found
| any pleasure in typing out the details of DTOs and their
| conversation functions repetitively by hand, for example.
| paulmooreparks wrote:
| I like having muscles. I hate lifting weights. I like being
| fit. I hate running. I like being able to play guitar and
| piano. I hate practicing. I like having food in my pantry. I
| hate grocery shopping. I like having custom software that fits
| my needs. I hate writing code.
| therein wrote:
| But this is using a machine to do the lifting for you so you
| don't develop the muscles. You are actually not strong
| through technology but left weak and helpless when left on
| your own.
|
| It is just a bunch of people that don't take pride in self-
| sufficiency. It is a muscle that has atrophied for them.
| paulmooreparks wrote:
| Yes, exactly.
| Disposal8433 wrote:
| "I'm a chef, I hate cooking, I buy readymade meals in the
| supermarket."
|
| You're right about the pride of writing actually good code.
| I think a lot about why I'm still writing software, and
| while I don't have an answer, it feels like the root cause
| is that LLMs deprive us of thoughts and decisions, our
| humanity actually.
|
| I have never felt threatened by an LSP or a text editor.
| But LLMs remove every joy, and their output is bad or may
| not what you wanted. If I hated programming, I would
| actually buy software as I don't have such precise needs to
| require tools perfect for those needs.
|
| No need to enjoy a good meal, AI will chew food for you and
| inject it in your bloodstream. No need to look at nature,
| AI will take pictures and write a PDF report.
|
| Tools help because they are useful. AI is in a weird
| position to replace every job, activity, and feeling. I
| don't know who enjoys that but it's very strange. Do they
| think living in a lounge chair like Wall-E spaceship is
| good?
|
| As for the article, it's yet another developer not using
| its tools properly. The free JetBrains code completion is
| bad, and using f-strings in logs is bad. I would reject
| that in a merge request, sorry. But thinking too much about
| it makes me sad about the state of software development,
| and sad about the pride and motivation of some (if not
| most) developers nowadays.
| Dilettante_ wrote:
| I do not (confidently) know how to make fire from
| "scratch". I do not know how to butcher or skin an animal.
| I do not know how to spin cloth, nor how to stitch it into
| clothing. My "finding the perfect kind of stone for
| knapping into a handaxe" muscles have fully atrophied.
|
| We live in a society. That means giving up self-sufficiency
| in exchange for bigger leverage in our chosen
| specialisation. I am 110% confident that when electric
| power became widespread, people were making the exact same
| argument against using it as you are making now.
| bowsamic wrote:
| Do you like doing anything? Sorry but it's just straight up
| bad if you only like results and hate the process to get
| there. That is not a fulfilling life
| adamhartenz wrote:
| You don't use auto-complete for for-loops? Wait... You use a
| compiled language, rather than writing machine code by hand?
| Some would call THAT programming.
| bravesoul2 wrote:
| Also logging is important! Send structured logs if possible.
| Make sure structure is consistent between logs. You may have to
| reach for some abstraction or metaprogramming to do this.
|
| All logs can be message, object and no need to format anything.
|
| That said ai saves typing time.
| ghurtado wrote:
| > What you're describing is called: programming.
|
| And once you have enough experience, you realize that
| maintaining your focus and managing your cognitive workload are
| the key levers that affect productivity.
|
| But, it looks like you are still caught up with iterating over
| arrays, so this realization might still be a few years away for
| you.
| jychang wrote:
| Yeah. This is a really weird complaint to be honest.
|
| By that standard, python is not real programming because
| you're not managing your own memory. Is python considered AI
| now?
| mym1990 wrote:
| Abstraction has always been a part of programming. Are you
| going to deride someone for not remembering how to write a
| sorting algorithm from scratch when .sort() is available? This
| is just another instance of that, trivial as it may be. The
| next abstraction level for programming is just natural
| language, if you want to try to gate keep that, have fun.
| skydhash wrote:
| Natural language to formal language is not a matter of
| implementation details, it's a matter of ambiguity where the
| definition of a term is contextual. Formalism is removing the
| dependency on context so that the semantic of a term or a
| proposition is embedded in itself.
|
| Formalism is so essential that we we use it to create
| spontaneous form of programming language (that we call
| pseudocode) to express some idea clearly.
| chvid wrote:
| The section you refer to is a justification for code completion
| and possible providing (visual) feedback for whether a various
| constructs are spelled or used correctly. It is fairly
| established that sort of thing increases programmer
| productivity (as in writing a Java program using notepad vs.
| writing it using IntelliJ).
|
| In the old days, we used to do this by using static type
| inference. This is harder to do in dynamic languages (such as
| Python), so now we try to do it with LLMs.
|
| It is not obvious to me that LLMs are a better solution; you
| may be able to do more but you loose the predictability of the
| classic approach.
| CafeRacer wrote:
| Yeah! And actually writing this inefficient code in python?
| Seriously? Be a man, write assembly.
| Cthulhu_ wrote:
| > What you're describing is called: programming. This can't be
| serious
|
| What that statement is telling me is that the author at one
| point didn't consider logging to be a fully fledged formal non-
| functional requirement, more of an optional and/or informal
| side chore.
|
| I used to work at a company that built software for mobile
| networks; their entire C codebase was full of logging
| statements, pretty much every step made in processing a signal
| was logged. Probably as a form of tracing, and automated
| instrumentation would possibly have been a better solution, but
| they were a bit old fashioned.
| timcobb wrote:
| I relate to this. The cognitive overhead of a for loop is,
| honestly, way less for me writing a log. There's something
| about writing logs that's a PITA.
| nojito wrote:
| > What you're describing is called: programming.
|
| If you feel copying and pasting documentation is programming,
| you're gonna have a really rough time.
| wiseowise wrote:
| What you're describing is useless noise that shouldn't even be
| a blip on my radar.
|
| Programming is solving a problem, not learning 20 different
| ways to say Log, logger, lumber, timber, and whatever else
| "creative" name writer of logger library chose to use.
| AmazingTurtle wrote:
| came here to say this. I don't want to wrap my head around
| writing pretty logs and involving all the variables I want to
| eventually see in my logs. I just want to "dump it" and keep
| writing main logic
| theshrike79 wrote:
| Exactly, I switch between multiple languages, projects and
| library conventions daily.
|
| I can't be arsed to remember how I add parameters in which
| type and did this one have context or not.
|
| Just today I got bit (again) by the fact that the Go log
| library doesn't have Debug as an option. And I've been
| writing Go for a decade. (log/slog does have levels though)
| Viliam1234 wrote:
| > 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 am old enough to remember people complaining about having to
| write a semicolon at the end of each line. Or declare a
| variable...
| cratermoon wrote:
| AOP solved this 30 years ago, though.
| nvader wrote:
| 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?
| nxpnsv wrote:
| It looks great out of the box, has fancy colors (if you want
| them). It is easier to configure than logging and you don't
| need a lot go get_logger stuff. It does log rotation, and you
| has lazy formatted {} comments `logger.info("x={x:.2f}", x)`.
| It is better for threading/multiproc, handles exceptions
| better. And it is fast. I like it on appearance.
| greatgib wrote:
| 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.
| nxpnsv wrote:
| The {} syntax is better, and more similar to f-strings. And you
| don't have to use that backtrace. I use it to send json for
| some batch jobs, or have it write to google cloud logger for
| gcp jobs. Are you holding it wrong?
| greatgib wrote:
| It's totally subjective that it is better. It's not like it
| can "execute code" inline like f-string. Just the replacement
| character is the same, end of the comparison. And any way the
| point is that more that it totally breaks the general
| convention for no valid reason. It's not even optional.
|
| For gcp jobs you can just output the structured log in the
| standard output so I don't see the purpose here. There are
| other structured logging libraries if this is what you need.
|
| For the backtrace yes, because logging.exception will be
| broken by default and all tools that process the backtrace
| automatically like sentry. And again, for no valid reason
| except than "look, my traceback looks so much cooler on my
| screen because I added crap and new lines when printing
| it"...
| nxpnsv wrote:
| I don't care too much about % vs {} . I have stuff where i
| need nice logs locally, and structured logs in batch, for
| me loguru made that easy. I don't think it's a terrible
| thing at all, but you do you :)
| spencer-p wrote:
| 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.
| lblume wrote:
| From how I read it dropping imports happens for every language.
| arscan wrote:
| 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.
| Spivak wrote:
| Python programmers, don't use f-strings for your logs.
| # yes logger.info("Super log %s", var) # no
| logger.info(f"Super log {var}")
|
| I know, it's not as nice looking. But the advantage is that the
| logging system knows that regardless of what values var takes
| that it's the same log. This is used by Sentry to aggregate the
| same logs together. Also if the variable being logged also
| happens to contain a %s then the f-string version will throw an
| exception. It doesn't matter because f-strings are so fast but
| the % method is also lazy and doesn't interpolate/format if it's
| not going to be logged. Maybe in the future we'll get to use
| template strings for this.
| bbkane wrote:
| Thanks for the reasons! I've been using f-strings because
| they're easy to keep track of, but you make really good
| arguments (I hadn't thought of Sentry/similar systems using %s
| to aggregate logs)
| WD-42 wrote:
| They aren't just arguments, it's facts. f-strings in logs,
| especially in a hot code path, can be really bad for
| performance.
| bbkane wrote:
| I've been lucky enough to not need Python in a perf-
| sensitive project
| nxpnsv wrote:
| Well if you use loguru (and really you should, it is awesome)
| you would use, `logger.info("Super log {var}", var=var)`
| (possibly without the keys). It is also lazy and works better
| for structured logs.
| suriya-ganesh wrote:
| 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
| Disposal8433 wrote:
| Do you use a debugger?
| suriya-ganesh wrote:
| I do, but logs are better.
| Guid_NewGuid wrote:
| 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.
| gbalduzzi wrote:
| I think we are overcomplicating this a bit.
|
| Typing "log" and tab to accept the auto complete is faster than
| writing the whole log yourself.
|
| When you need to add a bunch of log statement, this tool makes
| the activity faster and less tedious.
|
| Is it a technological breakthrough? No
|
| Does it save hours of developer time each day? No
|
| Is it nice to have? Hell yeah
| fudged71 wrote:
| Tangential, but making the logs understandable by the LLM is also
| very useful
| TZubiri wrote:
| 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.
| whyenot wrote:
| > 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.
|
| ...or something more like this? 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
| spapas82 wrote:
| 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?
| andutu wrote:
| 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!!!
| physicles wrote:
| 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...
| nxpnsv wrote:
| It does well but also sometimes gets it completely wrong but
| plausible looking. Together, we managed to make several quite
| intricate bugs. About two months in, I actually don't think my
| coding speed increased much from using Cursor - and I just
| can't take "Perfect, ..." "You're absolutley right, ..." - even
| with custom rules to supress it, it just can't help itself.
| Animats wrote:
| 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.
| djmips wrote:
| Microsoft was using 'AI' in the 90s?
| badsectoracula wrote:
| AI and ML aren't new, they were already well established by
| the 90s. For example the book from which i first learned
| about neural networks[0] was written in 1997.
|
| [0] https://www.cs.cmu.edu/~tom/mlbook.html
| Animats wrote:
| Classifiers go back that far.
| closewith wrote:
| Expert systems and decision trees were AI in the '90s.
|
| Remember, it's only AI until it works.
| neuroelectron wrote:
| An example of the output would be very helpful
| swiftcoder wrote:
| Programmer apparently never learned about "import ... as" syntax,
| adopts fuzzy LLM autocomplete instead. News at 11
| swiftcoder wrote:
| And look... I do get it. I have to switch between
| rust/typescript/python on the regular, and 3x sets of quirky
| syntax is a lot to keep in working memory.
|
| I'd rather simplify our software stacks than accept that an
| autocomplete that lies to me is the only tractable solution,
| though
| MagicMoonlight wrote:
| I thought this was going to be about an AI which actually writes
| useful logs for your program. Eg if it crashes, it explains in
| normal language what happened.
| pandemic_region wrote:
| > I've been a happy JetBrains customer for a long time now, and
| it's because they ship features like this.
|
| The Goland and Pycharm experience must be radically different
| from the Java experience then.
| voidUpdate wrote:
| Visual studio added the single line autocomplete thing a while
| back and it lasted about 2 days before i turned it off because it
| was frequently wrong and just got in the way. I often use the
| double tab template insert feature, but that would often accept
| the incorrect autocomplete instead, so i had to delete it and try
| again
| specproc wrote:
| Totally agree, this behaviour is maddening. I set a hotkey to
| toggle completions, made it useful again.
| i_niks_86 wrote:
| Could full-line code completion and smarter log inference change
| how developers approach debugging and monitoring altogether? If
| so, how?
| andrelaszlo wrote:
| I would have flagged that they're logging their Redis URL, if I
| was reviewing this. Most of the time this includes credentials.
|
| Normally I think it's a bit rude to criticize the code of blog
| posts, bit I thought it was relevant here for these reasons:
|
| "I often don't even remove when I'm done debugging because
| they're now valuable in prod" - think about where your production
| credentials end up. Most of the time, logging them won't hurt,
| just like keeping your password on a post-it doesn't hurt most of
| the time.
|
| The arguments about letting an AI reduce the mental overhead is
| compelling, but this shows one of the (often mentioned) risks:
| you didn't write it so you didn't consider the implications.
|
| Or maybe the author did consider it, and has a lot of good
| arguments for why logging it is perfectly safe. I often get
| pushback from other devs about stuff like this, for example:
|
| - We're the only ones with access to the logs (still, no reason
| to store credentials in the logs)
|
| - The Redis URL only has an IP, no credentials. (will we remember
| to update this log line when the settings.redis_url changes?)
|
| - We only log warnings or higher in production (same argument as
| above)
|
| Maybe I should stop worrying and learn to love AI? Human devs do
| the same thing, after all?
| WhyNotHugo wrote:
| You should not use f-strings for logging, because that performs
| all the formatting _before_ the logging module determines if the
| log needs to be printed. You want the formatting overhead to
| happen only for logs that will get printed. You can't achieve
| that with f-strings, just use normal logging calls.
|
| It kinda speaks bad of the auto-completion that it suggests such
| anti-pattern.
| HAMSHAMA wrote:
| You can do this with the new t strings! They're like f strings,
| but a template instead. https://peps.python.org/pep-0750/
| BiteCode_dev wrote:
| I have a /addlogs claude command just for that. Logging is mostly
| boiler plate, I'm glad I can outsource it.
| mbanerjeepalmer wrote:
| LLM-written code is typically over-commented and under-logged. So
| much so that I've given up pleading with them to stop commenting
| and start logging. Instead I say 'Great, now that you've written
| the code please replace the comments with logs.'
| yason wrote:
| People, in their excitement to play with or write cool tools to
| automate boring details in the programming process, often
| underestimate the value of boring grunt work.
|
| While what you're doing consciously is something simple you're
| simultaneously also mucking about in your codebase in the "spinal
| cord level", or spending quality time with your creation. It's
| times like those when bigger/other things often click together
| the first time all the while you're doing something that's
| seemingly just grunt work.
| ButOneDuck wrote:
| I get that writing logs can be incredibly frustrating, but most
| of the time people are looking at logs because either something
| went wrong, or they have a hunch that the program is misbehaving
| and they're looking for a clean sign or signal that they are on
| the right track. If I've spent multiple hours on someones broken
| piece of code, the last thing I want to be thinking is "did some
| non-deterministic chat-bot write this?", "are these logs even
| internally consistent?", "Why does this log mention code that
| doesn't exist?".
|
| I get that is most devs least favorite part, but logs and errors
| are supposed to be unshakable, ground-truth understandings,
| things that point you to the light in a dark room of broken
| spaghetti code and misunderstandings.
|
| Think about this from a users or a testers perspective, can you
| imagine the compounding frustration you would experience? To be
| chasing a skein of understanding through wall of text that you
| only mostly understand, to find out that the hunch was based on a
| red-herring by a dev who wasn't bothered to help you in return.
|
| Not to mention the amount of non-bugs you are generating for
| yourself in the future, we already have bug bounties being
| swarmed by LLM-gen faux-bugs, how is anyone supposed to reason
| about real bugs if the logs are only tangentially related to the
| truth?
| marcellus23 wrote:
| > "did some non-deterministic chat-bot write this?", "are these
| logs even internally consistent?", "Why does this log mention
| code that doesn't exist?".
|
| This is the same complaint about all AI-generated code, the
| simple answer to which is, review the code yourself before
| committing. Or if it's a real project, it'll get reviewed by
| someone else anyway, same as any other code that could have a
| mistake in it.
___________________________________________________________________
(page generated 2025-07-18 23:02 UTC)