Google CEO says more than a quarter of the company's new code is created by AI

I also work at google (until last Friday). Agree with what you said. My thoughts are

1. This quote is clearly meant to exaggerate reality, and they are likely including things like fully automated CL/PR's which have been around for a decade as "AI generated".

2. I stated before that if a team of 10 is equally as productive as a team of 8 utilizing things like copilot, it's fair to say "AI replaced 2 engineers", in my opinion. More importantly, Tech leaders would be making this claim if it were true. Copilot and it's clones have been around long enough know for the evidence to be in, and no one is stating "we've replaced X% of our workforce with AI" - therefor my claim is (by 'denying the consequent'), using copilot does not materially accelerate development.

I also work at Google and I agree with the general sentiment that AI completion is not doing engineering per se, simply because writing code is just a small part of engineering.

However in my experience the system is much more powerful than you described. Maybe this is because I'm mostly writing C++ for which there is a much bigger training corpus than JavaScript.

One thing the system is already pretty good at is writing entire short functions from a comment. The trick is not to write:

  function getAc...

But instead:

  // This function smargls the bleurgh
  // by flooming the trux.
  function getAc...

This way the completion goes much farther and the quality improves a lot. Essentially, use comments as the prompt to generate large chunks of code, instead of giving minimum context to the system, which limits it to single line completion.

So this is basically the google CEO saying "a quarter of our terminal inputs is written by a glorified tab completion"?

Do people find these AI auto complete things helpful? I was trying the XCode one and it kept suggesting API calls that don't exist. I spent more time fixing its errors than I would have spent typing the correct API call.

This is my experience as well. LLMs are great to boost productivity, especially in the hands of senior engineers who have a deep understanding of what they're doing because they know what questions to ask, they know when it's safe to use AI-generated code and they know what issues to look for.

In the hands of a junior, AI can create a false sense of confidence and it acts as a technical debt and security flaw multiplier.

We should bring back the title "Software engineer" instead of "Software developer." Many people from other engineering professions look down on software engineers as "Not real engineers" but that's because they have the same perspective on coding as typical management types have. They think all code is equal, it's unavoidable spaghetti. They think software design and architecture doesn't matter.

The problems a software engineer faces when building a software system are the same kinds of problems that a mechanical or electrical engineer faces when building any engine or system. It's about weighing up trade-offs and making a large number of nuanced technical decisions to ultimately meet operational requirements in the most efficient, cost-effective way possible.

In my day to day, this still remains the main way I interact with AI coding tools.

I regularly describe it as "The best snippet tool I've ever used (because it plays horseshoes)".

I'm working on a CRM with a flexible data model, and ChatGPT has written most of the code. I don't use the IDE integrations because I find them too "low level" - I work with GPT more in a sort of "pair programming" session: I give it high level, focused tasks with bits of low level detail if necessary; I paste code back and forth; and I let it develop new features or do refactorings.

This workflow is not perfect but I am definitely building out all the core features way faster than if I wrote the code myself, and the code is in quite a good state. Quite often I do some bits of cleanup, refactorings, making sure typings are complete myself, then update ChatGPT with what the code now looks like.

I think what people miss is there are dozens of different ways to apply AI to your day-to-day as a software engineer. It also helps with thinking things through, architecture, describing best practices.

This is exactly how I’ve used copilot for over a year now. It’s really helpful! Especially with repetitive code. Certainly worth what my employer pays for it.

The general public has a very different idea of that though and I frequently meet people very surprised the entire profession hasn’t been automated yet based on headlines like this.

A few years ago we called that IntelliSense, right?

I remember many years ago as a Java developer, Netbeans could do such things as complete `psvm` to "public static void main() {...}", or if you had a field "private String name;" you could press some key combination and it would generate you the getter and setter, complete with javadoc which was mandatory at that place because apparently you need "Returns the name.\n @return The name." on a method called getName() in case you wondered what it was for.

That's what I thought. In recent weeks, most of the code I’ve written has been AI-generated. But it was mostly JSDoc comments, type checking (I'm writing JavaScript), abstracting code if I see that I'm repeating myself a little too often, etc.

All things that I would consider tedious housekeeping, but nothing that needs serious reasoning.

It's basically a glorified LSP.

