charkubi

Microsoft's USP in one sentence.

Planning is important because you get the LLM to explain the problem and solution in its language and structure, not yours.

This shortcuts a range of problem cases where the LLM fights between the users strict and potentially conflicting requirements, and its own learning.

In the early days we used to get LLM to write the prompts for us to get round this problem, now we have planning built in.

Apple allowing iCloud directories to be permanently downloaded fixed this for me.

Great ideas. Observations:

- Making remote calls seem like they are local resulted in poor design decisions, the benefit of SOAP/REST was that people considered what the interface a useful service should be.

- Why not flip it and look to move groups of microservices onto the same machine, updating how the app communicate. - if component boundaries are fine grained, the combinations of local/remote services relative to each other increases, along with the testing burden; just because the system hides remote deploying, it still should be tested for.

- Incorporating this with storage, eg dynamic shard rebalancing would be super cool

I was there 2 weeks ago and got about 10. They are usually very small and take a while to find, you can often see people hunched over the same spot for a while sifting through the sand.

This is good advice generally.

The problem with printing variables is when you want to find them there's nothing to search for.

Maybe there'll be a Stardust reunion.