I've heard the argument that leaving these comments in, helps support future AI code generation. In this example, it was important to you at the time you made the change that create_* functions have defaults, so having this in the code captures that knowledge for later agents. It's similar to a more general argument that you should leave (correct) AI-generated code alone because it will be easier for the AI to "understand" code it generated that your modified version of it.

I see the validity in these arguments, but I don't think we should be so deferential to these models. The first part of this comment ("Now create_background params have default values") is completely redundant with the function signature and as no place in the code. The second part ("the same as create_screen") is genuine knowledge that is worth capturing for the agent, but it should be captured at a higher level doc about the codebase, rather than tacked onto some arbitrary function as a comment.

For example, if bugs were introduced and detected via a mostly uniformly random process, but most of the code was written in the early part of the project's lifecycle, then you would expect the age of bugs to go up over time (since there is less young code). Even if the code addition rate was constant, if developers were producing fewer bugs over time, then the age of the bugs would increase, since older code would be buggier.

I prefer the method described in the original post. Just start with one ball and get that right, then two, then three. It's a bit like the Karate Kid, though. Students don't find it as satisfying because they want to jump ahead before they've got the movement down.

2) I'm honestly not sure how I found my first. Possible I found some number at the local library, possible a friend in high school gave me one. Once you found one, you could learn about others from that one. There was a real culture of different sysops trying to get you to use their board (but only up to a point because it used phone lines)

3) It's really difficult to know. There was no equivalent to web search or a way to see what everyone else was doing. I'd expect the popularity followed some kind of power law, but everyone used a different subset of boards.

4) It's difficult for me to remember. Probably much shorter messages that would seem "simple" by today's standards.

That said, MCP could be an effective way to sandbox what an agent can do with a tool. Also, it seems plausible to me that a tool that actually provided information to a model via the MCP protocol could be more useful than a CLI tool which operates in the "silence means success" mode of most unix CLI tools.

Basically, make a design choice for _reasons_ and not just because you like that TLA of the option you picked.

For the first time in my career, I've seen an engineering org add "improve tech documentation" as a high-level goal. It makes me sad that it was never worthwhile to do for the engineers, but now we need it for the coding assistants who can't tell that our docs really out of date. On the flip side, the coding assistants will actually read the docs, unlike many engineers.

I don't see it, either the notion that other people's code is to be avoided for its own sake nor that depending on LLM-generated code is somehow analogous to depending on React.

Not that everything we want an agent to do is easy to express as a program, but we do know what computers are classically good at. If you had to bet on a correct outcome, would you rather an AI model sort 5000 numbers "in its head" or write a program to do the sort and execute that program?

I'd think this is obvious, but I see people professionally inserting AI models in very weird places these days, just to say they are a GenAI adopter.

In this case, I try to question the project owners on their assumptions and whether they have validated them. Usually this line of questioning reveals whether they have "done their homework".

When we first moved in, there was a seminar room that made some people physically nauseous due to its sloping walls. For a time, they were trying to use masking tape on the walls to make the effect less pronounced. Some of the grad students tried to name it the "vomitorium", but the name never stuck. Fortunately,, once the room had a full compliment of chairs, furniture, and a projector screen the effect seemed to be much less pronounced.

I much preferred working in the previous building, CS and AI lab building, NE43. It looked like a punch card from the outside, but had a very nice design with small offices (with closing doors) ringing a common space. The primary downside is the square footage per worker was decadent by today's standard.

Oh wait, we were talking about Frank Gehry, right? His museums looks cool but he should never have been allowed to design an office building.

Not only are his ideas about how to write software patently bad, but he is willfully obtuse when asked to provide nuance or discuss trade-offs. John Ousterhout's dialog with him, published as "A Philosophy of Software Design vs Clean Code" gave him every opportunity to think critically about his own suggestions and he just doubles down.

https://github.com/johnousterhout/aposd-vs-clean-code/blob/m...

He's just trolling us at this point.

https://github.com/johnousterhout/aposd-vs-clean-code/blob/m...