Before I go and rip out and replace my development workflow, is it notably better than auto complete suggestions from CoC in neovim (with say, rust-analyzer)? I'm generally pretty impressed how quickly it gives me the right function call or whatever, or it's the one of the top few.

Does it make you 25% more productive?

This is a great anecdote. SOTA models will not provide “engineering” per se, but they will easily double productivity of a product manager that is exploring new product ideas or technologies. They are much more than intelligent auto-complete. I have done more with side projects in the last year than I did in the preceding decade.

I can totally see it.

It is actually a testament that, part of Google's code are ... kinda formulaic to some degree. Prior to the LLM take over, we already heard praise how Google's code search works wonder in helping its engineer writing code, LLM just brought that experience to next level.

Long before this current AI hype cycle, we’ve had excellent code completion in editors for decades. So I guess by that definition, we’ve all been writing AI assisted code for a very long time.

So more or less on par with continue.dev using a local starcoder2:3b model

I wondered if this the real context. i.e. They are just referring to code-completion as AI-generated code. But, the article seems like it is referring to more than that?

Sounds like the JetBrains new local AI autocomplete. If it's anything like that, it's honestly my ideal application of generative deep learning.

Stuff that works well with AI seems to correlate pretty well with high churn changes. I've had good luck using AI to port large numbers of features from version A to version B, or getting code with a a lot of dependencies under mocked unit tests.

It's easy to see that adding up quickly to represent large percentages of the codebase by line, but it's not feature development or solving hard problems.

I wonder how this works with IP rights in the USA. Like, is `function getAc` eligible for copyright protection, but `tionHandler()` isn't? After all, [1]

[1] https://www.reuters.com/legal/ai-generated-art-cannot-receiv...

Thank you for this comment. So the code written in this manner isn't really "created by AI"; AI is just a nice additional feature of an editor.

I wonder if the enormous hype around AI is a good or bad thing; it's obviously both but will the good win out the bad, or will the disappointment eventually be so overwhelming as to extinguish any enthusiasm.

How do you square this comment with the one right below it[1], which explicitly confirms the statement that Google is using GenAI via Gemini to write code? Lots of mixed signals coming from the Googlers here.

1: https://news.ycombinator.com/item?id=41992028

This is pretty much what I've found with Copilot as well. It's like a slightly smarter autocomplete in most cases. Copilot tends toward being a little eager sometimes, but it's easy enough to just ignore the suggestions when it starts going down a weird path.

This autocomplete seems about on par with github copilot. Do you also get options for prompting it on specific chunks of code and performing specific actions such as writing docs or editing existing code? All things that come standard with gh copilot now.

I'm confused, I've been doing similar tab completion for function names in eclipse since about 2003...

We have this at our company too. I guess it’s useful but doesn’t really have a whole lot of time.

Which editor is Google's AI code completion integrated with? VS Code?

also useful for writing unit tests, comments, descriptions, so if you count all of that as code, together with boilerplate stuff, then yeah, it could add up to 25%.

> If I'm writing "function getAc..." it's smart enough to complete to "function getActionHandler()", and maybe suggest the correct arguments and a decent jsdoc comment.

I really mean no offense, but your example doesn't sound much different from what old IDEs (say, Netbeans) used to do 15 years ago.

I could design a Swing ui and it would generate the code and if I wanted to override a method it would generate a decent boilerplate boilerplate (a getter, like in your example) along with usual comments and definitely correct parameters list (with correct types).

Is this "AI Code" thing something that appears new because at some point we abandoned IDEs with very strong intellisense (etc) ?

"Our overhyped Autocomplete Implementation (A.I.) is completing 25% of our lines of code so well that we need to fund nuclear reactors to power the server farms."

My first reaction to the title was, "That explains why things are broken." but this explanation makes so much sense. Thanks for clarifying.

But yeah, I wish the new version of Chrome worked better. ¯\_(ツ)_/¯

Kerry said hi

I'm continually surprised by the amount of negativity that accompanies these sort of statements. The direction of travel is very clear - LLM based systems will be writing more and more code at all companies.

I don't think this is a bad thing - if this can be accompanied by an increase in software quality, which is possible. Right now its very hit and miss and everyone has examples of LLMs producing buggy or ridiculous code. But once the tooling improves to:

1. align produced code better to existing patterns and architecture 2. fix the feedback loop - with TDD, other LLM agents reviewing code, feeding in compile errors, letting other LLM agents interact with the produced code, etc.

