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

AI in software engineering at Google: Progress and the path ahead

research.google

Post reply on HN
Print view View original

191–200 of 245 posts

Re: AI in software engineering at Google: Progress and the path ahead

#191

Post by vitus »

bigiain wrote: post #14

I'm looking forward to the day that some spicy autocomplete regurgitates an obvious chunk of AGPL code that it's stolen without permission or attribution - and it ends up in some critical part of Googles money printing machine, and the outside world finds out about it. I'm gonna need a _lot_ of popcorn.

If there's any risk of this happening, it's probably because someone imported AGPL code into the codebase, outside of //third_party, after removing the copyright notice / license. (We have an allowlist of acceptable third-party licenses; I would not expect it to include copyleft licenses like AGPL.)

We nominally have controls against this sort of thing, but if it's only weakly-enforced policy, then unfortunately it's easy enough to bypass.

Re: AI in software engineering at Google: Progress and the path ahead

#192

Post by shermantanktop »

skydhash wrote: post #166
bongodongobob wrote: post #43

Earlier quoted context omitted.

Oh come on, the user is talking about building UIs. I don't know how else you learn. Your attitude just reeks of high-horse. As if it was better to learn things from stackoverflow.

Who learned stuff from stack overflow? In my own case, it was all books, plus a few videos. Stack Overflow was mostly to know why things has gone (errors not explicit enough) or very specific patterns. And there was a peer review system which lent credibility to answers.

“In my own case...” something worked for you. So what?

Are you sure that would work for others? And that other approaches might not be more effective?

I’ve learned lots of things from SO. The top voted answers usually provide quite a bit of “why” content which have general utility or pointers to more general content.

Yes, there are insufferable people on there, but there are gatekeepers and self-centered people everywhere.

Re: AI in software engineering at Google: Progress and the path ahead

#193

Post by shermantanktop »

booleandilemma wrote: post #177
DebtDeflation wrote: post #151

Earlier quoted context omitted.

It's the wrong question. It's like asking "How long until a bulldozer [1] fully replaces a human construction worker?" A bulldozer is not a full replacement for a human construction worker. However, 1 worker with a bulldozer can do the work of 10 workers with shovels. And 10 workers with bulldozers can build things no amount of workers with shovels can. [1] I'm using bulldozer as shorthand for all automated construct…

But then the 10 shovel-wielding humans are out of a job, right? The employer isn't just going to give everyone bulldozers. It'll be one guy with a bulldozer doing the work of ten men.

Buggy-whip makers aren’t around anymore…

New tech drives job changes. Always has, always will. No guarantee that the changes are good for every individual. And there’s no guarantee that they are good in the aggregate, either.

Re: AI in software engineering at Google: Progress and the path ahead

#194

Post by diggan »

pixiemaster wrote: post #180
stuckinhell wrote: post #176

Earlier quoted context omitted.

"When AI is used properly" is a very very loaded statement. Especially since evidence shows code is one of the worst things its good at, it' a lot better at other tasks.

every expert i talk to says: „LLMs are not good for my domain, but for $other_domain“

Put another way: "LLMs are great when I don't have lots of experience in the domain but want to do something in that domain. Otherwise, my own brain works better"

Re: AI in software engineering at Google: Progress and the path ahead

#195

Post by shermantanktop »

HeatrayEnjoyer wrote: post #20
jjallen wrote: post #16

Earlier quoted context omitted.

How would the outside world find out about private Google code? Maybe the fact could be leaked? Unlikely though.

An insider could tip them off, then IP owner sues and Google has to produce it during discovery.

And? For big companies, lawsuits are mostly about being forced to pay money. Rarely does losing a case drive real behavioral change, much less fundamental change.

IP getting coughed out of an AI will keep some lawyers busy and result in fig leaf changes.

Re: AI in software engineering at Google: Progress and the path ahead

#196

Post by wil421 »

booleandilemma wrote: post #177
DebtDeflation wrote: post #151

