Google Antigravity, so much wow

The internet of AI influencers is in awe, Google got out the killer agentic AI development tool, they destroyed all competition, yada yada, let’s give it a run right? I downloaded this VSCode-based editor, decided on a toy project, made a copy because I didn’t trust it with my Git, and here we go.

First thing I thought to ask the Antigravity agent to switch the backend queries (a class with 3 functions) from DynamoDB to PostgreSQL. The whole IDE is confusing, you must give approvals in the chat window, also in the approvals popup (which takes any random click as a yes) and in the automatic actions popup. They can come up sometimes all three and you’ll never know which does what. Maybe also because of this, it messed up the whole project when updating the usage of the DB queries class, with no way to revert than fetching it anew from git (for me, deleting and copying it over again). So much for a bigger refactoring.

After reverting, I thought of something smaller: to download a Java 21 and upgrade the project pom (it was Java 17). Sounds basic, it would have taken me maybe 15 minutes to google search, unpack, update the path and the pom. Half an hour later, after watching the IDE asking about hundred approvals, we’re still not there – it got stuck ugly with the maven wrapper. In the end I had to do it myself, eh. Ah and I also reached the Sonnet quota limit after all this nonsense, let’s switch to Gemini Pro.

Now I asked it to add the PostgreSQL dependencies to maven. It explained me what it’s gonna do, then stopped. I had to tell it to do it again. I wish it would ask when it actually has many changes (see above) not for adding exactly 6 lines. Oh well. And then asked again for confirmation, namely two buttons “accept” and “accept all” at the same time, what the heck is this. Only one of them gets the agent moving, and it’s not the one you’d think. So it run maven clean about hundred times to verify the verification of the verificator, keeping me in front of the terminal but basically doing nothing of use. It only changed the application.yml about ten times from what I can tell (it’s confusing to have so many console outputs on top of each other). And this just never ends, there’s no moment where it says “ok I’m done, what now” it just thinks and tries and verifies and requires input and runs around in circles. At this point the project doesn’t even build anymore and I’m one hour in. And lo, it exceeded the quota again, so I’m gonna work by hand like I’m used to, any maybe ask ChatGPT 5.1 for advice without losing my nerves with “agentic” anymore tonight.

What do I think about Google Antigravity? Maybe it will get useful later, but what I must say is that I’m still (or even more) fed up with you AI influencer bros and your “ooh I created 13k lines of code” nonsense.

PS Did I mention the agent crashing because an internal error? It happens a lot, but at least you can ask it to retry the last action and it will do it – it never crashed twice on a same prompt (yet?).

About building up skills

This post “Avoiding skill atrophy in the age of AI” (please read it!) of Addy Osmani got me thinking a bit, and it’s a topic I had in mind for quite some time. I know I’m digressing from the mentioned article, I know, but there it is.

Skill atrophy is not really a topic for me, because jumping between so many technologies I never had the opportunity to become a guru, basically to stick long enough to one to finally know it inside out. Not much to atrophy then. So rereading the same documents every two years was never fun, until AI helped me refresh those points quicker. Because all those years, although not allowing me to memorize all the API calls or environment variables, left behind patterns and memories of “how stuff can be done,” thus a certain capability to search the internet, consult the teammates – or lately prompt some AI – for the many missing puzzle pieces. But this is what I call “seniority.”

The actual thinking on AI-supported programming is that the seniors will become 10x with AI, possibly even more. And midrange will become finally really productive, cool as well. But how about juniors? How will they become seniors? How will they get the critical skills required to understand a solution, or image, or document? If all they learn is how to prompt an AI, then I can assume they will be rather sooner than later replaced by an AI-prompter AI. I can see no career development plan possible anymore to take one from junior to senior software developer, engineer, architect, you name it. Yes in theory there is, but which organization is gonna finance it? Does that mean there’s no need for seniors anymore? Right now the consensus seems to be they’re still essential, but how about the future? It definitely looks like we should think, or plan, for a future without understanding – and I’m not sure it’s a good thing…

About “vibe coding”

I hesitated so much to comment on the newest fad called vibe coding. However, when I read this post “Vibe coding vs Reality” I realized I’m far from being alone in this boat – the boat of mistrust. Do I need a long text for making my point? I don’t, I subscribe wholeheartedly to the sentiment in the post.

