Human-Cabbage

Funny, I’ve had an idea for a similar story for a couple of years. Some key details differ, at least, so it wouldn’t be a direct copy. (Just like you wouldn’t call “The Matrix” a rip-off of “The Terminator” because both involve a dystopian domination of humanity by machines.) But I’ll definitely have to check out this film and/or book sometime.

A wheelchair user is a person. Uber’s property is not.

I don’t agree with her stance, but it’s absurd to call standing in the sidewalk “disorderly conduct.” I hope the judge sees it that way too and dismisses the charge.

Is there a source for the claim that the post was removed per a request from Adobe? I don’t see any pinned comment from a moderator…?

Cursor shows “pushes per minute” while Anthropic shows “merges per day.” You can’t directly compare those and say Cursor’s system is more performant. Claude agents could be pushing a similar throughput of changesets into Scion, while some merge agent regularly takes batches and merges them into the trunk.

I wonder if this mixes up cause and effect. I've been working on several projects with AI tools to satisfy my intellectual and aesthetic curiosity. But I'm reluctant to share them--to engage with the community--because of the toxic discourse around usage of these tools. "Sure, I could post this cute Go library I worked on with Claude to /r/golang, but people will probably just say 'AI SLOP' and downvote it."

They do…? Well, “auto” mode has been default in Claude Code for a couple months now. It’s effectively “safer yolo:” tool calls are inspected by a separate classification system (another smaller LLM, I believe) to approve or deny. And you can always layer on additional sandboxing mechanisms to limit the blast radius deterministically.

Seems to be back up now, I've had a couple messages go through successfully in the past ~5min.

Huh, that’s what happened. Good thing my company has Bedrock as a backstop for situations like this.

Is ChatGPT's interface always this atrociously jittery? Or is it just because this page is getting an HN hug-of-death right now? Every time I try to scroll the whole page goes blank for a few seconds and then re-renders.

Is this the GTA 4 trailer?! /s

It’s too bad that ssh doesn’t carry sound. A MIDI-style rendition of the song would really tie it all together.

Surprised nobody here nor on the reddit thread caught this one: https://github.com/nahla-nee/wfqueue/blob/main/src/lib.rs#L3...

    unsafe impl<T, const N: usize> Sync for WFQueue<T, N> {}
    unsafe impl<T, const N: usize> Send for WFQueue<T, N> {}

These impls are unsound, because neither constrains `T` to be `Sync`/`Send`. As-written this would let you declare a `WFQueue<Rc<T>, N>` and pass non-atomic-refcount pointers between threads.

The fix is straightforward:

    unsafe impl<T: Sync, const N: usize> Sync for WFQueue<T, N> {}
    unsafe impl<T: Send, const N: usize> Send for WFQueue<T, N> {}

I.e., WFQueue is only Sync if T is Sync, and likewise for Send.

Actually, later on, the code makes a similar mistake, but only for one impl.

    unsafe impl<'a, T, const N: usize> Send for DrivableWFEnqueue<'a, T, N> where T: Send {}
    unsafe impl<'a, T, const N: usize> Send for DrivableWFDequeue<'a, T, N> {}

Yes, just like New Coke back in the 80s. Genius 4D marketing strategy.

This is correct at the firm level and breaks down at the aggregate level, which is where it gets interesting.

At the firm level, automating away labor costs is obviously rational. But capital in aggregate can't actually rid itself of labor, since labor is where surplus value comes from. A fully automated economy would be insanely productive and generate basically no profit. So the capitalist class pursuing this logic collectively is, without knowing it, pursuing the dissolution of the system that makes them the capitalist class.

You don't have to buy any of that to notice the more immediate mechanism though: AI doesn't need to actually replace workers to discipline them. The credible threat of replacement is enough to suppress wages, justify restructuring, and extract more from whoever's left. That's already happening and requires no AGI.

China and/or Russia might have a collection of zero-days they've been sitting on, which they could surreptitiously provide to Iran. Of course, there's attribution risk there, and the opportunity cost of not saving those zero-days for their own later use.

