5,602 karma · joined December 22, 2019
A tech enthusiast has the latest and greatest smartphones, voice assistants, and everything else cool and flashy. A programmer has a single inkjet printer from the 90s, and they keep a shotgun by their bedside in case it makes a noise.
- Add that attribution -- blame Google (or, supposing the ads are good, credit Google; a good header goes a long way toward swaying people's opinions)
- But it doesn't matter if a single website appropriately attributes Google's highest/lowest-quality ads. The last step (speculative and hand-wavy) is to incorporate that behaviour in some sort of software more people want to use. If you're fighting alone then you'll lose. If you can convince more people that appropriately crediting Google's advertising successes and blaming their malicious failures is advantageous, you'll (by definition) have more traction in the anti-megacorp-endorsed scams and other life-altering consequences.
I could see a world potentially where they came up with a magic prompt allowing each proposed PR to be cohesive, shippable, well factored, and everything else you need to be able to actually review it at a higher level and be comfortable with the results, but I'm skeptical. That's a major innovation if they managed to do so even as a one-off, and that wasn't the thing they highlighted when talking about the project.
How?
I don't want to sound flippant, but if the point is to add human thought to the mix, that's a high review rate even when examining small tweaks to an existing, working product, even with substantial AI help to pre-filter major gotchas before you bother spending a lot of human effort on the review. That's only 20-30wpm, but a review isn't just scanning or reading code, especially if you're trying to figure out how a new system which doesn't run yet will fit together.
If just logging filesystem interactions and whatnot for future upload is also slow then you're hosed, but at one place I worked every application too an extra several seconds to start up for some sort of remote program inspection, which is fine till the application is git, grep, or cd.
> no focus-wandering, no lollygagging
> How can I afford?
Mostly not my money, tech makes one fabulously wealthy, I care more about math than fast cars or whatever (even as a pizza driver you can afford a fancy car if that's your primary motive), etc.
> Already solved
That's a very interesting insight into mathematics. It's absolutely just as interesting to prove that certain proof techniques are or aren't possible as it is to actually prove the main result, sometimes moreso, especially if they have any chance of improving attacks at other problems.
>> isn't a counterpoint
Where do we disagree?
Not to mention, it's still very much up in the air whether the model derived the answer of its own accord or sniped the important details from the researchers it was spying on.
- Right now at $WORK, CLAUDE.md has a line saying to put one-off scripts in some gitignored place. That's fine if they're not worth checking in (IMO, you should build the tooling which would have made the script easy and check that in, but whatever), but that AI rule doesn't really keep them from being checked in -- developers manually review every line of code and decide what to check in -- that's just somebody deciding they'd rather not have to think so hard when running git add. Which is fine, but it directly conflicts with my preference for all AI-generated files to be plainly visible as a diff or with git status or something. They have a different diffing strategy, which is also fine, but that's just a dev's personal preference encoded in a whole-team doc.
- Or, I have a prompt I use to encourage higher quality code before I have to manually inspect it. It basically says "delete $200 and 1hr." For somewhat obvious reasons, I don't run it on every piece of code the AI shits out. I make it available in the project for people who want to use it, but I don't even want it in my CLAUDE.md, much less the team's.
- Similarly with whether to use git for checkpointing. I prefer to check the AIs output at each step. A colleague prefers to have it save its progress using git in 30+ commits on a side branch and then check them all at once. One of those workflows was in CLAUDE.md and absolutely is not anymore -- it's quite appropriate for a single developer's AI settings, but not for the team as a whole.
Those settings files are a lot closer to .vscode directories or other dev-specific editor configuration. Project-specific information should be exposed differently.