Then we will definitely start seeing more and more code produced by LLMs. Don't look at the state of the art not, look at the direction of travel.

To me the most interesting part of this is the claim that you can accurately and meaningfully measure software engineering productivity.

Is AI ready to crawl through all open source and find / fix all the potential security bugs or all bugs for that matter? If so will that become a commercial service or a free service?

Will AI be able to detect bugs and back doors that require multiple pieces of code working together rather than being in a single piece of code? Humans have a hard time with this.

- Hypothetical Example: Authentication bugs in sshd that requires a flaw in systemd which then requires a flaw in udev or nss or PAM or some underlying library ... but looking at each individual library or daemon there are no bugs that a professional penetration testing organization such as the NCC group or Google's Project Zero would find. In other words, will AI soon be able to find more complex bugs in a year than Tavis has found in his career and will they start to compete with one another and start finding all the state sponsored complex bugs and then ultimately be able to create a map that suggests a common set of developers that may need to be notified? Will there be a table that logs where AI found things that professional human penetration testers could not?

You mention safety as #1, but my impression is that Google has taken a uniquely primitive approach to safety with many of their models. Instead of influencing the weights of the core model, they check core model outputs with a tiny and much less competent “safety model”. This approach leads to things like a text-to-image model that refuses to output images when a user asks to generate “a picture of a child playing hopscotch in front of their school, shot with a Sony A1 at 200 mm, f2.8”. Gemini has similar issue: it will stop mid-sentence, erase its entire response and then claim that something is likely offensive and it can’t continue.

The whole paradigm should change. If you are indeed responsible for developer tools, I would hope that you’re activity leveraging Claude 3.5 Sonnet and o1-preview.

As someone working in cybersecurity and actively researching vulnerability scanning in codebases (including with LLMs), I’m struggling to understand what you mean by “safe.” If you’re referring to detecting security vulnerabilities, then you’re either working on a confidential project with unpublished methods, or your approach is likely on par with the current state of the art, which primarily addresses basic vulnerabilities.

How are you measuring productivity? And is the effect you see in A/B tests statistically significant? Both of these were challenging to do at Meta, even with many thousands of engineers —- curious what worked for you.

Was this comment cleared by comms

Is any of the AI generated code being committed to Google's open source repos, or is it only being used for private/internal stuff?

I’ve been thinking a lot lately about how an LLM trained in really high quality code would perform.

I’m far from impressed with the output of GPT/Claude, all they’ve done is weight against stack overflow - which is still low quality code relative to Google.

What is probability Google makes this a real product, or is it too likely to autocomplete trade secrets?

Seems like everything is working out without any issues. Shouldn't you be a bit suspicious?

I assume the amount of monitoring effort is less than the amount of effort that would be required to replicate the AI generated code by humans, but do you have numbers on what that ROI looks like? Is it more like 10% or 200%?

Would you say that the efficiency gain is less than, equal to, or greater than the cost?

It's always felt like having AI in the cloud for better autocomplete is a lot for a small gain.

> We work very closely with Google DeepMind to adapt Gemini models for Google-scale coding and other Software Engineering usecases.

Considering how terrible and frequently broken the code that the public facing Gemini produces, I'll have to be honest that that kind of scares me.

Gemini frequently fails at some fairly basic stuff, even in popular languages where it would have had a lot of source material to work from; where other public models (even free ones) sail through.

To give a fun, fairly recent example, here's a prime factorisation algorithm it produce for python:

  # Find the prime factorization of n
  prime_factors = []
  while n > 1:
    p = 2
    while n % p == 0:
      prime_factors.append(p)
      n //= p
    p += 1
  prime_factors.append(n)

Can you spot all the problems?

In Java, 25% of the code is import statements and curly braces

Another 60% is auto-generated protobuf/grpc code. Maybe protoc counts as "AI".

Go is a very small fraction of the code at Google.

It might not quite be there yet, but one key advantage large codebases have that I think LLMs in time will be able to better exploit is the detection of existing patterns - presuming they're consistent - and application to new code doing similar things or to fix bugs in existing code that deviates from the pattern in some way that causes a bug.

It's a different thing to what you're talking about, but it's one way I'd expect to see LLMs contribute a lot to productivity on larger codebases specifically.

