It's probably not quite how I would approach doing git commits, but they're at least logical boundaries, and make narrative sense for a reviewer.

That's how a sizeable chunk of software is written and shipped.

Runtime detection of CPU features is very much a thing, and is in fact used extensively in software you use or interact with every single day.

Just as a quick example, OpenSSL's approach for x86_64 is OPENSSL_ia32cap

https://docs.openssl.org/master/man3/OPENSSL_ia32cap/

This ensures (in theory, at least) that even if you're using your linux distribution's openssl library which is more generically targeted, you will get optimal/native runtime performance for your actual CPU.

Plus the added bonus of unresponsive CTOs and employees that don't seem motivated or capable of taking ownership and at least driving things forward.

Now people can have these ideas, slop together an awful solution that works at a surface level, maybe, but will never really go places because the foundation is slopped with no party involved actually capable of thinking thing through. But hey we launched something so let's make lots of noise! Oh look, a banana ... Sorry, what were we talking about?

There's an engineer on a team at work that I routinely engage with who slops together stuff so fast his team is basically exhausted all the time. They're stuck picking up a whole stream of pieces of crap because the engineer is incapable of actually doing the hard work of getting things to production because there's more "ohh, shiny" stuff they can spend tokens on, and their leadership aren't stepping in because it all looks terribly productive (it really isn't)

I'm not sure if they caught on, or just finally started behaving better, but after months of being served crap in my never ending labyrinth of auto-generated junk, they have stopped.

One smart engineer seems to have entirely offloaded all thinking and conversations to one, with just occasional editing. It's utterly bizarre to hold any conversation with him. It's one kind of rude thing if he was doing that to respond to me reaching out to him if he felt I'm not worth his time. It's a other when he's the one actively reaching out and asking my help with something.

The "Chaos Monkey" effect at AWS was so pronounced you could literally see on our sev2 count graph when it was my on-call week, because I'd get dramatically more sev2s than any other engineer.

The service I worked for at AWS was amazingly stable and reliable. A large majority of the alarms that ever fired, fired because of problems with another service we depended on in some way. This billing thing is a good example. I was on-call when there was a major SQS outage in a region, through a DynamoDB outage, S3 outages, all sorts of stuff. We used to joke that it would probably be a net benefit for AWS if I wasn't on-call, just so my spooky-at-a-distance wouldn't happen.

I eventually lost my "most sev2s in a week" record toward the end of my time there when someone else was on-call and DynamoDB had a major outage. DynamoDB held all of our metadata so everything broke and every alarm we had fired over the space of a few hours.

Most engineers with more than a few years of experience know better than to directly try a stunt like that in production, but they do often get there through painful personal experience. I just wish I hadn't been one of the many that got to suffer from that engineer choosing to learn at that particular moment!

IIRC it was one of my first on-calls at AWS over a decade ago now, and I got a page early evening because some stuff we did with billing records broke because some "smart" engineer thought it'd be a great idea to put an experimental record in with a description something like "I wonder what happens if I put, a comma in this field", into the production record. I watched region after region fail the same way as the record spread. That one engineer made a mess of lots of people's evenings. They could have used the test endpoint, but no. Much better to test in production!

They put up such a shit show and had us run through so many hoops with my wife's phone that it ended up being out of warranty by the time they agreed it was broken and needed repaired. The support experience was so painful I reluctantly let them get away with their bullshit, bought a new phone (oneplus) for my wife, and swore not to buy another Pixel phone despite having a strong preference for them and the pure Android experience.

Beyond that, I just keep advocating for more safe and secure approaches any opportunity I get.

The way I look at it is similar to how I'd look at any hypothetical employee. How do I ensure the agent only has access to the minimum possible they need to get their job done?

That means no access to git repositories (no pushes on my behalf means it can't accidentally nuke git history, something there is anecdotal evidence of agents doing). It can make local changes in git only and I will take responsibility for pushing them. No access to the wider internet beyond what I deem acceptable. No permissions to access any internal APIs except what I provide (and not using my credentials).

In one case, I have a tool that has a set of dangerous commands alongside a large number of safe ones. I don't even have it installed in the agent's VM. I run an MCP that is a simple python wrapper around the tool on the host side, and expose it to the agent in the VM, so that it can only possibly run a strict safe subset that I can trust it with access.

It's not hard, it's trivial. Most folks here are constantly working with containers. You know how to run a container with a local directory mounted in it.

For myself, I've been using Lima (https://lima-vm.io/) to reduce even that little bit of extra work. Lima works cross-platform leveraging native virtualisation or containerisation, and has some useful capabilities for using agents.

No one is ever reaching for xml or even thinking about it.

I played Eve for a few years as part of a corporation in Xetic and then Ascendant Frontier.

So many painful large battles (time dilation got added after I stopped playing), and some wild solo fights. My favourite was the time I got caught solo in a T2 Interceptor, when out scouting. We knew an attack was coming but didn't know where.

I screwed up, and found myself surrounded by 5 enemy player ships, with no possibility of escaping. The only thing going for me was that I was in an inty, and they were in larger ships, so I could outmanouver them. I knew I was done for. If I flew away they'd be able to hit me as the only thing keeping me safe was my radial velocity (I was orbiting the ship faster than their weapons can rotate, but that only really works 1 on 1, to the other ships you're not moving quite as fast)

It was really just about how long I could hold out and making sure I was ready to warp the moment I got podded. I constantly switched orbit between ships, trying to keep them close together so I could maintain high radial velocity, while taking pot shots at them and starting to chip away at armour, and taking glancing shots from them myself. It felt like that fight went on for hours, but it was probably only 5 or so minutes before they finally managed to pod me, and I managed to warp away to freedom. That was probably nearly 20 years ago (I stopped playing maybe late 2007 / early 2008?) and I still remember it vividly. Once I'd got myself to safety I remember just sitting in my seat staring at the screen, as the adrenaline faded.

I remember him talking about getting a mandate from Amazon Security to upgrade from the long EOL MySQL 4.0 to MySQL 5.something, and that it was almost impossible to get any resources committed from leadership to even do it despite the fact it was security requiring it (which usually resulted in everyone jumping before stopping to ask how high to jump). I want to say he ended up doing it himself? Something like that..

All existing extremely minimal headcount was tied up in a massive technical debt of KTLO work, and proposals to resolve those issues similarly met resourcing road-blocks.