allowing an AI agent to get hold of creds that let it execute destructive changes against production -- not a great idea

allowing prod database changes from the machine where the AI agent is running at all -- not a great idea

choosing a backup approach that fails completely if there's an accidental volume wipe API call -- not a great idea

choosing to outsource key dependencies to a vendor, where you want a recovery SLA, without negotiating & paying for a recovery SLA -- you get what you get, and you dont get upset

For anyone wanting to get into the weeds about detecting accounting fraud, the book "Financial Shenanigans" has lots of historical examples of ways company executives have cooked the books to make their public company financial statements appear more appealing to investors than they actually are.

Per the post, it sounds like this is most effective in closed-ecosystem internal monorepo-like contexts where an organisation has control over every instance of client code & can `go fix` all of the call sites to completely eradicate all usage of a deprecated APIs:

> For many years now, our Google colleagues on the teams supporting Java, Kotlin, and C++ have been using source-level inliner tools like this. To date, these tools have eliminated millions of calls to deprecated functions in Google’s code base. Users simply add the directives, and wait. During the night, robots quietly prepare, test, and submit batches of code changes across a monorepo of billions of lines of code. If all goes well, by the morning the old code is no longer in use and can be safely deleted. Go’s inliner is a relative newcomer, but it has already been used to prepare more than 18,000 changelists to Google’s monorepo.

It could still have some incremental benefit for public APIs where client code is not under centralised control, but would not allow deprecated APIs to be removed without breakage.

see https://boardgamegeek.com/boardgame/822/carcassonne

e.g. https://www.minizinc.org/ offers a high level modelling language that can target a few different solver backends

might be pretty good results to completely ignore writing a custom algorithm and drop in an existing industrial-grade constraint programming solver, model your procgen problem using a high level language, and use the existing solver to find you random solutions (or exhaustively enumerate them). then more time to iterate on changing the problem definition to produce more interesting maps rather than getting bogged down writing a solver.

agreed. this also provides an explanation for the otherwise surprising fact that prey animals in the savannah have never been observed to naturally evolve ion thrusters.

Also, some of those legal moves will set up a board state that the player taking a turn immediately after you can exploit for a lot more benefit than you got, so not only are the legal builds hard to identify for new players, half of those legal moves are also traps! If new players aren't comfortable learning the hard way, the player who is teaching the game can always call these out, explain what is going to happen & give people the opportunity to redo their move.

An alternative strategy game that is less complex than Brass is Friedemann Friese's classic Power Grid (2004) [1]. It has some of the same elements (network expansion, building stuff to make money) and parts of it are highly interactive (auctions!) but it is less complex and doesn't feature so many negative player interactions. The main down side of Power Grid is that some of the "admin" rules are pretty fiddly, but provided there is an experienced player to teach the game & be responsible for the admin, players who are learning don't need to care about the details.

[1] https://boardgamegeek.com/boardgame/2651/power-grid

Another quick, low-complexity game that is easy to teach & pretty good fun is Century: Spice Road [2]

Chinatown [3] (re-themed as Waterfall Park [3b] ) is a simple highly interactive game that is basically 100% negotiations between players who are trying to make real estate deals with each other. Can be played in 90 minutes, including rules explanation, plays up to 5. For a more complex asymmetric game that's more focused on engine building, with a healthy dose of negotiation, check out Sidereal Confluence [4].

For more complex games that take a bit longer to play to teach and play, that are largely focused on players doing their own thing ("multiplayer solitaire"), building their engines without much negative player interaction, check out Ark Nova [5] or Terraforming Mars [6]. These might take 3-4 hours or so to finish, provided there's an experienced player to teach everyone the rules.

For another moderately complex strategy game with a little more player interaction, check out Brass: Birmingham [7]. Takes around 4.5 hours to finish a 4 player game, including the rules explanation. If you have a group that enjoys complex strategy games and wants something with spikier negative player interactions, where one player's actions can completely wreck another player's plans, check out Barrage [8].

This probably doesn't help "without spending much money"! One trick is to find or create a regular board gaming group where everyone brings along different games. That way if, everyone buys a new game or two every year there's a lot of variety without everyone needing to buy heaps of games.

[1] https://boardgamegeek.com/boardgame/364073/splendor-duel

[2] https://boardgamegeek.com/boardgame/209685/century-spice-roa...

[3] https://boardgamegeek.com/boardgame/47/chinatown

[3b] https://boardgamegeek.com/boardgame/396618/waterfall-park

[4] https://boardgamegeek.com/boardgame/202426/sidereal-confluen...

[5] https://boardgamegeek.com/boardgame/342942/ark-nova

[6] https://boardgamegeek.com/boardgame/167791/terraforming-mars

[7] https://boardgamegeek.com/boardgame/224517/brass-birmingham

[8] https://boardgamegeek.com/boardgame/251247/barrage

other combinatorial optimisation problems - like the traveling salesman you mention - are much harder than pathfinding to solve optimally or even approximately

This argument is very much in line with Mike Acton's data-driven design philosophy [1] -- understand the actual specific problem you need to solve, not the abstract general problem. Understand the statistical distribution of actual problem instances, they'll have parameters in some range. Understand the hardware you're building writing software for, understand its finite capacity & capability.

It's common that new algorithms or data-structures with superior asymptotic efficiency are less performant for smaller problem sizes vs simpler alternatives. As always, it depends on the specifics of any given application.

[1] see Mike's CppCon 2014 talk "Data-Oriented Design and C++" https://www.youtube.com/watch?v=rX0ItVEVjHc