That’s because I took Cursor for a short ride myself. Why wouldn’t I ride the same bandwagon? Unless it’s hype, of course. And what did I get? I had this Java Maven project, and turned out that Cursor is not even able to rename a class. It will either rename just the class but not the file, and then when reprompted it will create with the new name a new empty file. Twice. Now how on Earth should I trust it to do anything with my project? Hacker News folks were dismissive “haha Java” or such, so I don’t know whether Cursor was only trained in the frontend framework du jour (I lost track of those sorry) or those folks don’t actually care about real world applications. But for me it meant uninstalling it and building a serious dose of mistrust in magical AI solutions.

But next year? We will see next year.

About “Developer philosophy”

I like to read such posts slowly and compare them with my experiences. This time it’s “Developer philosophy” by qntm.

An even more interesting question is: are there still gonna be junior developers, in the age of AI? According to just any press release, no – actually not even seniors. But let’s say you still need a senior vetting the AI code before letting it loose. When they retire, what? Or when AI gets so reliable, what? I talked to young people (I’m far from that age) and they sounded really worried about their career chances, and while I tried to answer something comforting, I actually quite shared their point: once it gets smarter and much cheaper, it’s bye for all of us. If you don’t agree, remember offshoring. And no, outsourcing/offshoring only gets reverted because the promise of smart/cheap got lost on the way.

Anyway, I totally agree that the conditions bringing a rewrite on the table are nothing that came over night. But. They also mean a complacent organizational culture – which actually wouldn’t want to do the rewrite either. So only when somebody new joins, the need for such a kick becomes apparent. Well, I still think it’s often not too late and the accrued gaps can be still addressed one by one. Or at least that’s how it worked for me in many projects. Also because rewriting is a big project, and big projects are usually pushing the timeline, and when that happens “less important” things get skipped and that’s how you land in a year’s time with a debt of missing or sloppy pieces of code – basically working against the very reason you started the rewrite in the first place.

Too bad the blog post is running out of breath from now on, so I’ll just point some thoughts to the short remaining paragraphs:

• I’m all for automating good practices, but that step should happen only when you have the buy-in for said best practices. If not ${everybody_important} is in the same boat, you can kiss your best practice goodbye. Replace with your own values of everybody_important.
• edge cases come together with the 90-10 rule, or 80-20 whatever you like. They will be more often than not noticed only late, so expect the rule to apply exactly then.
• you will get the opportunity to write it simpler only at the end, so don’t count on your rewrite to be simpler, or at least not from the start. Maybe towards the end, depending on the remaining time and enthusiasm.
• testable and correct code… wouldn’t we want it all? Anything which looks testable and correct can bite you back, so good luck with this. But, try at least.

APoSD vs Clean Code, a debate

Welcome to the next fight debate, Robert Martin aka Uncle Bob (Clean Code) vs John Ousterhout (A philosophy of software design) arguing over software design, an interesting text even if you didn’t read their seminal books. Here’s the link to the debate, on Github.

They are talking basically about two different concerns: the cognitive load and the separation of concerns, and jumping from the one to another. While John truthfully argues that there’s a risk to over-engineer and over-separate the code, Bob underlines that the end justifies the mans and the load would be smaller. While they are both right in their way, they are both overdoing it in the same way. The wrap-up helps seeing the similarity and differences in the two approaches. So find your own answer in the middle: make small units of code, and make them do one thing (whatever you define as thing). And, don’t overdo it in either direction just for the sake of ideology – here come your years of experience into play, hopefully.

Same with comments: meaningful naming helps a long way, but remember the joke of Leon Bambrick: “There are 2 hard problems in computer science: cache invalidation, naming things, and off-by-1 errors.” Yup, failing naming you’ll have to resort to comments, so use them. Not “here be tigers” but a real explanation why you put a wait() here. Future you will appreciate, even if the comment is difficult to grasp it’s still better than nothing. Oh, and don’t forget to update the comments when you update the code – comments are no holy book. Also change the function/variable names whenever they changed meaning!

About TDD I don’t have a strong opinion, even after reading this debate. It certainly helps to have those tests beforehand, I give that. But I’ve never (yes, never) been in a situation where the problem was properly defined from the start, so tests and code had always to grow together over time. So, again do both, tests and higher level design. Today I’m actually somewhere where I rather appreciate a certain amount of integration tests (higher level, so more in John’s direction) but I still stand to be corrected by real world projects and setups. Maybe also because I’m seldom writing mathematical or library code?