Hacker News new | past | comments | ask | show | jobs | submit

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

https://www.businessinsider.com/google-earnings-q3-2024-new-code-created-by-ai-2024-10
loading story #41991323
I work for Google, and I just got done with my work day. I was just writing I guess what you'd call "AI generated code."

But the code completion engine is basically just good at finishing the lines I'm writing. 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.

So basically, it's a helpful productivity tool but it's not doing any engineering at all. It's probably about as good, maybe slightly worse, than Copilot. (I haven't used it recently though.)

loading story #42004709
loading story #42004808
loading story #42003639
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.
loading story #42004410
loading story #42003596
loading story #42004568
loading story #42005193
loading story #42004193
loading story #42003968
I mostly use one-line completes and they are pretty good. Also I really like when Copilot generates boilerplate like

    if err != nil {
      return fmt.Errorf("Cannot open settings: %w", err);
    }
loading story #42004009
loading story #42003699
loading story #42005890
loading story #42004373
loading story #42004333
loading story #42007683
loading story #42003802
loading story #42005519
loading story #42004494
loading story #42007054
loading story #42004372
loading story #42004313
loading story #42004884
loading story #42004083
loading story #42003391
loading story #42004594
loading story #42004050
loading story #42005683
loading story #42009328
loading story #42004457
loading story #42003354
loading story #42003488
loading story #42004489
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.
I'd say so, and it's a bit misleading to leave that out. Code generation is almost as old as computing. So far, most of it happened to be deterministic.
Yeah but it didn't cost trillions and needed its own nuclear power plant. Noone disputes that llm/ai is cool/can be helpful but at what cost, where is the roi?
loading story #42003527
loading story #42008508
loading story #42003335
loading story #42008062
loading story #42007834
loading story #42007456
loading story #42009515
loading story #42008789
loading story #42003323
loading story #42007444
loading story #42006845
loading story #42006989
loading story #42008180
> 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) ?

This video is a pretty good one on how it works in practice: https://storage.googleapis.com/gweb-research2023-media/media...
loading story #42005398
loading story #42008195
loading story #42003496
loading story #42003447
Hi, I lead the teams responsible for our internal developer tools, including AI features. We work very closely with Google DeepMind to adapt Gemini models for Google-scale coding and other Software Engineering usecases. Google has a unique, massive monorepo which poses a lot of fun challenges when it comes to deploying AI capabilities at scale.

1. We take a lot of care to make sure the AI recommendations are safe and have a high quality bar (regular monitoring, code provenance tracking, adversarial testing, and more).

2. We also do regular A/B tests and randomized control trials to ensure these features are improving SWE productivity and throughput.

3. We see similar efficiencies across all programming languages and frameworks used internally at Google and engineers across all tenure and experience cohorts show similar gain in productivity.

You can read more on our approach here:

https://research.google/blog/ai-in-software-engineering-at-g...

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.

loading story #41993430
loading story #42000029
loading story #42003728
loading story #42002610
loading story #42006520
loading story #42004196
loading story #42003765
loading story #42000839
loading story #42004369
loading story #42008118
loading story #42003197
I think that at least partially the negativity is due to the tech bros hyping AI just like they hyped crypto.
To me the most interesting part of this is the claim that you can accurately and meaningfully measure software engineering productivity.
You can - but not on the level of a single developer and you cannot use those measures to manage productivity of a specific dev.

For teams you can measure meaningful outcomes and improve team metrics.

You shouldn’t really compare teams but it also is possible if you know what teams are doing.

If you are some disconnected manager that thinks he can make decisions or improvements reducing things to single numbers - yeah that’s not possible.

> For teams you can measure meaningful outcomes and improve team metrics.

How? Which metrics?

loading story #41999603
loading story #42003039
loading story #41994340
loading story #42008202
At scale you can do this in a bunch of interesting ways. For example, you could measure "amount of time between opening a crash log and writing the first character of a new change" across 10,000s of engineers. Yes, each individual data point is highly messy. Alice might start coding as a means of investigation. Bob might like to think about the crash over dinner. Carol might get a really hard bug while David gets a really easy one. But at scale you can see how changes in the tools change this metric.

None of this works to evaluate individuals or even teams. But it can be effective at evaluating tools.

There's lots of stuff you can measure. It's not clear whether any of it is correlated with productivity.

To use your example, a user with an LLM might say "LLM please fix this" as a first line of action, drastically improving this metric, even if it ruins your overall productivity.

You can come up with measures for it and then watch them, that’s for sure.
when metric becomes the target it ceases to be a good metric. when discovered how it works developers will type the first character immediately after opening the log.