Earlier quoted context omitted.

It's the wrong question. It's like asking "How long until a bulldozer [1] fully replaces a human construction worker?" A bulldozer is not a full replacement for a human construction worker. However, 1 worker with a bulldozer can do the work of 10 workers with shovels. And 10 workers with bulldozers can build things no amount of workers with shovels can. [1] I'm using bulldozer as shorthand for all automated construct…

But then the 10 shovel-wielding humans are out of a job, right? The employer isn't just going to give everyone bulldozers. It'll be one guy with a bulldozer doing the work of ten men.

Or you become a bug hunter for 10 AI shovels who are now your senior.

Re: AI in software engineering at Google: Progress and the path ahead

#197

Post by ffsm8 »

vonmoltke wrote: post #185
ffsm8 wrote: post #148

Earlier quoted context omitted.

These kinds of similies make less and less sense nowadays because we've got nvme storage nowadays, and that can be as fast as 7GByte/s. That's a lot faster then the RAM in most devices today. And with less latency too. RAMs differentiating factor is increasingly just that it can handle a lot of read/write cycles, not it's speed. And that doesn't map to anything in biology

> These kinds of similies make less and less sense nowadays because we've got nvme storage nowadays, and that can be as fast as 7GByte/s. That's a lot faster then the RAM in most devices today. And with less latency too. 7 GB/s is the low end of the DDR3 performance range; DDR3 is 17 years old. Meanwhile, DDR5 performance ranges from about 33.5 GB/s to about 69 GB/s. RAM latency, even on DDR3, is measured in nanoseco…

By quantity, most devices are low-end and old androids. But I admit, I might have phrased my comment poorly. I didn't mean to imply that high end RAM has the same performance profile as high end NVMe storage

Re: AI in software engineering at Google: Progress and the path ahead

#198

Post by ghnws »

jillesvangurp wrote: post #142

LLMs are undeniably useful for programming. The core challenge in making them more useful is the right UX for making this more seamless. I use intellij and things like codegpt. A few weeks ago they enabled auto complete. I disabled it after a day. Reason: most of the suggestions weren't great and it drowned out the traditional auto complete, which I depend on. I just found the whole thing too distracting. I also have…

IntelliJ also has "full line completion" built in that uses a local model. I've found it rather good and it's the only in-IDE code generation I use. It does not get in the way and usually gives me exactly what I want.

https://www.jetbrains.com/help/idea/full-line-code-completio...

Re: AI in software engineering at Google: Progress and the path ahead

#199

Post by naijaboiler »

jprete wrote: post #6
trybackprop wrote: post #2

From the blog post: > We observe that with AI-based suggestions, the code author increasingly becomes a reviewer, and it is important to find a balance between the cost of review and added value. We typically address the tradeoff with acceptance rate targets. In the past year since GPT-4 came out, I've also found this to be the case. I'm an ML/backend engineer with little experience in frontend development. Yet, I've…

This isn't a good trend. Reviewers never have the depth of knowledge or understanding of authors.

Yup that’s an old reviewer/author problem. Reviewer has a huge blind spot because they don’t even know what they don’t know. The author knows what he knows but more importantly also has a bigger grasp on what he doesn’t know. So he understands what’s safe to do and what’s not

Re: AI in software engineering at Google: Progress and the path ahead

#200

Post by skydhash »

williamcotton wrote: post #147
ks2048 wrote: post #15

Earlier quoted context omitted.

Seems they need to compare against "dumb" code completion. It seems that even when they are error-free, "large" AI-code-completions are just boilerplate that should be abstracted away in some functions rather than inserted into your code base. On a related note, maybe they should measure number of code characters that can be REMOVED by AI rather than inserted!

boilerplate that should be abstracted away in some functions rather than inserted into your code base Boilerplate is often tedious to write and just as often easy to read. Abstraction puts more cognitive load on the developer and sometimes this is not worth the impact on legibility.

Code generators and snippets template are your friends.
Post reply on HN