I think it is true that people who obviously dislike AI for ideological reasons often lead with ecological concerns or doubt about the capabilities, leading to an unproductive discussion.
Have you considered engaging on those ecological concerns? There is quite a lot to dig into and can be pretty interesting. For example, try to project how much electricity will be needed to power all the datacenters in construction, then compare that to the existing grid and infra, then figure out the cooling capacity. If done well you will see that we have a pretty massive resource problem here
I had a look now, and apparently we are projected to increase by 2.3x datacenter power consumption until 2030 from 415 TWh to 945 TWh.
That is going from 1.5% of global electricity use to 3%.
It is less than I expected.
Maybe if AI does work out better than expected for knowledge work or becomes applicable to robotics and fields like construction, we are going to see a larger buildout.
> That is going from 1.5% of global electricity use to 3%.
> It is less than I expected.
I suspect this is because of the word "global". Are not most of these currently planned specifically for the USA? Sure, the USA has a disproportionate use of electricity, but IIRC it's like 16% (1/6th) of global?
3% of global electricity is roughly the same as 18% of US electricity; a bit less because not all the new DCs will be in the US, but that's something that I consider with regards to the economics and why I'm bearish on this topic, as I think it will be a case of Dutch disease in the USA: https://en.wikipedia.org/wiki/Dutch_disease
Okay nice, after looking at the macroview look at the immediate impact into local communities and how much data these companies refuse to, rightfully I might add, share with the public.
Weird how all these concerns can simply go away if they just simply shared the information the public wants (water usage, sound generation, power usage) rather than refuse to do so.
Right click on the back button and you get a full list of the previous ramen entries you've viewed. If he implemented with Javascript, he'd have to build a custom history menu.
You can today develop a mobile app with 20 screens without ever reviewing any of the code generated.
If you test each feature and have it iterate on your feedback, you can build a decent product in this way.
Does it write too much code? Perhaps. Could I bring those 100k lines through code review in a team where some members nitpick? No.
That does not change the fact that it works, and that you do not need to read the code even today.
Unless progress slows down dramatically and soon, it seems rather likely that most of us will not be reading code in the near future. Their marketing is not wrong.
I really hope vibe coded apps have to be labeled as such so I can make sure to avoid using them. As a customer, I have zero interest in using something that was made with little care or expertise.
Unless the app is released and running on user’s device, your “it works” is on the level of hackathon’s demo. Being on prod has always been the true testing ground of code.
It seems like when people are talking about production level quality and how the AI. should be helping them there, plenty of people comes up with their “it works on my machine” anecdotes.
Honestly, things have really changed in the past 6 months. Opus 4.5 got most of the way there, and Fable can now literally one-shot your run off the mill CRUD app.
I use a few of them daily. While there are still bugs, there are significantly less than there used to be back when everything was being maintained in my spare time.
Still not Netflix/Google standard yet, but definitely better than the average side project or pre-AI Bangalore special.
That is true, I was mostly speaking about a supposed need to review the code.
My effort instead goes to manual QA testing, providing feedback and preferences, and asking questions.
The limitation here is mostly that the model does not know what looks and feels good.
With improvements to the vision capabilities and a better understanding of motion, or what looks appealing to humans, the implementation could probably happen much more autonomously.
> That is true, I was mostly speaking about a supposed need to review the code.
Until you go to prod, you can believe a lot of things about the state of your code. Reviewing code is not merely about “Does this things work”. Testing and linting do cover most of that. Reviewing is mostly about: Will this design cover the current set of constraints (some may be conformance) and can it evolve? Are the assumptions correct? Is the security layer good enough?…
The user interface part of the code is only one single component out of many.
Even though a lot of mobile app are just presentation layer for a backend service, there are indeed a few stuff that warrants carefulness.
Like any data saved offline. Any update to that offline format means a migration plan unless it’s just a cache for the online data. Then if you support something like multiple organization, you don’t want user data to jump the separation between those siloes. And finally, if you you data that are created locally, or present data that are transformed locally using some feature, you have to be sure you’re not corrupting it or open some side vulnerabilities (think about the clickable vulnerability in messaging apps).
UX and UI can be designed using a prototyping tool coupled with user feedbacks. And with the wealth of components in the mobile SDK and the UI toolkit ability to create custom widgets, it’s very easy to implement the final version of that design. Most of the delicate work is presenting the correct information and that each interaction proceeds well.
Regarding clickable vulnerabilities in messaging apps, are you referring to the exploits that were enabled by vulnerabilities in system media parser and browser components?
This has essentially no practical relevance to app implementation.
What we are left with is not corrupting user data, particularly during migrations on app updates.
Compared to the attack surface of a backend service that handles user data, this is trivial.
We agree that the delicate work is presentation and interactions working well on device.
In my opinion this is best supported by extensive manual QA and user testing, rather than code review.
This is what unlocks tremendous productivity for mobile app development with AI.
I believe I was still using Opus 4.6 with the Claude Code CLI.
Before that, Gemini 3 Pro in Antigravity.
I have no experience with GPT 5.3 beyond seeing the nightmares colleagues produced in their MRs with GPT 5.3 Codex. It could be that they had the distilled 5.3 Codex Spark selected, I am not sure.
I am as horrified by the outcome here as the next person, but what exactly do you imagine police should do when responding to a call about an active shooter where they encounter a suspect armed with a handgun?
They could start by verifying the address of the house they're raiding. Way too often this doesn't happen and the police murder someone because they got the wrong house. They should identify the occupants of the house. The victim in this case had been swatted before and he had already warned the police that could happen. The swat team should have been skeptical going into this situation and taken the time to verify what was going on first. The call they got in this case claimed to be from the victim who said his father had shot his sister and he was hiding in another room. Even if the 911 call had been legit, the police would have shot the person who called for help and not the father, because they didn't bother to identify who they were shooting or who else was around when they sprayed bullets around the room from outside. They should have identified themselves as police. There's no reason not to. They should have at least attempted to use their big boy words before they started shooting up the place.
Identify themselves as LE, and of course physically represent as such, unambiguously, then demand the person put down the firearm. "Active Shooter" has no meaning just because the word is used. Also consider what everyone long forgot and few pay attention to; officers are paid, not volunteers. Risk is part of the job. You cannot shoot everything you think might be a threat. One can also question the quality of the system that handles emergency calls, or that responds to them. There are lots of guns in America. And lots of people who can say the words "active shooter". And often enough, phones and other objects are conveniently interpreted as guns, so I am not convinced that is the most important variable. Did he point it at the officers? If so, were the officers in proper uniform?
Now, if I were to answer your question, I would say it first depends on circumstances. I have encountered many people with guns. But if I was and active officer and encountered someone with a gun, I would do my best so that the encounter was arranged in a manner that gave me some advantage and at least a second or two to think before acting. Sometimes, mistakes are made though, and they always will be made. But the fact someone had a gun is no excuse.
The very smart and obvious thing to do would be to announce themselves loudly on arrival; all squad cars have very loud speakers on them and most police departments have at least one armored vehicle specially for high risk situations. Breaking in through a bathroom window and then running around the house with guns drawn is a recipe for disaster. If this kid had had good pistol skills (not that unusual unusual in the US) it might just as easily have ended with one or both of the cops getting shot.
Police in many jurisdictions will just walk onto your property in pursuit of a suspect and get mad at you if you open a window or door to see what the hell is going on outside your home.
I am making an argument based on the fundamental nature of the tool, which is to make stochastic, unvetted decisions our behalf — categorically different from everything else in our toolbox. The technical and social repercussions to this are potentially vast: no other tool comes close. So it is actually Linus who is making an unconvincing appeal to emotion (and authority) by pretending that LLMs resemble hammers.
I said at face value because there was no reason given in either the policy nor the article submitted here.
It would be interesting to know why they decided for a general prohibition, rather than going with the default "a human must be responsible for the contribution" kind of policy.
Perhaps they have received a flood of undesirable AI generated contributions, and actual contributors do not use AI significantly.
> To my knowledge there is not a single known case where this happened.
> News back then were about intentionally prompting to output known copyrighted material.
First, there are other cases if you take the time to dig. This is quite an old example (GPT-2) as i haven't kept up to date on this field recently, but it does show that this problem has been known about since before these systems were widely adopted: https://arxiv.org/abs/2012.07805 [0]
Second, GP said nothing about the type of effort required to make it happen, just that it can be done and that the copyright owner could come along and cause legal problems later. It's absolutely possible to have a fly-by contributor who purposefully asks for code that reproduces X/Y/Z without a maintainer knowing about it.
But then the maintainer is the one in legal trouble.
> When, despite millions of developers using agentic AI already, are these lawsuits supposed to manifest?
Legal / copyright / etc. cases often take a lot longer than a couple of years to come to fruition.
---
[0]: edit -- to clarify this is an example of the reproduction problem, not an example copyright infringement case.
The problem you linked is an older example of intentional prompting for copyrighted material.
The concern discussed here is copyrighted material being generated unintentionally and the original author asserting their rights.
This has, to my knowledge, not happened once.
If we are not talking about unintentional violations, I don't understand the point of the discussion.
I can also intentionally copy paste the copyrighted material into my merge request without the use of AI in an attempt to get the maintainer into trouble.
> The concern discussed here is copyrighted material being generated unintentionally and the original author asserting their rights.
both intentional (malicious contributor) or unintentional (Large-Laundering-Model) are copyright issues -- which is the point of GCC's policy.
> I can also intentionally copy paste the copyrighted material into my merge request without the use of AI in an attempt to get the maintainer into trouble.
You can. You can also do it significantly faster with significantly less effort while being harder to detect using agents etc.
I do not think some untested theory about sabotaging open-source projects by intentionally inserting copyrighted material using AI, causing legal issues for maintainers, is worthwhile to discuss here.
That is obviously not what anyone was referring to, nor does it make sense, when there is a much more reasonable basis to prohibit the same contribution.
Namely inserting vulnerabilities. This one actually happened before afaik, and provides a clear benefit to the attacker.
> just that it can be done and that the copyright owner could come along and cause legal problems later. It's absolutely possible to have a fly-by contributor who purposefully asks for code that reproduces X/Y/Z without a maintainer knowing about it.
If a contributor doesn't care about submitting copyrighted code, they can do it without an LLM as well.
Someone tried to contribute “vibe-coded” device support to a project I’m involved with, they said they did it all based on the device documentation, the code their agents spit out was copied verbatim out of a (GPL’d) project with which I’m familiar which supports that device.
LLMs are not learning things and then using that learning to construct new things. They are essentially a form of lossy compression of their training set. And you don’t need to be explicit about trying to reproduce a portion of that training set for an LLM to output one.
As it happens, all evaluations I have seen in the news were in fact explicit about trying to reproduce a portion of the training set.
I am not aware of any study attempting to measure unintentional reproduction.
With your example, I question whether you have seen this happen first hand. For all I know, the contributor could have explicitly prompted the model to reference the GPL project and had the agent clone the code from the web.
At a certain point you have to take people at their word; I’m reporting what the contributor said they did (used the documentation to generate the code).
I mean ai has generated copyright headers verbatim in code I asked it to make. I had a tutorial open from the web and asked the AI to generate an example for me and it was the example from the tutorial verbatim as well...
It was a frontier model from a few months ago. It hasn't done it recently. But it has happened. I imagine if there isn't a lot of training data for an idea it probably has a higher change of generating verbatim, so as time goes on, it should become less of a problem (at least with high quality models).
If anything, I would imagine that Google's changes are motivated by driving traffic to their Google Play Store, where they make billions in commissions.
Once this framework is in place for the Google Play Store, perhaps they can lobby for strict age verification laws, and then tell developers who publish outside of Google Play that they are responsible for compliance themselves.
reply