Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Google Antigravity

antigravity.google

Post reply on HN
Print view View original

981–990 of 1001 posts

Re: Google Antigravity

#981

Post by theshrike79 »

NitpickLawyer wrote: post #315
crazygringo wrote: post #152

Earlier quoted context omitted.

You can ask agents to identify and remove cruft. You can ask an agent why something is breaking -- to hypothesize potential causes and test them for validity. If you don't understand how something is built, you can ask the agent to give you an overview of the architecture and then dive into whatever part you want to explore more. And it's not like any of your criticisms don't apply to human teams. They also let cruft…

> you can ask the agent to give you an overview of the architecture and then dive into whatever part you want to explore more. This is actually a cool use that's being explored more and more. I first saw it in the wiki thing from the devin people, and now google released one as well.

There's a cool demo from Anthropic: https://www.youtube.com/watch?v=OwMu0pyYZBc

Where they use Claude to analyse an old (demo) COBOL application.

And it understands the context of the files, decrypts the process and even draws graphs to the documentation it creates.

I wish I had this 20 years ago when I was consulting and had to jump into really funky client codebases with zero documentation and everything on fire.

Re: Google Antigravity

#982

Post by diegof79 »

w3news wrote: post #874
diegof79 wrote: post #432

Earlier quoted context omitted.

You just described Eclipse RCP. The issue with Eclipse and that approach is the complexity of mixing plugins to do everything, which kills the UX. When VSCode started, the differentiator from Atom and Eclipse was that the extension points were intentionally limited to optimize the user experience. But with the introduction of Copilot that wasn’t enough, hence the amount of forks. I think that the Zed approach of havi…

Microsoft just fork Atom, and Atom had already good and a lot of extensions. Before Microsoft buy Github, there was no reason to switch to VSCode instead of Atom. When Microsoft buy Github, it received Atom from the Github team, and Microsoft stops the development of Atom. VSCode was just Atom with the Microsoft brand, and some little tweaks from Microsoft, never a game changer compared to Atom, like Atom was in it's…

I guess we have different perspectives and information about the “rise” of VSCode.

I was an Atom user. Even before the acquisition of GitHub the major feature of VSCode was its speed and TS integration. AFAIK, the only common part between Atom and VSCode is Electron. Other than that, VSCode started with a different codebase based on TypeScript, while Atom was originally written in CoffeeScript.

Multiple design decisions helped VSCode to thrive (btw Erich Gamma was also part of Eclipse):

- The creation of the LSP. Each release of VSCode is also tied to TypeScript releases and improvements. There is a lot of collaboration between the two teams. That gave VSCode the best support for TS and JS. I used Atom and WebStorm regularly when VSCode came out, and VSCode auto-complete and TS support were orders of magnitude better. Everybody caught up since then, but I guess many users like me switched because of that.

- Unlike Atom, VSCode was designed with web integration in mind. A lot of sites started to use Monaco for code editing, and a lot of web-based IDEs use parts of it (CodeSandbox, StackBlitz, etc).

- Gradual rollout of plugin integration. While Atom has the philosophy of everything is pluggable, VSCode was intentionally limited. Which was a good thing given the poor loading performance of Atom.

By the time MS acquired GitHub, Atom usage was already in decline.

* Note: my side of the history, comes from my experience of working in a company that did a custom Eclipse IDE. We evaluated Atom and then VSCode as alternatives to “modernize” our IDE. So I have experience in looking at both Atom and VSCode code bases: they are totally different. Also, the main problem with VSCode for us was the limited extensibility.

Re: Google Antigravity

#984

Post by Topfi »

theshrike79 wrote: post #979
onion2k wrote: post #745

Earlier quoted context omitted.

So the error messaging is wrong, giving the user the impression it's their fault for not paying. I think that's worse..

It's both. Free tier users get to use what's left over from Google's capacity. They pay with their data, Google uses their inputs for training. Paid tier users pay with money, Google doesn't use their inputs. They get priority when capacity is running out (like right after a launch as happened here).

There is no paid tier on Antigravity currently.

Re: Google Antigravity

#985

Post by etruong42 »

gopher_space wrote: post #964
etruong42 wrote: post #957

Earlier quoted context omitted.

Spot on. I would suggest a slightly different framing where the antagonist isn't really the "approving" teams but "leaders" who all want a seat at the table and exercise their authority lest their authority muscles atrophy. Since they're not part of the development, unless they object to something, would they really have any impact or leadership? I always laugh-cry with whomever I'm sitting next to whenever launch an…

Involving everyone who shows up to meetings is a great way to move forward and/or trim down attendees. Management who enjoys getting their brain picked or homework assignments are always welcome.

That's presuming a healthy culture. In an unhealthy culture, some people will feel pressure to uphold some comment that someone "senior" made offhand in a meeting several months ago, even if that leader is no longer attending project meetings. The people who report to this leader may otherwise receive blowback if the "decision" their leader made is not being upheld, whether such a leader recalls their several-month-old decision correctly or not, in the case they recall it at all. I have found it frustratingly-more-common-than-I-would-like where people, including leaders, retroactively adjust their past decisions so that they claim "I-told-you-so" and "you-should-have-done-what-I-said".

In response to your comment, yes, I would largely be in favor of moving forward only with whatever is said in the relevant meetings with the given attendees of a meeting. That assumes a reasonably healthy culture where these meetings are scheduled in good faith reasonable times for all relevant stakeholders.