At the end of the day an LLM is just a compiler anyway. The developer isn't going away even if 100% of the code is generated by LLMs, just as the developer didn't go away when we stopped spending our days flipping toggle switches.

> that realistically could easily replace any entry-level or junior developer.

This is a massive, unsubstantiated leap.

> Google codebase is arguably one of the most curated, and iterated on datasets in existence

I spent 12 years of my career in the Google codebase.

This assertion is technically correct in that google3 has been around for 20 years, and all code gets reviewed, but the implication that Google's codebase is a high-quality training set is not consistent with my experience.

Philosophically, these models are akin to scholars prior to differentiation during their course of study. Throttling data, depending on one's course of study, and this shifting of the period in history step-by-step. Either it's a tit-for-tat manner of exchange that the junior developer is engaged in, when overseeing every edit that an LLM has modified, or I'd assume that there are in-built methods of garbage collection, that another LLM evaluating a hash function partly identifying a block of tokenized internal code would be responsible for.

Is the public gemini code gen LLM trained on their internal repo? I wonder if one could get it to cough up propriety code with the right prompt.

It probably does. But an amazing number of commenters think they are prompting the copy & pasting, and hoping for the best.

> The other 75% is the stuff you actually have to think about.

I’m pretty sure the actual ratio is much lower than that. In other words, LLMs are currently not good enough to remove the majority of chores, even with the state of the art model trained on highly curated dataset.

I think it just shows how much noise there is in coding. Code gets reviewed anyways (although review quality was going down rapidly the more PMs where added to the team)

Most of the code must be what could be snippets (opening files and handling errors with absl::, and moving data from proto to proto). One thing that doesn't help here, is that when writing for many engineers on different teams to read, spelling out simple code instead of depending on too many abstractions seems to be preferred by most teams.

I guess that LLMs do provide smarter snippets that I don't need to fill out in detail, and when it understands types and whether things compile it gets quite good and "smart" when it comes to write down boilerplate.

This may have been intended as a joke, but it's the only explanation that reconciles the quote for me.

The split is roughly 25% AI, 25% typed, 50% pasted.

You’re also the CEO so chances are the people looking at that ticket aren’t going to tell you the absolute mess the AI snippet actually is and how pointless it was to include it instead of a simple succinct sentence explaining the requirements.

If you’re not a developer chances are very high the code it produces will look passable but is actually worthless — or worse, it’s misleading and now a dev has to spend more time deciphering the task.

> Everyone knows this was “made by AI” because there’s no way in hell I would ever have the time.

Doubtful. A decent fraction of the people reading it will guess that you've wasted your time writing incoherent nonsense in the jira. Engineers don't usually have much insight into what the C suite are doing. It would be a prudent move to spend the couple of seconds to write "something like this AI sketch:" before the copy&paste.

> Everyone knows this was “made by AI” because ...

They should know because you told them so.

Having to decipher weird code only to discover it was not written by a human is not nice.

> dev lead suggested I write a JIRA. I’m the CEO, so this is not my usual thing (and probably should not be)

Fascinating point of view.

You just made it less attractive to the target corps who are to buy this product from Google. Saying, intellisense means corps already have license of various of these and some are even mostly free. Saying AI generate our 25% code sounds more attractive to corps, because it feels like something new and novel and you can imagine laying off 25% of the personnel and justify buying this product from Google.

When someone who uses a product says it, there is a 50% chance of it being true, but when someone far away from the user says it, it is 100% promotion of product and setup for trust building for a future sale.

Looks like it's an impressive autocomplete feature, yeah. Check out the video about halfway down here: https://research.google/blog/ai-in-software-engineering-at-g... (linked from other comment https://news.ycombinator.com/item?id=41992028 )

Not what I thought when I heard "AI coding", but seems pretty neat.

> I don't write code as I'm a sysadmin. Mostly just scripts.

.... so what do you put in your scripts if not code?

Devs who pride themselves on their capacity for rational thought seem to forget that regression to the mean applies everywhere...even to the places that they aspire to.

>a lot of garbage gets pumped into their codebases

I would imagine it always has.

>Google CEO says more than a quarter of the company's new code is created by AI

It may very well be starting to become apparent anyway :\

