> I think I'm a pretty skilled programmer, or I'm at least good enough at interviewing to convince other people of that, but it's pretty obvious from comparing LLM generated code to code I'd write myself that in many domains LLMs are superior to me.
there's an important caveat here - LLMs absolutely can write better code than me, but they can also write far worse code, and often don't seem to be able to tell the difference. I find myself spending a lot of time prompting the bots to refine their code in specific ways that I only know about because I read the generated output.
there was an old riddle I saw on usenet, "there is a key I use for one of its intended purposes several times a day, but when it stopped working I never missed it. what key was that?". the answer was the caps lock key, one of whose intended purposes was reverting back to normal after accidentally pressing it to go into caps mode.
I've been using it happily for longer than that! I do remember having to tweak the default search behaviours when I first installed it but it's been largely problem free ever since.
reminds me of the time when you got strips of fn key binding cheat sheets for various popular software packages like lotus 123 and wordperfect, and keyboards came with a space to hold them.
I just recently read the novelisation of "shada"[0]. it was altogether delightful, and reminded me of the time in college when I was a huge fan of dr who novels despite never really getting into the TV show.
agreed! I'm actually pulled in different directions; I love the nostalgic value of physical books and enjoy possessing them as artefacts, but I vastly prefer the experience of reading an ebook, especially the page turning with one finger.
I enjoy writing code, but even more than that I love having good code. I wouldn't vibe code in the pure sense because the code itself is an artefact I value, not just the resulting behaviour, but I'm perfectly willing to use an LLM as a tool to help me sculpt and garden my codebase.
reviews I've seen have been very positive, with the caveat that "out of the box" includes reimaging it with open source firmware. make sure you get a device that can be reimaged this way.
I'm not talking about the transient aspects of producing software; I'm happy to accept that AI will change that, but also I feel that it will change it in ways that really aren't very hard to learn, and truth be told the more time that passes the smaller the gap will get as the agents get more capable.
what I am talking about is principles that govern what good software looks like, what properties it has to satisfy in order to be extensible and maintainable and performant and all that other good stuff, and the AIs are not going to make that knowledge obsolete any time soon.
but the solution, ironically, is not learning more about ai, but learning more about good software engineering, so you can tell when the ai is not doing it
this reminds me of a debate about science education - somewhere in elementary school we had to study various proofs that the world was round, mostly with historical context. some people now argue that we don't need this to be part of the curriculum any more - the answer is "we have gone to space and seen it, here are the photos!"
one of the best things about it is not the proof per se, but the fact that mathematicians continue to work on the theorem. bodes well for interesting mathematical research not being killed by AI proofs.
I have found that claude (opus 4.8 and 5) can do a very good job of implementing good architecture and system design if I can just steer it right. left to its own devices it does produce less than optimal code, but if I just spend a few minutes explaining how some pattern will improve the code, claude will go do it the right way, and can even have a pretty sensible discussion about the tradeoffs involved. so it does know about good code architecture and patterns, it just doesn't have the taste and initiative to use them without being told.
there was an interesting retcon of that story in one of niven's later works, where it was pointed out that any spacefaring race would know instantly what killed him. it was just better PR to pretend that it was a huge mystery, and that their hull wasn't vulnerable to some stupidly obvious danger but rather to something no one could have foreseen.
not to take away from the author's appreciation of newly accessible formal proofs, but people have been talking about the savings in formalization effort for longer than they have been talking about the AI doing the actual proofs!
I once read a (possibly apocryphal) description of a swiss sign saying in english "please don't pick the flowers", in french "those who love nature leave the flowers alone", and in german "picking the flowers is forbidden"
reading that shopify supports users designing their own custom shopfronts really helped put the acquisition into context. makes a lot of sense to bet on tailwind for that.
addressing the category error rather than the specifics of whether js belongs in the backend - just because a language is theoretically general purpose, it doesn't mean it's the best tool for the job. in the case of language tooling in particular, the operations involved are fairly well understood, and they do not really play to the strengths of javascript (or indeed of any of the currently popular dynamic languages), because what you want is optimised performance rather than exploration of ambiguous business rules, or runtime adaptation to the shape of user data, or consuming untyped blobs from a remote API, or any of the range of other problems backend js is indeed decently useful for.