SketchySeaBeast

There's definitely a reason we use tents while camping and don't just huddle around the fire.

Man love synergy.

Indoors best invention since fire.

Not just after an incident, but what sort of maintenance requirements and burden will there be now? Can there be an equivalent to the beater for flying cars?

Not totally, I'll catch an occasional video - I'm watching one right now - but then I'll switch and it'll die again. Can't use Youtube music either for the same reason.

Yeah, that's better.

But if we look at the article's example, the two barely diverge. I don't think either of the texts are less divorced from reality than the other. The second is more "truthful" (read: cynical), but they are largely the same.

Tone over truth over comfort instruction set.

What's the typical run for you cost?

This is why this particular emperor has no clothes. They keep trying to jam AI into stuff to make it "easier", but the LLMs, by their very nature do the tasks in lossy or incorrect ways. Imagine if Microsoft had sold Excel with a "be sure to verify all the calculations" caveat.

Which is just the PR message if you squash. To be clear, I'm not advocating for bad messages, but I am saying I don't worry about each commit and focus instead on the quality and presentation of the PR.

Yeah, make it work. Commit. Build unit test. Commit. Fix bugs. Commit. Make pretty. Commit and raise a PR.

Well, if the AI controls the computer and is how the user interacts with it, I was going to use "Operating System" myself. But that's two words, my bad.

What's ridiculous is that second paragraph:

"There isn’t enough bandwidth to transmit video to all devices from the servers and there won’t always be good connectivity, so there still needs to be significant client-side AI compute."

So no real operating system, except an AI which operates the whole computer including all inputs and outputs? I feel like there's a word for that.

Commits aren't necessarily messy, but they're also not supposed to be necessarily clean. There's clearly two different work flows here.

It seems some people treat every commit like it's its own little tidy PR, when others do not. For me, a commit is a place to save my WIP when I'm context switching, or to create a save point when I know my code works so that I can revert back to that if something goes awry during refactoring, it's a step on the way to completing my task. The PR is the final product to be reviewed, it's where you get the explanation. The commits are imperfect steps along the way.

For others, every commit is the equivalent of a PR. To me that doesn't make a lot of sense - now the PR isn't an (ideal world) atomic update leading to a single goal, it's a digest of changes, some of which require paragraphs of explanation to understand the reasoning behind. What happens if you realize that your last commit was the incorrect approach? Are you constantly rebasing? Is that the reader's problem? Sure, that happens with PRs as well, but again, that's the difference in process - raising a PR requires a much higher standard of completion than a commit.

Yeah "should" is often not reality, BUT I'm arguing that not squashing doesn't make things better.

Yeah, I don't see the value in looking through that. At best I'll solve the problem, commit because the code works now, create unit tests, commit them, and then refactor one or both in another commit. That first commit is just ugly and that second holds no additional information that the end product won't have.

I feel like that requires a lot of coordination that I, in the midst of development, don't necessarily have. Taking my WIP and trying to build a story around it at each step requires a lot of additional effort, but I can see how that would be useful for the reviewer.

We can agree that we don't need those additional steps once the PR is merged, though, right?

I can see the intent, but how often do people look through commit history to learn anything beside "when did this break and why"? If you want lessons learned put it in a wiki or a special branch.

Main should be a clear, concise log of changes. It's already hard enough to parse code and it's made even harder by then parsing versions throughout the code's history, we should try to minimize the cognitive load required to track the number of times something is added and then immediately removed because there's going to be enough of that already in the finished merges.

And branches are free.

I do a bunch of context switching, and I commit every time I switch as stashing would be miserable. I never expect those WIP commits to reviewed and it'd be madness to try.

That's true, some are big and messy, or the change has to be created across a couple of PRs, but I don't think that the answer to "some PRs are messy" is "let's include all the mess". I don't think the job is made easier by having to dig through a half dozen messy commits to find where the bug is as opposed to one or two large ones.

> It sucks if you bisect and find the change happened in some enormous incohesive commit.

But why are any PRs like this? Each PR should represent an atomic action against the codebase - implementing feature 1234, fixing bug 4567. The project's changelog should only be updated at the end of each PR. The fact that I went down the wrong path three times doesn't need to be documented.

Assuming you squash when you merge the PR (and if you don't, why not?), why even care? Do people actually look through the commit history to review a PR? When I review I'm just looking at the finished product.

Stochastically correct is the best sort of correct?

There's probably a meme in here somewhere about how we wrapped your JSON in our JSON so we can parse JSON to help you parse your JSON.

If you ask the LLM to give you back that context does it give back to you verbatim?

A fun anecdote, and I assume it's tongue in cheek, although you never know these days, but is the LLM guaranteed to give you back an uncorrupted version of the file? A lossy version control system seems to me to be only marginally better than having no VCS at all.

Use "Will I be ok with this transcript between me and ChatGPT being read back verbatim in a court of law?" as a guide for what you send ChatGPT.

Given that the video showed ~1 second of "flying", I don't even know if that's the case.