Applying the actions is unsolved. Unless you YOLO the LLMs, taking stateful actions automatically requires a lot of protective infrastructure, solid testing infra etc.

It’s all just more code, but a “create me a shopping website” LLM is likely not going to be doing the infrastructure level thinking required to handle it for now.

The equivalent is something like hand tool woodworking - it’s still a thing despite the advent of machines, but more of a niche. You can still aim to become excellent, but maybe you won’t be famous.

It could even use a special “NULL” address. Just don’t pollute every type with it.

For example, a physics degree is expected to have experiments. You are not required, expected (and possibly do not want) to know the tools required to professionally build a bridge because you did courses on mechanics. But you might do an experiment on the structural integrity and properties of small structures.

Whether this is a good split is an entirely different question.

The key property of SSL that is useful for tamper resistance is that it’s hard to do silently. A random ASN doing a hijack will cause an observable BGP event and theoretically preventable via RPKI. If your ISP or similar does it, you can still detect it with CT logs.

Even the issuance is a little better, because LE will test from multiple vantage points. This doesn’t protect against an ISP interception, but it’s better than no protection.

If it is so cheap to make something that they recommend using (rather than a proof of concept), why buy Astro (presumably it was more expensive than the token cost of this clone?).

One conclusion is that, at the organisational level, it still makes sense to hire the “vision” behind the framework, rather than just clone it. Alternatively, maybe AI has improved that much in 1 month!

I’m not saying that’s how it actually works, and this process doesn’t have warts, but the ideal of individual employees not having direct access is not novel.

Having regulation, or standardisation is a step toward producing a common language to express these problems and have them be taken seriously.

Leadership gets a strong signal - ignoring engineers surfacing regulated issues has large costs. Company might be sued and executives are criminally liable (if discovered to have known about the violation).

Engineering gets the authority and liability to sign off on things - the equivalent of “chartership” in regular fields with the same penalties. This gives them a strong personal reason to surface things.

It’s possible that this is harder for software engineering in its entirety, but there is definitely low hanging fruit (password storage and security etc).

And then also there’s all the non-systems stuff - what is actually feasible, what’s most valuable etc. Less “fun”, but still lots of potential for thinking.

I guess my main point is there is still lots to think about even post-LLM, but the real challenge is making it as “fun” or as easily useful as it was pre-LLM.

I think local code architecture was a very easy domain for “optimality” that is actually tractable and the joy that comes with it, and LLMs are harmful to that, but I don’t think there’s nothing to replace it with.

I would imagine mature organisations without serious short/medium term existential risk due to product features may build some push back mechanisms to defend against the inherent cost of maintaining existing business (ie prioritising tech debt to avoid outages etc).

In general, it is a probably a mix of the two - even if there is a mandate from up high, things are typically arranged so that it can only occupy X% of a team’s capacity in normal operation etc, with at least some amount “protected” for things the team thinks are important. Of course, this is not the case everywhere and a specific demand might require “all hands on deck”, but to me that seems like a short-sighted decision without an extremely good reason.

For work coming from outside the team, it’s sort of upto your management chain and team lead to prioritise. But for internally driven work (tech debt reduction, reliability/efficiency improvements etc) often the senior engineer has a better idea of the priorities for their area of expertise.

Prioritisation between the two is often a bit more collaborative and as a senior engineer you have to justify why thing X is super critical (not just propose that thing X needs to be done).

I view the goal of managers + lead as more balancing the various things the team could be doing (especially externally) and the goal of a senior engineer is to be an input to the process for a specific system they know most about.

Since you mentioned DDOS, I’m assuming you are talking about ingress anycast?

I wasn’t precise, but what I meant was more akin to a single IP shared by multiple datacenters in different regions (from a BGP perspective), which I don’t think Cloudflare has. This is general parallel of ingress unicast as well, a single IP that can be routed to multiple destinations (even if on the BGP level, the entire aggregate is anycast).

It would also not explain the OP, because they are seeing the same source IP, but from many (presumably) different source locations whereas with the Cloudflare scheme each location would have a different source IP.

I don’t think I’ve seen a similar case for anycast egress. Naively, doesn’t seem like it would work well because a lot of the internet (eg non-anycast geographic load balancing) relies on unique sources, and Cloudflare definitely break out their other anycast addresses (eg they don’t send outbound DNS requests from 1.1.1.1).

I also don’t trust myself to not screw up anything more complex than running a command on Bash, without the guard rails of something like shellcheck!

Fish is nicer to script in by far, and you can keep those isolated with shebang lines and still run Bash scripts (with a proper shebang line). The only thing that’s tricky is `source` and equivalents, but I don’t think I’ve ever needed this in my main shell and not a throw-away sub shell.