The Anti-Antigravity

Francisco — Wed, 20 May 2026 14:47:46 +0000

The Antigravity Paradox

Google’s rollout of Antigravity 2.0 marks a massive paradigm shift in the agentic tool space. Officially launched as a standalone desktop application, Antigravity 2.0 strips away the traditional coding environment to deliver a purely "agent-first" experience powered by the latest Gemini models. It introduces features like dynamic subagents, asynchronous task management, and other stuff. However, by packing these sweeping platform changes under the flagship "2.0" label, Google has inadvertently sparked a wave of confusion across the developers.

Antigravity 2.0 is Not the Antigravity IDE

For power users expecting an upgraded development environment, Antigravity 2.0 takes things in a completely new direction. This is not a traditional coding companion tool. In a deliberate move to transition away from local workspace management, Google has completely omitted fundamental developer primitives. In Antigravity 2.0, you cannot:

• Access a file explorer to navigate directories.
• Open a native terminal to execute local commands.
• Manage extensions to customize your environment.
• Utilize Git control for version tracking and branching.

Rather than assisting you as you write code, the interface acts as an orchestrator for high-level tasks, prioritizing "vibe coding" and broad knowledge work over engineering.

The New "Google AI Studio" for the Masses

To understand Google’s true intent, it helps to look at Antigravity 2.0 not as a code editor, but as a successor to Google AI Studio. Google AI Studio has long served as a flexible prototyping environment where developers and non-developers alike can experiment with prompts, tweak model parameters, and test system instructions without being tethered to a local codebase.
Antigravity 2.0 takes that exact philosophy and wraps it in a consumer-facing desktop app. By decoupling the agent from a specific repository and organizing work into multi-folder "projects," Google is targeting a non-developer audience—enterprises, product managers, and knowledge workers—who want to orchestrate automated workflows via natural language without the daunting complexity of an IDE.

The "Dual-Wielding" Dilemma: A Promised Future?

Google’s official recommendation for engineers is to "dual-wield" both applications side-by-side, using the IDE for development and 2.0 for background automation. But this raises a glaring question: Who actually codes with two IDE applications open at the same time? Swapping windows between two heavily branded, similarly named apps just to separate your terminal from your agent manager is a clunky user experience.
Furthermore, skepticism is brewing over whether Google will keep its promise to support both. Google has already announced that an upcoming release will remove the Agent Manager surface from the Antigravity IDE to make it a purely developer-focused editor. History shows that maintaining two parallel products under the same brand name is rarely a permanent strategy. For a community that adopted the original Antigravity for its seamless, all-in-one agentic integration, splitting the ecosystem feels less like a step forward and more like a platform paradox.

The Bottom Line

The paradox isn't clever naming — it's the fundamental contradiction between what was promised (a better Antigravity) and what was actually delivered (a different kind of product wearing the same name).

Source: Google Antigravity Blog – Introducing Google Antigravity 2.0

The Clean Coder: Opinion

Francisco — Sat, 13 Dec 2025 09:45:34 +0000

Where to start? Well my friend borrowed the book, and I thought it was the Clean Code book from the one and only Robert C. Martin.

When I realized that this book was more about the ethics of programming (The Clean Coder, NOT Clean Code), I was a bit disappointed. However, soon after I read the Preface it became clear to me that this book was a gem.

Imagining that you found this article just to know if the book is something for you, or just for the sake of refreshing some takeaways from the book. I decided not to paste here all the hot takes from the book, but to relate some of my experiences as a developer with some excerpts from the book.

Perhaps you can also associate some of these with your experiences or get curious about what else is "hidden" in the book and give it a read.

Without further ado, here are my key excerpts...

Work Ethic

“You should plan working 60 hours a week. The first 40 hours are for your employer. This time you should just spend on your employer’s problems, not on your problems. The remaining 20 hours are for you. during this remaining 20 hours you should be reading, practicing, learning, and otherwise enhancing your career.”

Like the author implies, we have 168 hours in a week. We should be using 56 hours for sleeping + 40 hours for our jobs + 20 hours for self-development (have fun), which leaves us with 52 hours for everything else.

The key here is not to get stressed in those 20 hours that we dedicate to our career; it is to do what we are passionate about and keep us motivated about what we do or want to do (I know it is easier to say it than to do it).

Know Your Domain

“When starting a project in a new domain, read a book or two on the topic. Interview your Customer and users about the foundation and basics of the domain. Spend some time with the experts, and try to understand their principles and values.”

I consider this to be a hard one. As developers we join companies to develop code because we have fun at it. Of course, we would like to work for the company that we have always dreamed of, but regrettably it is not always the case that we can get the job at such companies. Thus, reading books about the main topics of the company where you land your job might result boring or difficulty. Nevertheless, I agree with Robert! You were not only hired to code well but also because your interest in bringing value to the company, and for that it is really relevant to get closer to the products/services your company offers. This is summing up your points as a professional.

