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.
Some of the slowdown will come from not indexing the FK columns themselves, as they need to be searched during updates / deletes to check the constraints.
Neat, I noticed it gave me wrong data though, and when I asked for the top 3 rows it provided the wrong value, due to not using UTF8 - Asking ChatGPT to use utf8 support fixed it, perhaps update it's prompt.
Worth noting the difference between an AWS Application Load Balancer (ALB) that is HTTP request aware, and Network Load Balancer (NLB) which is not, when load balancing HTTP traffic.
AWS ALB (and others I'm sure) can balance by "Least outstanding requests" [1] which means a server with the least in-flight HTTP requests (not keep-alive network connections!) to an app server will be chosen.
If the balancer operates on the network level (eg NLB) and it maintains keep-alive connections to servers, the balancing won't be as even from a HTTP request perspective because a keep-alive connection may or may not be processing a request right now and so the request will be routed based on number of TCP connections to app servers, not current HTTP request activity to them.
I’m not a target user, but you mentioned the tagging problem and git integration, perhaps you could infer at least the git user responsible for each resource cost (git blame the TF file and identify the username who added the resource) as a minimum amount of detail provided out of the box?
A technique I've used before is to treat Elasticsearch as rebuildable at any time, consider this approach:
A cron runs every 5 minutes that looks at your database for any objects you're indexing where last_modified_at timestamp > last_indexing_started_timestamp.
Index the objects into Elasticsearch, then update the last_indexing_started_timestamp value to be when you started the original sync process, so we catch any modified objects between the start/end of the update run, next run.
Then if Elasticsearch needs rebuilding you can just clear out the last indexing timestamp and resync from the start of time, and its self-recovering / won't get out of sync.
Hard to reverse actions need multiple safety switches, for example, turning off the machines in that region for 2 weeks before deleting them, which would bring support issues to attention ahead of the no-going-back step of deleting data.
I’ve had to triage Cloudflare connectivity issues before, if you have a timestamp or when the error appears you can ask CF support to check backend logs for the error reason