They still have enough unskilled labor they can pull from the country side. They pack up the village and ship them (relocate the people) to a city in need of workers.

They increasingly don't (much of rural China is depopulating rapidly, with only the old folks left) and "pack up the village and ship them to a city" is not a thing, unless it's being demolished for a dam etc.

why is this downvoted?

Finally. Now I can remove all my symlinks. :)

Consider: the US is a (somewhat) greenfield project, while the EU is a brownfield refactoring.

These sorts of refactorings take time, even more so if done by "committee". The good thing is that explicit interfaces have to be created thereby (hopefully) increasing adaptability and resilience over time.

The US was greenfield 2 centuries ago. It currently has a lot more technical (political?) debt than the EU. Some reforms are long overdue.

I want this one to succeed, but refactors often fail and revert to the original code structure :)

Why would one need a blackboard if one had a coordinating agent that would launch a sequence of builder agents that run either in parallel or in sequence depending on what the coordinating agent determined was safe?()

Honest question, I don't really get how this would improve my work flow.

() Spec and (variably coarse) implementation plan are already grounded in code reality and are commited.

Translation: As the number of bugs per line of code is a constant depending on language and project, we will experience a world full of bugs now that LLMs generate so much more code. On the other hand, LLMs are so quick at fixing them, the number of bugs should go down.

I wonder which trend will be winning though. I personally won't bet on quality.

I noticed back in the days that my FidoNet point client software ran a lot faster (actually processing a lot of messages, so IO and CPU heavy) in Windows than in DOS, which was unintuitive to me back then.

Likely 32-bit file access[1] and the caching it included? The arrangement where Windows calls 16-bit MS-DOS entry points to do I/O (including from 32-bit programs) to respect preexisting DOS drivers, network redirectors, etc., but then in 3.11+ intercepts those 16-bit entry points (including when used from 16-bit DOS programs) to use a different 32-bit I/O stack when possible... it wasn’t intuitive back then and I don’t think it any more intuitive now.

[1] https://en.wikipedia.org/wiki/Microsoft_32-bit_file_access

What was the minimum required density you derived?

Not if the models are way cheaper. For many tasks you can do with DeepSeek Flash, and for more gnarly problems you switch to GLM or Kimi. But sure, if you do everything in large models like Kimi K3 or GLM it gets expensive quickly.

Until the manufacturers enter an arms race and copy a page out of the mobile hardware vendors book. But perhaps they'll do it badly and we've got a few more years.

I'm sure they will eventually, but for the first time their incompetence is working to our benefit.

Apparently the task was to remove dead weight. Haven't read what they replaced "Enzyme" with.

I did subagent based removal tasks a few times. These were the ones that required the least amount of input or thinking from me, because the requirements are abundantly clear. "Remove this part of the code without breaking any other part or by porting the tests done with it onto another system."

In these situations the code acts as the bookkeeping ledger itself, and coordination complexity is almost a no-brainer.