edit: typo

Only if the developer is being judged on the thing. If the tool is being judged on the thing, it's much less relevant.

That is, I, personally, am not measured on how much AI generated code I create, and while the number is non-zero, I can't tell you what it is because I don't care and don't have any incentive to care. And I'm someone who is personally fairly bearish on the value of LLM-based codegen/autocomplete.

That was my point, veiled in an attempt to be cute.
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?

No, that would require AGI. Actual reasoning.

Adversaries are already detecting issues tho, using proven means such as code review and fuzzing.

Google project zero consists of a team of rock star hackers. I don't see LLM even replacing junior devs right now.

Seems like there is more gain on the adversary side of this equation. Think nation-states like North Korea or China, and commercial entities like Pegasus Group.
loading story #42000551
loading story #42004476
loading story #42003599
loading story #42000536
loading story #42002830
loading story #42001677
loading story #42003860
loading story #42000268
loading story #41992117
loading story #41999590
loading story #41994430
loading story #42007268
loading story #42001758
loading story #41999945
loading story #41992206
loading story #41992588
loading story #42000521
loading story #42003871
loading story #42007019
loading story #42000174
loading story #41999953
loading story #41991568
loading story #41999702
loading story #41999698
loading story #42003983
I don't write code as I'm a sysadmin. Mostly just scripts. But is this like saying intellisense writes 25% of my code? Because I use autocomplete to shortcut stuff or to create a for loop to fill with things I want to do.
loading story #41992077
loading story #42000001
> I don't write code as I'm a sysadmin. Mostly just scripts.

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

loading story #42012291
The colloquial difference is a few lines, maybe a dozen or two, for maintenance and one off stuff, not a full blown application.
loading story #41999782
loading story #42002036
loading story #42002335
loading story #42001551
i would be may more impressed if LLMs could do code compression. more code == more things that can break, and when llms can generate boatloads of it with a click you can imagine what might happen
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.
loading story #41991427
loading story #41999610
loading story #41996609
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.

loading story #41991663
loading story #41993450
loading story #41991469
Exactly this. Code is a liability, if you can do the same thing with less code you're often better off.
loading story #41991697
How would it know which edge cases are being useful and which ones aren't?

I understand more code as being more edge cases

loading story #42000440
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.

loading story #42000565
loading story #42006923
loading story #42002820
loading story #42008609
loading story #41999869
loading story #42004712
loading story #42001225
loading story #42004421
loading story #42004454
loading story #41999634
loading story #41992468
loading story #42001320
loading story #42001694
loading story #42001703
loading story #42005686
loading story #42043146
loading story #42000637
loading story #42000055
loading story #42005555
loading story #42020669
loading story #42000248
loading story #42003153
loading story #42006275
loading story #42001685
loading story #42003072
loading story #42000717
loading story #42000810
loading story #42008752
loading story #42007550
loading story #42000746
loading story #42002118
loading story #42000993
loading story #42000421
loading story #42001233
loading story #42000769
loading story #42001328
loading story #42007659
loading story #42006144
loading story #42001475
loading story #42002750
To me, programming assistants have two usecases:

1. Generate unit tests for modules which are already written to be tested 2. Generate documentation for interfaces

Both of these require quite deep knowledge in what to write, then it simply documents and fills in the blanks using the context which already has been laid out.

loading story #42004790
loading story #42008786
loading story #42004466
loading story #42001066
loading story #42002228
loading story #42000569
loading story #42000050
loading story #42001262
loading story #42001789
loading story #42001036
loading story #41991689
loading story #42000523
I've had mixed results writing "normal" business logic in c++, but i gotta say, for SQL it's pretty incredible. Granted SQL has a lot of boilerplate and predictable structure, but it saves a ton of time honestly.
loading story #41991557
loading story #42001751
loading story #42004002
loading story #42001428
loading story #42005939
loading story #42004428
loading story #42004444
loading story #41996990
loading story #42000418
loading story #42005373
loading story #42001062
loading story #41992027
loading story #42000724
loading story #42013730
loading story #42007492
loading story #42006028
loading story #42007673
loading story #42034942
loading story #42009445
loading story #42004718
loading story #42005286
loading story #42009401
loading story #42009266
loading story #41999956
loading story #42002156
loading story #42002246
loading story #42004096
loading story #42004602
loading story #42004693
loading story #41999725
loading story #42000561
loading story #42002880
loading story #41991563
loading story #41999917
loading story #42001070
loading story #42001945
loading story #42013808
loading story #42004691
loading story #42009942
loading story #42002183
loading story #42019203
loading story #42002239
loading story #42002611
loading story #42004912
loading story #42000615
loading story #42002911
loading story #41999673
loading story #41991434
loading story #42020301
loading story #42000975
loading story #42006746
loading story #42014575
loading story #42006219
loading story #42006318
loading story #42008380
loading story #42002767
loading story #42005292
loading story #42008560
loading story #42006738
imho code that is written by AI is code that is not worth having.
loading story #42007636
loading story #42008273
loading story #42002591
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?

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

