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

Re:AI in software engineering at Google: Progress and the pa... by vitus on Friday June 07, 2024 @10:30AM (#40609109)

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.

[ Parent | on HN ]

Re:AI in software engineering at Google: Progress and the pa... by danpalmer on Monday June 10, 2024 @09:03AM (#40633156)

I see your point, and maybe you're right, but I do think formatting tools are materially different. You can define correctness for a formatting tool and they're understood to be about enforcing a consistent style. That doesn't apply to code more generally where there's more open to interpretation, other "style" to consider, program behaviour, etc.

Also I would say that automatic formatters weren't popular until the mid 2010s from what I've experienced, despite being technically possible since pretty much the advent of programming. I even remember having to push hard for adoption of them in ~2018. Even if the AI tools were at the level (and they're definitely not yet, any of them), it could easily take a decade for it to become the norm or for it to be mandated.

[ Parent | on HN ]