The large percentage of software development is people doing hello world or similar difficulty. "CRUD apps," remember?

Hopefully they are not live-coding that crap though. Do you want to make those apps even more unreliable than they already are, and encourage devs not to learn any lessons (as vibe coding prescribes)?

One thing I've really internalized since IBM Watson is that the first reports of any breakthrough will always be the most skeevy. This is because to be amplified it can be either true or exaggerated, and exaggeration is easier. That is to say, if you model the process as a slowly increasing "merit term" plus a random "error term", the first samples that cross a threshold will always have unusually high errors.

For this reason, hype-driven/novelty-driven sites like HN usually overestimate initial developments, because they overestimate the merit term, and then underestimate later developments - because they now overestimate the error term from their earlier experience.

IBM Watson is old, before deep learning.

Deep learning systems have exceeded the hype. In 2016 we saw potential with models like AlphaGo Zero but no one could foresee the capability of LLMs (a type of deep learning model).

It's actually very fun, ime.

I have plenty of experience doing code reviews and to do a good job is pretty hard and thankless work. If I had to do that all day every day I'd be very unhappy.

It is definitely thankless work, at least at my company.

It’d be even more thankless if instead of writing good feedback that somebody can learn from (or can spark interesting conversations that I can learn from), you would just said “nope GPT it’s not secure enough” and regenerate the whole PR, then read all the way through it again. Absolute tedium nightmare

> In fact, you should commit your LLM dialogs along with your code.

Wholeheartedly agree with this.

I think code review will evolve from "Review this code" to "Review this prompt that was used to generate some code"

All LLM output is non-deterministically wrong. Without a human in the loop who understands the code, you are stochastically releasing broken, insecure, unmaintainable software.

Any software engineer who puts a stamp of approval on software they have not read and understood is committing professional malpractice.

We've tried Literate Programming before, and it wasn't helpful.

Mostly because we almost never read code to understand the intention behind the code: we read it to figure out why the fuck it isn't working, and the intentions don't help us answer that.

> In fact, you should commit your LLM dialogs along with your code.

Absolutely, for different reasons including later reviews / visits to the code + prompts.

I wonder if some sort of summarization / gist of the course correction / teaching would work.

For example Cursor has checked-in rules files and there is a way to have the model update the rules themselves based on the conversation

From the UK...?

Perhaps a couple of grams of silver?

The Post Office will sell you US currency, but AFAIK not US stamps.

I would like to note, just for fun, that "proofed" also exists and means something else entirely.

(This happens when the LLM mentions them.)

Computers don't need AI help to have trouble finding the printer, lol.

My bicycle is a chair, apparently.

Temptation does not require nondeterminism.