There's a false equivalency between software engineering and civil engineering here, in my opinion. I would argue that the craftsmanship SWEs see in their work stems from a necessity to be novel in order to truly make something worth putting out into the market. "Oh, you're making an app that tracks heartrate/makes music/provides driving directions? Why wouldn't the user just use <insert 'X' market-leading app>?" There's no real merit to making clones, whereas in civil engineering (I would argue) this is the bread and butter. You can't copy and paste a bridge. There's a physicality to it that says "okay, make another bridge similar to this but now for that gap", so the challenge becomes making the necessary repetition more efficient, and it's "fine" if no one is going out of their way to be an "artisanal civil engineer".

Combine this argument with the fact that LLMs are reliant on what information they've ingested; they'll only give you responses based on what already exists. The creativity needed to make something (worth making) is missing there. You'd hope that the humans using the AI fill that role, but comments like this one and others lauding praises on AI and vibe-coding give me serious doubt. We could argue instead that SWE is a misnomer for this field, but that's a separate conversation.

In my opinion, SWE should prioritize true innovation, which AI isn't designed for. (IMO, AI is better suited for fast info lookup rather than key production tasks) Without creativity in SWE, the industry bloats to a unsustainable mass of cloned/useless apps and startups just hoping to be eaten (bought) by a bigger fish, with investors/customers repeatedly being promised "something better is right around the corner!" ...and it just never comes, and the whole thing just collapses on itself.

> I would argue that the craftsmanship SWEs see in their work stems from a necessity to be novel in order to truly make something worth putting out into the market. ... There's no real merit to making clones, whereas in civil engineering (I would argue) this is the bread and butter. You can't copy and paste a bridge. There's a physicality to it that says "okay, make another bridge similar to this but now for that gap", so the challenge becomes making the necessary repetition more efficient, and it's "fine" if no one is going out of their way to be an "artisanal civil engineer".

This is a key insight that invalidates a lot of the manufacturing thought that infects software development. Manufacturing (in large part) is about making copies, better and cheaper. But with software, you can create perfect copies for free. A "software factory" makes no sense, there's a fundamental paradigm mismatch.