8 ms·

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 confid

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? I simply don't understand the value proposition. Does Google now have 25% subtly wrong code? Or do they have 25% trivial code? Or do all their engineers babysit the AI and bugfix the subtly wrong code? Or are all their engineers so junior that an AI is such a substantial help? Like, isn't this announcement a terrible indictment of how inexperienced their engineers are, or how trivial the problems they solve are, or both?

tmoravec 2y ago
Does the figure include unit tests?
airstrike 2y ago
By definition, "trivial" code should make up a significant portion of any code base, so perhaps the 25% is precisely the bit that is trivial and easily automated.
- Smaug123 2y ago
  I don't think the word "definition" means what you think it means!
hifromwork 2y ago
25% trivial code sounds like a reasonable guess.
- fzysingularity 2y ago
  This seems reasonable - but I'm interpreting this as most junior-level coding needs will end and be replaced with AI.
  - mrguyorama 2y ago
    And the non junior developers will then just magically appear from the aether!With 10 years experience in a four year old stack.
Nasrudith 2y ago
I wouldn't call it an indictment necessarily, because so much is dependent upon circumstances. They can't all be "deep problems" in the real world. Projects tend to have two components, "deep" work which is difficult and requires high skill and cannot be made up with by using masses of inexperienced and "shallow" work where being skilled doesn't really help, or doesn't help too much compared to throwing more bodies at the problem. To use an example it is like advanced accounting vs just counting up sales receipts. Even if their engineers were inexperienced that wouldn't be an indictment in itself so long as they had a sufficient necessary amount of shallow work. Using all experienced engineers to do shallow work is just inefficient, like having brain surgeons removing bunions. Automation is basically a way to transform deep work to a producer of "free" shallow work. That said, the real impressive thing with code isn't in its creation but in its ability to losslessly delete code and maintain or improve functionality.
andyjohnson0 2y ago
I suspect that a lot of the hard, google-scale stuff has already been done and packaged as an internal service or library - and just gets re-used. So the AIs are probably churning out new settings dialogs and the like.
jajko 2y ago
I can generate in eclipse pojo classes or their accessor methods. I can let maven build entire packages from say XSDs (I know I am talking old boring tech, just giving an example). I can copy&paste half the code (if not more) from stack overflow. Now replace all this and much more with 'AI'. If they said AI helped them increase say ad effectivity by 3-5%, I'll start paying attention.
akira2501 2y ago
> 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.
jjtheblunt 2y ago
Maybe the trick is to hide vetted correct code, of whatever origin, behind function calls for documented functions, thereby iteratively simplifying the work a later-trained LLM would need to do?
toasteros 2y ago
> 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.
- chongli 2y ago
  we've decided we can't be bothered with traditional search Traditional search (at least on the web) is dying. The entire edifice is drowning under a rapidly rising tide of spam and scam sites. No one, including Google, knows what to do about it so we're punting on the whole project and hoping AI will swoop in like deus ex machina and save the day.
  - romwell 2y ago
    Narrator: it did not, in fact, save the day.
  - petre 2y ago
    AI will generate even more spam and scam sites more trivially.
    - ses1984 2y ago
      What do you mean “will”, we are a few years past that point.
  - 2y ago
nwellinghoff 2y ago
They probably have ai that scans existing human written code and auto generates patches and fixes to improve performance or security. The 25% is just a top level stat with no real meaning without context.
groestl 2y ago
> 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.
- hughesjj 2y ago
  I'd bet at least 25% of code attributes to me in gitfarm at Amazon was generated by octane and/or bones. God I miss that, thanks for the other person on HN introducing me to projen. Yeoman wasnt cutting it. These days I write a surprising amount of shell script and awk with LLMs. I review and adapt it, of course, but for short snippets of low context scripting it's been a huge time saver. I'm talking like 3-4, up to 20 lines of POSIX shell. Idk. Some day I'll actually learn AWK, and while I've gotten decent with POSIX shell (and bash), it's definitely been more monkey see monkey do than me going over all the libraries and reference docs like I did for python and the cpp FAQ.
tobyjsullivan 2y ago
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.
- cj 2y ago
  Do they have tooling for generating scaffolding for various things (like unit/integration tests)? If we’re guessing what code is easiest and largest proportion of codebase to write, my first guess would be test suites. Lots of lines of repetitive code patterns that repeat and AI is decent at dealing with
skissane 2y ago
> 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)
- deleted 2y ago
  [deleted]
wvenable 2y ago
> 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.
- randomNumber7 2y ago
  Yes but then it would be more logical to say "AI makes our devs 25% more efficient". This is not what he said, but imo you are obviously right.
  - wvenable 2y ago
    Not necessarily. If 25% of the code is written by AI but that code isn't very interesting or difficult, it might not be making the devs 25% more efficient. It could even possibly be more but, either way, these are different metrics.
  - johannes1234321 2y ago
    The benefit doesn't translate 1:1. The generated code has to be read and verified and might require small adaptions. (Partially that can be done by AI as well) But for me it massively improved all the boilerplate generic work. A lot of those things which are just annoying work, but not interesting. Then I can focus on the bigger things, on the important parts.
- lambdasquirrel 2y ago
  I’ve already had one job interview where the applicant seemed broadly knowledgeable about everything we asked them during lead-in questions before actual debugging. Then when they had to actually dig deeper or demonstrate understanding while solving some problem, they fell short. I’m pretty sure they weren’t the first and there’ve been others we didn’t know about. So now I don’t ask lead-in questions anymore. Surprisingly, it doesn’t seem to make much of a difference and I don’t need to get burned again.
