Putting that aside, prototype software is recombining existing technologies and concepts in well trodden domains, which is distinct from the genuinely novel scientific work the author was contrasting with. Software prototypes are not in the same league, as much as you may like it to be.

> “GPTs are a non kinetic form of warfare designed to embed the values of a small number of people into much wider communities by capturing the process of decision making. The delivery mechanism is the appearance of helpfulness i.e. coherent and authoritative arguments. The payload is helplessness and the creation of a new theocracy.”

https://lnkd.in/p/efk8KaAN

As a result, after 15 years as a software engineer, I’m genuinely considering leaving the industry altogether because the only roles available to me are ones where I’m expected to deliver features rather than organisational change and growth. It’s like my heaps of experience have navigated my career into a cup-de-sac, and the only way out is backwards. I’m so jaded. Hopefully it’s a phase. I need a coach. Help.

What am I talking about? Nil and partially constructed structs are impossible to prevent the creation of in Go.

Sure, if you’ve got a small program with limited scope, that’s probably fine if you look through squinted eyes. But the teams I work with are working on sprawling, evolving software where the compiler saying “hey, that’s not a valid Widget” would be extremely useful and save much heartache.

An LLM does a good job of “checking” for other uses and “checking” if everything is going to work correctly, but - supposedly we’ve committed the concept to code so that the compiler can actually verify it - and Go intentionally permits invalid states of structs. This makes Go a fundamentally problematic language choice for the kind of software I work with teams on, LLM or not.

Yeah, it’s called a branch, or PR. It’s a set of changes you want to sign off.

It seems like you want CI run on every commit, which seems rather unnecessary. And if you don’t, well, that’s always been the case.

> Not in a way that worked properly.

GitHub operates git. No git changes have happened. It’s just commits and branches, in git. So anything that worked before, works exactly the same now, but with buttons taking out some of the small amount of effort you had to put in.

You don’t need to merge those changes progressively. If you do, you go through exactly the same process of creating a separate branch and PR. The only difference is that GH has now added some UI and automation for rebasing and merging the PRs. In the past we would have explained the chaining in the PR and rebased manually.

You don’t need CI to run on each commit.

You only lose your commit history if you squash merge, many people don’t, and you don’t have to either.

The arguments come from angle that doesn’t appear to be aware that stacked PRs were a thing before GH made these UX improvements.

And the upshot for the LLM providers is that they get to charge for n reviews, instead of one.