Containers here, though I don't run Claude Code within containers, nor do I pass `--dangerously-skip-permissions`. Instead, I provide a way for agents to run commands within containers.

These containers only have the worker agent's workspace and some caching dirs (e.g. GOMODCACHE) mounted, and by default have `--network none` set. (Some commands, like `go mod download`, can be explicitly exempted to have network access.)

I also use per-skill hooks to enforce more filesystem isolation and check if an agent attempts to run e.g. `go build`, and tell it to run `aww exec go build` instead. (AWW is the name of the agent workflow system I've been developing over the past month—"Agent Workflow Wrangler.")

This feels like a pragmatic setup. I'm sure it's not riskless, but hopefully it does enough to mitigate the worst risks. I may yet go back to running Claude Code in a dedicated VM, along with the containerized commands, to add yet another layer of isolation.

Julia is aimed at scientific computing. It competes against Python with numpy/scipy, R, etc.

Use the exoskeleton at the warehouse to reduce stress and injury; just keep lifting weights at home to not let yourself atrophy.

> the “art” part of it is writing sound, scalable, performant code that can adapt and stand the test of time.

Sure, and it's possible to use LLM tools to aid in writing such code.

The optimistic case is that instead of a team of 10 people working on one project, you could have those 10 people using AI assistants to work on 10 independent projects.

That, of course, assumes that there are 9 other projects that are both known (or knowable) and worth doing. And in the case of Uber/Lyft drivers, there's a skillset mismatch between the "deprecated" jobs and their replacements.

This conflates use-value and exchange-value. Water to someone dying of thirst has extremely high use-value, while a diamond would in that same moment have nearly no use-value, except for the fact that, as a commodity, the diamond has an exchange-value, and so can be sold to help acquire a source of water.

It'd be more helpful if you explained what exactly is wrong, and what you suggest to do instead.

There are a couple main ways to achieve a workflow similar to Git's staging area.

#1: Squashing

Create a revision for the feature, then create another revision atop that.

  $ jj new main -m 'feature'
  $ jj new
  $ jj
  @  trtpzvno [email protected] 2025-09-01 12:32:33 9ac76a0f
  │  (empty) (no description set)
  ○  wvzltyyr [email protected] 2025-09-01 12:32:31 80b2d5d0
  │  (empty) feature
  ◆  zxrulorx [email protected] 2024-12-11 03:44:38 main 351a2b30
  │  all the stuff
  $ vim
  $ jj
  @  trtpzvno [email protected] 2025-09-01 12:34:50 5516c2b9
  │  (no description set)
  ○  wvzltyyr [email protected] 2025-09-01 12:32:31 80b2d5d0
  │  (empty) feature
  ◆  zxrulorx [email protected] 2024-12-11 03:44:38 main 351a2b30
  │  all the stuff
  ~
  $ jj squash -i
  # interactively choose hunks to squash into parent
  $ jj
  @  oxqnumku [email protected] 2025-09-01 12:35:48 8694aa34
  │  (empty) (no description set)
  ○  wvzltyyr [email protected] 2025-09-01 12:35:48 47110bff
  │  feature
  ◆  zxrulorx [email protected] 2024-12-11 03:44:38 main 351a2b30
  │  all the stuff
  ~

#2: Splitting

Create a revision for the feature, then split it up retroactively.

  $ jj new main -m 'feature'
  $ jj
  @  snomlyny [email protected] 2025-09-01 12:38:39 84c6ecaa
  │  (empty) feature
  ◆  zxrulorx [email protected] 2024-12-11 03:44:38 main 351a2b30
  │  all the stuff
  ~
  $ vim
  $ jj
  @  snomlyny [email protected] 2025-09-01 12:39:51 8038bdd4
  │  feature
  ◆  zxrulorx [email protected] 2024-12-11 03:44:38 main 351a2b30
  │  all the stuff
  ~
  $ jj split
  # interactively choose hunks to keep, splitting the rest into a new revision
  $ jj
  @  zpnpvvzl [email protected] 2025-09-01 12:41:47 5656f1c5
  │  debugging junk
  ○  snomlyny [email protected] 2025-09-01 12:41:44 1d17740b
  │  feature
  ◆  zxrulorx [email protected] 2024-12-11 03:44:38 main 351a2b30
  │  all the stuff
  ~

Jujutsu distinguishes between "revisions" and "commits." Revision IDs like "rzouzmyw" stay stable, whereas commit IDs of course change with the content. You can see in my example how the commits associated with a revision change over time: rzouzmyw starts as fb73d4dc, then 30ff9b0f, and finally 88ed8085. I used "merge revision" to by consistent with Jujutsu's terminology.

Anyway, I just tried that command you suggested, but it didn't seem to work?

  $ jj new
  $ jj bookmark create woot -r @-
  $ jj
  @  wxkrvmxs [email protected] 2025-08-31 14:53:19 4bbb7f5a
  │  (empty) (no description set)
  ○      rzouzmyw [email protected] 2025-08-31 13:27:41 woot git_head() 30ff9b0f
  ├─┬─╮  (empty) (no description set)
  │ │ ○  nwtxnvxp [email protected] 2025-08-31 13:27:41 fb3cca28
  │ │ │  Feature A
  │ ○ │  ukqynvts [email protected] 2025-08-31 13:21:26 ceee7029
  │ ├─╯  (empty) Feature B
  ○ │  qxoklwxv [email protected] 2025-08-31 13:21:27 9cda0936
  ├─╯  (empty) Feature C
  │ ◆  zvpmmzru [email protected] 2025-08-29 15:59:55 master 658a3d12
  │ │  Update Claude Code to 1.0.98.
  │ ~  (elided revisions)
  ├─╯
  ◆  yxuvtolz [email protected] 2025-08-27 09:49:16 8e80b150
  │  Update Claude Code to 1.0.93.
  ~
  $ git checkout woot
  $ git log --graph
  *-.   commit 30ff9b0f274c9adaca4eeadcf21d5e918e4e3578 (HEAD -> woot)
  |\ \  Merge: 9cda093 ceee702 fb3cca2
  | | | Author: Sam Fredrickson <[email protected]>
  | | | Date:   Sun Aug 31 13:27:41 2025 -0700
  | | |
  | | * commit fb3cca2823b4dffe374b67d28e3c91c206828d47
  | | | Author: Sam Fredrickson <[email protected]>
  | | | Date:   Sun Aug 31 13:21:24 2025 -0700
  | | |
  | | |     Feature A
  | | |
  | * | commit ceee7029730c49ae30890c1641c7d6645e60fca4
  | |/  Author: Sam Fredrickson <[email protected]>
  | |   Date:   Sun Aug 31 13:21:26 2025 -0700
  | |
  | |       Feature B
  | |
  * | commit 9cda09363efe257a954b5563ce6af287a506d808
  |/  Author: Sam Fredrickson <[email protected]>
  |   Date:   Sun Aug 31 13:21:27 2025 -0700
  |
  |       Feature C
  |
  * commit 8e80b15010c4d9373c5828fdf8a83c53df75ec00
  | Author: Sam Fredrickson <[email protected]>
  | Date:   Wed Aug 27 09:48:45 2025 -0700
  |
  |     Update Claude Code to 1.0.93.
  $ git rebase --rebase-merges --update-refs master
  Trying simple merge with cfa85486fa3d53401be518cb42936fb6fd3c128c
  Trying simple merge with ffebef1cb34ca1670b48c594b2014e71be7d1b2b
  error: Empty commit message.
  Not committing merge; use 'git commit' to complete the merge.
  Could not apply 30ff9b0... rev-ceee702 rev-fb3cca2 #
  $ git status
  interactive rebase in progress; onto 658a3d1
  Last commands done (10 commands done):
     pick 9cda093 # Feature C # empty
     merge -C 30ff9b0f274c9adaca4eeadcf21d5e918e4e3578 rev-ceee702 rev-fb3cca2 #
    (see more in file .git/rebase-merge/done)
  No commands remaining.
  
  All conflicts fixed but you are still merging.
    (use "git commit" to conclude merge)
  
  Changes to be committed:
          modified:   README.md
  $ jj
  Reset the working copy parent to the new Git HEAD.
  @  tymwqlyq [email protected] 2025-08-31 14:57:22 d083f61e
  │  (no description set)
  ○  vmnnlqro [email protected] 2025-08-31 14:56:55 git_head() f92f7505
  │  (empty) Feature C
  ◆  zvpmmzru [email protected] 2025-08-29 15:59:55 master 658a3d12
  │  Update Claude Code to 1.0.98.
  ~  (elided revisions)
  │ ○      rzouzmyw [email protected] 2025-08-31 13:27:41 woot 30ff9b0f
  │ ├─┬─╮  (empty) (no description set)
  │ │ │ ○  nwtxnvxp [email protected] 2025-08-31 13:27:41 fb3cca28
  ├─────╯  Feature A
  │ │ ○  ukqynvts [email protected] 2025-08-31 13:21:26 ceee7029
  ├───╯  (empty) Feature B
  │ ○  qxoklwxv [email protected] 2025-08-31 13:21:27 9cda0936
  ├─╯  (empty) Feature C
  ◆  yxuvtolz [email protected] 2025-08-27 09:49:16 8e80b150
  │  Update Claude Code to 1.0.93.
  ~

Maybe I'm using the git command incorrectly?

Also, though, I'm assuming that git command will only rebase the branch you have currently checked out, whereas the jj command I gave will rebase _everything_, not just revisions that are parents of HEAD.

Edit: I figured out my issue. Git doesn't like empty commits & merge commits with no description. After addressing that, then the `git rebase --rebase-merges --update-refs master` command worked.

There's still the caveat though that the Git command will only rebase the "woot" branch. If I had some other "feature D" commit that wasn't included in "woot", that commit wouldn't be rebased. But the `jjsr` command would see and rebase that commit as well.

  $ jj
  @  qsvwusnk [email protected] 2025-08-31 16:17:35 6fd02707
  │  (empty) (no description set)
  ○      rzouzmyw [email protected] 2025-08-31 16:17:35 woot git_head() e6d64886
  ├─┬─╮  (empty) Merge
  │ │ ○  nwtxnvxp [email protected] 2025-08-31 13:27:41 fb3cca28
  │ │ │  Feature A
  │ ○ │  ukqynvts [email protected] 2025-08-31 16:16:36 9957dca2
  │ ├─╯  Feature B
  ○ │  qxoklwxv [email protected] 2025-08-31 16:16:44 4361de8b
  ├─╯  Feature C
  │ ○  nwoxyzlx [email protected] 2025-08-31 16:14:42 ce8de62d
  ├─╯  Feature D
  │ ◆  zvpmmzru [email protected] 2025-08-29 15:59:55 master 658a3d12
  │ │  Update Claude Code to 1.0.98.
  │ ~  (elided revisions)
  ├─╯
  ◆  yxuvtolz [email protected] 2025-08-27 09:49:16 8e80b150
  │  Update Claude Code to 1.0.93.
  ~
  
  $ git checkout woot
  Switched to branch 'woot'
  
  $ git rebase --rebase-merges --update-refs master
  Trying simple merge with f339926f729437f78ac407c28fc84ce3b0441eb7
  Trying simple merge with 4372b2c4f538164a10bb9d8e81899bf61eeecaf2
  Merge made by the 'octopus' strategy.
  Successfully rebased and updated refs/heads/woot.
  
  $ jj
  Reset the working copy parent to the new Git HEAD.
  Abandoned 4 commits that are no longer reachable.
  Done importing changes from the underlying Git repo.
  @  zlxqyrmq [email protected] 2025-08-31 16:17:59 970c80f8
  │  (empty) (no description set)
  ○      qumulkxr [email protected] 2025-08-31 16:17:42 woot git_head() cc189c82
  ├─┬─╮  (empty) Merge
  │ │ ○  vkuwsssr [email protected] 2025-08-31 16:17:42 4372b2c4
  │ │ │  Feature A
  │ ○ │  lmsrxxzm [email protected] 2025-08-31 16:17:42 f339926f
  │ ├─╯  Feature B
  ○ │  wrsnrokn [email protected] 2025-08-31 16:17:42 53ec4dc0
  ├─╯  Feature C
  ◆  zvpmmzru [email protected] 2025-08-29 15:59:55 master 658a3d12
  │  Update Claude Code to 1.0.98.
  ~  (elided revisions)
  │ ○  nwoxyzlx [email protected] 2025-08-31 16:14:42 ce8de62d
  ├─╯  Feature D
  ◆  yxuvtolz [email protected] 2025-08-27 09:49:16 8e80b150
  │  Update Claude Code to 1.0.93.
  ~

Versus:

  $ jjsr
  Rebased 6 commits to destination
  Working copy  (@) now at: qsvwusnk e793b1e4 (empty) (no description set)
  Parent commit (@-)      : rzouzmyw 3927be34 woot | (empty) Merge
  Added 0 files, modified 2 files, removed 0 files
  
  $ jj
  @  qsvwusnk [email protected] 2025-08-31 16:18:58 e793b1e4
  │  (empty) (no description set)
  ○      rzouzmyw [email protected] 2025-08-31 16:18:58 woot git_head() 3927be34
  ├─┬─╮  (empty) Merge
  │ │ ○  nwtxnvxp [email protected] 2025-08-31 16:18:58 12f659cf
  │ │ │  Feature A
  │ ○ │  ukqynvts [email protected] 2025-08-31 16:18:58 5c0ce98f
  │ ├─╯  Feature B
  ○ │  qxoklwxv [email protected] 2025-08-31 16:18:58 f9f217e8
  ├─╯  Feature C
  │ ○  nwoxyzlx [email protected] 2025-08-31 16:18:58 373d6ab1
  ├─╯  Feature D
  ◆  zvpmmzru [email protected] 2025-08-29 15:59:55 master 658a3d12
  │  Update Claude Code to 1.0.98.
  ~

To reinforce the sibling reply with a concrete example:

Let's say you've got a few feature branches, all based of the trunk branch.

  $ jj
  @  ozywpwxm [email protected] 2025-08-31 13:21:59 b2f1364d
  │  (empty) (no description set)
  │ ○  qxoklwxv [email protected] 2025-08-31 13:21:27 9cda0936
  ├─╯  (empty) Feature C
  │ ○  ukqynvts [email protected] 2025-08-31 13:21:26 ceee7029
  ├─╯  (empty) Feature B
  │ ○  nwtxnvxp [email protected] 2025-08-31 13:21:24 9ccbedf6
  ├─╯  (empty) Feature A
  ◆  yxuvtolz [email protected] 2025-08-27 09:49:16 master git_head() 8e80b150
  │  Update Claude Code to 1.0.93.

One neat workflow supported by Jujutsu is "working on all branches at the same time."

  $ jj new q u n
  Working copy  (@) now at: zzxxqlzr fb73d4dc (empty) (no description set)
  Parent commit (@-)      : qxoklwxv 9cda0936 (empty) Feature C
  Parent commit (@-)      : ukqynvts ceee7029 (empty) Feature B
  Parent commit (@-)      : nwtxnvxp 9ccbedf6 (empty) Feature A
  $ jj
  @      rzouzmyw [email protected] 2025-08-31 13:25:56 fb73d4dc
  ├─┬─╮  (empty) (no description set)
  │ │ ○  nwtxnvxp [email protected] 2025-08-31 13:21:24 9ccbedf6
  │ │ │  (empty) Feature A
  │ ○ │  ukqynvts [email protected] 2025-08-31 13:21:26 ceee7029
  │ ├─╯  (empty) Feature B
  ○ │  qxoklwxv [email protected] 2025-08-31 13:21:27 git_head() 9cda0936
  ├─╯  (empty) Feature C
  ◆  yxuvtolz [email protected] 2025-08-27 09:49:16 master 8e80b150
  │  Update Claude Code to 1.0.93.
  ~

Now you can use the merge revision as a scratch space, and then squash changes from it into one of the feature revisions.

  $ vim README.md
  $ jj squash --into n
  Working copy  (@) now at: rzouzmyw 30ff9b0f (empty) (no description set)
  Parent commit (@-)      : qxoklwxv 9cda0936 (empty) Feature C
  Parent commit (@-)      : ukqynvts ceee7029 (empty) Feature B
  Parent commit (@-)      : nwtxnvxp fb3cca28 Feature A
  $ jj
  @      rzouzmyw [email protected] 2025-08-31 13:27:41 30ff9b0f
  ├─┬─╮  (empty) (no description set)
  │ │ ○  nwtxnvxp [email protected] 2025-08-31 13:27:41 fb3cca28
  │ │ │  Feature A
  │ ○ │  ukqynvts [email protected] 2025-08-31 13:21:26 ceee7029
  │ ├─╯  (empty) Feature B
  ○ │  qxoklwxv [email protected] 2025-08-31 13:21:27 git_head() 9cda0936
  ├─╯  (empty) Feature C
  ◆  yxuvtolz [email protected] 2025-08-27 09:49:16 master 8e80b150
  │  Update Claude Code to 1.0.93.

Later, you decide to fetch changes from your remote, and notice that your revisions are based on an out-of-date version of the trunk.

  $ jj git fetch
  remote: Enumerating objects: 17, done.
  remote: Total 12 (delta 6), reused 0 (delta 0), pack-reused 0
  bookmark: master@origin [updated] tracked
  $ jj
  @      rzouzmyw [email protected] 2025-08-31 13:27:41 30ff9b0f
  ├─┬─╮  (empty) (no description set)
  │ │ ○  nwtxnvxp [email protected] 2025-08-31 13:27:41 fb3cca28
  │ │ │  Feature A
  │ ○ │  ukqynvts [email protected] 2025-08-31 13:21:26 ceee7029
  │ ├─╯  (empty) Feature B
  ○ │  qxoklwxv [email protected] 2025-08-31 13:21:27 git_head() 9cda0936
  ├─╯  (empty) Feature C
  │ ◆  zvpmmzru [email protected] 2025-08-29 15:59:55 master 658a3d12
  │ │  Update Claude Code to 1.0.98.
  │ ~  (elided revisions)
  ├─╯
  ◆  yxuvtolz [email protected] 2025-08-27 09:49:16 8e80b150
  │  Update Claude Code to 1.0.93.
  ~

With Jujutsu, you can run one command to rebase _everything_ against the latest trunk revision.

  $ jj rebase -s 'roots(trunk()..mutable())' -d 'trunk()'
  Rebased 4 commits to destination
  Working copy  (@) now at: rzouzmyw 88ed8085 (empty) (no description set)
  Parent commit (@-)      : qxoklwxv 005442c3 (empty) Feature C
  Parent commit (@-)      : ukqynvts 23923cf2 (empty) Feature B
  Parent commit (@-)      : nwtxnvxp 769d0539 Feature A
  Added 0 files, modified 2 files, removed 0 files
  $ jj
  @      rzouzmyw [email protected] 2025-08-31 13:32:08 88ed8085
  ├─┬─╮  (empty) (no description set)
  │ │ ○  nwtxnvxp [email protected] 2025-08-31 13:32:08 769d0539
  │ │ │  Feature A
  │ ○ │  ukqynvts [email protected] 2025-08-31 13:32:08 23923cf2
  │ ├─╯  (empty) Feature B
  ○ │  qxoklwxv [email protected] 2025-08-31 13:32:08 git_head() 005442c3
  ├─╯  (empty) Feature C
  ◆  zvpmmzru [email protected] 2025-08-29 15:59:55 master 658a3d12
  │  Update Claude Code to 1.0.98.
  ~

I use this command so much that it's aliased as "jjsr", "Jujutsu Super Rebase".

This is the second time I've seen $7T referenced without a clear citation. Is this just rhetorical or did Sam Altman actually say it somewhere?