sangnoir 2y ago
> Does Google now have 25% subtly wrong code? How do you quantify "new code" - is it by lines of code or number of PRs/changesets generated? I can easily see it being the latter - if an AI workflow suggests 1 naming-change/cleanup commit to your PR made of 3 other human-authored commits, has it authored 25% of code? Arguably, yes - but it's trivial code that ought to be reviewed by humans. Dependabot is responsible for a good chunk of PRs already. Having a monorepo brings plenty of opportunities for automation when refactoring - whether its AI, AST manipulation or even good old grep. The trick is not to merge the code directly, but have humans in the loop to approve, or take-over and correct the code first.
rpcope1 2y ago
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.
- solumunus 2y ago
  Supermaven is an incredible intellisense. Most code IS trivial and I barely write trivial code anymore. My imports appear instantly, with high accuracy. I have lots of embedded SQL queries and it’s able to guess the structure of my database very accurately. As I’m writing a query the suggested joins are accurate probably 80% of the time. I’m significantly more productive and having to type much less. If this is as good as it ever gets I’m quite happy. I rarely use AI for non trivial code, but non trivial code is what I want to work on…
  - ta_1138 2y ago
    This is all about the tooling most companies choose when building software: Things with more than enough boilerplate most code is trivial. We can build tools that have far less triviality and more density, where the distance between the code we write and business logic is very narrow.. but then every line of code we write is hard, because it's meaningful, and that feels bad enough to many developers, so we end up with tools where we might not be more productive, but we might feel productive, even though most of that apparent productivity is trivially generated. We also have the ceremonial layers of certain forms of corporate architecture, where nothing actually happens, but the steps must exist to match the holy box, box cylinder architecture. Ceremonial input massaging here, ceremonial data transformation over there, duplicated error checking... if it's easy for the LLM to do, maybe we shouldn't be doing it everywhere in the first place.
skeeter2020 2y ago
trivial code could very easily include the vast majority of most apps we're building these days. Most of it's just glue, and AI can probably stitch together a bunch of API calls and some UI as well as a human. It could also be a lot of non-product code, tooling, one-time things, etc.
ithkuil 2y ago
Or perhaps that even for excellent engineers and complicated problems a quarter of the code one writes is stupid almost copy-pasteable boilerplate which is now an excellent target for the magic lArge text Interpolator
eco 2y ago
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.
- randomNumber7 2y ago
  It is way more scary to use it for C or C++ than Python imo.
- cybrox 2y ago
  If you use it as advanced IntelliSense/auto-complete, it's not any worse than with typed languages. If you just let it generate and run the code... yeah, probably, since you won't catch the issues at compile time.
- int_19h 2y ago
  I can't help but think that Go might be one of the better languages for AI to target - statically typed, verbose with a lot of repeated scaffolding, yet generally not that easy to shoot yourself in the foot. Which might explain why this is a thing at Google specifically.
Kiro 2y ago
You're doing circular reasoning based on your initial concern actually being a problem in practice. In my experience it's not, which makes all your other speculations inherently incorrect.
JohnMakin 2y ago
> 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.
notyourwork 2y ago
To your point, I don't buy the truth of the statement. I work in big tech and am convinced that 25% of the code being written is not coming from AI.
cybrox 2y ago
Depends if they include test code in this metric. I have found AI most valuable in generating test code. I usually want to keep tests as simple as possible, so I prefer some repetition over abstraction to make sure there's no issues with the test logic itself, AI makes this somewhat verbose process very easy and efficient.
slibhb 2y ago
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.
- gorjusborg 2y ago
  > Most programming is trivial That's a bold statement, and incorrect, in my opinion. At a junior level software development can be about churning out trivial code in a previously defined box. I don't think its fair to call that 'most programming'.
  - BobbyJo 2y ago
    Probably overloading of the term "programming" is the issue here. Most "software engineering" is non-programming work. Most programming is not actually typing code. Most of the time, when I am typing code, the code I am producing is trivial, however.
  - deleted 2y ago
    [deleted]
  - uh_uh 2y ago
    Think of all the menial stuff you must perform regardless of experience level. E.g. you change the return type of a function and now you have to unpack the results slightly differently. Traditional automated tools fail at this. But if you show some examples to Cursor, it quickly catches on to the pattern and start autocompleting semi-automatically (semi because you still have to put the cursor to the right place but then you can tab, tab, tab…).
aorloff 2y ago
Its been a while since I was really fully in the trenches, but not that long. How people deal with this is they start by writing the test case. Once they have that, debugging that 25% comes relatively easily and after that its basically packaging up the PR
afavour 2y ago
> Or do they have 25% trivial code? If anything that's probably an underestimate. Not to downplay the complexity in much of what Google does but I'm sure they also do an absolute ton of tedious, boring CRUD operations that an AI could write.
ants_everywhere 2y ago
Google's internal codebase is nicer and more structured than the average open source code base. Their internal AI tools are presumably trained on their code, and it wouldn't surprise me if the AI is capable of much more internally than public coding AIs are.
fsckboy 2y ago
> Does Google now have 25% subtly wrong code? maybe the ai generates 100% of the company's new code, and then by the time the programmers have fixed it, only 25% is left of the AI's ship of Theseus
vkou 2y ago
How would you react to a tech firm that in 2018, proudly announced that 25% of their code was generated by IntelliJ/Resharper/Visual Studio's codegen and autocomplete and refactoring tools?
grepLeigh 2y ago
I have a whole "chop wood, carry water" speech born from leading corporate software teams. A lot of work at a company of sufficient size boils down to keeping up with software entropy while also chipping away at some initiative that rolls up to an OKR. It can be such a demotivating experience for the type of smart, passionate people that FANNGs like to hire. There's even a buzzword for it: KTLO (keep the lights on). You don't want to be spending 100% of your time on KTLO work, but it's unrealistic to expect to do done of it. Most software engineers would gladly outsource this type of scutwork.
- girvo 2y ago
  > KTLO (keep the lights on) Some places also call this "RTB" for "run the business" type work. Nothing but respect for the engineers who enjoy that kind of approach, I work with several!
