Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Define policy forbidding use of AI code generators

github.com

Post reply on HN
Print view View original

371–380 of 427 posts

Re: Define policy forbidding use of AI code generators

#371

Post by brulard »

amake wrote: post #222
bredren wrote: post #200

Earlier quoted context omitted.

This is happening right now and it won’t be obvious until the liquidity events provide enough cover for victory lap story telling. The very knowledge that an organization is experiencing hyper acceleration due to its successful adoption of AI across the enterprise is proprietary. There are no HBS case studies about businesses that successfully established and implemented strategic pillars for AI because the pillars w…

> This is happening right now and it won’t be obvious until I asked for evidence and, as always, lots of people are popping out of the woodwork to swear that it's true but I can't see the evidence yet. OK, then. Good luck with that.

Do you think that company success and it's causes are measurable day by day? I've worked for an industrial company that completely screwed up their software development, but their business is rooted so deep into other businesses, that it would take a decade until the result emerges. This may be extreme, but for average business I would expect 2-3 years for these results to be measurable. Startups may be quicker, but it's extremely difficult to compare them as every startup is quite unique. So if you wait for hard evidence, good luck not missing the train.

Re: Define policy forbidding use of AI code generators

#372

Post by brulard »

bredren wrote: post #205
WD-42 wrote: post #115

Earlier quoted context omitted.

For some reason these fully functional ai generated projects that the authors vibe out while playing guitar and clipping their toenails are never open source.

Mine is. And it is awesome: https://github.com/banagale/FileKitty The most recent release includes a MacOS build in a dmg signed by Apple: https://github.com/banagale/FileKitty/releases/tag/v0.2.3 I vibed that workflow just so more people could have access to this tool. It was a pain and it actually took time away from toenail clipping. And while I didn't lay hands on a guitar much during this period, I did manage to…

man, the icon is beautiful!

Re: Define policy forbidding use of AI code generators

#373

Post by brulard »

amake wrote: post #191
linsomniac wrote: post #156

Earlier quoted context omitted.

Not OP, but: I'm getting towards the end of a vibe coded ZFS storage backend to ganeti that includes the ability to live migrate VMs to another host by: taking snapshot and replicating it to target, pausing VM, taking another incremental snapshot and replicating it, and then unpausing the VM on the new destination machine. https://github.com/linsomniac/ganeti/tree/newzfs Other LLM tools I've built this week: This aft…

None of this seems relevant to the original claim: "Software projects that somehow are 100% human developed will not be competitive with AI assisted or written projects" I don't feel like it's meaningful to discuss the "competitiveness" of a handful of bespoke local or internal tools.

It's like saying "if we discuss professional furniture making, it's not relevant that you are able to cut, drill, assemble, glue, paint, finish wood quickly with good enough quality".

Re: Define policy forbidding use of AI code generators

#375

Post by brulard »

linsomniac wrote: post #161
Retric wrote: post #146

Earlier quoted context omitted.

That’s true in the short term. Longer term it’s questionable as using AI tools heavily means you don’t remember all the details creating a new form of technical debt.

Dude, have you ever looked at code you wrote 6 months ago and gone "What was the developer thinking?" ;-)

Exactly. Claude code can explain code I've written to me better than I could. I feel like people who don't see AI as a transformative element to programming probably didn't experience what it can do today as opposed to 6 months or a year ago. It's night and day difference. And it still was useful back then

Re: Define policy forbidding use of AI code generators

#376

Post by brulard »

halostatue wrote: post #48
JonChesterfield wrote: post #22

Interesting. Harder line than the LLVM one found at https://llvm.org/docs/DeveloperPolicy.html#ai-generated-cont... I'm very old man shouting at clouds about this stuff. I don't want to review code the author doesn't understand and I don't want to merge code neither of us understand.

I have just started adding DCO to _all_ of the open source code that I maintain and will be adding text like this on `CONTRIBUTING.md`: --- LLM-Generated Contribution Policy Color is a library full of complex math and subtle decisions (some of them possibly even wrong). It is extremely important that any issues or pull requests be well understood by the submitter and that, especially for pull requests, the developer…

Good luck detecting the LLM use

Re: Define policy forbidding use of AI code generators

#377

Post by galangalalgol »

brulard wrote: post #375
linsomniac wrote: post #161

Earlier quoted context omitted.

Dude, have you ever looked at code you wrote 6 months ago and gone "What was the developer thinking?" ;-)

Exactly. Claude code can explain code I've written to me better than I could. I feel like people who don't see AI as a transformative element to programming probably didn't experience what it can do today as opposed to 6 months or a year ago. It's night and day difference. And it still was useful back then

Yeah 6 months ago Claude could make me a rust function that wouldn't compile but got me pointed in the right direction. Now it will make it correct with comments and unit tests with idiomatic style just using chat. But we don't have to use chat. Even open models today like devstral when combined with an agent can run cargo check and clippy and self prompt (with rusts great error messages) to fix everything. Prompting it with some unit test cases lets it iterate until those pass too. Software development has fundamentally changed. I still would advise developers who care about performance to be able to read asm. But just like I wouldn't write asm anymore, because the llvm optimiser is really good, we are going to get to a point where designing the test cases will be the same as developing the software.

Re: Define policy forbidding use of AI code generators

#378

Post by alganet »

TeMPOraL wrote: post #364
bonzini wrote: post #209

Earlier quoted context omitted.

Good luck debugging

You don't debug AI-generated code - you throw the problematic chunk away and have AI write it again, and if that doesn't help, you repeat the process, possibly with larger chunks. Okay, not in every case, but in many, and that's where we're headed. The reason is economics - i.e. the same reason approximately no one in the West repairs their clothes or appliances; they just throw the damaged thing away and buy a new o…

You don't throw away dams, bridges, factories, submarines, planes.

There is a lot of man made stuff you just cannot easily replace. Instead, we maintain it.

Remember, _this is not about you_. The post is about qemu.

I would argue that qemu is analogous to one of these pieces of infrastructure. There is only a handful of powerful virtual machines. These are _not_ easily replaceable commodities.

Re: Define policy forbidding use of AI code generators

#379

Post by saurik »

As someone who once worked on a product that had to carefully walk the line of legality, I haven't found any mention in this discussion of what I imagine is a key problem for qemu, that doesn't face other projects: as an emulator, they are already under a lot of scrutiny for legality, and so they are going to need to be a lot more conservative than other random projects with respect to increasing their legal risk.
Post reply on HN