yeh, but the main problem is the quality. with algorithm bug can be fixed. with llm it's more complicated. in practice they do some mistakes consistently, and in some cases cannot recover even with assistance. (don't take me wrong, I'm very happy with the results most of the time)

But for this boiletplate creating a few snippets in your code generally works better. Especially if things change you dont have to retrain your model.

Thats my main problem: for trivial things it works but isnt much better than conventional tools, for hard things it just produces incorrect code such that writing it from scratch barely makes a difference

Were people seriously writing this boilerplate by hand up until this point? I started using snippets and stuff more than 15 years ago!

This actually sparked an idea for me. Could code complexity be measured as cumulative entropy as measured by running LLM token predictions on a codebase? Notably, verbose boilerplate would be pretty low entropy, and straightforward code should be decently low as well.

I agree. It seems like counting lines of generated code is like counting bytes/instructions of compiled code - who cares? If “code” becomes prompts, then AI should lead to much smaller code than before.

I’m aware that the difference is that AI-generated code can be read and modified by humans. But that quantity is bad because humans have to understand it to read or modify it.

Exactly this. Code is a liability, if you can do the same thing with less code you're often better off.

How would it know which edge cases are being useful and which ones aren't?

I understand more code as being more edge cases

meh - the LLM code I'm seeing isn't particularly more verbose. And as others have said, if you want tighter code, just add that to the prompt.

fun story: today I had an LLM write me a non-trivial perl one-liner. It tried to be verbose but I insisted and it gave me one tight line.

My guess is that they counted each line of code made by an engineer using AI coding tools.

Besides, even google employees write a lot of boilerplate, especially android IIRC, not to mention simple but essential code, so AI can prevent carpal tunnel for the junior devs working on that.

80% or more of the code you write day to day is just grunt work. Boring code that has, for the most part, already been written in some form such that it was copied from Google or StackOverflow. AI is basically a shortcut to using that stuff..

Yes, like the old story about why not to measure productivity by LoC generated.

https://www.folklore.org/Negative_2000_Lines_Of_Code.html

> Is Google out there monitoring the IDE activity of every engineer, logging the amount of code created, by what, lines, characters, and how it was generated

A good chunk () of their code goes in a centralized repo, and is written via a centralized web IDE. So measuring everything you mentioned is not hard.

() Android, Chrome, and other similar projects are exceptions.

Very good point. How was the 25% measured?

That would make sense and be a good use case, essentially doing what OpenAPI generators do (or Yeoman generators of yore), but less deterministic I’d imagine. So optimistically I would guess it covers ground that isn’t already solved by mainstream tools.

For the example of generating an http app scaffolding from an openapi spec, it would probably account for at least 25% of the text in the generated source code. But I imagine this report would conveniently exclude the creation of the original source yaml driving the generator — I can’t imagine you’d save much typing (or mental overhead) trying to prompt a chatbot to design your api spec correctly before the codegen

I'd say most CEO statements are quite useless already, as they're mostly corporate newspeak.

> Paste in my actual code.

> Prompt: Write unit tests

TDD in shambles. What you'd like is:

> Give your specs to some AI

> Get a test suite generated with all edge cases accounted for

> Code

Ollama, docker and "open webui".

It immediately works out of the box and that's it. I've been using local LLMs on my laptop for a while, it's pretty nice.

The only thing you really need to worry about is VRAM. Make sure your GPU has enough memory to run your model and that's pretty much it.

Also "open webui" is the worst project name I've ever seen.

I'm very happy to hear this; maybe it's finally time to buy a ton of ram for my PC! A local, private LLM would be great. I'd try talking to it about stuff I don't feel comfortable being on OpenAI's servers.

I didn't know anyone outside Google actually used that...

You just reinvented the compiler.

Because you can't trust what the LLM generates, so you have to read it. Of course the question then is whether you can trust your developer or not.

I think they spit out human-readable code, because they've been tried on human authors.

But you make an interesting point: eventually AI will be making for other AI's + machines, and human verification can be an after thought.

Different audiences.

You tell investors that AI is freaking magic and going to usher in an age of savings and productivity gains.

You tell your developers that it's a neat autocomplete, they should use carefully.

> I can remember how many fiercely argued 2 years ago that GenAI and Copilot are producing garbage. But here we are: These systems improve the workflow of creating / editing code enormously