Cthulhu_ 2y ago
You're quick to jump to the assertion that AI only generates SO style utility code to do X, but it can also be used to generate boring mapping code (e.g. to/from SQL datasets). I heard one ex Google dev say that most of his job wat fiddling with Protobuf definitions and payloads.
bluerooibos 2y ago
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.
- ghosty141 2y ago
  I havent seen anybody use them and be more productive. With c++ my experience is that the results are completely worthless. It saves you from writing a few keywords but nothing that really helps in a big way. Yes Copilot CAN work, for example writing some JS or filter functions, but in my job these trivial snippets are rather uncommon. I‘d genuinely love to see some resources that show its usefulness that arent just PR bs.
  - bluerooibos 2y ago
    > I havent seen anybody use them and be more productive. What does that even mean? What are you expecting to see? I've seen people who can't code ship entire new applications which actually work, in a few days or so. That to me seems more productive? I use these tools daily in a FAANG level SWE role and they help me debug issues quickly - all the time, especially with tech I'm new to and have no experience with. I really don't understand the hate - it's like skipping stack overflow and giving you the ideal answer a lot faster. Nobody likes to shout that they're using these tools but most people are.
- thegrim33 2y ago
  These tools have exploded in popularity for good reason. If they were no good, people wouldn't be using them. You're saying anything that's ever been popular is popular for a good reason? You can't think of counter examples that disprove this? You're saying anything that people decide to do is good, or else people wouldn't do it? People never act irrationally? People never blindly act on trends? People never sacrifice long-term results for short-term gain? You can't come up with any counter examples?
ZiiS 2y ago
Yes 25% of code is trivial; certainly for companies like Google that have always been a bit NIH.
fuzzy2 2y ago
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.
- alfiedotwtf 2y ago
  > replace "AI" with "junior dev", done. Damn, that’s a good way of putting it. But I’ll go one further: replace "AI" with "junior dev who doesn’t like reading documentation or googling how things work so instead confidently types away while guessing the syntax and API so it kind of looks right”
  - hughesjj 2y ago
    I've been saying it's like an intern who has an incredible breadth of knowledge but very little depth, is excessively over confident in their own abilities given the error rates they commit, and is anxious to the point they'll straight up lie to you rather than admit a mistake. Currently, they don't learn skills as fast as a motivated intern. A stellar intern can go from no idea to "makes relevant contributions to our product with significant independence and low error rate" (hi Matt if you ever see this) in 3 months. LLMs, to my understanding, take significantly more attention from super smart people working long hours and an army of mechanical Turks, but won't be able to independently implement a feature and will still have a higher error rate in the same 3 months. It's still super impressive what LLMs can do, but that same intern is going to keep growing at that faster rate in skills and competency as they go from jr->mid->sr. Sure the intern won't have as large of a competency pool, and takes longer to respond to any given question, but the scope of what they can implement is so much greater.
- palata 2y ago
  Isn't the whole point of hiring a junior dev that they will learn and become senior devs eventually?
uoaei 2y ago
I've suspected for a while now that the people who find value in AI-generated code don't actually have hard problems to solve. I wonder how else they might justify their salary.
dmurray 2y ago
> Or do they have 25% trivial code? Surely yes. I (not at Google) rarely use the LLM for anything more than two lines at a time, but it writes/autocompletes 25% of my code no problem. I believe Google have character-level telemetry for measuring things like this, so they can easily count it in a way that can be called "writing 25% of the code". Having plenty of "trivial code" isn't an indictment of the organisation. Every codebase has parts that are straightforward.
dyauspitr 2y ago
This subtly wrong thing happens maybe 10% of the time in my experience and asking it to generate unit tests or writing your own ahead of time almost completely eliminates it.
name_nick_sex_m 2y ago
[flagged]
djvuvtgcuehb 2y ago
A better analogy is a self driving car where you need to keep your hands on the wheel in case something goes wrong. For the most part, it drives itself. Yes, the majority of my code is trivial. But I've also had ai iterate on some very non trivial work including writing the test suite. It's basically autocomplete on steroids that predicts your next change in the file, not just the next change on the line. The copy paste from stack overflow trope is a bit weird, I haven't done that in ten years and I don't think the code it produces is that low quality either. Copy paste from an open source repo on GitHub maybe?
aiforecastthway 2y ago
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.
- javaunsafe2019 2y ago
  Since when is engineering boring? Stranges ideas and claims u made. I’m an engineer who writes code since 20 years and it’s far away from trivial . Maybe to do web dev for a simple Webshop is. Elsewhere software has often times special requirements. Be them technical or domain wise both make the process complex and not simple IMHO
  - aiforecastthway 2y ago
    Boring is the opposite of exciting/dynamic. Not all engineering is boring. Also, boring is not bad. A lot of my career has been spent working to make software boring. To the extent that I've helped contribute to the status quo, where we can build certain types of software in a relatively secure fashion and on relatively predictable timelines, I am proud to have made the world more boring! (Also, complexity can be extraordinarily boring. Some of the most complex things are also the most boring. Nothing more boring than a set of business rules that has an irreducible complexity coming in at 5,211 lines of if-else blocks wrapped in two while loops! Give me a simple set of partial differential equations any day -- much more exciting to work with those! If you're the type of person who enjoys reading tax code, then we just have different definitions of boring; and if you're the type of person doesn't think tax code is complex, then I'm just a dummy compared to you :)) But e.g. in the early naughts doing structural engineering work for residential new build projects was certainly less engaging and exciting work than building websites. Most engineering works aims for repeatable and predictable outcomes. That's a good thing, and it's not easy to achieve! But if Software has reached the point where the process of building certain types of software is "repeatable and predictable", and if Google needs a lot of that type of software, then if the main criticism of AI code assistants is "it's only good for repeatable and predictable", well, then the criticism isn't exactly the indictment that skeptics think it is. There is nothing wrong with boring in the sense I'm using it. Boring can be tremendously intellectually demanding. Also, predictable and repeatable processes are incredibly important if you want quality work at scale. Engineering is a good thing. Maturing as a field is a good thing. But if we're maturing from "wild west everything is a greenfield project" to "70% of things are pretty systematic and repeatable" then that says something about the criticism of AI coding assistants as being only good for the systematic and repeatable stuff, right? Also: the AI coding assistant paradigm is coming for structural/mechanical/civil engineering next, and in a big way!
