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

221–230 of 245 posts

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

#221

Post by pquki4 »

refulgentis wrote: post #213
endisneigh wrote: post #154

Earlier quoted context omitted.

> You don't receive AI suggestions in code review, you receive suggestions from your reviewers If a reviewer makes a comment, Critique will create an AI suggestion based on their comment, even if they didn’t explicitly do so (unless they turn off giving AI suggestions on their end, but there’s no way to stop from seeing it from the other). > not by ruling out AI tools just because they're AI tools. This was not my po…

Word of advice from someone who left: if you've reached the point you're trashing work for a root-level OKR that is considered existential, taking an absolutist exaggerated stance against it, and discussing fine-grained details of internal tools, while claiming they go against PR/"research papers"...you're well past the right time to leave. We all have unique circumstances, but I can almost guarantee you that you'll…

> you are well past the right time to leave

Well, that's easy for you to say. People have family to feed, right?

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

#222

Post by bufferoverflow »

knallfrosch wrote: post #105
suyash wrote: post #94

So how long till AI will be fully replacing a SWE at Google? That is where the drive for productivity at organizations like Google are leading towards.

Assuming Google has tens of thousands of software engineers (for a lower bound of 10,000) and artificial intelligence increases productivity by at least 0.01%, the first engineer has already been replaced.

Or not, and they want more productivity.

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

#223

Post by the_doctah »

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…

>Instead I have to specify that I want it to generate a unit test, use kotlin-test and kotest-assertions

Am I missing something? I tell GPT to remember my preferences and it does.

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

#224

Post by the_doctah »

piloto_ciego wrote: post #202
dennis_moore wrote: post #128

Earlier quoted context omitted.

It works until it doesn't at which point you have a massive, useless pile of uninterpretable garbage.

Then you ask another LLM to explain it to you lol, like - I don’t think people are thinking hard enough about what this future is likely to look like.

Crazy that people say shit like this without seeing a problem with it.

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

#225

Post by piloto_ciego »

the_doctah wrote: post #224
piloto_ciego wrote: post #202

Earlier quoted context omitted.

Then you ask another LLM to explain it to you lol, like - I don’t think people are thinking hard enough about what this future is likely to look like.

Crazy that people say shit like this without seeing a problem with it.

It’s really not a problem at a certain point. Also, we’ll probably have “remove and replace” but for software in the next couple years with this stuff.

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

#226

Post by dilawar »

vitus wrote: post #189
dilawar wrote: post #69

Earlier quoted context omitted.

I never found my experience that simple. Even at times when I was paying attention which is always in short supply when you need it most. Libraries are biggest pain point. You don't know what a function really doing unless you have used it before yourself. Docs are not always helpful even when you read them. Lot of assumptions that may not be totally wrong but not right also. In c++, using [] on a map to access an el…

> using [] on a map to access an element is really really dangerous if you haven't read the docs carefully and assumes that it does what you believe it should do It's not that bad, as it just inserts a default-constructed element if it's not present. What would you expect it to do, such that it returns a reference of the appropriate type (such that you can write `map[key] = value;`)? Throw an exception? That's what .…

Something akin to `std::optional` would have been great. These days, folks don't come to C++ from C and are not used to such under-the-hood tricks.

The committee decided that since the reference can't be null, therefore, we'll insert something into the map when someone "query" for a key. Perhaps two mistakes can make a right!! It is hard to make peace with it when you are used to a better alternative.

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

#227

Post by refulgentis »

pquki4 wrote: post #221
refulgentis wrote: post #213

Earlier quoted context omitted.

Word of advice from someone who left: if you've reached the point you're trashing work for a root-level OKR that is considered existential, taking an absolutist exaggerated stance against it, and discussing fine-grained details of internal tools, while claiming they go against PR/"research papers"...you're well past the right time to leave. We all have unique circumstances, but I can almost guarantee you that you'll…

> you are well past the right time to leave Well, that's easy for you to say. People have family to feed, right?

> We all have unique circumstances, but I can almost guarantee you that you'll be absurdly happier elsewhere.

Thanks for your insightful contribution - I read the post again and found this right after what you found, like, right after. I hope this helps clarify

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

#228

Post by motoxpro »

stuckinhell wrote: post #176
kgilpin wrote: post #74

When AI is used properly, it’s doing one of two things: 1) Making non-controversial fixes that save time and take cognitive load off the developer. The best example is when code completion is working well. 2) It’s making you smarter and more knowledgeable by virtue of the suggestions it makes. You may discard them but you still learn something new, and having an assistant brainstorm for you enables a different mode o…

"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.

Code is one of the only things LLMs ARE good at.

At this point, asking an LLM to "implement feature X please" is not going to give you great results. however, unless you can type at 600 wpm, an LLM doing extremely trivial boilerplate code completion is a godesend.

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

#229

Post by motoxpro »

diggan wrote: post #194
pixiemaster wrote: post #180

Earlier quoted context omitted.

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"

Id argue it's the opposite. If you have extremely deep knowledge you can constrain the problem and get a great answer. i.e. boilerplate for X. Boilerplate is only boilerplate because you have a certain level of knowledge.

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

#230

Post by fnordpiglet »

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.

Does everything ever written need to be crafted by an artisan? And awful lot of useful stuff written “good enough” is good enough. Depth of knowledge or understanding is irrelevant to a lot of front end UI development where the key is the design itself and that the behavior of the design is accurate and reliable not that the engineer -really- understand at a core of their soul graphql and react with the passion of a Japanese craftsman when they’re building a user interface for the ML backend that internal users use for non critical tasks. There does exist a hierarchy of when depth matters and it’s not homogeneously “literally everything you do.”
Post reply on HN