> 1. models are now extremely good at totally automating tedious tasks such as updating dependancies, build/deploys scripts, unit tests, etc what used to take days now can takes minutes. Easily 50x speedup on this. This was non-trivial part of every engineer's day-to-day at an established company. "platform engineering" or whatever they call this now is dead.
I confess that I don't understand why this isn't true, because it seems to be true on the micro level, but it really hasn't been my experience. The platform engineers I'm familiar with are desperately trying to tread water to keep their systems healthy against the now-higher code velocity without falling to pieces. (Perhaps people used to make minor day-to-day improvements while coding that Claude enables us to ignore?)
I think it’s because most PEs are in general conservative (the whole “mr no” meme) and also have limited experience writing software so they will be slow to adapt to this paradigm shift
Because "platform engineering" isn't about writing bash scripts, it's about having a mental model of the system architecture. (Which the LLM definitely doesn't have.)
Also, it's always the case where you think LLMs are great at doing whatever it is that you don't understand or value.
There was lot of lofty ideas around devops/pe and the like but ime the grim reality is that in most of managers’ heads it’s basically “tools that product engs don’t want to be concerned with” and like i said current models are really really good at this. Also disagree on the mental model thing - give opus 4.7 or latest codex access to your code, design mds and your logging mcp - in five minutes it will be better at debugging production issues than 90% of platform engineers I’ve worked with. It is truly over
> and like i said current models are really really good at this
They're absolutely shit at this. You only say that because it's a thing you "don't want to be concerned with".
> in five minutes it will be better at debugging production issues
In my circles "debugging production issues" is running perf to diagnose memory allocation hot paths and tcpdump to figure out who is sending bad packets.
> In my circles "debugging production issues" is running perf to diagnose memory allocation hot paths and tcpdump to figure out who is sending bad packets.
I confess that I don't understand why this isn't true, because it seems to be true on the micro level, but it really hasn't been my experience. The platform engineers I'm familiar with are desperately trying to tread water to keep their systems healthy against the now-higher code velocity without falling to pieces. (Perhaps people used to make minor day-to-day improvements while coding that Claude enables us to ignore?)