signa11 2y ago
``` Like, isn't this announcement a terrible indictment of how inexperienced their engineers are, or how trivial the problems they solve are, or both? ``` there is a 3rd possibility as well: having spent a huge chunk of change on these techniques, why not overhype it (not outright lie about it) and hope to, somewhat recoup the cost from unsuspecting masses ?
sally_glance 2y ago
I guess the obvious response would be - yes, they have _at least_ 25% trivial code (as any other enterprise), and yes, they should have lots of engineers 'babysitting' (aka generating training data). So in another year or two there will be no manpower at all needed for the trivial tasks.
asdfman123 2y ago
No, AI is generating a quarter of all characters. It's an autocomplete engine. You press tab, it finishes the line. Doesn't do any heavy lifting at all. Source: I work there, see my previous comment.
TacticalCoder 2y ago
> and they'll very confidently generate subtly wrong code for anything that's non-trivial for an experienced programmer to write Thankfully I don't find it subtle but plain wrong for anything but trivial stuff. I use it (and pay an AI subscription) for things where false positive won't ruin the day, like parameters validation. But for anything advanced, it's pretty hopeless. I've talked with lawyers: same thing. With doctors: same thing. Which ain't no surprise see how these things do work. > Like, isn't this announcement a terrible indictment of how inexperienced their engineers are, or how trivial the problems they solve are, or both? Probably lots of highly repetitive boilerplate stuff everywhere. Which in itself is quite horrifying if you think about it.
nimithryn 2y ago
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.
pjmorris 2y ago
> Like, isn't this announcement a terrible indictment of how inexperienced their engineers are, or how trivial the problems they solve are, or both? Or maybe there's a KPI around lines of code or commits.
manquer 2y ago
if their sales and stock depends on saying that new shinny thing is changing the world then they have to say so, and say how it is changing their world . It is not Netflix or Airbnb or Stripe etc making this claim, google managers have a vested interest in this. If this metric was meaningful either of two things should have happened - google should have fired 25 % developers or built 25 % more product . Both of this would visible in their financial reporting and has not happened. metrics like this claim depends on how you count, that is easily gamed and can be made to show any % between 0-99 you want. Of the top of head - I could count all AI generated code used for training as new code - consider compiler output to assembly as AI code by adding some meaningless AI step in it - code generated with boilerplate perhaps even generated by llm now - mix autocomplete with llm prompts so on The number only needs to believable , 25 is believable now, it is not true but you would believe it >50 has psychological significance and bad PR on machines replacing humans jobs , less than 10 is bad for AI sales , 25 works all the commenters in this thread is testament to that
llm_trw 2y ago
Or alternatively you don't know how to use AI to help you code and are in the 2020s equivalent of the 'Why do I need google when I have the yellow pages?' phase a lot of adults went through in the 2000s. This is not a bad thing since you can improve, but constantly dismissing something that a lot of people are finding an amazing productivity boost should give you some pause.
- johnnyanmac 2y ago
  It's like blockchain right now. I'm sure there is some killer feature that can justify its problem space. But as of now the field is full of swamps. Of grifters, of people with a solution looking for a problem. Of outright scams of questionable legality being challenged as we speak. I'll wait until the swamps work itself out before evaluating an LLM workflow.
  - llm_trw 2y ago
    Blockchain was always a solution looking for a problem. LLMs are being used right now by a lot of people, myself included, to do tasks which we would have never bothered with before. Again, if you don't know how to use them you can learn.
    - johnnyanmac 2y ago
      And the same was said with the last fad when Blockcbain was all investors wanted to hear about ("Big Data" I suppose). It's all a pattern. It's a legal nightmare in my domain as of now, so I'll make sure the Sam Breaker-Friends are weeded out. If it's really all the hype it won't be going anywhere in 5 years.
      - llm_trw 2y ago
        It's been 5 years since GPT2. I'm really struggling to understand the amount of negativity towards the biggest breakthrough in computing since the WWW.
deleted 2y ago
[deleted]
herval 2y ago
In my experience, that was always the case with gpt3.5, most times the case with gpt4, some times the case with the latest sonnet. It’s getting better FAST, and the kind of code they can handle is increasing fast too
rh2323o4jl234 2y ago
> Does Google now have 25% subtly wrong code? I think you underestimate the amount of boiler-plate code that a typical job at Google requires. I found it soul-crushingly boring (though their pay is insane).
geodel 2y ago
> Like, isn't this announcement a terrible indictment of how inexperienced their engineers are.. Well, Rob Pike said same thing about experience and that seemed to pissed lot of people endlessly. However I don't think it as indictment It just seems very reasonable to me. In fact 25% seem to be on lower end. Amazon seems to have thousands of software engineers who are doing API calling API calling API.. kind of crap. Now their annual income might be more than my lifetime earnings. But to think that all these highly paid engineers are doing highly complex work that need high skills seems just a myth that is useful to boost ego of engineers and their employers alike.
deleted 2y ago
[deleted]
toviahudson5 2y ago
[dead]

