Live data from Hacker News

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

research.google

181–190 of 245 posts

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

#181

Earlier quoted context omitted.

> So how can AI usefully suggest design-level and conceptual ideas in a way that doesn’t require a user “trigger”? Within the IDE, I’m not sure. https://upload.wikimedia.org/wikipedia/en/d/db/Clippy-letter...

Clippy was on the right path at the wrong time, the issue wasn't the concept of an assistant that watches your work and provides help, the issue was it could detect a letter, offer help but the help it gave you was just a bunch of shallow formatting suggestions without context to the actual work. An actual assistant that can preempt what you need and create it before you get there with a 95% success rate will not fee…

Clippy from MSFT? this is where the techies really lose perspective.. you see, its not just a computer, a computer company, and a user.. Real life includes social systems with social contract, and the relationship of the user's logs, records and autonomy to the "master" of the economic relationship. Microsoft has made it clear that surveilling the user and restricting autonomy is as valuable or more valuable from a business perspective than the actual actions performed, AND at the same time, entire industry product lines are designed to trivialize and factor out personal skill and make job performance more like replaceable piece-work.

Lastly, people are more or less aware of these other dynamics at work. Yet, people are people and respond to other social cues. The sheer popularity of something being novel, cute or especially "cool" does move the needle about adoption and implementation. Clippy was a direct marketing response to Apple getting "cool" ratings with innovative GUI elements.

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

#182
post #165

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, and not use backticks for the function names (doesn't work with kotlin-js). Every time. Have you experimented with GPTs much? I'd solve this problem by creating my own private "write a unit test" GPT that has my preferences configured in the system prompt.

you can fit a lot in 1 system prompt. i would instead put it all in the main system prompt, at least until openai comes up with a better ux

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

#183

Earlier quoted context omitted.

I work at Google, this stuff is available, entirely optional, and in fact the most recent stuff is still something you have to sign up for and get on an opt-in basis in return for providing feedback/answering surveys.

+1 for this. Stuff is completely optional.

+1 like in google+? :D

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

#184
post #47

Today on Facebook I saw a headline: "Marvel Fans Want to See Miley Cyrus as Rogue in the MCU". And I thought to myself: Which Marvel fans? And now... > Just five years later, in 2024, there is widespread enthusiasm among software engineers about how AI is helping write code. Which software engineers?

[deleted]

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

#185
post #148
post #39

Earlier quoted context omitted.

"Humans have limited RAM" I would suggest we have flexible RAM. Also, we have an awful lot of it. The analogy breaks down as soon as you look at it too seriously! In IT we largely deal with compute, persistent storage and non-persistent storage. Roughly speaking: CPU, RAM, HDD. In humans we might be considered to have similar "abilities" but unlike IT there is a mostly a single thing that performs all of those functi…

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 nanoseconds; NVMe latency is measured in microseconds, making it about three orders of magnitude higher.

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

#186

Earlier quoted context omitted.

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.

So how long till AI will be fully replacing a SWE at Google? Notice parent said "fully"

The question posed makes no sense.

Either it's 1 Software developer full-time equivalent (already happened) or all SWEs (never going to happen.)

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

#187
post #45

Earlier quoted context omitted.

> entirely optional Optional. I'll bet.

What would it mean for code suggestions to be non-optional? Like, you can't edit the code file yourself but have to talk to a chatbot to ask it to make the edits for you? I think that's fairly obviously a ridiculous notion.

I could envision some point in the future where the tooling is good enough that if you reject the suggestion, you had better have a very good reason for doing so. We're already there on the formatting front, as well as the widely-enabled clang-tidy checks (e.g. pessimizing moves). Once a tool consistently meets that high bar, it's irrelevant whether its suggestions are derived from static analysis or a LLM.

As far as being non-optional: a code owner could very much refuse to approve your change until it conforms to their standards for their code base.

ML code suggestions at Google do not inspire that high level of confidence in me today, but I have no reason for thinking that will always be the case.

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

#189
post #69
post #62

Earlier quoted context omitted.

Not to be rude but I have a hard time relating. Code is its own meaning, and to read it is to understand it. The only way you can use code you don't "understand" is to lack understanding of the language you are using.

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 .at() is for. I totally agree that the C++ standard library is full of weird unintuitive behavior, and it's hard to know which methods will throw exceptions vs have side effects vs result in undefined behavior without reading documentation, but map::operator[] is fairly tame.

Meanwhile, operator[] to access an element of a vector will result in a buffer overflow if not appropriately bounds-checked.

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

#190

Earlier quoted context omitted.

Also, people shouldn't be allowed to use computers unless they understand how transistors work. If you don't have the depth of knowledge you get nothing.

Although this is well-expressed, I'm left with an unexplainable feeling that I can't quite put my finger on.

Let me try and articulate it.

The person Im responding to was gatekeeping. I responded by sarcastically doing the same to an extreme degree. A lot of people Will have agreed with the person i'm responding to. "Oh yeah of course You should understand these things, the things that I already understand", genuinely not realizing that there's no basis for that. When they reae my response they realize what they were doing, and are less feeling embarrassed for their senseless (and pretentious!) gatekeeping.

Post reply on HN