Counterpoint: don't read the comments

> And it can pay for itself twice: once in real work shipped, and once again in something else you could probably use more of, which is gravity.

what?

as someone who doesn't know how to get better design out of LLMs, can you elaborate?

Have an opinion on the design, imagine something, then tell it to do just that, then iterate. It's when you're unspecific you get the generic, bland and typical LLM design, you just have to be subjective and influence it in some (human) direction.

Also check out https://impeccable.style/, it's really good

I have finally embraced squashing PRs and realized I wasted my youth trying to write Good Commits.

These Good Commits are for the review’s benefit, not necessarily trunk history.

PRs very frequently contain more than 1 logical change.

it's tribal, it feels good to rally against a common enemy

good luck formally verifying everything

If the alternative is "burn more tokens on finding issues than the attackers do", formal verification starts to look comparatively feasible cost. Think of it as setting an upper bound on cost, vs just burning more and more tokens.

AI assistants would reduce effort of verification too.

I declare ~bankruptcy~ formal verification

that ship has sailed

for me it's that it works remotely and my kids can access it over Discord

this seems like what MCPs should have been from the beginning. If you think MCPs are better, can you explain why?

I suspect the main trade-off is structured data versus text parsing. While CLIs are composable, relying on stdout is brittle for anything complex. MCP enforces a schema (types), which acts as a contract between the model and your backend. If you're building reliable pipelines rather than just one-off scripts, that structure is pretty critical to avoid parsing errors downstream.

the problem with any approach like this based on usage metrics is that it will be abused to death