tmoravec 2y ago

Does the figure include unit tests?

airstrike 2y ago

By definition, "trivial" code should make up a significant portion of any code base, so perhaps the 25% is precisely the bit that is trivial and easily automated.

Smaug123 2y ago
I don't think the word "definition" means what you think it means!

hifromwork 2y ago

25% trivial code sounds like a reasonable guess.

fzysingularity 2y ago
This seems reasonable - but I'm interpreting this as most junior-level coding needs will end and be replaced with AI.
- mrguyorama 2y ago
  And the non junior developers will then just magically appear from the aether!With 10 years experience in a four year old stack.

Nasrudith 2y ago

I wouldn't call it an indictment necessarily, because so much is dependent upon circumstances. They can't all be "deep problems" in the real world. Projects tend to have two components, "deep" work which is difficult and requires high skill and cannot be made up with by using masses of inexperienced and "shallow" work where being skilled doesn't really help, or doesn't help too much compared to throwing more bodies at the problem. To use an example it is like advanced accounting vs just counting up sales receipts. Even if their engineers were inexperienced that wouldn't be an indictment in itself so long as they had a sufficient necessary amount of shallow work. Using all experienced engineers to do shallow work is just inefficient, like having brain surgeons removing bunions. Automation is basically a way to transform deep work to a producer of "free" shallow work. That said, the real impressive thing with code isn't in its creation but in its ability to losslessly delete code and maintain or improve functionality.

andyjohnson0 2y ago

I suspect that a lot of the hard, google-scale stuff has already been done and packaged as an internal service or library - and just gets re-used. So the AIs are probably churning out new settings dialogs and the like.

jajko 2y ago

I can generate in eclipse pojo classes or their accessor methods. I can let maven build entire packages from say XSDs (I know I am talking old boring tech, just giving an example). I can copy&paste half the code (if not more) from stack overflow. Now replace all this and much more with 'AI'. If they said AI helped them increase say ad effectivity by 3-5%, I'll start paying attention.

akira2501 2y ago

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

jjtheblunt 2y ago

Maybe the trick is to hide vetted correct code, of whatever origin, behind function calls for documented functions, thereby iteratively simplifying the work a later-trained LLM would need to do?

toasteros 2y ago

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

chongli 2y ago
we've decided we can't be bothered with traditional search Traditional search (at least on the web) is dying. The entire edifice is drowning under a rapidly rising tide of spam and scam sites. No one, including Google, knows what to do about it so we're punting on the whole project and hoping AI will swoop in like deus ex machina and save the day.
- romwell 2y ago
  Narrator: it did not, in fact, save the day.
- petre 2y ago
  AI will generate even more spam and scam sites more trivially.
  - ses1984 2y ago
    What do you mean “will”, we are a few years past that point.
- 2y ago

nwellinghoff 2y ago

They probably have ai that scans existing human written code and auto generates patches and fixes to improve performance or security. The 25% is just a top level stat with no real meaning without context.

groestl 2y ago

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

hughesjj 2y ago
I'd bet at least 25% of code attributes to me in gitfarm at Amazon was generated by octane and/or bones. God I miss that, thanks for the other person on HN introducing me to projen. Yeoman wasnt cutting it. These days I write a surprising amount of shell script and awk with LLMs. I review and adapt it, of course, but for short snippets of low context scripting it's been a huge time saver. I'm talking like 3-4, up to 20 lines of POSIX shell. Idk. Some day I'll actually learn AWK, and while I've gotten decent with POSIX shell (and bash), it's definitely been more monkey see monkey do than me going over all the libraries and reference docs like I did for python and the cpp FAQ.

tobyjsullivan 2y ago

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.

cj 2y ago
Do they have tooling for generating scaffolding for various things (like unit/integration tests)? If we’re guessing what code is easiest and largest proportion of codebase to write, my first guess would be test suites. Lots of lines of repetitive code patterns that repeat and AI is decent at dealing with

skissane 2y ago

> 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)

deleted 2y ago
[deleted]

wvenable 2y ago

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

randomNumber7 2y ago
Yes but then it would be more logical to say "AI makes our devs 25% more efficient". This is not what he said, but imo you are obviously right.
- wvenable 2y ago
  Not necessarily. If 25% of the code is written by AI but that code isn't very interesting or difficult, it might not be making the devs 25% more efficient. It could even possibly be more but, either way, these are different metrics.
- johannes1234321 2y ago
  The benefit doesn't translate 1:1. The generated code has to be read and verified and might require small adaptions. (Partially that can be done by AI as well) But for me it massively improved all the boilerplate generic work. A lot of those things which are just annoying work, but not interesting. Then I can focus on the bigger things, on the important parts.
lambdasquirrel 2y ago
I’ve already had one job interview where the applicant seemed broadly knowledgeable about everything we asked them during lead-in questions before actual debugging. Then when they had to actually dig deeper or demonstrate understanding while solving some problem, they fell short. I’m pretty sure they weren’t the first and there’ve been others we didn’t know about. So now I don’t ask lead-in questions anymore. Surprisingly, it doesn’t seem to make much of a difference and I don’t need to get burned again.

sangnoir 2y ago

