Live data from Hacker News

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

research.google

211–220 of 245 posts

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

#211

Earlier quoted context omitted.

I’ll add to their anecdote, with my own. I don’t think I’ve ever learned anything from SO. It is books and occasional videos for me too.

Maybe I am being snarky, but saying “I don’t like that” or “that’s not how I did it” just isn’t that interesting. I’d love to hear why books are so much effective, for instance, or which books, or what YT channels were useful.

> why books are so much effective

Because they’re consistent and they follow (the good ones) a clear path to learn what you want to learn. The explanations may not be obvious at first glance and that’s when you may need somone to present to you in another perspective (your teacher) or provide the required foundational knowledge that you may lack. You pair it with some practice or do cross-reference with other books and you can get very far. Also they’re can be pretty dense in terms of information.

> which books, or what YT channels were useful.

I mostly read manuals nowadays, instead of tutorials. But I remember starting with the “Site du Zero” books (a French platform) for C and Python. As tech is moving rapidly, for tutorial like books, it’s important to get the latest one and know which software versions it’s referring to.

Now I keep books like “Programming Clojure”, “The GO Programming Language”, “Write Great Code” series, “Mastering Emacs”, “The TCP/IP Guide”, “Absolute FreeBSD”, “Using SQlite”, etc. They’re mostly for references purposes and deep dive in one subject.

The videos I’m talking about were Courses from Coursera and MIT. Algorithms, Android Programming, Theory of Computation. There are great videos on Youtube, but they’re hidden under all the worthless one.

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

#212

Humans have limited RAM, so we have to put our ideas into an external medium that can then be refined. I've been finding AI's suggestions -- even when rather wrong -- help me do that initial step faster. Which, I think, jives with their findings here.

> I've been finding AI's suggestions -- even when rather wrong -- help me do that initial step faster. Which, I think, jives with their findings here. What's your process? Can you give an example? So far for me, I found them to be most useful using LLMs as code copilot.

For example, I asked it for a database schema given some parameters. What it gave me wasn't quite what I wanted, but seeing it written out helped me realize some flaws in the original design I had in mind. It wasn't that what it gave me was better. The act of evaluating its suggestions helped me clarify my own ideas.

It's sort of like Cunningham's Law with a party of one. Giving me the wrong answer helps me clarify what the correct answer should look like.

Or, perhaps a better way to put it:

It's easier to criticize than to create. It gives me something to criticize and tinker with. Doing so helps me hone in on the solution I want. (Provided its suggestion was at least in the right universe, of course.)

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

#213

Earlier quoted context omitted.

You don't receive AI suggestions in code review, you receive suggestions from your reviewers. If they are providing bad recommendations, regardless of the source, I suggest providing them feedback. I agree this may not be how they are used, but honestly, code review is a skill and many people are bad at it. Blindly suggesting things because an AI (or a presubmit) suggests it is bad form regardless of the source. Peop…

> 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 be absurdly happier elsewhere.

Life's short, and no matter how much you save, something can take it away.

Better to start pursuing it now, than after being the sacrificial MI, or after the call from HR asking you to chill because a VP got upset and had lackeys reverse engineer your identity.

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

#214

Earlier quoted context omitted.

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 b…

While I agree with some of your points about corporate data practices and the potential for technology to deskill labor, I'm not sure I see the direct connection with Clippy. Clippy, as limited as it was, seems like a poor example of these larger concerns.

Furthermore, saying "techies really lose perspective" comes across as dismissive and judgmental. It's important to remember that people are drawn to technology for various reasons, and many are deeply concerned about the ethical implications of what they build. Painting an entire group as lacking awareness isn't helpful or accurate.

If we want to have a productive conversation about the impact of technology, we need to avoid generalizations and engage with each other respectfully, even when we disagree.

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

#215

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…

>LLMs are undeniably useful for programming.

I don't know. There's an idealized vision that people have in their heads of what LLMs should be in which they're "undeniably useful". It's unclear if that already exists and is just constrained by the right UX concept, or if it doesn't exist and never will.

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

#216
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.

Why would it mean that? Couldn't it just mean google is more productive?

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

#217

Earlier quoted context omitted.

> I've been finding AI's suggestions -- even when rather wrong -- help me do that initial step faster. I have no idea how I could even integrate AI into my workflow so that it's useful. It's even less reliable than search is for basic research and can't even cite its sources.... This argument held a lot more weight when it was a search engine playing the role of our memory.

That comment was solely about AI code suggestions. Generative AI still has a ways to go for other forms of research, and it will never fully replace the utility of a search engine. They're two different tools for different but overlapping tasks.

> That comment was solely about AI code suggestions.

Even AI code suggestions seem to be only a minor improvement over basic LSP integration. One major exception is tedious formatting of the text—say you want to copy over a table by hand to a domain value, copilot is really good at recognizing values and situating them appropriately in the parent l-value.

If chatbots could serve as my RAM, surely they'd be able to generate code relevant to the rest of the codebase or at the very least not require deep scrutiny to ensure their RAM matches mine (it most often does not).

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

#218

Earlier quoted context omitted.

Frankly, its fine more often than we may care to admit. As the parent comment suggested, UI elements are a great candidate for this. Often very similar (how many apps have a menu bar, side bar, etc) and full of boilerplate. And at the rate things change on the front-end, it's often a candidate for frequent re-writes, so code quality and health don't need to be as strict. It'd be nice if every piece of software ever w…

UI is a terrible example to make your point. Tell me you don’t know frontend development… Accessibility, cross browser+platform support, design systems, SEO, consistency and polish, you name it. You are most certainly not getting that from an LLM and most engineers don’t know how or don’t have a good eye for it to catch when the agent has gone astray or suggested a common mistake

You definitely have a point, but the reality is that LLMs are about as good as an "average" UI developers in some cases -- lots of people who work on UI every day think very little about accessibility and don't understand if their code actually runs in a non-chromium browser.

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

#219

Earlier quoted context omitted.

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.

Say I'm faced with a choice right now -- repeat the same line twice with 2 minor differences which gets checked by IDE immediately, or create a code generator that generates all 3 lines which may not work well with the IDE and the build system which leads to more mistakes?

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

#220

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.

Well, someone (a human being) still maintains it, and ultimately someone likely will find the code unmaintainable even if LLMs help. If you use ChatGPT enough you would know it has its standards as well, actually pretty high. At one point the code likely still needs to be refactored, by human or not.
Post reply on HN