What I can't wrap my head around is that making good, efficient software doesn't (by and large) take significantly longer than making bloated, inefficient enterprise spaghetti. The problem is finding people to do it with who care enough to think rigorously about what they're going to do before they start doing it. There's this bizarre misconception popular among bigtech managers that there's some tunable tradeoff between quality and development speed. But it doesn't actually work that way at all. I can't even count anymore how many times I've had to explain how taking this or that locally optimal shortcut will make it take longer overall to complete the project.

In other words, it's a skill issue. LLMs can only make this worse. Hiring unskilled programmers and giving them a machine for generating garbage isn't the way. Instead, train them, and reject low quality work.

> What I can't wrap my head around is that making good, efficient software doesn't (by and large) take significantly longer than making bloated, inefficient enterprise spaghetti. The problem is finding people to do it with who care enough to think rigorously about what they're going to do before they start doing it.

I don't think finding such programmers is really difficult. What is difficult is finding such people if you expect them to be docile to incompetent managers and other incompetent people involved in the project who, for example, got their position not by merit and competence, but by playing political games.

loading story #42002161
loading story #42003055
Agreed.

The way I explain this to managers is that software development is unlike most work. If I'm making widgets and I fuck up, that widget goes out the door never to be seen again. But in software, today's outputs are tomorrow's raw materials. You can trade quality for speed in the very short term at the cost of future productivity, so you're really trading speed for speed.

I should add, though, that one can do the rigorous thinking before or after the doing, and ideally one should do both. That was the key insight behind Martin Fowler's "Refactoring: Improving the Design of Existing Code". Think up front if you can, but the best designs are based on the most information, and there's a lot of information that is not available until later in a project. So you'll want to think as information comes in and adjust designs as you go.

That's something an LLM absolutely can't do, because it doesn't have access to that flow of information and it can't think about where the system should be going.

> the best designs are based on the most information, and there's a lot of information that is not available until later in a project

This is an important point. I don't remember where I read it, but someone said something similar about taking a loss on your first few customers as an early stage startup--basically, the idea is you're buying information about how well or poorly your product meets a need.

Where it goes wrong is if you choose not to act on that information.

loading story #42016875
loading story #42002376
loading story #42002185
<< Instead, train them, and reject low quality work.

Ahh, well, in order to save money, training is done via an online class with multiple choice questions, or, if your company is like mine and really committed to making sure that you know they take your training seriously, they put portions of a generic book on 'tech Z' in pdf spread spread over a drm ridden web pages.

As for code, that is reviewed, commented and rejected by llms as well. It is used to be turtles. Now it truly is llms all the way down.

That said, in a sane world, this is what should be happening for a company that actually wants to get good results over time .

loading story #42003797
loading story #42002139
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.

loading story #42000772
Google results are not polluted with spam because Google doesn't know how to deal with it.

Google results are polluted with spam because it is more profitable for Google. This is a conscious decision they made five years ago.

because it is more profitable for Google

Then why are DuckDuckGo results also (arguably even more so) polluted with spam/scam sites? I doubt DDG is making any profit from those sites since Google essentially owns the display ad business.

loading story #42001393
loading story #42002525
loading story #42000813
> Traditional search (at least on the web) is dying.

That's not my experience at all. While there are scammy sites, using the search engines as an index instead of an oracle still yields useful results. It only requires to learn the keywords which you can do by reading the relevant materials .

How do you read the relevant materials if you haven’t found them yet? It’s a chicken and egg problem. If your goal is to become an expert in a subject but you’re currently a novice, search can’t help you if it’s only giving you terrible results until you “crack the code.”
loading story #42001569
loading story #42000449
loading story #42001358
loading story #42001698
loading story #42001451
>The entire edifice is drowning under a rapidly rising tide of spam and scam sites.

You make this claim with such confidence, but what is it based on?

There have always been hordes of spam and scam websites. Can you point to anything that actually indicates that the ratio is now getting worse?

There have always been hordes of spam and scam websites. Can you point to anything that actually indicates that the ratio is now getting worse?

