Not sure about copilot, but most enterprise plans do offer a way to export all prompts to a company siem.

If someone is making the kind of mistakes that cause oncall issues to increase, put that person on call. It doesn't matter if they can't do anything, call them every time they cause someone else to be paged.

IME too many don't care about on call unless they are personally affected.

> If someone is making the kind of mistakes that cause oncall issues to increase

the problem is that identifying the root cause can take a lot of time, and often the "mistakes" aren't clearly sourced down to an individual.

So someone oncall just takes the hit (ala, waking up at 3am and having to do work). That someone may or may not be the original progenitor of said mistake(s).

Framed less blamefully, that's basically the central thesis of "devops". That is the notion that owning your code in production is a good idea because then you're directly incentivized to make it good. It shouldn't be a punishment, just standard practice that if you write code you're responsible for it in production.

The (almost) opposite is also a feature: it's OSS and will still be available if the business goes out of business

Companies need someone to blame who has skin in the game.

An "open source contributor" is not gonna wake up at 2AM on a Saturday because the business that someone else partially built on their free code suddenly went down.

This is ALSO, conveniently, why AI's will never completely replace human developers. You cannot blame, reward, or punish an entity that has no such sensitivities.

I somewhat like the idea of not using MCP as much as it is being hyped.

It's certainly helpful for some things, but at the same time - I would rather improved CLI tools get created that can be used by humans and llm tools alike.

Indeed, I think the only "new" thing about clawdbot is that it is using discord/telegram/etc as the interface? Which isn't really new, but seems to be what people really like

I think a big part of it is timing. Claude Opus 4.5 is really good at running agentic loops, and Clawdbot happened to be the easiest thing to install on your own machine to experience that in a semi-convenient interface.

I'm assuming OP means cloud-based load balancers (listening on public ips). Some providers scale load balancers pretty often depending on traffic which can result in a set of new IPs.

Being specific: AWS load balancers use a 60 second DNS TTL. I think the burden of proof is on TFA to explain why AWS is following an "urban legend" (to use TFA's words). I'm not convinced by what is written here. This seems like a reasonable use case by AWS.

depending on how you set up the reverse proxy, clawdbot can think _all_ traffic comes from localhost

What if you have two people with different ideas of how to name a certain variable and they just flip the name back and forth every release?

I like this review method too though, and like that some pr review tools have a 'suggest changes' and 'apply changes' button now too

> What if you have two people with different ideas of how to name a certain variable and they just flip the name back and forth every release?

Fire both. There is no amount of skill and productivity that can justify that amount of pettiness.

Typically in this system you encode obligations - e.g. "eieio should review, or at least be aware of, all changes made to this library." I think that means you're unlikely in practice to have a problem like that, which (unless the team is not functioning well) requires two people who care deeply about the variable name and don't know that someone else is changing it.

I think it's a good idea to have a style guide of sorts that you can point to when people sweat the small stuff.

Apply rule 8 of Go

If it's a single project, you could try putting some of your corrections in AGENTS.md/CLAUDE.md if supported. I don't remember if cursor reads from there, but I think it does have its own rules system.

Basically just a bullet list of stuff like "- use httpx instead of requests" or "- http libraries already exist, we dont need to build a new one that shells out to /proc/tcp"

Just add stuff you find yourself correcting a lot. You may realize you have a set of coding conventions and you just need to document it in the repo and point to that.

Smaller project-specific lists like that have been better imo vs giant prompts. If I wouldn't expect a colleague to read a giant instruction doc, I'm not going to expect llms to do a good job of it either.

Oh man, I remember these. A modern version would be pretty cool.