Like, isn't this announcement a terrible indictment of how inexperienced their engineers are, or how trivial the problems they solve are, or both?
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.
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.
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.
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.
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.
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.
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.
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.
> 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.
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.
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)
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.
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.
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.
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.
Source: I work there, see my previous comment.
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.
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.
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.
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.
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.
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.
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?
Or maybe there's a KPI around lines of code or commits.
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
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
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.
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 ?
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
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.
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 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.
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?
I’m far from impressed with the output of GPT/Claude, all they’ve done is weight against stack overflow - which is still low quality code relative to Google.
What is probability Google makes this a real product, or is it too likely to autocomplete trade secrets?
Considering how terrible and frequently broken the code that the public facing Gemini produces, I'll have to be honest that that kind of scares me.
Gemini frequently fails at some fairly basic stuff, even in popular languages where it would have had a lot of source material to work from; where other public models (even free ones) sail through.
To give a fun, fairly recent example, here's a prime factorisation algorithm it produce for python:
# Find the prime factorization of n
prime_factors = []
while n > 1:
p = 2
while n % p == 0:
prime_factors.append(p)
n //= p
p += 1
prime_factors.append(n)
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.
I understand more code as being more edge cases
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.
Not to mention Elon publicly demonstrated losing 80% of staff when he took over twitter and - you can complain about his management all you want - as someone who's been using it the whole way through, from a technical POV their downtimes and software quality has not been any worse and they're shipping features faster. A lot of software companies are overstaffed, especially Google who has spent years paying people to make projects just to get a PO promoted, then letting the projects rot and die to be replaced by something else. That's a lot of useless work being done.
You have to establish that the CEO is actually aware of the reality and is interested in accurately conveying that to you. As far as I can tell there is absolutely no reason to believe any part of this.
With g3's immense amount of context, LLMs can vastly help you discover how other people are using existing libraries.
Google could be writing the same amount of code with fewer developers (they have had multiple layoffs lately), or their developers could be focusing more of their time and attention on the code they do write.
The truth is likely somewhere in between.
But you make an interesting point: eventually AI will be making for other AI's + machines, and human verification can be an after thought.
One common misconception is that all LLMs are the same. The models are trained the same, but trained on wildly different datasets. Google, and more specifically the Google codebase is arguably one of the most curated, and iterated on datasets in existence. This is a massive lever for Google to train their internal code-gen models, that realistically could easily replace any entry-level or junior developer.
- Code review is another dimension of the process of maintaining a codebase that we can expect huge improvements with LLMs. The highly-curated commentary on existing code / flawed diff / corrected diff that Google possesses give them an opportunity to build a whole set of new internal tools / infra that's extremely tailored to their own coding standard / culture.
This is a massive, unsubstantiated leap.
When someone who uses a product says it, there is a 50% chance of it being true, but when someone far away from the user says it, it is 100% promotion of product and setup for trust building for a future sale.
Not what I thought when I heard "AI coding", but seems pretty neat.
I'll be looking into ways of running a local LLM for this purpose (code assistance in VS Code). I'm already really impressed with various quite large models running on my 32 GB Mac Studio M2 Max via Ollama. It feels like having a locally running chatgpt.
It immediately works out of the box and that's it. I've been using local LLMs on my laptop for a while, it's pretty nice.
The only thing you really need to worry about is VRAM. Make sure your GPU has enough memory to run your model and that's pretty much it.
Also "open webui" is the worst project name I've ever seen.
Not that I'm really discounting the value of AI here. For example, I've found a ton of value and saved time getting AI to write CDKTF (basically, Terraform in Typescript) config scripts for me. I don't write Terraform that often, there are a ton of options I always forget, etc. So asking ChatGPT to write a Terraform config for, say, a new scheduled task for example saves me from a lot of manual lookup.
But at the same time, the AI isn't really writing the complicated logic pieces for me. I think that comes down to the fact that when I do need to write complicated logic, I'm a decent enough programmer that it's probably faster for me to write it out in a high-level programming language than write it in English first.
IMO it's only really an issue if a competent human wasn't involved in the process, basically a person who could have written it if needed, then they do the work connecting it to the useful stuff, and have appropriate QA/testing in place...the latter often taking far more effort than the actual writing-the-code time itself, even when a human does it.
The other 75% is the stuff you actually have to think about.
This feels like saying linters impact x0% of code. This just feels like an extension of that.
Most of the code must be what could be snippets (opening files and handling errors with absl::, and moving data from proto to proto). One thing that doesn't help here, is that when writing for many engineers on different teams to read, spelling out simple code instead of depending on too many abstractions seems to be preferred by most teams.
I guess that LLMs do provide smarter snippets that I don't need to fill out in detail, and when it understands types and whether things compile it gets quite good and "smart" when it comes to write down boilerplate.
25% of coding is just the most basic boilerplate. I think of AI not as a thinking machine but as a 1000 WPM boilerplate typer.
If it is halucinating, you're trying to make it do stuff that is too complex.
Thats my main problem: for trivial things it works but isnt much better than conventional tools, for hard things it just produces incorrect code such that writing it from scratch barely makes a difference
For the example of generating an http app scaffolding from an openapi spec, it would probably account for at least 25% of the text in the generated source code. But I imagine this report would conveniently exclude the creation of the original source yaml driving the generator — I can’t imagine you’d save much typing (or mental overhead) trying to prompt a chatbot to design your api spec correctly before the codegen
These statements are brilliant.
which puts it in line with previous code-generation technologies i would imagine. I wonder which of these increased productivity the most?
- Assembly Language
- early Compilers
- databases
- graphics frameworks
- ui frameworks (windows)
- web apps
- code generators (rails scaffolding)
- genAI
The gap between "high level assembly" and "compiled language" is about as large as it gets.
Seriously. The penchant for outright ignoring user search terms, relentlessly forcing irrelevant or just plain wrong information on users, and the obnoxious UI changes on YouTube! If I'm watching a video on full screen I have explicitly made it clear that I want YouTube to only show me video! STOP BRINGING UP THE FUCKING VIDEO DESCRIPTION TO TAKE UP HALF THE SCREEN IF I TRY TO BRIEFLY SWIPE TO VIEW THE TIME OR READ A MESSAGE.
I have such deep-seated contempt for AI and it's products for just how much worse it makes people's lives.
Then again, their devices are also coming out with known fatal design flaws, like not being able to make phone calls, or the screen going black permanently.
There are still things I do in my IDE that I can’t seem to get AI to do. It’s not really close yet. I don’t doubt it could get there eventually, but I suppose I don’t believe it’s about to eat those parts of the industry.
I do anticipate a massive issue from lower skill software jobs vanishing. I don’t know what entry into the industry will look like. There will be a strange gap that’s filled by AI and some people who use it to do basic things but have no idea how it does it. They will be somewhat like data entry workers, knowing how to use a spreadsheet or word processor but having no idea how the program actually works let alone the underlying operating system. I fully expect that to happen, and I can’t properly imagine what the implications will be.
That may explain why google search has, in the past couple of months, become so unusable for me that I switched (happily) to kagi.
it's like companies paying all those todolist and tutorial apps left running on aws ec2 instances in 2007ish.
I'd be worried if i were a google investor. lol.
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.)
When dealing with a fermenting pile of technical debt? I expect very little. LLM's don't have application-wide context yet.
AI is definitely revolutionizing our field, but the same people that said that no-code tools and all of the other hype-of-the-decade technologies would make developers jobless are actually the people AI is making jobless.
Generate an opinion piece about how AI is going to make developers jobless, using AI? Less than a minute. And you don't need to maintain that article, once it's published, it's done.
While there's a tsunami of AI-generated almost-there projects coming that need to be moved to a shippable and sellable state. So I'm more afraid about the kind of work I'm going to get while still getting paid handsomely for my skills, than ever being jobless as the only guy that really understands the whole stack from top to bottom.
Everyone knows this was “made by AI” because there’s no way in hell I would ever have the time. These models might not be able to sit there and build an entire project from scratch yet, but if what you need is some help adding the next control panel page, Claude’s got your back on that.
Whenever the problem requires thinking, it horribly fails because it cannot reason (yet). So unless this is also true for google devs, I cannot see that 25% number.
Is Google out there monitoring the IDE activity of every engineer, logging the amount of code created, by what, lines, characters, and how it was generated? Dubious.
Maybe my situation is unusual; I haven't written all that much code at Google lately, but what I do write is pretty tied to specific details of the program and the AI auto completion is just not that useful. Sometimes it auto completes a method signature correctly, but it never gets the body right (or even particularly close).
And it routinely making up methods or fields on objects I want to use is anti productive.
In that case those 25% are probably the very same 25% that were automatically generated by LTP based auto-completion.
1. Paste in my actual code.
2. Prompt: Write unit tests, test tables. Include scenarios: A, B, C, D, E. Include all other scenarios I left out, isolate suggestions for review.
I used to spend the majority of the coding time writing unit tests and mocking test data, now it's more like 10%.
The AI is fine, but every time it makes a little mistake that I have to correct it really breaks my flow. I might type a lot more boilerplate without it but I get better flow and overall that saves me time with less mistakes.
Some say „this is mere tab completion“, some say „it won’t replace the senior engineer.“
I can remember how many fiercely argued 2 years ago that GenAI and Copilot are producing garbage. But here we are: These systems improve the workflow of creating / editing code enormously. You seniors might not be affected, but there are endless many scenarios where it replaces the junior who‘d write code to transform data, write scripts, write one-off scripts, or even write boilerplate, test code and what not.
And this is only after a short time. I cannot even imagine what we‘ll have ten years from now where we can propably have much larger context windows where the system can „unterstand“ the whole code base, not just parts.
I am sorry for low level engineering jobs, but I am super exited as well.
With GebAI I have been writing super complex Elisp code to automate workflow in Emacs, or VBA scripts in Excel, or Bash scripts I wouldn’t have otherwise been able to write, or JavaScript, or quickly write Python code to solve very tricky problems (and I am very high level in Python), or even React code for web apps for my personal use.
The future looks exiting to me.
Google, and really, the whole financial machine has a vested interest playing up the potential of AI. Unfortunate that it isn’t being given time to grow organically.
Financial incentives at large companies are not aligned with low volumes of code. There are no rewards for less code. People get rewarded for another bullshit framework to slap on their resume. Box me in, no, cube me in to a morass of a thick ingress layer, that uses 1/8th of my CPU.
Claude 3.5-sonnet (latest) is barely able to stay coherent on 500 LOC files, and easily gets tripped up when there are several files in the same directory.
I have tried similarly with o1-preview and 4o, and gemini pro...
If google is using a 5M token context window LLM with 100k+ token-output trained on all the code that is not public... then I can believe this claim.
This just goes to show how critical of an issue this is that these models are behind closed doors.
His position seems secure despite these missteps, which highlights an interesting double standard: there appears to be far more tolerance for strategic failures at the CEO level compared to the rigorous performance standards expected of engineering staff.
NO! False. I can confirm they are not. I've known of several major obvious unfixed bugs/flaws in Google apps for years. and in the last year or so especially theres been an explosion in the number of head-scratching, jaw-dropping fails and UX anti-patterns in their code. GMail, Search, Maps and Android are now riddled with them.
on Sundar Pichai's watch he's been devolving Google to be yet another Microsoft type in terms of quality, care and taste.
My conclusion is that we are at the first wave of a split between those who use LLMs to augment their abilities and knowledge, and those who delay. In cyberpunk terminally, it's aug-tech, not real AGI. (and the lesser ones code abilities and simpler the task, the more benefit, it's an accelerator)
What missing is that code being written by AI may have less of an impact than dataset that are developed or refined by AI. Consider examples like a utility function's coefficients, or the weights of a model.
As these are aggressively tuned using ML feedback, they'll influence far more systems than raw code.
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.
I will be curious to see if it has any impact positive or negative over a couple of years.
Will the code be more secure since the AI does not make the mistakes humans do?
Or will the code, not well enough understood by the employees, exposes exploits that would not be there?
Will it change average up time?
More lines == more shit to maintain. Complex lines == the shit is unmanageable.
But wall street investors love simplistic narratives such as More X == More revenue. So here we are. Pretty clever marketing imo.
Search Copy-Paste as a Service is hiding a deeper issue.
Alphabet ($GOOG) 2024 Q3 earnings release
How do they know this? At face value, it sounds like alot, but it only says "new code generated". Nothing about code making it into source control or production, or even which parts of googles vast business units.
For all we know, this could be the result of some internal poll "Tell us if you've been using Goose recently" or some marketing analytics on the Goose "Generate" button.
It's puff piece to put Google back in the lime light, and everyone is lapping it up.
:)
If this stuff really works as well as these companies claim it does, wouldn’t their entire workforce excitedly be using these tools already?
Is that a good thing though? We should work and making code small and easy to manage without AI tools.
That's not that much...
> New tool bypasses Google Chrome’s new cookie encryption system