No, there haven't always been hordes of spam and scam websites. I remember the web of the 90s. When Google first arrived on the scene every site on the results page was a real site, not a spam/scam site.

loading story #42002646
loading story #42001421
loading story #42001287
loading story #42000365
loading story #42000516
loading story #42000840
loading story #42003672
loading story #42000384
loading story #42002267
loading story #42002894
loading story #42002397
loading story #42002631
loading story #42001525
loading story #42001631
loading story #42002172
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.

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…
loading story #42000829
I don't think that is the signal that I think most people are hoping for here.

When I hear that most code is trivial, I think of this as a language design or a framework related issue making things harder than they should be.

Throwing AI or generates at the problem just to claim that they fixed it is just frustrating.

loading story #42001850
loading story #42005016
loading story #42001946
loading story #42001042
loading story #42000334
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.

>I think most programmers who claim that LLMs aren't useful are reacting emotionally.

I don't think that's true. Most programmers I speak to have been keen to try it out and reap some benefits.

The almost universal experience has been that it works for trivial problems, starts injecting mistakes for harder problems and goes completely off the rails for anything really difficult.

loading story #42002326
> 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'.

loading story #42000960
loading story #42002768
loading story #42001687
From my perspective, writing out the requirements for an AI to produce the code I want is just as easy as writing it myself. There are some types of boilerplate code that I can see being useful to produce with an LLM, but I don't write them often enough to warrant actually setting up the workflow.

Even with the debugging example, if I just read what I wrote I'll find the bug because I understand the language. For more complex bugs, I'd have to feed the LLM a large fraction of my codebase and at that point we're exceeding the level of understanding these things can have.

I would be pretty happy to see an AI that can do effective code reviews, but until that point I probably won't bother.

It's reasonable to say that LLMs are not completely useless. There is also a very valid case to make that LLMs are not good at generating production ready code. I have found asking LLMs to make me Nix flakes to be a very nice way to make use of Nix without learning the Nix language.

As an example of not being production ready: I recently tried to use ChatGPT-4 to provide me with a script to manage my gmail labels. The APIs for these are all online, I didn't want to read them. ChatGPT-4 gave me a workable PoC that was extremely slow because it was using inefficient APIs. It then lied to me about better APIs existing and I realized that when reading the docs. The "vibes" outcome of this is that it can produce working slop code. For the curious I discuss this in more specific detail at: https://er4hn.info/blog/2024.10.26-gmail-labels/#using-ai-to...

loading story #42001332
> 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.

I think revealing the domain each programmer works in and asking in hose domains would reveal obvious trends. I imagine if you work in Web that you'll get workable enough AI gen code, but something like High Performance computing would get slop worse than copying and lasting the first result on Stackoverflow.

A model is only as good as its learning set, and not all types are code are readily able to be indexable.

> 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 think that’s exactly right. I used to have to create the puzzle pieces and then fit them together. Now, a lot of the time something else makes the piece and I’m just doing the fitting together part. Whether there will come a day when we just need to describe the completed puzzle remains to be seen.

Trivial is fine but as you compound all the triviality the system starts to have a difficult time with putting it together. I don't expect it to nail it but then you have to unwind everything and figure out the issues so it isn't all gravy - fair bit of debug.
It’s always harder to build a mental model of the code written by someone else. No matter what, if you trust an LLM on small things in the long run you’ll trust it for bigger things. And the most code the LLM writes, the harder it is to build this mental construct. In the end it’ll be « it worked on 90% of cases so we trust it ». And who will debug 300 millions of code written by a machine that no one read based on trust ?
They are useful, but so far, I haven't seen LLMs being obviously more useful than stackoverflow. It might generate code closer to what I need than what I find already coded, but it also produces buggier code. Sometimes it will show me a function I wasn't aware of or approach I wouldn't have considered, but I have to balance that with all the other attempts that didn't produce something useful.
Yes. Productivity tools make programmer time more valuable, not less. This is basic economics. You’re now able to generate more value per hour than before.

(Or if you’re being paid to waste time, maybe consider coding in assembly?)

So don’t be afraid. Learn to use the tools. They’re not magic, so stop expecting that. It’s like anything else, good at some things and not others.

A good farmer isn’t likely to complain about getting a new tractor. But it might put a few horses out of work.
I would add that a lot of the time when I'm programming, I'm an expert on the problem domain but not the solution domain — that is, I know exactly what the pseudocode to solve my problem should look like; but I'm not necessarily fluent in the particular language and libraries/APIs I happen to have to use, in the particular codebase I'm working on, to operationalize that pseudocode.

