Live data from Hacker News

Define policy forbidding use of AI code generators

github.com

411–420 of 427 posts

Re: Define policy forbidding use of AI code generators

#411
post #406

Earlier quoted context omitted.

SourceHut has a crazy dude in charge. I'm not going there.

If no one calls you crazy you are doing something wrong. Crazy in what way?

maybe its all the stallman drama?

https://news.ycombinator.com/item?id=41837782

Re: Define policy forbidding use of AI code generators

#412

Earlier quoted context omitted.

> You don't fix their parts either, unless you absolutely have no other options. You don't build these parts in assembly lines. They're often not cheap commodities. Satellites, for example, are full of parts made by hand because no assembly line can handle the requirements. These, require specialized troubleshooting (debugging). If you're talking exclusively about the cheap stuff (trivial programs), you're in the wro…

Satellites are the most extreme of edge cases. The equivalent might be a binary that gets burned into a ROM chip installed in an impossible to access location. QEMU is not that. Granted I don't think something as specialized as QEMU is well suited to a component replacement model. But large parts of the codebases of the vast majority of software out there is.

> Satellites are the most extreme of edge cases.

Were the most extreme of edge cases. That was entirely because of space economics being stuck in a death spiral. SpaceX near single-handedly[0] turned this around, by focusing on slashing launch costs and increasing launch cadence. Both of that lead to more missions, meaning less risk, so satellites can be smaller and made of cheap COTS parts because now you can do 10 for price of 1, which enables economies of scale, blah blah. A feedback loop.

Or rather, the feedback loop. It's the same one that enabled mass production and commodities in every aspect of our lives. Satellites aren't an exception to my argument - space industry is just late to the party, but it's going through a commoditization process right now, in front of our very eyes.

10+ years from now, you won't find a hand-made part in any satellite outside obscure prototype edge cases.

--

[0] - Of course it was possible thanks to NASA COTS programs which funded it, and accumulation of knowledge, etc. SpaceX was the "operating end" of this transformation.

Re: Define policy forbidding use of AI code generators

#413

Earlier quoted context omitted.

Satellites are the most extreme of edge cases. The equivalent might be a binary that gets burned into a ROM chip installed in an impossible to access location. QEMU is not that. Granted I don't think something as specialized as QEMU is well suited to a component replacement model. But large parts of the codebases of the vast majority of software out there is.

> Satellites are the most extreme of edge cases. Were the most extreme of edge cases. That was entirely because of space economics being stuck in a death spiral. SpaceX near single-handedly[0] turned this around, by focusing on slashing launch costs and increasing launch cadence. Both of that lead to more missions, meaning less risk, so satellites can be smaller and made of cheap COTS parts because now you can do 10…

I see the evidence to the contrary.

SpaceX took years to develop and debug their own engine, from scratch. Highly specialized work.

They proud themselves of not relying on external supply chains, and doing everything in house.

The refurbishment of boosters is very much what I described earlier "you don't throw away good stuff, you maintain it".

So, in a sense, you went around your own argument without noticing and proved my point.

Re: Define policy forbidding use of AI code generators

#414

Earlier quoted context omitted.

What's the risk of not doing this? Better code but slower velocity for an open source project? I think that particular brand of risk makes sense for this particular project, and the authors don't seem particularly negative toward GenAI as a concept, just going through a "one way door" with it.

>Better code but slower velocity for an open source project Better code and "AI assist coding" are not exclusive of each other.

In my experience they seem to be, granted that is anecdotal.

Re: Define policy forbidding use of AI code generators

#415

Earlier quoted context omitted.

If no one calls you crazy you are doing something wrong. Crazy in what way?

maybe its all the stallman drama? https://news.ycombinator.com/item?id=41837782

What about it?

Re: Define policy forbidding use of AI code generators

#416

Earlier quoted context omitted.

> Satellites are the most extreme of edge cases. Were the most extreme of edge cases. That was entirely because of space economics being stuck in a death spiral. SpaceX near single-handedly[0] turned this around, by focusing on slashing launch costs and increasing launch cadence. Both of that lead to more missions, meaning less risk, so satellites can be smaller and made of cheap COTS parts because now you can do 10…

