I would be more careful before assuming 5 years depreciation schedule. Currently price tags are attached to computing power, not the production cost. Computing is not getting meaningfully cheaper with newer GPUs but it only allows better scaling, which makes older hardware more relevant for many use cases. This is why A100 is still selling like hotcakes. I don't think this trend will change soon.
Apple can enjoy because it controls a significant fraction of consumer computing platform so they can simply collect tax from everyone else. This is not true for the rest of big tech. Only Google has Android but it cannot sit and enjoy because they still don't control hardware and AI is an existential problem for their search business.
There is a pretty simple yet disappointing reason. CSAM is much easier to investigate and prosecute. You got evidence, you prosecute. Almost guaranteed conviction. You can even enforce big tech to implement proactive monitoring systems.
Compared to this, CSA is much harder. Every case is different. You have to do due diligence. And it is extremely hard to proactively detect them. Careful criminals will destroy all evidence. The number of case itself is smaller. And there is a good chance to lose in the court and for prosecutors this is a clearly risky move. Good ol' criminal investigation is expensive. There is a structural reason not to prioritize them.
The whole incentive structure is broken. The only thing to fix this is external pressure, but even it does not work these days. Exposing CSA is a rare event but media needs constant, sensitive headlines so they tend to treat CSA and CSAM like the same thing. Hence external pressures do not work, and even worse those work in a wrong way. This creates a bad feedback loop.
The title is kinda misleading. The actual wording is not specific about humanoid robots but "physical AI" which encompasses every machinery that can be potentially integrated with AI, especially focused on mass manufacturing for the Korean case. Basically this project is about all physical infrastructures to automate high tech manufacturing industry.
My personal rule of thumb: I am usually okay with agents driving e2e implementations if this won't make life noticeably worse when it does not work. Some analytical code? Perfectly fine. Hobby projects? Fine, though I prefer doing a fun part myself. Refactoring production code generating 10x more revenue than my salary? You'd better be at least understanding what it does.
This is one of the reason why that law will surely be challenged and very likely invalidated by SCOTUS. Trade secret protection is a very fundamental part and if this is forced to be broken by legally compelled speech, then it needs to have very creative interpretations over judicial precedents.
Many developers with good will actually tried that and gave up due to lots of problems. This is not just bad ROI but also a legal minefield. Engineers usually cannot argue against this kind of risks. Enforcing this will unlikely work in higher courts. Though something like open sourcing protocols for server reimplementation may have some chances.
While I see problems in the law but the spirit is reasonable. We need to push toward this direction. At least there should be difficult economical trade-off for publishers when they decide to shut down the game. Nowadays, some random executive just takes look into some excel, see some games have declining revenue and decides to "simplify the business" without much thoughts. This has to stop.
Because of high coupling dependencies between google3 projects, compiling just a single project usually pulls hundreds of thousands of different build targets.
All the developments are done in a virtual remote file system. From editing to compiling, everything is done remotely. Of course this does not fully stop people from doing manual c&p, but it still makes it hard enough to discourage it.
I guess it is much more frequent to maintain internal patches rather than doing all the merging work into upstream, especially the feature is non-trivial. Merging upstream consumes more time externally and internally, and many developers are working with an aggressive timeline. I don't think it is fair to criticize them because they didn't do ideal things from the beginning.
The quality of generated code does not matter. The problem is when it breaks 2 AM and you're burning thousands of dollars every minutes. You don't own the code that you don't understand, but unfortunately that does not mean you don't own the responsibility as well. Good luck on writing the postmortem, your boss will have lots of question for you.
This is not very surprising. I've always thought that it's more of correlation than causation. If you're a good problem solver, then there is a good chance that you are probably good at both college admission and software engineering. So companies have been using it as their proxy for hiring because... why not. I'm not saying college curricula are useless, but this dependency on (imperfect) correlation might have caused significant opportunity costs for talent acquisition and now companies are slowly acknowledging it.
I just hope them to provide an option to get rid of all those predictive models and just use a static, consistent layout. At least I can blame myself if my typo is from my own mistake.
This looks interesting. This project has some novelty as a research and actually delivered a promising PoC but as a product it implies that its training was severely constrained by computing resources, which correlates well with the report that their CFO overruled CEO's decision on ML infra investment.
JG's recent departure and follow up massive reorg to get rid of AI, rumors on Tim's upcoming step down in early 2026... All of these signals indicate that those non-ML folks have won corporate politics to reduce the in-house AI efforts.
I suppose this was a part of serious efforts to deliver in-house models but the directional changes on AI strategy made them to give up. What a shame... At least the approach itself seem interesting and hope others to take a look and use it for building something useful.
Don't forget to mention automatic enrollment of your production group into access-on-demand. Any minor access on the production now requires the group manager's approval. I had a fun time with some production fire where only director level folks can approve the access. Even funnier thing is that this "refactor" was done without any prior notice.