Earlier quoted context omitted.
I don't want to review code the author doesn't understand This really bothers me. I've had people ask me to do some task except they get AI to provide instructions on how to do the task and send me the instructions, rather than saying "Hey can you please do X". It's insulting.
Had someone higher up ask about something in my area of expertise. I said I didn't think is was possible, he followed up with a chatGPT conversation he had where it "gave him some ideas that we could use as an approach", as if that was some useful insight. This is the same people that think that "learning to code" is a translation issue they don't have time for as opposed to experience they don't have.
Define policy forbidding use of AI code generators
351–360 of 427 posts
Re: Define policy forbidding use of AI code generators
#352Earlier quoted context omitted.
> The LLM work sounds dumb, and the suggestion that it made "a qr code generator" is disingenuous. The LLM barely did a frontend for it. Barely. Yes, and? The goal wasn't "write me a QR library" it was "here's my pain point, solve it". > It sounds like the author payed for `npm install`, and thinks he's on top of things and being smart. I can put this another way if you prefer: Running `npm install qrious`: trivial.…
> Knowing qrious exists and how to integrate it into a page: expensive. qrious literally has it integrated already: https://github.com/davidshimjs/qrcodejs/blob/master/index.ht... I see many issues. The main one is that none of this is relevant to the qemu discussion. It's on another whole level of project. I kind of regret asking the poor guy to show his stuff. None of these tutorial projects come even close to what…
So the fact they've already got the example is great if you do in fact already have that knowledge, and *completely useless* if you don't.
> I kind of regret asking the poor guy to show his stuff. None of these tutorial projects come even close to what an AI contribution to qemu would look like. It's pointless.
For better and worse, I suspect it's very much the kind of thing AI would contribute.
I also use it for things, and it's… well, I have seen worse code from real humans, but I don't think highly of those humans' coding skills. The AI I've used so far are solidly at the quality level of "decent for a junior developer", not more, not less. Ridiculously broad knowledge (which is why that quality level is even useful), but that quality level.
Use it because it's cheap or free, when that skill level is sufficient. Unless there's a legal issue, which there is for qemu, in which case don't.
Re: Define policy forbidding use of AI code generators
#353Earlier quoted context omitted.
>I don't want to review code the author doesn't understand I get that. But the AI tooling when guided by a competent human can generate some pretty competent code, a lot of it can be driven entirely through natural language instructions. And every few months, the tooling is getting significantly more capable. I'm contemplating what exactly it means to "understand" the code though. In the case of one project I'm worki…
> I'm contemplating what exactly it means to "understand" the code though. You can't seriously be questioning the meaning of "understand"... That's straight from Jordan B. Peterson's debate playbook which does nothing but devolve the conversation into absurdism, while making the person sound smart. > I've set up a test cluster and am running a variety of testing scenarios on the new storage backend. So I understand i…
Re: Define policy forbidding use of AI code generators
#354Earlier quoted context omitted.
> The LLM work sounds dumb, and the suggestion that it made "a qr code generator" is disingenuous. The LLM barely did a frontend for it. Barely. Yes, and? The goal wasn't "write me a QR library" it was "here's my pain point, solve it". > It sounds like the author payed for `npm install`, and thinks he's on top of things and being smart. I can put this another way if you prefer: Running `npm install qrious`: trivial.…
> Knowing qrious exists and how to integrate it into a page: expensive. qrious literally has it integrated already: https://github.com/davidshimjs/qrcodejs/blob/master/index.ht... I see many issues. The main one is that none of this is relevant to the qemu discussion. It's on another whole level of project. I kind of regret asking the poor guy to show his stuff. None of these tutorial projects come even close to what…
I didn't know qrious exist. Last time I checked for frontend-only QR code generators myself, pre-AI, I couldn't find anything useful. I don't do frontend work daily, I'm not on top of the garbagefest the JS environment is.
Probably half the win applying AI to this project was that it a) discovered qrious for me, and b) made me a working example frontend, in less time than it would take me to find the library myself among sea of noise.
'ben_w is absolutely correct when he wrote:
> The goal wasn't "write me a QR library" it was "here's my pain point, solve it".
And:
Running `npm install qrious`: trivial.
Knowing qrious exists and how to integrate it into a page: expensive.
This is precisely what it was. I built this in between other stuff, paying half attention to it, to solve an immediate need my wife had. The only thing I cared about it here is that:1. It worked and was trivial to use
2. Was 100% under my control, to guarantee no tracking, telemetry, ads, crypto miners, and other usual web dangers, are present, and ensure they never are going to be present.
3. It had no build step whatsoever, and minimal dependencies that could be vendored, because again, I don't do webshit for a living and don't have time for figuring out this week's flavor of building "Hello world" in Node land.
(Incidentally, I'm using Claude Code to build something bigger using a web stack, which forced me to figure out the current state of tooling, and believe me, it's not much like what I saw 6 months ago, and nothing like what I saw a year ago.)
2 and 3 basically translate to "I don't want to ever think about it again". Zero ops is my principle :).
----
> I see many issues. The main one is that none of this is relevant to the qemu discussion. It's on another whole level of project.
It was relevant to the topic discussed in this subthread. Specifically about the statement:
> But there are also local tools generated faster than you could adjust existing tools to do what you want. I'm running 3 things now just for myself that I generated from scratch instead of trying to send feature requests to existing apps I can buy.
The implicit point of larger importance is: AI contributions may not show up fully polished in OSS repos, but making it possible to do throwaway tools to address pain points directly provides advantages that compound.
And my examples are just concrete examples of projects that were AI generated with a mindset of "solve this pain point" and not "build a product", and making them took less time and effort than my participation in this discussion already did.
Re: Define policy forbidding use of AI code generators
#355Earlier quoted context omitted.
While this is a generally true statement (and has echoes in other areas like sovereign citizens), GenAI may make copyright (and copyleft) economically redundant. While the AI we have now is not good enough to make an entire operating system when asked*, if/when they can, the benefits of all the current licensing models evaporate, and it doesn't matter if that model is proprietary with no source, or GPL, or MIT, becau…
I have a few sociophilosophical quibbles about the impact of this, but to focus on a practical part: > by that point anyone else can reproduce your OS for whatever the cost of tokens is without ever touching your code. Do you think that the cost of tokens will remain low enough once these companies for now operating at loss have to be profitable, and it really is going to be “anyone else”? Or, would it be limited to…
When considering current models, it's not in their power to prevent it:
DeepSeek demonstrated big models could be trained very easily for a modest budget, and inference is mostly constrained by memory access rather than compute, so if we had smartphones with a terabyte of RAM with a very high bandwidth to something like a current generation Apple NPU, things like DeepSeek R1 would run locally at (back-of-the-envelope calculation) about real-time — and drain the battery in half an hour if you used that model continuously.
But current models are not good enough, so the real question is: "who will hold what power when such models hypothetically are created?", and I have absolutely no idea.
> Do you think someone would create and make public (and gather so much contributor effort) something on the scale Linux, if they knew that it would be open to be scraped by an intermediary who can sell it at whatever price they choose to set to companies that then are free to call it their own and repackage commercially without contributing back, providing their source or crediting the original authors in any way?
Consider it differently: how much would it cost to use an LLM to reproduce all of Linux?
I previously rough-estimated that at $230/megatoken of (useful final product) output, an AI would be energy-competitive vs. humans consuming calories to live: https://news.ycombinator.com/item?id=44304186
As I don't have specifics, I need to Fermi-estimate this:
I'm not actually sure how big any OS (with or without apps) is, but I hear a lot of numbers in the range of 10-50 million. Let's say 50 Mloc.
I don't know the tokens per line, I'm going to guess 10.
50e6 lines * 10 tokens/line * $230/(1e6 tokens) = $115,000
There's no fundamental reason for $230/megatoken beyond that's when the AI is economically preferable to feeding a human who is doing it for free and you just need to stop them from starving to death, even if you have figured out how to directly metabolise electricity which is much cheaper than food: on the one hand $230, this is on the very expensive end of current models; on the second hand, see previous point about running DeepSeek R1 on phone processor with more RAM and bandwidth to match; on the third hand*, see other previous point that current models just aren't good enough to bother.
So it's current not available at any price, but when the quality is good, even charging a rate that's currently expensive makes all humans unemployable.
* Insert your own joke about about off-by-one-errors
Re: Define policy forbidding use of AI code generators
#356Earlier quoted context omitted.
> Knowing qrious exists and how to integrate it into a page: expensive. qrious literally has it integrated already: https://github.com/davidshimjs/qrcodejs/blob/master/index.ht... I see many issues. The main one is that none of this is relevant to the qemu discussion. It's on another whole level of project. I kind of regret asking the poor guy to show his stuff. None of these tutorial projects come even close to what…
Person in question here. I didn't know qrious exist. Last time I checked for frontend-only QR code generators myself, pre-AI, I couldn't find anything useful. I don't do frontend work daily, I'm not on top of the garbagefest the JS environment is. Probably half the win applying AI to this project was that it a) discovered qrious for me, and b) made me a working example frontend, in less time than it would take me to…
Since you're here, I have another question relevant to the thread: do you pay for AI tools or are you using them for free?
Re: Define policy forbidding use of AI code generators
#357Earlier quoted context omitted.
Yup. Or, "Just look around!".
If it was self-evident then I wouldn’t need to ask for evidence. And I imagine you wouldn’t need to be waving your hands making excuses for the lack of evidence.
It's not possible for this level of impact at the bottom to make no change on the net near the top, so I propose that effects may be delayed and not immediately apparent. LLMs are still a new thing in business timelines.
TL;DR: just wait a bit more.
One thing I can hint at, but can't go into details, is that I personally know of at least one enterprise-grade project whose roadmap and scoping - and therefore, funding - is critically dependent on AI speeding up significant amount of development and devops tasks by at least 2-3x; that aspect is understood by both developers, managers, customers and investors, and not disputed.
So, again: just wait a little longer.
--
[0] - Except maybe for Aider, whose author always posts how much of its own code Aider wrote in a given release; it's usually way above 50%.
Re: Define policy forbidding use of AI code generators
#358Earlier quoted context omitted.
Person in question here. I didn't know qrious exist. Last time I checked for frontend-only QR code generators myself, pre-AI, I couldn't find anything useful. I don't do frontend work daily, I'm not on top of the garbagefest the JS environment is. Probably half the win applying AI to this project was that it a) discovered qrious for me, and b) made me a working example frontend, in less time than it would take me to…
Cool, makes sense. Since you're here, I have another question relevant to the thread: do you pay for AI tools or are you using them for free?
I pay for them; until last week, this was almost entirely[0] pay-as-you-go use of API keys via TypingMind (for chat) and Aider (for coding). The QR code project I linked was made by Aider. Total cost was around $1 IIRC.
API options were, until recently, very cheap. Most of my use was around $2 to $5 per project, sometimes under $2. I mostly worked with GPT-4, then Sonnet 3.5, briefly with Deepseek-R1; by the time I got around to testing Claude Sonnet 3.7, Google released Gemini 2.5 Pro, which was substantially cheaper, so I stuck to the latter.
Last week I got myself the Max plan for Anthropic (first 5x, then the 20x one) specifically for Claude Code, because using pay-as-you-go pricing with top models in the new "agentic" way got stupidly expensive; $100 or $200 per month may sound like a lot, but less so when taking the API route would have you burn this much in a day or two.
--
[0] - I have the $20/month "Plus" subscription to ChatGPT, which I keep because of gpt-4o image generation and o3 being excellent as my default model for random questions/problems, many of them not even coding-related. I could access o3 via API, but this gets stupidly expensive for casual use; subscription is a better deal now.
Re: Define policy forbidding use of AI code generators
#359Earlier quoted context omitted.
> I feel like we'd be hearing from business that crushed their competition by delivering faster or with fewer people. Where are those businesses? As if tech part was the major part of getting the product to market. Those businesses are probably everywhere. They just aren't open about admitting they're using AI to speed up their marketing/product design/programming/project management/graphics design, because a) it's n…
> They just aren't open about admitting they're using AI to speed up their marketing/product design/programming/project management/graphics design Sure… they'd hate to get money thrown at them from investors.
Re: Define policy forbidding use of AI code generators
#360Earlier quoted context omitted.
Cool, makes sense. Since you're here, I have another question relevant to the thread: do you pay for AI tools or are you using them for free?
TL;DR: I pay, I always try to use SOTA models if I can. I pay for them; until last week, this was almost entirely[0] pay-as-you-go use of API keys via TypingMind (for chat) and Aider (for coding). The QR code project I linked was made by Aider. Total cost was around $1 IIRC. API options were, until recently, very cheap. Most of my use was around $2 to $5 per project, sometimes under $2. I mostly worked with GPT-4, th…
Interesting; I'm finding myself doing the opposite — I have API access to at least OpenAI, but all the SOTA stuff becomes free so fast that I don't expect to lose much by waiting.
My OpenAI API credit expired mostly unused.