I see the evidence to the contrary. SpaceX took years to develop and debug their own engine, from scratch. Highly specialized work. They proud themselves of not relying on external supply chains, and doing everything in house. The refurbishment of boosters is very much what I described earlier "you don't throw away good stuff, you maintain it". So, in a sense, you went around your own argument without noticing and pr…

I think you need to look closer on what SpaceX does, how it does it, and why.

The degree of vertical integration lets them optimize production of the boosters. They're not throwaway things, but they're not pets either. They streamline production of parts as much as possible - but the point of reusability is to cut costs by orders of magnitude, and increase launch cadence, all of which created conditions for the rest of the space industry to scale up production.

In short: SpaceX not throwing away boosters enables everyone else to throw away satellites. SpaceX, too - consider the size of the Starlink constellations. These are not hand-made "pets".

Also consider their entire philosophy that led to reusable F9s: just keep launching, let shit explode, because throwing away more means making more gets cheaper, and learning gets faster. Even as they're an actual, well-tested product, reusability is still a book-keeping thing. They don't worry much about losing a booster or three, they can just make more - it's just more flights per booster on average -> lower costs for everyone.

And then also look at where they're heading: Starship is basically a steel can with some engines on top. The reasoning is similar: they need to be cheap to make at scale.

Re: Define policy forbidding use of AI code generators

#417

Earlier quoted context omitted.

maybe its all the stallman drama? https://news.ycombinator.com/item?id=41837782

What about it?

when I see the username, thats one of the threads that comes to mind so I searched for it.

Re: Define policy forbidding use of AI code generators

#418

Earlier quoted context omitted.

What about it?

when I see the username, thats one of the threads that comes to mind so I searched for it.

Which username and how is it related?

Edit: I see, interesting. Not sure it makes me change my opinion on the service but might explain what the other commenter meant.

Re: Define policy forbidding use of AI code generators

#419

Earlier quoted context omitted.

I see the evidence to the contrary. SpaceX took years to develop and debug their own engine, from scratch. Highly specialized work. They proud themselves of not relying on external supply chains, and doing everything in house. The refurbishment of boosters is very much what I described earlier "you don't throw away good stuff, you maintain it". So, in a sense, you went around your own argument without noticing and pr…

I think you need to look closer on what SpaceX does, how it does it, and why. The degree of vertical integration lets them optimize production of the boosters. They're not throwaway things, but they're not pets either. They streamline production of parts as much as possible - but the point of reusability is to cut costs by orders of magnitude, and increase launch cadence, all of which created conditions for the rest…

This degree of vertical integration is missing from any of the AI examples you mentioned.

The example you provided, the QR code generator, presents none of those qualities.

You used multiple AIs from different vendors (according to you: Sonnet and Gemini), a middleman (Aider), to produce a product that is not vertically integrated (uses qrious).

Meanwhile, qemu depends only on a tight set of dependencies (gcc, glib2, everything else optional). They are actually a good case of vertical integration.

In my opinion, you got it all reversed.

--

Starship is a terrible example. After failing to produce composite materials in house using an automated process, they hired specialized metal workers to do the body in steel, by hand. Again, it favors my line of reasoning that commoditization has many limitations.

--

You are also drifting away from the subject drastically, again. I have to constantly pull you in and remember you that we're talking about software first.

Not only you left the qemu subject, but now you forgotten that your own qr-generator _that you have chosen to showcase here_ has many of the failures you're now pointing at.

If you're only trying to leave with the last word, you're making it embarassing.

Re: Define policy forbidding use of AI code generators

#420

Oh hey, the thing I predicted in my blog titled "yes i will judge you for using AI" happened lol Basically I think open source has traditionally HEAVILY relied on hidden competency markers to judge the quality of incoming contributions. LLMs throw that entire concept on its head by presenting code that has competent markers but none of the backing experience. It is a very very jarring experience for experienced indiv…

this is 100% the actual crux of the problem, I agree
Post reply on HN