Good engineering requires that you still pay attention to the result produced by the agent(s).

Bad engineering might skip over that part.

Therefore, via Amdahl's law, LLM-based agents overall provide more acceleration to bad engineering than they do to good engineering.

Some people will interpret it one way, some a subtly different way, but is there a reason that people's interpretation changes over time in a way that is more rapid and more significant than the underlying question of how good their life is broadly? Probably not.

There may be cultural differences that make it tricky to do comparisons between cultures / countries, but it should give something useful when looking at the same culture / country over time.

The open sharing approach is traditional for research and academia, while the information restricting approach is traditional for business-oriented thinking.

So, a young field will typically start out fairly open and then get increasingly closed down. The long-term trajectory differs by field, and the modern open-source landscape shows that there can be a fair bit of oscillation.

We're seeing the same basic shape of story play out in generative AI.

According to their charts they're at a throughput of something like 7T tok/week total now. At 1$/Mtok, that's 7M$ per week. Less than half a billion per year. How much is that compared to the total inference market? And yet again, their throughput went like 20x in one year, who knows what's to come...

You could perhaps make an argument that among the flood of AI-related submissions, this one doesn't particularly move the needle on intellectual curiosity. Although satire is generally a good way to allow for some reflection on a serious topic, and I don't recall seeing AI-related satire here in a while.

A system that allows this kind of extreme wealth accumulation is quite fundamentally at odds with democracy because extreme wealth can be and is in practice used to influence politics in a way that undermines democracy.

Some people might not care about that, but if your goal is improving the outcomes of the largest number of people, then pretty much everything else is secondary to having a functioning democracy.

(And I believe I'm fairly typical for my team. While there are more junior folks, it's not that I'm just stuck with powerpoint or something all day. Writing code is rarely the bottleneck.)

So... either their job is really just churning out code (where do these jobs exist, and are there any jobs like this at all that still care about quality?) or the most generous explanation that I can think of is that people are really, really bad at self-evaluations of productivity.

I've graded many exams in my university days (and set some myself), and it's exceedingly obvious that that's what many students are doing. I do wonder though how often they manage to fly under the radar. I'm sure it happens, as you described.

(This is also the reason why I strongly believe that in exams where students write free-form answers, points should be subtracted for incorrect statements even if a correct solution is somewhere in the word salad.)

I didn't see internationalization and localization, but I don't see anything fundamental about those that would be different.

Security, on the other hand, does feel like a different beast.

You can make some, though!

Basically, the idea is to define a class template NoAlias that contains a single value of type T. Implement operators etc. to make the type useful in practice for working with the wrapped value. Type-based alias rules mean that an access to the value wrapped in NoAlias can never alias a value wrapped in NoAlias. (Tag1 and Tag2 can just be forward-declared structs that are never defined.)

One time, I even encountered a situation where this was mildly useful.

It admittedly doesn't have a lot of polish, but I do use it regularly and I'd be happy to help anybody who is interested in using it.

Given two version (old and new) of a Git change (i.e., individual commit or patch series from a pull request) it produces a diff that is actually useful for reviewing purposes, assuming you've already reviewed the old version of the change.

It's sort of like `git range-diff`, but where `git range-diff` produces a "diff of diffs" that is very hard to impossible to read, this tool gives you a direct diff between old and new versions, but filters out any irrelevant changes that were introduced because the author rebased on a more recent version of the target branch.

I hope that makes sense - I never know quite how to put it into words for somebody to understand who isn't intimately familiar with Git. It is very powerful though if you combine it with a minimal amount of setup e.g. for fetching all PR branches from a GitHub repository. I use it almost daily as part of my code review workflow.

The issue is one of review scaling. I wrote a blog post about this a while ago[0], but the gist of it is that those clean logical units are often too small for meaningful high-level reviews of more complex work.

With complex features or refactorings, you're often in a situation where those clean logical units allow reviewers to do a good low-level review (do a check for logic corner cases, style issues, etc.) but they don´t allow a high-level review of how all the pieces of the feature work together.

IMHO the most open-source process friendly solution to the issue is to review patch series, where you can review the series as a whole for the big picture, but also dig into individual commits for the details. Building such a patch series requires an approach as described in the article.

(In closed source environments, you may get a good enough approximation of the result with a separate, disciplined software design process.)

[0] http://nhaehnle.blogspot.com/2020/06/they-want-to-be-small-t...

Patch series are an important part of a healthy review workflow because they allow both a micro and a macro view of changes. I have written about this before: http://nhaehnle.blogspot.com/2020/06/they-want-to-be-small-t...

Stacked diffs make that possible because you can review either individual commits or an entire stack at once.

The irony is that this is largely the way that Linux kernel development works -- and the Linux kernel was the first user of Git! Most projects who later adopted Git seem to have never learned this lesson that was there from the beginning, and have since been reinventing wheels.

[0] http://nhaehnle.blogspot.com/2020/06/they-want-to-be-small-t...