> Does Google now have 25% subtly wrong code? How do you quantify "new code" - is it by lines of code or number of PRs/changesets generated? I can easily see it being the latter - if an AI workflow suggests 1 naming-change/cleanup commit to your PR made of 3 other human-authored commits, has it authored 25% of code? Arguably, yes - but it's trivial code that ought to be reviewed by humans. Dependabot is responsible for a good chunk of PRs already. Having a monorepo brings plenty of opportunities for automation when refactoring - whether its AI, AST manipulation or even good old grep. The trick is not to merge the code directly, but have humans in the loop to approve, or take-over and correct the code first.

rpcope1 2y ago

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.

solumunus 2y ago
Supermaven is an incredible intellisense. Most code IS trivial and I barely write trivial code anymore. My imports appear instantly, with high accuracy. I have lots of embedded SQL queries and it’s able to guess the structure of my database very accurately. As I’m writing a query the suggested joins are accurate probably 80% of the time. I’m significantly more productive and having to type much less. If this is as good as it ever gets I’m quite happy. I rarely use AI for non trivial code, but non trivial code is what I want to work on…
- ta_1138 2y ago
  This is all about the tooling most companies choose when building software: Things with more than enough boilerplate most code is trivial. We can build tools that have far less triviality and more density, where the distance between the code we write and business logic is very narrow.. but then every line of code we write is hard, because it's meaningful, and that feels bad enough to many developers, so we end up with tools where we might not be more productive, but we might feel productive, even though most of that apparent productivity is trivially generated. We also have the ceremonial layers of certain forms of corporate architecture, where nothing actually happens, but the steps must exist to match the holy box, box cylinder architecture. Ceremonial input massaging here, ceremonial data transformation over there, duplicated error checking... if it's easy for the LLM to do, maybe we shouldn't be doing it everywhere in the first place.

skeeter2020 2y ago

trivial code could very easily include the vast majority of most apps we're building these days. Most of it's just glue, and AI can probably stitch together a bunch of API calls and some UI as well as a human. It could also be a lot of non-product code, tooling, one-time things, etc.

ithkuil 2y ago

Or perhaps that even for excellent engineers and complicated problems a quarter of the code one writes is stupid almost copy-pasteable boilerplate which is now an excellent target for the magic lArge text Interpolator

eco 2y ago

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.

randomNumber7 2y ago
It is way more scary to use it for C or C++ than Python imo.
cybrox 2y ago
If you use it as advanced IntelliSense/auto-complete, it's not any worse than with typed languages. If you just let it generate and run the code... yeah, probably, since you won't catch the issues at compile time.
int_19h 2y ago
I can't help but think that Go might be one of the better languages for AI to target - statically typed, verbose with a lot of repeated scaffolding, yet generally not that easy to shoot yourself in the foot. Which might explain why this is a thing at Google specifically.

Kiro 2y ago

You're doing circular reasoning based on your initial concern actually being a problem in practice. In my experience it's not, which makes all your other speculations inherently incorrect.

JohnMakin 2y ago

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

notyourwork 2y ago

To your point, I don't buy the truth of the statement. I work in big tech and am convinced that 25% of the code being written is not coming from AI.

cybrox 2y ago

Depends if they include test code in this metric. I have found AI most valuable in generating test code. I usually want to keep tests as simple as possible, so I prefer some repetition over abstraction to make sure there's no issues with the test logic itself, AI makes this somewhat verbose process very easy and efficient.

slibhb 2y ago

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.

gorjusborg 2y ago
> Most programming is trivial That's a bold statement, and incorrect, in my opinion. At a junior level software development can be about churning out trivial code in a previously defined box. I don't think its fair to call that 'most programming'.
- BobbyJo 2y ago
  Probably overloading of the term "programming" is the issue here. Most "software engineering" is non-programming work. Most programming is not actually typing code. Most of the time, when I am typing code, the code I am producing is trivial, however.
- deleted 2y ago
  [deleted]
- uh_uh 2y ago
  Think of all the menial stuff you must perform regardless of experience level. E.g. you change the return type of a function and now you have to unpack the results slightly differently. Traditional automated tools fail at this. But if you show some examples to Cursor, it quickly catches on to the pattern and start autocompleting semi-automatically (semi because you still have to put the cursor to the right place but then you can tab, tab, tab…).

aorloff 2y ago

Its been a while since I was really fully in the trenches, but not that long. How people deal with this is they start by writing the test case. Once they have that, debugging that 25% comes relatively easily and after that its basically packaging up the PR

afavour 2y ago

> Or do they have 25% trivial code? If anything that's probably an underestimate. Not to downplay the complexity in much of what Google does but I'm sure they also do an absolute ton of tedious, boring CRUD operations that an AI could write.

ants_everywhere 2y ago

Google's internal codebase is nicer and more structured than the average open source code base. Their internal AI tools are presumably trained on their code, and it wouldn't surprise me if the AI is capable of much more internally than public coding AIs are.

fsckboy 2y ago

> Does Google now have 25% subtly wrong code? maybe the ai generates 100% of the company's new code, and then by the time the programmers have fixed it, only 25% is left of the AI's ship of Theseus

vkou 2y ago

How would you react to a tech firm that in 2018, proudly announced that 25% of their code was generated by IntelliJ/Resharper/Visual Studio's codegen and autocomplete and refactoring tools?

grepLeigh 2y ago

I have a whole "chop wood, carry water" speech born from leading corporate software teams. A lot of work at a company of sufficient size boils down to keeping up with software entropy while also chipping away at some initiative that rolls up to an OKR. It can be such a demotivating experience for the type of smart, passionate people that FANNGs like to hire. There's even a buzzword for it: KTLO (keep the lights on). You don't want to be spending 100% of your time on KTLO work, but it's unrealistic to expect to do done of it. Most software engineers would gladly outsource this type of scutwork.

girvo 2y ago
> KTLO (keep the lights on) Some places also call this "RTB" for "run the business" type work. Nothing but respect for the engineers who enjoy that kind of approach, I work with several!

