This is just one way to use TDD. I personally get the most value from TDD as a design approach. I iteratively decompose the project into stubbed, testable components as I start the project, and implement when I have to to get my tests to pass. At each stage I'm asking myself questions like "who needs to call who? with what data? What does it expect back as a return value?" etc.

>> They have been natively incentivized to generate more where possible

Do you have any evidence of this?

The cloud providers charge per output token, so aren't they then incentivized to generate as many tokens as possible? The business model is the incentive.

This is only true in some cases though and not others. With a Claude Pro plan, I'm being billed monthly regardless of token usage so maximizing token count just causes frustration when I hit the rather low usage limits. I've also observed quite the opposite problem when using Github's Copilot, which charges per-prompt. In that world, I have to carefully structure prompts to be bounded in scope, or the agent will start taking shortcuts and half-assing work when it decides the prompt has gone on too long. It's not good at stopping and just saying "I need you to prompt me again so I can charge you for the next chunk of work".

So the summary of the annecdata to me is that the model itself certainly isn't incentivized to do anything in particular here, it's the tooling that's putting its finger on the scale (and different tooling nudges things in different directions).

"rigorously" is doing a lot of heavy lifting here.

Let's substitute rigorously with "in an extremely thorough, careful, and methodical way."

I think it's a perfectly fine point. The OP said (my interpretation) that LLMs are messy, non-deterministic, and can produce bad code. The same is true of many humans, even those whose "job" is to produce clean, predictable, good code. The OP would like the argument to be narrowly about LLMs, but the bigger point even is "who generates the final code, and why and how much do we trust them?"

As of right now agents have almost no ability to reason about the impact of code changes on existing functionality.

A human can produce a 100k LOC program with absolute no external guardrails at all. An agent Can't do that. To produce a 100k LOC program they require external feedback forcing them from spiraling off into building something completely different.

This may change. Agents may get better.

Did you review all the code-gen code that might have been created in your projects pre-AI? Scaffolding, boilerplate, extended autocomplete, etc?

No, but that's not a fair comparison. LLM's are inherently non-deterministic. Boilerplate generation is.

>> and the use to oneself of such a phrase is much different from using it in response to the concerns of others

Quite right.

Cadillac margarita would like a word. ;)

Or they hate cars/waymo/etc and will come up with any chain of reasoning that puts those things in a bad light.

>> "The Body Keeps The Score"

Such a great book. Highly recommended.

>> This guarantees worse outcomes.

[Citation needed]

An opposite argument is that compulsory voting smooths out or buffers the extreme radical urgency of any faction that might, in the right circumstances, carry the day in a low-turnout election.

Why put the [citation needed]? I've told you what my rationale is behind my statement. Just argue against my logic.

> An opposite argument is that compulsory voting smooths out or buffers the extreme radical urgency of any faction that might, in the right circumstances, carry the day in a low-turnout election.

That is a bad thing IMO. I am (and many other people) are disenfranchised by mainstream politics and I want to see more radical ideas/policies/opinions, I (and many others) don't want more of the same.