Re: Google Antigravity

#986

Post by jatora »

absoluteunit1 wrote: post #928
jatora wrote: post #722

Earlier quoted context omitted.

it is absolutely poor skill, or disengenuous at best, for any coder to claim AI tools slow them down lol.

I didn’t make this claim. I also have a personal rule that I will try something for at least 4 months actively before making my decision about it (programming language, new tools, or in this case AI assisted coding) I made the claim that in my area of expertise - I have found that *most of the time it is faster to write something myself than I write out really detailed md file / prompt. It becomes more tedious to exp…

claim that i claimed you claimed: "for any coder to claim AI tools slow them down"

---

claim you made: "One thing I’ve noticed though that actually coding (without the use of AI; maybe a bit of tab auto-complete) is that I’m actually way faster when working in my domain than I am when using AI tools."

---

You did make that claim but I'm aware my approach would bring the defensiveness out of anyone :P

Re: Google Antigravity

#987

Post by jatora »

recitedropper wrote: post #734
jatora wrote: post #722

Earlier quoted context omitted.

it is absolutely poor skill, or disengenuous at best, for any coder to claim AI tools slow them down lol.

For seasoned maintainers of open source repos, there is explicit evidence it does slow them down, even when they think it sped them up: https://arxiv.org/abs/2507.09089 Cue: "the tools are so much better now", "the people in the study didn't know how to use Cursor", etc. Regardless if one takes issue with this study, there are enough others of its kind to suggest skepticism regarding how much these tools really creat…

I have seen this study cited enough to have a copy paste for it. And no, there are not a bunch of other studies that have any sort of conclusive evidence to support this claim either. I have looked and would welcome any with good analysis.

"""

1. The sample is extremely narrow (16 elite open-source maintainers doing ~2-hour issues on large repos they know intimately), so any measured slowdown applies only to that sliver of work, not “developers” or “software engineering” in general.

2. The treatment is really “Cursor + Claude, often in a different IDE than participants normally use, after light onboarding,” so the result could reflect tool/UX friction or unfamiliar workflows rather than an inherent slowdown from AI assistance itself.

3. The only primary outcome is self-reported time-to-completion; there is no direct measurement of code quality, scope of work, or long-term value, so a longer duration could just mean “more or better work done,” not lower productivity.

4. With 246 issues from 16 people and substantial modeling choices (e.g., regression adjustment using forecasted times, clustering decisions), the reported ~19% slowdown is statistically fragile and heavily model-dependent, making it weak evidence for a robust, general slowdown effect.

"""

Any developer (who was a developer before March 2023) that is actively using these tools and understands the nuances of how to search the vector space (prompt) is being sped up substantially.

Re: Google Antigravity

#988

Post by pcf »

senbrow wrote: post #967
cmrdporcupine wrote: post #935

Earlier quoted context omitted.

Yep, that and (also used to work there) the motivations of the implementing teams end up getting very detached from the customer focus and product excellence because of bureaucratic incentives and procedures that reward other things. There's a lot of "shipping the org chart" -- competing internal products, turf wars over who gets to own things, who gets the glory, rather than what's fundamentally best for the custome…

Hah, that exact transition was my last project there before I decided I had had enough! The GPM team was hugely passionate about music and curating a good experience for users, but YT leadership just wanted us to "reuse existing video architecture" to the Nth degree when we merged into the YT org. After literally years of negotiations you got... what YTM is. Many of the original GPM team members left before the trans…

That is so sad to hear. I absolutely loved Google Play Music – especially features like saving e.g. an online Universal Music release to my "archive" and then for myself being able to actually RENAME TRACKS with e.g. wrong metadata.

That and being able to mix my own uploaded tracks with online music releases into a curated collection almost made it a viable contender to my local iTunes collection.

And then... they just removed it forever. Bastards.

Re: Google Antigravity

#990

Post by cmrdporcupine »

pcf wrote: post #988
senbrow wrote: post #967

Earlier quoted context omitted.

Hah, that exact transition was my last project there before I decided I had had enough! The GPM team was hugely passionate about music and curating a good experience for users, but YT leadership just wanted us to "reuse existing video architecture" to the Nth degree when we merged into the YT org. After literally years of negotiations you got... what YTM is. Many of the original GPM team members left before the trans…

That is so sad to hear. I absolutely loved Google Play Music – especially features like saving e.g. an online Universal Music release to my "archive" and then for myself being able to actually RENAME TRACKS with e.g. wrong metadata. That and being able to mix my own uploaded tracks with online music releases into a curated collection almost made it a viable contender to my local iTunes collection. And then... they ju…

Yep, YTM is/was so clearly the inferior product it's laughable. Even as a Google employee with a discount etc (I can't remember what that was, but) on these things I switched to Spotify when they dropped it.

I worked on a team that wrote software for Chromecast based devices. The YTM app didn't even support Chromecast, our own product, and their responses on bug tickets from Googlers reporting this as a problem was pretty arrogant. It was very disheartening to watch. Complete organizational dysfunction.

I think YTM has substantially improved since then, but it still has terrible recommendations, and it still bizarrely blurs between video and music content.

Google went from a company run by engineers to one run by empire-building product managers so fast, it all happened in a matter of 2-3 years.

Post reply on HN