Seems very much like your goal was to rain on a parade.

Not trying to rain on someone's parade, but the only reason I would care about HN comments nowadays is to feed them to my model of choice and let it generate the contrarian hot takes it's supposed to be generating. So it's not like I am willing to read through this thread and think to myself "I cannot wait to pick up some new ways of complaining about documentation." I'm the Editor-in-Chief to my synthetic pundit army now.

I guess you would type out a comment manually every now and then for your own enjoyment, but at that point do you really care about comments at scale?

---

EDIT (above is a joke) It's very important that every time you find something that is of no use to you, you write a comment explaining that this link is of no interest to you, discouraging people from things you have no interest in. Monoculture for all!

> I'm the general to my agentic army now.

What have you produced with your agentic army? Would you like to share with the class?

The point of style guides is to optimize for readability despite a cognitively diverse workforce coding in the same repos.

I would think they're probably even more meaningful in an agentic world.

Shitty generals can't review meaningfully review the work of their troops.

On top of that all, I just enjoy programming itself. It's less and less of the meat of a software job over time, but I was coding before I got paid for it, and I'll probably keep coding well after I can get paid for it.

First paragraph: “includes guidance on API and implementation design”

It seems to me that if the intent is not just to produce code but also to operate it, having the different pieces behave in a similar, predictable way is kind of nice. Whether the software is written by AI or humans.

I'm not sure I really agree with your main point (I think it's probably still important for LLM-generated code to be generally human-understandable, at least if you care about long-term maintainability), but setting that aside to answer this question:

> I guess you would code manually every now and then for your own enjoyment but at that point do you care about style guides written for scale?

I think they're still quite valuable in that case, for a couple reasons:

- When learning a new language (which happens much more frequently when writing code "for pleasure," as it were), "written for scale" guidelines still translate pretty well to "written for oneself" IME. At the very least, they tell you what to expect in code you read, and give you a reasonable starting point as you develop your own taste and stylistic preferences.

- I've noticed some open source projects beginning to institute anti-AI contribution guidelines, and such projects still benefit from codified style guides. Google obviously doesn't fall under this category themselves, but in other language ecosystems, their style guides tend to find use in OSS projects.

Are you saying that you don't ever look at the code once it's been generated?

This is what we do in my company, give the guidelines to the model. Unfortunately, the model isn't always following them and it's impossible to enforce them manually. There's too much code to review, the code is generally low quality, and is more often than not auto-approved by AI.

Unless you're working on your own project on which you have full control, or you have a strong authority figure in your company who cares about that, it's a lost battle.

It's sad for anyone who love their craft, but tbh I'm not even sure it matters anymore for most projects.

This is a sub-case of the general one that is narrowing the interpretation of things. A big infinite amount of things can be true or false, only one can be a Rust variant.

grownups with important jobs write C

The good emotions come with the confidence in the engineering quality that it gives you as output (once you overcome the friction, which AI can help you big time to achieve).

Maybe one or two line functions are a totally different scale than "all source code files in a crate"? So like, one is problematic in a way the other is not. And the guidance is "prefer small," not "always super tiny." See: "Larger crates are allowed" later on. And also see: "Rationale: Fine-grained library targets are recommended in Chromium due to the massive size of our codebase, non-local effects of adding dependencies in the build graph, and to improve performance of parallel compilation and build caching."

Compilation speed?

It might have to do with optimizing compile times. A crate is the unit of compilation, so small crates increase the likelihood that you won't end up recompiling a lot of unrelated code.

I guess smaller crates and avoiding nested modules could also help optimize for making the code greppable by coding agents without blowing up context windows.