This is the disconnect. I, along with others, haven't seen this yet. I'm begging to see it because I'd love to automate my work away, but I can't. This comment comes off as hand-wavy to me because it says "here we are" as if Google saying their AI works is evidence itself and not a statement that requires evidence.

I don’t fully understand the workflow were you hand boiler plate code off to a junior wouldn’t the communication overhead be higher than writing it yourself. Certainly llms have valid uses but I see improving junior productivity more than senior productivity

> This just goes to show how critical of an issue this is that these models are behind closed doors.

How is competitive advantage, using in-house developed/funded tools, a critical issue? Every company has tools that only they have, that they pay significantly for to develop, and use extensively. It's can often be the primary thing that really differentiates companies who are all doing similar things.

To be fair the paper that helped launch LLMs to a new level was from Google. “All You Need Is Attention”, Keras… They fell behind when it comes to marketing AI maybe…

My linux terminal tab-complete has written 50% of my code

I don't think it's a lie, but I do think it's very misleading. With common languages probably 25% of code can be generated by an AI, but IME it's mostly just boilerplate or some pattern that largely just saves typing time, not programming/thinking time. In other words it's the 25% lowest hanging fruit, so thinking like "1/4 of programming is now done by AI" is misleading. It's probably more like 5 to 10 percent.

This was one of my first thoughts, too. In what ways can this contaminate their codebase? What if they use AI to add uncopyrightable code to GPL projects?

what makes you think that current direction of AI development would lead to making less mistakes than humans do, as opposed to repeating same miskates plus hallucinating more?

These statements rely on an unchallenged monopoly position. This is not sustainable. These statements will hasten the collapse.

Seems just overhyped tech to push up stock prices. It was already claimed 2 years ago that half of the jobs would be taken by "AI" but barely any have and AI has barely improved since GPT3.5. Latest Anthropic is only slightly helpful for software development, mostly for unusual bug investigations and logs analysis, at least in my experience.

They still need someone to write 75% of the code.

yes: https://alphacode.deepmind.com/ edit: blog link https://deepmind.google/discover/blog/competitive-programmin...

"AI generated code" essentially means using Github Copilot or an alternative - these barely write a function without errors, nor are they even close to implementing a new feature autonomously.

I expect these tools to improve productivity for new-ish developers, however for anyone that is literate in a programming language the effect is marginal at best ("Copilot pause" etc.)

I'd suggest the bigger factor in those layoffs is the money was made in earlier covid years where money was flowing and everyone was overhiring to show off record growth, then none of those employees had any justification for being kept around and were just a money sink so they fired them all.

Not to mention Elon publicly demonstrated losing 80% of staff when he took over twitter and - you can complain about his management all you want - as someone who's been using it the whole way through, from a technical POV their downtimes and software quality has not been any worse and they're shipping features faster. A lot of software companies are overstaffed, especially Google who has spent years paying people to make projects just to get a PO promoted, then letting the projects rot and die to be replaced by something else. That's a lot of useless work being done.

> Can’t really deny that reality anymore folks.

You have to establish that the CEO is actually aware of the reality and is interested in accurately conveying that to you. As far as I can tell there is absolutely no reason to believe any part of this.

When leaders without the requisite technical knowledge are making decisions then the question of whether AI is capable of replacing human workers is orthogonal to the question of whether human workers will be replaced by AI.

Who claims that he is speaking the truth and not some marketing jargon?

Early Compilers. By a wide margin. They are the enabling factor for everything that comes below it. It's what allows you to share library interfaces and actually use them in a consistent manor and across multiple architectures. It entirely changed the shape of software development.

The gap between "high level assembly" and "compiled language" is about as large as it gets.

