I ran Claude Code on my ca 2015 ThinkPad which was having wifi issues and asked it to fix them. It diagnosed the problem and applied some obscure kernel flag which fixed the issue.
There are plenty of expenses in this order of magnitude that are not tied to direct increases in productivity. I think it may become a serious hiring impediment for companies to be really skimpy on these budgets for example.
There was a time when some employees wanted 1000$ per month for rent, imagine that.
It's absolutely insane, 1500 * 12 is north of 17K dollars, I know that in Google outside of few specific cities and roles.
Getting a 17k bump in salary is good enough to switch, if I was being 17k extra I am more than willing to use my local qwen and hand code most if not all stuff.
Companies can pay for code review tools to make life easier but writing code with AI if it's 10-15% pay cut is just too much.
Everyone is happy right now because this money hasn't been a line item in your salary/benefits.
Imagine 10k yearly AI allowance, I will probably just ask to keep that money.
All the work I do if I was judicious I could do just as much with a 20$ spend or on a local model.
Few tasks need Mythos like models, and if your task does you are already doing too much with AI
Is it really that different with the current iteration of AI compared to what was possible 10 years ago? There may be some new awareness at the executive level of what is possible, but I feel like a "slacker detector" or whatever would have been possible with xgboost or lstms.
The most amazing thing to me about Cider-V was that Cider (without the V) actually went away after a relatively short amount of time, when virtually every other internal service that is officially EOL-ed lives on essentially forever.
That is because the Cider team did an amazing job of managing it, and spent tons of time going bug report by bug report to find and fix the blockers stopping people from preferring Cider-V over Cider, instead of the typical Google deprecation approach of "monkey knife fight"
I came from storage, so the monkey knife fight there was between PARMs. Very entertaining. For storage engineering could basically say "Well, figure it out, because if you don't find XX capacity, Google will stop working. Like, all of it."
I dunno, there's certainly a lot of monkey knife fight deprecations, but there's a lot that are handled pretty well.
If we're talking about the source side of things, p4->piper/citc was done well. cs (get) -> grimoire was done well. I'd like to think we did a pretty good job of grokv2-> Kythe, though we did drop a few clients of grokv2 who were wayyyyyyy the fuck up xkcd/1172 creek (we did try to help them in the right direction, like offloading onto direct blaze depserver queries).
I guess those are all close in the org to cider, so maybe that's just how dev infra deprecations used to go.
Initially I had thought so too. But later I realized that it’s quite easy to do so when you force-deprecate the old product. There was no real choice, the old IDE simply stopped working after a certain cutoff date. Adoption metrics felt forced and pushed, but were presented as if users were actively and willingly choosing the newer IDE.
I feel like core dev team learned a lot about actually enabling a web based ide for line 100k engineers across the globe for a gazillion line mono repo. ciderv is really just a skin for the amazing infra. Which is also why I think there was less resistance to the change
That seems possible for generating completely new proteins.
Do you think it's also the case for lead optimization where you typically have some degree of measurements around your starting point, and you are expecting to stay in that local neighborhood for the generated candidates, too?
Would you be open to sharing a version of your pitch deck? The main question in my mind is what kind of exit the VCs have in mind when they give you this money.
reply