$165k won't get you far on salaried engineers. There's every chance that 1 engineer, assuming Anthropic employs them, is on $500k or more. Assuming average of $336k in that pool of 50 engineers, then for 11 days for 50 engineers you've spent $710k[0].
> - Not sure what they're called, but I've seen a lot of fully automated outdoor "locker stations" for packet deliveries
Drop boxes!
I was part of a team prototyping these some 20 years ago. I highly doubt we were the only team doing so, but we were certainly unaware of any commercially available/deployed stations at the time. I was writing the software, in particular the orchestration of the locks and event bus for the transmissions.
Lots of fun from trying to fathom how undocumented solenoids operated, to trips to various countries for remote and environmental testing, and destructive tests simulating someone driving a truck into an installation (i.e., by deliberately driving a truck into one!)
The nerdiest moment was taking a mainboard model that we were getting intermittent faults with and recreating the exact environmental conditions to recreate the problem. This involved incubating the mainboard in a sealed environment chamber to control temperature, humidity, and atmospheric pressure. The fault was bit-flipping because electrons were jumping rails when the microchip(s) were cold and damp.
If the title simply said "AI is out-performing humans at CTF" then none of this confusion exists. Nothing is "broken," we don't need to be superfluous with "frontier," and the point is still there.
I've found the first, and most important, step for any team or organisation to eliminate concerns with NFRs, "tech debt", and whatever else it may be called, is to stop giving it a name.
I'm being completely serious. By giving it some kind of distinct name, you are giving license to it being ring-fenced and de-prioritised by someone who doesn't (but, arguably, probably should) know better.
Quality matters. It hits your P&L very quickly and very hard if you don't maintain it. So it is as important as any other factor.
`jj new` simply means "create a new commit [ontop of <location>]" - you don't have to describe it immediately. I never do.
I know that the intention was to do that, and I tried forcing the habit, but I too found it counter-productive to invariably end up re-writing the description.
No that is correct when in colocate mode (which is the default mode). Simply removing the .jj folder will "de-jj" the repo entirely, but will leave you in a headless state. Simple to fix with a `git switch` though.
If you are _not_ in colocate mode, the .git folder is located _inside_ the .jj folder. So worth checking!
Tbf you wouldn't use/switch to jj for (because of) those kind of commands, and are quite the outlier in the grand list of reasons to use jj. However the option to use the revset language in that manner is a high-ranking reason to use jj in my opinion.
The most frequent "complex" command I use is to find commits in my name that are unsigned, and then sign them (this is owing to my workflow with agents that commit on my behalf but I'm not going to give agents my private key!)
jj log -r 'mine() & ~signed()'
# or if yolo mode...
jj sign -r 'mine() & ~signed()'
I hadn't even spared a moment to consider the git equivalent but I would humbly expect it to be quite obtuse.
Yes but it is easy to abuse/misuse IME, in that I think it requires one to maintain your own sense of discipline for the principle separation rather than the library/framework guide you into it. The threshold between UI and state management is comically easy to confuse.
Not dismissing it, mind, that inherent guidance is not something that is easy to achieve and I much prefer working with the likes of React than without.
Might be naive, but this has always been a concern of the view-model for me. Every GUI change results in a VM change via event/command. The VM becomes gospel for UI state which means reducers are much simpler, and my actual model doesn't care if it is indeed a button, expando, radio button or whatever else.
I stand corrected. It makes sense that it is a chroot/rootfs rather than fully independent VMs.
re: side-by-side running, I always get socket and/port port problems when doing that. Without having looked into it at all I figure it is NAT collisions.
Salary info: https://www.levels.fyi/companies/anthropic/salaries/software...
[0]The maths I used (posting because I'm tired and prone to mistakes):