Antigravity: My Approach to Deliver the Most Assured Value for the Least Money

As I'm not a professional developer but a guy who needs to use automation to get things done, I follow one main rule: keep it simple. Overengineering hurts. I use the Pareto rule—spend 20% of the effort to get 80% of the result. When I use AI agents like Antigravity, my goal is not to let the AI write complex code that no one can read. My goal is to build simple, secure features fast. At the same time, I control costs by saving tokens. Here is the exact workflow I use. _You can listen a podcast generated based on this publication (thanks [NotebookLM](https://notebooklm.google/)):_ {% youtube DkDfPMzXDXk %} ## The Token Economy Strategy LLM tokens cost money. Using a smart, expensive model just to fix code spaces is not worth the cost. I change models based on how hard the task is. - **High-Tier Models:** They are for the big tasks: planning architecture, writing complex business logic, checking security, and counting cloud costs. - **Low-Tier Models:** These folks are for simple tasks: fixing syntax errors, aligning code to Pylint, and writing standard code pieces.  ## Task Decomposition & In-Repo Architecture Large prompts can break LLMs. If a prompt has too much text, the AI gets confused and wastes tokens. To stop this, I break every task into small, separate pieces so the AI only sees what it needs. I store all architecture plans and tasks inside the code repository (for example, `./docs`). This keeps the instructions very close to the code for the AI. Every task I write uses this strict four-part structure: 1. **Idea:** The main business or tech goal. *Why it matters:* It proves the task is useful before I spend tokens for delivering a code to review. 2. **Plan:** The technical blueprint. *Why it matters:* It locks down the plan, keeps security high, and stops the AI from inventing bad solutions. 3. **What Was Done:** A short log of the work. *Why it matters:* It gives future AI tasks a quick summary, so the AI does not have to read every code file again. 4. **Debt:** A list of any technical shortcuts or "crutches" used to save time. *Why it matters:* Hidden debt ruins the project. **Important: My custom Quality Gate checks this section. If it finds unapproved shortcuts in the code, it blocks the release completely.** ## System Instructions for the AI To keep the AI agent aligned with the goals, I pass strict system instructions on every run. It never lets the model guess my coding standards. Here are the core rules enforced: - **No Crutches:** Any "crutch" or technical shortcut must be approved by me. Then, the AI must document it as technical debt in the project files. - **No Inventing Wheels:** I try hard to avoid this. If a working approach already exists in another project, the AI reuses it. - **Learn from the Past:** When building a new service, the AI must check the old tech debt to avoid repeating past mistakes. - **Simple Code Only:** The code structure should just use standard classes. I avoid "genius-level" extreme one-line code tricks or overwhelming structures. - **Maintainability First:** A middle-level, part-time developer must be able to read and maintain the code. ## The Core Workflow Every feature goes through a step-by-step process. I'm trying to keep security and simplicity as the main focus at each step. ### 1. Plan & The Plan Review *Using a High-Tier Model.* - **Plan:** Defining the code structure, the security rules, the cost limits, etc. I make sure not to add to old technical debt. - **Review:** I look at the plan with a "fresh eye." I do not start coding until the plan is clear with main code snippets planned. ### 2. Code & Code Review *Using a Low or Mid-Tier Model for code and Mid or High-Tier Model for review.* - **Code:** Implement the code exactly as planned. Use clear classes and avoid complex, one-line code tricks. A middle-level developer must be able to maintain it easily. - **Review:** Make sure the code matches the rest of the project. I prefer another "person" to check it before I call it done.  ### 3. Lint & Quality Gate *Using Free External Tools & A Custom Nanoservice.* - **Lint:** I do not pay LLMs to fix missing spaces. I use free tools like `autopep8`, `ruff`, and `pylint` to save tokens. - **Quality Gate:** I built a simple nanoservice using the Vertex API. It checks the code changes against the `main` branch. It works like an automatic review from the CTO, CISO, and CFO. It checks every line for good architecture, proper security access, and cost impact before the code goes to production. **Why is it so important?** The Quality Gate is not overwhelmed by the full chat history inside the IDE. Its "fresh eye" often finds architectural and coding flaws that were missed by the IDE models, even after 6 to 9 rounds of review.   ## The Bottom Line AI coding is not magic. In my experience, it requires a strict testing gate, smart model swapping, and simple design. By owning the process and letting the AI act as a typist, it is possible to ship secure code fast. I share this approach for an open discussion on how we can build better automation.