Maybe we just shouldn't fill out every optional text field with as much Claude nonsense as it can possibly fill in there. It really feels like they went from "Co-authored-by" propaganda to "You'll know, don't worry. Just watch these invisible watermarks!"
Here's an AI-generated pull request I made, but you wouldn't know because there's no slop:
Without having tried JJ, as a hype chaser, I can say it's both worth it and not worth it.
I run NixOS, work with Kubernetes, code Rust, use a 40% split, layered keyboard with Dvorak layout and open source firmware, kaj mi parolas Esperanton.
They're just hobbies that, once you've sunk the hours in, they're awesome.
I don't actually type faster. Or maybe I do type a little faster because it made me use all 12 fingers instead of the ad-hoc 7-finger system you taught yourself in primary school, but typing was never a bottleneck, and split keyboards actually hurt my wrists more.
Jujutsu is marginally better than git, but costs time. If you like to spend the time, it will probably make you a little better. If you care deeply about your time, and it's already being allocated for anything but arbitrary intellectual pursuit, it's not worth it. Some people grow businesses, plants, or sedentary habits.
You can undo a push, yes. It undoes the local state of the remote branches after the push operation. ie: branch@origin will point at the commit it did before the push action. It doesn't actually update the branch on the remote. That would require another push operation.
jj itself doesn't have a native ‘push’. `jj git push` and `jj piper upload`¹ operate on external systems that don't necessarily support undoing arbitrary operations. Pure speculation, but if I were ESRC I'd make my backend handle it (subject to enterprise audit policies).
You're still the product of your environment. You'd not be using words like 'uncritical', 'agentic', 'maximalist', 'cringe', 'cultivating' etc were you not.
You're just as branded as an LLM user by your admission that you read hours of its output daily as any potential use of 'load-bearing'.
'Cringe' for instance, rose to popularity once, became cringe itself, fell to obscurity, and was only relatively recently restored to frequent use. 'load-bearing', 'circle back', and 'let's be honest' were all also once heavily used in particular communities and are therefore heavily represented in any algorithm supplied with this data that is trained to sound professional and authoritative.
These words and phrases are simply suffering the same oversaturation point that all the greats (groovy, radicle, spiffy, cool) do at some point. At some point, some population that is not native to the word (say adults for 'fire' or junior devs for 'circle back') start to use them and the original culture begins to see that the term has been diluted and is therefore disfavored for some new or re-used construction.
My point is that the phenomenon of choosing ones words as a reflection of one's environment is not a new thing. It's really nothing to do with the machine generation component. As when the masses refuse eloquence as a snub against the bourgeoisie it's not really about the money itself so much as signalling a particular identity. This is just the latest hotness to signal distance from.
> Cringe' for instance, rose to popularity once, became cringe itself, fell to obscurity, and was only relatively recently restored to frequent use
When were those changes supposed to happen? Cause saying cringe was never cringy in my neck of woods. And the word was in use the whole time.
> load-bearing', 'circle back', and 'let's be honest' were all also once heavily used in particular communities and are therefore heavily represented in any algorithm supplied with this data that is trained to sound professional and authoritative.
They dont sound professional nor authoritative. And never did. Load bearing was rarely use, circle back is just empty business jargon. Lets be honest is neither professional not authoritative. Never was. That is what people say when they are about to say something negative or ironic.
> My point is that the phenomenon of choosing ones words as a reflection of one's environment is not a new thing.
And that choice oftentimes used to flag you with negative implications ... precisedly because it made it clear which circles you are in.
Mathematicians and computer scientists will also say
"for all" / "there exists" instead of "every" / "there's at least one"
"let" as an imperative for establishing facts
"fix" for choosing a value
"given" instead of "if"
"modulo" instead of "except for"
"if, and only if," when the occasion warrants it
"implies" instead of "means"
"trivial" without intending to be mean
"yes" when asked an "or" question
"transitively"
"by symmetry"
"it follows"
"canonical"
It's a lovely, concise language.
You can say a lot with few words when you have rich definitions.
> if a seasoned programmer sits behind Claude Code, the quality output will likely be higher than if a non technical person does it
Anecdotal: I recently rewrote a service in Rust for a much needed 100x performance boost (largely due to architectural changes, somewhat due to better runtime).
My colleague who now maintains the app is not a Rust developer and knows little about threads and tokio. Debugging a problem, he said he’d reach the context window before pinning the problem. I never have that problem and effortlessly find problems in the first 100k tokens without trying.
The difference must be in the wording that initially guides the agent.
The miniatures come prepainted but as tiny bits, like a croissant, or a lamp, or a sofa. So it's not so much about painting them as it is gluing tiny magnets to them and making small installations that are repluggable.
Some of the items have tiny electrics inside, e.g. an actual tiny LED lamp.
The "scenery" (much like Warhammer battlefields) are then made from cardboard and hobby materials. You can also buy them pre-assembled, but they're much less impressive (usually one color, generic, e.g. "doll house" or "house sliced halfway"). There's a subgenre for 3D printing the scenery.
My wife uses small glass jars upside down. so the items live on the jar's lid. Looks very cute with a small LED lamp and lights off.
I think none of this is rare, but surely some items are more unusual than others.
The rarity comes from this being a hobby that not many know about.
Ah this makes more sense. I was wondering how on earth they were making this stuff because a lot of it looked like injection moulded plastic that would be just too hard to make at home.
Do you know what this stuff is called specifically? I wanna see what kinda items you can get.
That excellent post talks about searching for bugs in extant code, but a similar maxim applies to new code:
With AI, you can choose your position on the speed/quality trade-off curve. You can vibe code crap, you can guide/review more closely and get a higher quality product more slowly.
And that choice can extend past non-AI coding: with AI you can produce software even more slowly but even higher quality than you did in the past before AI.
One straightforward way to achieve this is to code manually and use AI to more thoroughly review & audit your code. But that's not the only way to get there -- you can use AI for coding assistance and still produce higher quality code slower. It's tricky, though.
> with AI you can produce software even more slowly but even higher quality than you did in the past before AI
I hadn't thought about it before, but this is precisely what I did in one project.
After replacing a webhook that I've been monkey-patching for ten straight bugs, I had enough of an idea of how the software worked and what edge cases to look out for to reproduce the software without the bugs and with a well-modelled, well-tested foundational client library.
After testing the foundational client library with all the methods I know (unit tests, property tests, mock tests, integration tests, and live tests), I had a race condition in my live tests that accidentally turned into a fuzz test of the live service the client connects to, and discovered a bug in the server.
The actual webhook has been brewing for a long time. For weeks I've just casually added more tests. Nothing interesting happened. I've went live with it now, and nothing comes up. So on to make a load test with mock endpoints.
I love how AI makes advanced, extensive testing techniques (and TDD) take little enough time to justify using them all.
As someone who taught CS for some years, it is very satisfying to finally come to a point where "we're not testing" cannot be justified from an economic perspective, it is purely a cultural (or lack of cultural) decision, and a lack of knowledge of any testing techniques beyond unit testing.
Sounds like unbounded, dynamic allocation to me!
reply