LLMs are great at translating already-rigorously-thought-out pseudocode requirements, into a specific (non-esoteric) programming language, with calls to (popular) libraries/APIs of that language. They might make little mistakes — but so can human developers. If you're good at catching little mistakes, then this can still be faster!

For a concrete example of what I mean:

I hardly ever code in JavaScript; I'm mostly a backend developer. But sometimes I want to quickly fix a problem with our frontend that's preventing end-to-end testing; or I want to add a proof-of-concept frontend half to a new backend feature, to demonstrate to the frontend devs by example the way the frontend should be using the new API endpoint.

Now, I can sit down with a JS syntax + browser-DOM API cheat-sheet, and probably, eventually write correct code that doesn't accidentally e.g. incorrectly reject reject zero or empty strings because they're "false-y", or incorrectly interpolate the literal string "null" into a template string, or incorrectly try to call Element.setAttribute with a boolean true instead of an empty string (or any of JS's other thousand warts.) And I can do that because I have written some JS, and have been bitten by those things, just enough times now to recognize those JS code smells when I see them when reviewing code.

But just because I can recognize bad JS code, doesn't mean that I can instantly conjure to mind whole blocks of JS code that do everything right and avoid all those pitfalls. I know "the right way" exists, and I've probably even used it before, and I would know it if I saw it... but it's not "on the tip of my tongue" like it would be for languages I'm more familiar with. I'd probably need to look it up, or check-and-test in a REPL, or look at some other code in the codebase to verify how it's done.

With an LLM, though, I can just tell it the pseudocode (or equivalent code in a language I know better), get an initial attempt at the JS version of it out, immediately see whether it passes the "sniff test"; and if it doesn't, iterate just by pointing out my concerns in plain English — which will either result in code updated to solve the problem, or an explanation of why my concern isn't relevant. (Which, in the latter case, is a learning opportunity — but one to follow up in non-LLM sources.)

The product of this iteration process is basically the same JS code I would have written myself — the same code I wanted to write myself, but didn't remember exactly "how it went." But I didn't have to spend any time dredging my memory for "how it went." The LLM handled that part.

I would liken this to the difference between asking someone who knows anatomy but only ever does sculpture, to draw (rather than sculpt) someone's face; vs sitting the sculptor in front of a professional illustrator (who also knows anatomy), and having the sculptor describe the person's face to the illustrator in anatomical terms, with the sketch being iteratively improved through conversation and observation. The illustrator won't perfectly understand the requirements of the sculptor immediately — but the illustrator is still a lot more fluent in the medium than the sculptor is; and both parties have all the required knowledge of the domain (anatomy) to communicate efficiently about the sculptor's vision. So it still goes faster!

> people who can do it will be high status

They don't have high status even today, imagine in a world where they will be seen as just reviewers for AI code...

loading story #42002725
loading story #42000378
loading story #42000265
loading story #41999959
loading story #42002328
loading story #42001410
loading story #42001466
loading story #42000375
loading story #42000630
loading story #42000566
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.

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

loading story #42001942
loading story #42001347
loading story #42002218
> 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.

loading story #41999874
loading story #41999824
loading story #42002203
loading story #42000381
loading story #42003118
loading story #42001148
loading story #42000934
loading story #42002641
loading story #42001718
loading story #42002422
loading story #42001258
loading story #42003040
loading story #42002637
loading story #41999777
loading story #42002457
loading story #41999938
loading story #42001950
loading story #42000686
loading story #42002008
loading story #42000409
loading story #42001395
loading story #42000801
loading story #41999911
loading story #42001277
loading story #42000048
loading story #41999962
loading story #42001523
loading story #42001575
loading story #42000678
loading story #42001426
loading story #41999772
loading story #42000427
loading story #42000916
loading story #42013583
loading story #42003119
loading story #42001684
loading story #42002613
loading story #42010135
loading story #42003266
loading story #42005993
loading story #42006299
loading story #42004095
loading story #42002132
loading story #42005526
loading story #42003971
loading story #42002601
loading story #41992182
loading story #41991347
loading story #41991375
loading story #41991499
loading story #41991357
loading story #41991381
loading story #41991392
loading story #41991402
loading story #41991741
[flagged]
{"deleted":true,"id":41991506,"parent":41991501,"time":1730256399,"type":"comment"}
loading story #41991452
loading story #41991468
loading story #41991436
loading story #42006057
loading story #41991356
loading story #41991351
loading story #41993294
loading story #42001542
loading story #42007799
loading story #41991570
loading story #41991981