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

AI tooling must be disclosed for contributions

github.com

Post reply on HN
Print view View original

111–120 of 482 posts

Re: AI tooling must be disclosed for contributions

#111

Post by ToucanLoucan »

geodel wrote: post #107
btucker wrote: post #81

Earlier quoted context omitted.

I've been starting to think of it like this: Great Engineer + AI = Great Engineer++ (Where a great engineer isn't just someone who is a great coder, they also are a great communicator & collaborator, and love to learn) Good Engineer + AI = Good Engineer OK Engineer + AI = Mediocre Engineer

Not Engineer + AI = Now an Engineer Thats the reason for high valuation of AI companies.

Of all the things I would absolutely not trust the stock market to evaluate, "technical competence" is either near or at the top.

The people deciding how much OpenAI is worth would probably struggle to run first-time setup on an iPad.

Re: AI tooling must be disclosed for contributions

#112

Post by biophysboy »

QuercusMax wrote: post #106
biophysboy wrote: post #94

Earlier quoted context omitted.

I sort of think of it in terms of self-deskilling. If an OK engineer is still actively trying to learn, making mistakes, memorizing essentials, etc. then there is no issue. On the other hand, if they're surrendering 100% of their judgment to AI, then they will be mediocre.

The same people who just copy-pasted stack overflow answers and didn't understand why or how things work are now using AI to create stuff that they also don't understand.

And for low-stakes one-time hobby projects, they're correct to do so!

Re: AI tooling must be disclosed for contributions

#113

Post by popalchemist »

alfalfasprout wrote: post #97
ineedasername wrote: post #72

Earlier quoted context omitted.

Courts (at least in the US) have already ruled that use of ingested data for training is transformative. There’s lots of details to figure, but the genie is out of the bottle. Sure it’s a big hill to climb in rethinking IP laws to align with a societal desire that generating IP continue to be a viable economic work product, but that is what’s necessary.

> Courts (at least in the US) have already ruled that use of ingested data for training is transformative This is far from settled law. Let's not mischaracterize it. Even so, an AI regurgitating proprietary code that's licensed in some other way is a very real risk.

No more so than regurgitating an entire book. While it could technically be possible in the case of certain repos that are ubiquitous on the internet (and therefore overrepresented in training data to the point that they are "regurgitated" verbatim, in whole), it is extremely unlikely and would only occur after deliberate prompting. The NYT suit against Open AI shows (in discovery) that the NYT was only able to get partial results after deliberately prompting the model with portions of the text they were trying to force it to regurgitate.

So. Yes, technically possible. But impossible by accident. Furthermore when you make this argument you reveal that you don't understand how these models work. They do not simply compress all the data they were trained on into a tiny storable version. They are effectively multiplication matrices that allow math to be done to predict the most likely next token (read: 2-3 Unicode characters) given some input.

So the model does not "contain" code. It "contains" a way of doing calculations for predicting what text comes next.

Finally, let's say that it is possible that the model does spit out not entire works, but a handful of lines of code that appear in some codebase.

This does not constitute copyright infringement, as the lines in question a) represent a tiny portion of the whole work (and copyright only protecst against the reduplication of whole works or siginficant portions of the work), and B) there are a limited number of ways to accomplish a certain function and it is not only possible but inevitable that two devs working independently could arrive at the same implementation. Therefore using an identical implementation (which is what this case would be) of a part of a work is no more illegal than the use of a certain chord progression or melodic phrasing or drum rhythm. Courts have ruled about this thoroughly.

Re: AI tooling must be disclosed for contributions

#114

Post by danenania »

thallavajhula wrote: post #27

I’m loving today. HN’s front page is filled with some good sources today. No nonsense sensationalism or preaching AI doom, but more realistic experiences. I’ve completely turned off AI assist on my personal computer and only use AI assist sparingly on my work computer. It is so bad at compound work. AI assist is great at atomic work. The rest should be handled by humans and use AI wisely. It all boils down back to hu…