Saying No - Trying

“By promising to try you are promising to change your plans. After all, the plans you had were insufficient. By promising to try, you are saying that you have a new plan. What is the new plan? What change will you make to your behavior? what different things are you going to do because new you are “trying”?”

The writer implies that by saying that we are going to “try” but not having a new plan on how to achieve the goal, so we would be basically lying. We do this in order to avoid confrontation. This will just delay the uncomfortable conversation when it is clear for everyone that the goal(s) will not be achieved on time.

Saying Yes - A Language of Commitment

By Roy Osherove

Say. Mean. Do.

There are three parts to making a commitment.

You say you’ll do it.

You mean it.

You actually do it.

Recognizing the language of commitment can help us determine on time whether some estimations, deadlines, or face-to-face communications are on the line (at risk). Although I personally think that depending on your position at the company, this could lead to micromanagement. Please be careful with that 🤓.

Coding - Flow Zone & Writer's Block

Do not get fooled by trying to get into the zone or hyper-focus mode. This can cause frustrations and does not help you to work in a team.

Find a pair partner, this will help you to get doubts cleared and melt away where you were blocked.

I felt like the author was sending me a written letter as I read this one. Coding together with Hans Zimmer, Ludovico Einaudi, and others has been one of my methods to get into the so-called "zone", and yes I think the author might be right. Still I find it super useful to listen to certain kinds of music to at least feel that I focus on something. Once I have listened to one or two songs, then I can continue working like I charm.

Practicing - Practice Ethics

“Professional programmers practice on their own time. It is not your employer’s job to help you keep your skills sharp for you. It is not your employer’s job to help you keep your resume tuned. Patience does not pay doctors to practice sutures. Football fans do not (usually) pay to see players run through tires. Concert-goers do not pay to hear musicians play scales. And employers of programmers don’t have to pay you for your practice time.”

This is a bold one. Here I had to learn to differentiate the blurry line between practicing and learning to get something done at work. After I read this excerpt from the book I was shocked by the examples/analogies Martin gave us. I think if you are facing issues getting started with your 20 hours a week to enhance your skills outside of your work schedule, this excerpt can be harsh but motivational.

Time Management - Stand-Up Meetings & Focus-Manna

“…Each participant takes a turn to answer three questions:

What did I do yesterday?
What am i going to do today?
What’s in my way?

That is all. Each question should require no more than 20 seconds, …”

This is something that personally speaking results in really difficult for me. Especially on days when a lot of things are happening. However, trying to get better at that, I have decided to say the least possible, and if someone is interested in more details, I try to get on another short-call with that person after the stand-up session.

Regarding Focus-Manna, I think we all have been in that case where we feel so close to solving a problem or completing a feature that we do not feel like we deserve a pause. That is completely wrong! I have tried POMODORO many times, but in general what works best for me is to work in a desk that you can adjust its height, and at some point my body will ask me to change my current position, and that is when I take my short break to take some fresh air at the window and disconnect for a moment. Nevertheless, I am curious how others deal with this, please leave me a comment with your solution to recharge your batteries.

Collaboration

“I learned something that day. It is good to be passionate about what we do. But it's also good to keep your eye on the goals of the people who pay you.”

I think this one speaks for itself...

But just as a reminder that we should distinguish our practice time from the value we create during our work schedule.

Mentoring, Apprenticeship, and Craftsmanship

“School can teach the theory of computer programming. But school does not, and cannot teach the discipline, practice, and skill of being a craftsman. Those things are acquired through years of personal tutelage and mentoring. It is time for those of us in the software industry to face the fact that building the next batch of software developers to maturity will fail to us, not to the universities. It is time for us to adopt a program of apprenticeship, internship, and long-term guidance.”

Reading this, I got a reminder of what some companies I worked for did to push us (developers) to share the tools and hacks we use to improve our work. Of course that was no internship but after such session you can always ask further questions to the presenter and/or get motivated to share some content or ask for some of the things that you think help you and your team to deliver more/better value to the company.

Tooling - UML/MDA

“We are detail managers. Although there are enough Model Driven Architecture (MDA) like Power Automate, it is still not possible to replace the developers for tools that take care of programming since a higher level of abstraction misses the nuances that we as developers can bring with textual languages.”

I think of vibe coding as a good example for this. Although you can ask certain agents to build you the application you want, there is still too much overhead to develop a complex application with it. Of course you can get a simple application on a whim, but you also (nowadays) need to spent a good amount of time setting up the guardrails with the agents to get a meaningful and qualitative output (although this is not a must).

Thank you for getting until this point. I appreciate any feedback on my first post on the portal, and I hope you have got some insights.

Forem: Francisco