Yeah that might explain some of the loss of quality. Google apps and sites used to be solid, now they are full of not-breaking-but-annoying bugs like race conditions (don't press buttons too fast), display glitches, awful recommendations, and other usability problems.

Then again, their devices are also coming out with known fatal design flaws, like not being able to make phone calls, or the screen going black permanently.

You think when people say AI can only write trivial code that they are writing from the perspective of AI, where trivial is actually impressive? That's is backward ass logic.

> the kind you might as well copy&paste from stackoverflow

This bothers me. I completely understand the conversational aspect - "what approach might work for this?", "how could we reduce the crud in this function?" - it worked a lot for me last year when I tried learning C.

But the vast majority of AI use that I see is...not that. It's just glorified, very expensive search. We are willing to burn far, far more fuel than necessary because we've decided we can't be bothered with traditional search.

A lot of enterprise software is poorly cobbled together using stackoverflow gathered code as it is. It's part of the reason why MS Teams makes your laptop run so hot. We've decided that power-inefficient software is the best approach. Now we want to amplify that effect by burning more fuel to get the same answers, but from an LLM.

It's frustrating. It should be snowing where I am now, but it's not. Because we want to frivolously chase false convenience and burn gallons and gallons of fuel to do it. LLM usage is a part of that.

I don't get it either. People will say all sorts of strange stuff about how it writes the code for them or whatever, but even using the new Claude 3.5 Sonnet or whatever variant of GPT4, the moment I ask it anything that isn't the most basic done-to-death boilerplate, it generates stuff that's wrong, and often subtly wrong. If you're not at least pretty knowledgeable about exactly what it's generating, you'll be stuck trying to troubleshoot bad code, and if you are it's often about as quick to just write it yourself. It's especially bad if you get away from Python, and try to make it do anything else. SQL especially, for whatever reason, I've seen all of the major players generate either stuff that's just junk or will cause problems (things that your run of the mill DBA will catch).

Honestly, I think it will become a better Intellisense but not much more. I'm a little excited because there's going to be so many people buying into this, generating so much bad code/bad architecture/etc. that will inevitably need someone to fix after the hype dies down and the rug is pulled, that I think there will continue to be employment opportunities.

I'm not a Google employee but I've heard enough stories to know that a surprising amount of code changes at google are basically updating API interfaces.

The way google works, the person changing an interface is responsible for updating all dependent code. They create PRs which are then sent to code owners for approval. For lower-level dependencies, this can involve creating thousands of PRs across hundreds of projects.

Google has had tooling to help with these large-scale refactors for decades, generally taking the form of static analysis tools. However, these would be inherently limited in their capability. Manual PR authoring would still be required in many cases.

With this background, LLM code gen seems like a natural tool to augment Google's existing process.

I expect Google is currently executing a wave of newly-unblocked refactoring projects.

If anyone works/worked at google, feel free to correct me on this.

Most programming is trivial. Lots of non-trivial programming tasks can be broken down into pure, trivial sections. Then, the non-trivial part becomes knowing how the entire system fits together.

I've been using LLMs for about a month now. It's a nice productivity gain. You do have to read generated code and understand it. Another useful strategy is pasting a buggy function and ask for revisions.

I think most programmers who claim that LLMs aren't useful are reacting emotionally. They don't want LLMs to be useful because, in their eyes, that would lower the status of programming. This is a silly insecurity: ultimately programmers are useful because they can think formally better than most people. For the forseeable future, there's going to be massive demand for that, and people who can do it will be high status.

> Or do they have 25% trivial code?

We all have probably 25% or more trivial code. AI is great for that. I have X (table structure, model, data, etc) and I want to make Y with it. A lot of code is pretty much mindless shuffling data around.

The other thing is good for is anything pretty standard. If I'm using a new technology and I just want to get started with whatever is the best practice, it's going to do that.

If I ever have to do PowerShell (I hate PowerShell), I can get AI to generate pretty much whatever I want and then I'm smart enough to fix any issues. But I really don't like starting from nothing in a tech I hate.

> do they have 25% trivial code?

From what I've seen on Google Cloud, both as a user and from leaked source code, 25% of their code is probably just packing and unpacking of protobufs.

> isn't this announcement a terrible indictment

Of obviously flawed corporate structures. This CEO has no particular programming expertise and most of his companies profits do not seem to flow from this activity. I strongly doubt he has a grip on the actual facts here and is uncritically repeating what was told to him in a meeting.

He should, given his position, been the very _first_ person to ask the questions you've posed here.

An example:

I'm looking for a new job, so I've been grinding leetcode (oof). I'm an experienced engineer and have worked at multiple FAANGs, so I'm pretty good at leetcode.

Today I solved a leetcode problem 95% of the way to completion, but there was a subtle bug (maybe 10% of the test cases failing). I decided to see if Claude could help debug the code.

I put the problem and the code into Claude and asked it to debug. Over the course of the conversation, Claude managed to provide 5 or 6 totally plausible but also completely wrong "fixes". Luckily, I am experienced enough at leetcode, and leetcode problems are simple enough, that I could easily tell that Claude was mistaken. Note that I am also very experienced with prompt engineering, as I ran a startup that used prompt engineering very heavily. Maybe it's a skill issue (my company did fail, hence why I need a job), but somehow I doubt it.

Eventually, I found the bug on my own, without Claude's help. But leetcode are super simple, with known answers, and probably mostly in the training set! I can't imagine writing a big system and using an LLM heavily.

Similarly, the other day I was trying to learn about e-graphs (the data structure). I went to Claude for help. I noticed that the more I used Claude, the more confused I became. I found other sources, and as it turns out, Claude was subtly wrong about e-graphs, an uncommon but reasonably well-researched data structure! Once again, it's lucky I was able to recognize that something was up. If the problem wasn't limited in scope, I'd have been totally lost!

I use LLMs to help me code. I'm pro new technology. But when I see people bragging on Twitter about their fully automated coding solutions, or coding complex systems, or using LLMs for medical records or law or military or other highly critical domains, I seriously question their wisdom and experience.

At what point are people going to stop shitting on the code that Copilot or other LLM tools generate?

> how trivial the problems they solve are

A single line of code IS trivial. Simple code is good code. If I write the first 3 lines of a complex method and I let Copilot complete the 4th, that's 25% of my code written by an LLM.

These tools have exploded in popularity for good reason. If they were no good, people wouldn't be using them.

I can only assume people making such comments don't actually code on a daily basis and use these tools daily. Either that or you haven't figured out the knack of how to make it work properly for you.

I'll just answer here, but this isn't about this post in particular. It's about all of them. I've been struggling with a team of junior devs for the past months. How would I describe the experience? It's easy: just take any of these posts, replace "AI" with "junior dev", done.

Except of course AI at least can do spelling. (Or at least I haven't encountered a problem in that regard.)

I'm highly skeptical regarding LLM-assisted development. But I must admit: it works. If paired with an experienced senior developer. IMHO it must not be used otherwise.

> To my experience, AIs can generate perfectly good code relatively easy things, the kind you might as well copy&paste from stackoverflow, and they'll very confidently generate subtly wrong code for anything that's non-trivial for an experienced programmer to write. How do people deal with this?

Well, just in the last 24 hours, ChatGPT gave me solutions to some relatively complex problems that turned out to be significantly wrong.

Did that mean it was a complete waste of my time? I’m not sure. Its broken code gave me a starting point for tinkering and exploring and trying to understand why it wasn’t working (even if superficially it looked like it should). I’m not convinced I lost anything by trying its suggestions. And I learned some things in the process (e.g. asyncio doesn’t play well together with Flask-Sock)

> To my experience, AIs can generate perfectly good code relatively easy things, the kind you might as well copy&paste from stackoverflow,

This, imho, is what is happening. In the olden days, when StackOverflow + Google used to magically find the exact problem from the exact domain you needed every time - even then you'd often need to sift through the answers (top voted one was increasingly not what you needed) to find what you needed, then modify it further to precisely fit whatever you were doing. This worked fine for me for a long time until search rendered itself worthless and the overall answer quality of StackOverflow has gone down (imo). So, we are here, essentially doing the exact same thing in a much more expensive way, as you said.

Regarding future employment opportunities - this rot is already happening and hires are coming from it, at least from what I'm seeing in my own domain.

I'd be terribly scared to use it in a language that isn't statically typed with many, many compile time error checks.

Unless you're the type of programmer that is writing sabots all day (connecting round pegs into square holes between two data sources) you've got to be very critical of what these things are spitting out.

I decided to go into programming instead of becoming an Engineer because most Engineering jobs seemed systematic and boring. (Software Engineers weren't really a thing at the time.)

For most of my career, Software Engineering was a misnomer. The field was too young, and the tools used changed too quickly, for an appreciable amount of the work to be systematic and boring enough to consider it an Engineering discipline.

I think we're now at the point where Software Engineering is... actually Engineering. Particularly in the case of large established companies that take software seriously, like Google (as opposed to e.g. a bank).

Call it "trivial" and "boring" all you want, but at some point a road is just a road, and a train track is just a train track, and if it's not "trivial and boring" then you've probably fucked up pretty badly.