Not sure I agree with the “three pillar” framing in this one. I think it’s more like he was able to use the LLMs effectively because he had already built those years of experience. Someone new trying to vibe code their way into designing robust distributed systems is going to need a similar amount of time to build the correct intuitions, because the LLM doesn’t give a shit one way or the other, it’ll just do what’s in the prompt.
On the other hand, commodotizing domains that fit a repeatable pattern isn’t so bad, is it? At work I sometimes have to remind people that we’re generally just building CRUD apps to interact with data, which isn’t exactly at the bleeding edge of software. I like the idea of software engineers getting to be more portable, but unfortunately the industry still thinks LLMs are going to replace most jobs, which is obviously not possible.
I’m always fighting to get people to start thinking about areas of responsibility and consistency across codebases, since the natural tendency is to just add whatever functionality you think you need wherever you happen to be working at the time. I mostly work in C# but at least it has nullable annotations these days. I don’t think null guards are really that bad though, at least when you have a language that lets you do it smoothly, like Kotlin and Typescript. Like the author said, it mostly gets real bad when you let responsibilities get all muddy.