Well, giving it access to a simple linux terminal is theoretically enough to cause more damage than most people are comfortable with, and doing so is trivial enough that it will be done (and has been, tens of thousands of times).

Should we also morally align the Linux terminal then?

Pangram says 100% - "We believe that this entire text is AI."

A workflow I was introduced to and have worked with a lot in my teams is,

1. Everyone uses feature branches

2. Everyone cleans up their branch using interactive rebase on top of main before review

3. All merges have been freshly rebase on main

I think it works very well and keeps the history clean while preserving "each commit does one thing".

I wish my team would at least use the rebase merge strategy by default to avoid branch graphs looking like the London tube network. Not in 10 years did I have an issue with that (okay, except accidentally rebasing deliberate no-ff merges).

The one time I suggested that, someone immediately came up to me trying to convince me that rebases are the most dangerous thing ever.

I worked on a team that did this, + required feature branches to get squashed to a single commit before merge. On that commit, we'd require a very brief bullet list of changes, sometimes a POC, and a link to the PR. This made git blame a lot more helpful when debugging issues. I am a big fan of this approach.

> On that commit, we'd require a very brief bullet list of changes, sometimes a POC, and a link to the PR.

one of the first things i do in a new gitlab repo is set up ff+squash commit merges with the squash commit message template automatically pulling the MR title, link, description, authors etc.

    %{title} 

    -
    ref: %{reference}
    url: %{url}
    authored by: %{merge_request_author}
    merged by: %{merged_by}
    -
    %{description}

I run as uid 0, but it's not called root, because my system is mine and I'll call it what I want.

I used to complain about all the levels of indirection of modern software, running in a javascript jit, in a browser container, in a vm, on an os, etc.

I eventually just accepted it, but this new agent layer really takes things to a new level.

I've created my own keyboard layout plus do some key remapping on my mac. Are you sure this won't work for tilde?

The tilde key exists in the key map here: https://developer.apple.com/library/archive/technotes/tn2450...

You can see how I did mine here if you're interested: https://github.com/bruse/dotfiles/tree/main/macOS (I suspect com.local.KeyRemapping.plist is most interesting, but the key layout file is there too, with some comments on how it was generated).

Thank you. I'll check as soon as I can. I remember having asked that in the Ask Different Stack Exchange forum, but I couldn't even find my question.

I must have missed some trends changing in the last decade or so. People have production secrets in the open on their development machines?

Or what type of secrets are stored in the local .env files that the LLM should not see?

I try to run environments where developers don't get to see production secrets at all. Of course this doesn't work for small teams or solo developers, but even then the secrets are very separated from development work.

I think having API keys for some third-party services (whatever LLM provider, for example) in a .env file to be able to easily run the app locally is pretty common. Even if they are dev-only API keys, still not great if they leak.

If you can't trust the "agent" with a secret to the LLM which is practically like access to its runtime, what the hell... others propose mitming yourself...

All of this does seem kinda funny

Usually, some people change their .env files in the root of the project to inject the credentials into the code. Those .env files have the credentials in plain text. This is "safe" since .gitignore ignores that file, but sometimes it doesn't (user error) and we've seen tons of leaks because of that. Those are the variables and files the llms are accessing and leaking now.

Sure, but it's probably unwise to have your production credentials on your development machine at all. It's far more likely to be compromised than your locked down production environment.

Sometimes it can be handy for testing some code locally. Especially in some highly automated CICD setups it can be a pain to just try out if the code works, yes it is ironic.

It's interesting, because a few years ago I would have put this strictly under the "not invented here" fallacy, where we'd now be stuck maintaining another project for the foreseeable future. I used to press pretty hard to avoid it.

Now I wonder if the maintenance cost for this type of internal system has gone down to a level where that is no longer an issue.

I can see it going both ways. If knowledge work continues to roughly look the way it looks then I think maintenance is going to be an issue. Both in terms of keeping the spaghetti together but also in terms of all the bad design decisions you get from everyone bolting on their ideas. If however knowledge work becomes just talking to LLMs and occasionally interacting with an on the fly generated UI then maintenance becomes a non issue

Interesting! I know Sweden was not first, but Stockholm has had 3g coverage in the subway since 2005 and 4g since 2016.

Lots of countries do where the underground is near the surface, but London it is very deep.

Quick googling gave that Stockholm is deeper on average, although the deepest point of London metro is currently deeper than Stockholm. No drastical differences that should affect this question I think.

(This will change when they are done with Sofia station, a new station in Stockholm that they are building 100 m below the surface.)

If I understand correctly the only thing not public that was leaked was the role each person had in the government.

Why would the role within the government not be public? I can't imagine that being treated as a secret.