Cthulhu_ 2y ago

You're quick to jump to the assertion that AI only generates SO style utility code to do X, but it can also be used to generate boring mapping code (e.g. to/from SQL datasets). I heard one ex Google dev say that most of his job wat fiddling with Protobuf definitions and payloads.

bluerooibos 2y ago

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.

ghosty141 2y ago
I havent seen anybody use them and be more productive. With c++ my experience is that the results are completely worthless. It saves you from writing a few keywords but nothing that really helps in a big way. Yes Copilot CAN work, for example writing some JS or filter functions, but in my job these trivial snippets are rather uncommon. I‘d genuinely love to see some resources that show its usefulness that arent just PR bs.
- bluerooibos 2y ago
  > I havent seen anybody use them and be more productive. What does that even mean? What are you expecting to see? I've seen people who can't code ship entire new applications which actually work, in a few days or so. That to me seems more productive? I use these tools daily in a FAANG level SWE role and they help me debug issues quickly - all the time, especially with tech I'm new to and have no experience with. I really don't understand the hate - it's like skipping stack overflow and giving you the ideal answer a lot faster. Nobody likes to shout that they're using these tools but most people are.
thegrim33 2y ago
These tools have exploded in popularity for good reason. If they were no good, people wouldn't be using them. You're saying anything that's ever been popular is popular for a good reason? You can't think of counter examples that disprove this? You're saying anything that people decide to do is good, or else people wouldn't do it? People never act irrationally? People never blindly act on trends? People never sacrifice long-term results for short-term gain? You can't come up with any counter examples?

ZiiS 2y ago

Yes 25% of code is trivial; certainly for companies like Google that have always been a bit NIH.

fuzzy2 2y ago

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.

alfiedotwtf 2y ago
> replace "AI" with "junior dev", done. Damn, that’s a good way of putting it. But I’ll go one further: replace "AI" with "junior dev who doesn’t like reading documentation or googling how things work so instead confidently types away while guessing the syntax and API so it kind of looks right”
- hughesjj 2y ago
  I've been saying it's like an intern who has an incredible breadth of knowledge but very little depth, is excessively over confident in their own abilities given the error rates they commit, and is anxious to the point they'll straight up lie to you rather than admit a mistake. Currently, they don't learn skills as fast as a motivated intern. A stellar intern can go from no idea to "makes relevant contributions to our product with significant independence and low error rate" (hi Matt if you ever see this) in 3 months. LLMs, to my understanding, take significantly more attention from super smart people working long hours and an army of mechanical Turks, but won't be able to independently implement a feature and will still have a higher error rate in the same 3 months. It's still super impressive what LLMs can do, but that same intern is going to keep growing at that faster rate in skills and competency as they go from jr->mid->sr. Sure the intern won't have as large of a competency pool, and takes longer to respond to any given question, but the scope of what they can implement is so much greater.
palata 2y ago
Isn't the whole point of hiring a junior dev that they will learn and become senior devs eventually?

uoaei 2y ago

I've suspected for a while now that the people who find value in AI-generated code don't actually have hard problems to solve. I wonder how else they might justify their salary.

dmurray 2y ago

> Or do they have 25% trivial code? Surely yes. I (not at Google) rarely use the LLM for anything more than two lines at a time, but it writes/autocompletes 25% of my code no problem. I believe Google have character-level telemetry for measuring things like this, so they can easily count it in a way that can be called "writing 25% of the code". Having plenty of "trivial code" isn't an indictment of the organisation. Every codebase has parts that are straightforward.

dyauspitr 2y ago

This subtly wrong thing happens maybe 10% of the time in my experience and asking it to generate unit tests or writing your own ahead of time almost completely eliminates it.

name_nick_sex_m 2y ago

[flagged]

djvuvtgcuehb 2y ago

A better analogy is a self driving car where you need to keep your hands on the wheel in case something goes wrong. For the most part, it drives itself. Yes, the majority of my code is trivial. But I've also had ai iterate on some very non trivial work including writing the test suite. It's basically autocomplete on steroids that predicts your next change in the file, not just the next change on the line. The copy paste from stack overflow trope is a bit weird, I haven't done that in ten years and I don't think the code it produces is that low quality either. Copy paste from an open source repo on GitHub maybe?

aiforecastthway 2y ago

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.

javaunsafe2019 2y ago
Since when is engineering boring? Stranges ideas and claims u made. I’m an engineer who writes code since 20 years and it’s far away from trivial . Maybe to do web dev for a simple Webshop is. Elsewhere software has often times special requirements. Be them technical or domain wise both make the process complex and not simple IMHO
- aiforecastthway 2y ago
  Boring is the opposite of exciting/dynamic. Not all engineering is boring. Also, boring is not bad. A lot of my career has been spent working to make software boring. To the extent that I've helped contribute to the status quo, where we can build certain types of software in a relatively secure fashion and on relatively predictable timelines, I am proud to have made the world more boring! (Also, complexity can be extraordinarily boring. Some of the most complex things are also the most boring. Nothing more boring than a set of business rules that has an irreducible complexity coming in at 5,211 lines of if-else blocks wrapped in two while loops! Give me a simple set of partial differential equations any day -- much more exciting to work with those! If you're the type of person who enjoys reading tax code, then we just have different definitions of boring; and if you're the type of person doesn't think tax code is complex, then I'm just a dummy compared to you :)) But e.g. in the early naughts doing structural engineering work for residential new build projects was certainly less engaging and exciting work than building websites. Most engineering works aims for repeatable and predictable outcomes. That's a good thing, and it's not easy to achieve! But if Software has reached the point where the process of building certain types of software is "repeatable and predictable", and if Google needs a lot of that type of software, then if the main criticism of AI code assistants is "it's only good for repeatable and predictable", well, then the criticism isn't exactly the indictment that skeptics think it is. There is nothing wrong with boring in the sense I'm using it. Boring can be tremendously intellectually demanding. Also, predictable and repeatable processes are incredibly important if you want quality work at scale. Engineering is a good thing. Maturing as a field is a good thing. But if we're maturing from "wild west everything is a greenfield project" to "70% of things are pretty systematic and repeatable" then that says something about the criticism of AI coding assistants as being only good for the systematic and repeatable stuff, right? Also: the AI coding assistant paradigm is coming for structural/mechanical/civil engineering next, and in a big way!