The way I've been thinking about it is that the human makes the key decisions and then the AI connects the dots.

What's a key decision and what's a dot to connect varies by app and by domain, but the upside is that generally most code by volume is dot connecting (and in some cases it's like 80-90% of the code), so if you draw the lines correctly, huge productivity boosts can be found with little downside.

But if you draw the lines wrong, such that AI is making key decisions, you will have a bad time. In that case, you are usually better off deleting everything it produced and starting again rather than spending time to understand and fix its mistakes.

Things that are typically key decisions:

- database table layout and indexes

- core types

- important dependencies (don't let the AI choose dependencies unless it's low consequence)

- system design—caches, queues, etc.

- infrastructure design—VPC layout, networking permissions, secrets management

- what all the UI screens are and what they contain, user flows, etc.

- color scheme, typography, visual hierarchy

- what to test and not to test (AI will overdo it with unnecessary tests and test complexity if you let it)

- code organization: directory layout, component boundaries, when to DRY

Things that are typically dot connecting:

- database access methods for crud

- API handlers

- client-side code to make API requests

- helpers that restructure data, translate between types, etc.

- deploy scripts/CI and CD

- dev environment setup

- test harness

- test implementation (vs. deciding what to test)

- UI component implementation (once client-side types and data model are in place)

- styling code

- one-off scripts for data cleanup, analytics, etc.

That's not exhaustive on either side, but you get the idea.

AI can be helpful for making the key decisions too, in terms of research, ideation, exploring alternatives, poking holes, etc., but imo the human needs to make the final choices and write the code that corresponds to these decisions either manually or with very close supervision.

Re: AI tooling must be disclosed for contributions

#115

Post by fnimick »

falcor84 wrote: post #64
koolba wrote: post #56

Earlier quoted context omitted.

> You must ask "Do I trust where this came from?" And to answer that, you need to know where it come from. No you don’t. You can’t outsource trust determinations. Especially to the people you claim not to trust! You make the judgement call by looking at the code and your known history of the contributor. Nobody cares if contributors use an LLM or a magnetic needle to generate code. They care if bad code gets introduc…

Trust is absolutely a thing. Maintaining an open source project is an unreasonably demanding and thankless job, and it would be even more so if you had to treat every single PR as if it's a high likelihood supply-chain attack.

While true, we really should be treating every single piece of external code as though it's malicious.

Re: AI tooling must be disclosed for contributions

#116

Post by kazinator »

I think that in the FOSS environmment, it is assumed that when you submit something upstream, that you are the copyright holder. Some projects like GNU require you to sign papers legally attesting this.

It would be a lie to sign those papers for something you vibe coded.

It's not just courtesy; you are committing fraud if you put your copyright notice on something you didn't create and publishing that to the world.

I don't just want that disclosed; I cannot merge it if it is disclosed, period.

Re: AI tooling must be disclosed for contributions

#120

Post by ilc »

btown wrote: post #83
tick_tock_tick wrote: post #55

Earlier quoted context omitted.

> AI is only as smart as the human handling it. I think I'm slowly coming around to this viewpoint too. I really just couldn't understand how so many people were having widely different experiences. AI isn't magic; how could I have expected all the people I've worked with who struggle to explain stuff to team members, who have near perfect context, to manage to get anything valuable across to an AI? I was original pr…

One of my mental models is that the notion of "effective engineer" used to mean "effective software developer" whether or not they were good at system design. Now, an "effective engineer" can be a less battle-tested software developer, but they must be good at system design. (And by system design, I don't just mean architecture diagrams: it's a personal culture of constantly questioning and innovating around "let's t…

I suspect that truly battle tested engineers will go up in value.

I don't think that it lowers the bar there, if anything the bar is far harsher.

If I'm doing normal coding I make X choices per time period, with Y impacts.

With AI X will go up and the Y / X ratio may ALSO go up, so making more decisions of higher leverage!

Post reply on HN