To be honest, just a user here, it’s only recently (like a week?) you can ask Copilot to edit an existing PR, historically it’s had to open a new one (that merged back to original PR) or it had to make it to begin with, I can see this unintentionally happening as part of this improvement to edit existing PRs
I think you’d find Dr. Richard Scolyer’s story really relatable. He’s an Australian cancer expert who, along with his colleague, is using himself as "patient zero" for a world-first treatment for his own brain cancer. They’re basically doing the research and the treatment in parallel to find a new way forward: https://www.abc.net.au/news/2025-10-30/dr-richard-scolyer-sp...
Yes, moved to GitHub Codespaces and generally has been good.
Pros: one click setup for devs jumping between projects after you get the devcontainer setup process working, takes some fiddling, trial and error.
Has felt good for some older projects to be wrapped in the devcontainer and once it’s working feel comfortable the environment is stable, and also moving everyone to new environments has been easy.
Keeping a haywire dev/npm script away from your main machine is also good, but I know it’s not foolproof.
Cons: Codespaces CPUs are usual cloud slow so you need to pay more and single threaded perf won’t be as good as your laptop, a real shame. I think GitHub competitors would have better CPUs.
Very rarely but Codespaces can have a technical issue and you can't do your work (inaccessible), and to avoid it sleeping during the day due to inactivity you may leave it running most of the day but it demands a shutdown after 12 hours or so, so very long dev sessions can be interrupted.
GitHub also dropped support for using JetBrains IDEs which was not cool, so it’s just vscode which is usable but would have preferred other IDEs.
If Codespaces team is reading would love to see some improvements here.
GitLab's write-up mentions a dead man's switch where "The malware continuously monitors its access to GitHub (for exfiltration) and npm (for propagation). If an infected system loses access to both channels simultaneously, it triggers immediate data destruction on the compromised machine. "
Neat! How do you handle state changes during tests, for example, in a todo app the agents are (likely) working on the same account in parallel or even as a subsequent run, some test data has been left behind or now data is not perhaps setup for a test run.
I’m curious if you’d also move into API testing too using the same discovery/attempt approach.
Would it help to replace Corrosion with a simpler "Here's my local known state" blob that is POST'd to blob storage (for example) on a major cloud provider, and have another service read that at intervals? Just to make it really simple.
There will be a better way than that, but my thought is if you can make it simpler (known state is always just pushed, so missing updates auto-recovers and avoids corruption) then you can be building on top of a more stable service discovery system.
Centralized secret storage, can you keep the US instance read/write, but replicate read-only copies (a side-car tool that copies the database to other regions at various intervals?) so each region can fetch secrets locally?
Or perhaps both can be solved with a general "Copy local state to other regions" service that is pretty simple but gives each region its own copy of other region's information (secrets, provisioning states, ...).
I've needed to do similar things for some of the apps I've built, where a service needed another (simpler) service in front of it to bear the traffic load but was operationally simple (deferred the smarts to the system it was using as the source of truth) and automatically recovered from failure due to its simplicity.
Not sure how your backend works, but I read a neat technique by I think Second Life, where each actor is in a zone, and a zone is managed by a server.
If a player leaves the zone, their entire code stack and current state is shipped to the next zone (script hand off) without the player noticing. They mentioned because each actor is running in a VM/scripting language, the servers can pause/resume the VM for that actor on any machine they move to - pretty neat.