signa11 2y ago

``` Like, isn't this announcement a terrible indictment of how inexperienced their engineers are, or how trivial the problems they solve are, or both? ``` there is a 3rd possibility as well: having spent a huge chunk of change on these techniques, why not overhype it (not outright lie about it) and hope to, somewhat recoup the cost from unsuspecting masses ?

sally_glance 2y ago

I guess the obvious response would be - yes, they have _at least_ 25% trivial code (as any other enterprise), and yes, they should have lots of engineers 'babysitting' (aka generating training data). So in another year or two there will be no manpower at all needed for the trivial tasks.

asdfman123 2y ago

No, AI is generating a quarter of all characters. It's an autocomplete engine. You press tab, it finishes the line. Doesn't do any heavy lifting at all. Source: I work there, see my previous comment.

TacticalCoder 2y ago

> and they'll very confidently generate subtly wrong code for anything that's non-trivial for an experienced programmer to write Thankfully I don't find it subtle but plain wrong for anything but trivial stuff. I use it (and pay an AI subscription) for things where false positive won't ruin the day, like parameters validation. But for anything advanced, it's pretty hopeless. I've talked with lawyers: same thing. With doctors: same thing. Which ain't no surprise see how these things do work. > Like, isn't this announcement a terrible indictment of how inexperienced their engineers are, or how trivial the problems they solve are, or both? Probably lots of highly repetitive boilerplate stuff everywhere. Which in itself is quite horrifying if you think about it.

nimithryn 2y ago

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.

pjmorris 2y ago

> Like, isn't this announcement a terrible indictment of how inexperienced their engineers are, or how trivial the problems they solve are, or both? Or maybe there's a KPI around lines of code or commits.

manquer 2y ago

if their sales and stock depends on saying that new shinny thing is changing the world then they have to say so, and say how it is changing their world . It is not Netflix or Airbnb or Stripe etc making this claim, google managers have a vested interest in this. If this metric was meaningful either of two things should have happened - google should have fired 25 % developers or built 25 % more product . Both of this would visible in their financial reporting and has not happened. metrics like this claim depends on how you count, that is easily gamed and can be made to show any % between 0-99 you want. Of the top of head - I could count all AI generated code used for training as new code - consider compiler output to assembly as AI code by adding some meaningless AI step in it - code generated with boilerplate perhaps even generated by llm now - mix autocomplete with llm prompts so on The number only needs to believable , 25 is believable now, it is not true but you would believe it >50 has psychological significance and bad PR on machines replacing humans jobs , less than 10 is bad for AI sales , 25 works all the commenters in this thread is testament to that

llm_trw 2y ago

Or alternatively you don't know how to use AI to help you code and are in the 2020s equivalent of the 'Why do I need google when I have the yellow pages?' phase a lot of adults went through in the 2000s. This is not a bad thing since you can improve, but constantly dismissing something that a lot of people are finding an amazing productivity boost should give you some pause.

johnnyanmac 2y ago
It's like blockchain right now. I'm sure there is some killer feature that can justify its problem space. But as of now the field is full of swamps. Of grifters, of people with a solution looking for a problem. Of outright scams of questionable legality being challenged as we speak. I'll wait until the swamps work itself out before evaluating an LLM workflow.
- llm_trw 2y ago
  Blockchain was always a solution looking for a problem. LLMs are being used right now by a lot of people, myself included, to do tasks which we would have never bothered with before. Again, if you don't know how to use them you can learn.
  - johnnyanmac 2y ago
    And the same was said with the last fad when Blockcbain was all investors wanted to hear about ("Big Data" I suppose). It's all a pattern. It's a legal nightmare in my domain as of now, so I'll make sure the Sam Breaker-Friends are weeded out. If it's really all the hype it won't be going anywhere in 5 years.
    - llm_trw 2y ago
      It's been 5 years since GPT2. I'm really struggling to understand the amount of negativity towards the biggest breakthrough in computing since the WWW.

deleted 2y ago

[deleted]

herval 2y ago

In my experience, that was always the case with gpt3.5, most times the case with gpt4, some times the case with the latest sonnet. It’s getting better FAST, and the kind of code they can handle is increasing fast too

rh2323o4jl234 2y ago

> Does Google now have 25% subtly wrong code? I think you underestimate the amount of boiler-plate code that a typical job at Google requires. I found it soul-crushingly boring (though their pay is insane).

geodel 2y ago

> Like, isn't this announcement a terrible indictment of how inexperienced their engineers are.. Well, Rob Pike said same thing about experience and that seemed to pissed lot of people endlessly. However I don't think it as indictment It just seems very reasonable to me. In fact 25% seem to be on lower end. Amazon seems to have thousands of software engineers who are doing API calling API calling API.. kind of crap. Now their annual income might be more than my lifetime earnings. But to think that all these highly paid engineers are doing highly complex work that need high skills seems just a myth that is useful to boost ego of engineers and their employers alike.

deleted 2y ago

[deleted]

toviahudson5 2y ago

[dead]