Back to All Articles

My Real AI Coding Workflow: Splitting Speed with Antigravity and Deep Logic with Codex (Sol 5.6)

My Real AI Coding Workflow: Splitting Speed with Antigravity and Deep Logic with Codex (Sol 5.6)

Back in March, I published a post about leaving WordPress behind to build faster with Gemini-assisted workflows. At the time, the native speed and massive context window felt like a substantial leap over my old development routines.

However, as the weeks went by and initial project prototypes grew into production-grade systems, everyday engineering reality set in. I quickly learned that when it comes to AI-assisted software development, there is no single "do-it-all" silver bullet.

Here is an honest, unvarnished look at how my actual daily coding setup looks today: why I use Antigravity and Codex completely separately, and how I split tasks based on genuine complexity.

Why I Couldn't Rely Solely on Gemini

Gemini was useful for kicking off new ideas and scaffolding early prototypes. But once a codebase expands into thousands of lines of TypeScript—where the job shifts from writing brand-new files to carefully refactoring sensitive, interconnected business logic—the model's limitations quickly showed:

  • Lazy diffs and omitted lines: On larger refactorings, it frequently left placeholders like // ... rest of implementation unchanged ..., or silently skipped critical error boundaries and edge cases.
  • Loose typing under pressure: When dealing with trickier generic constraints or nested data structures, it tended to compromise on type strictness, falling back to any instead of resolving the proper interface contracts.
  • Superficial patches for deep bugs: When subtle asynchronous race conditions or hydration issues popped up, it often suggested generic workarounds (like adding redundant useEffect triggers or arbitrary timeouts) rather than helping diagnose the root cause in the underlying state machine.

It became evident that for genuinely complex, high-stakes engineering work, I needed a much more disciplined tool.

The Two Distinct Tracks: Antigravity vs. Codex

Contrary to popular hype, I don't run some elaborate, unified all-in-one system. I use Antigravity and Codex as two completely separate applications, reaching for whichever tool fits the specific challenge at hand.

┌────────────────────────────────────────────────────────────────────────┐
│                         PRACTICAL DIVISION OF WORK                     │
├───────────────────────┬────────────────────────────────────────────────┤
│  Fast, straightforward tasks │ Google Antigravity (speed & daily routine) │
│  Complex, architecture-heavy │ Codex + Sol 5.6 model (precision & logic) │
│  Brainstorming & concepts    │ ChatGPT (sanity checks before coding)     │
└───────────────────────┴────────────────────────────────────────────────┘

1. Google Antigravity: When Speed and Momentum Matter

I still use Antigravity every single day, specifically for its raw speed on simpler, day-to-day development tasks:

  • Quick UI adjustments, styling tweaks, and button states.
  • Hooking up straightforward API endpoints and data display components.
  • Scaffolding well-defined, boilerplate components.
  • Routine bug fixes and minor iterative feature additions.

When I know exactly what needs to be built and the problem doesn't require multi-step reasoning, waiting on a slower, heavy-thinking model just breaks flow state. Antigravity is responsive, convenient, and gets straightforward jobs done fast without unnecessary overhead.

2. Codex with Sol 5.6: The Heavy Artillery for Complex Logic

When a task is genuinely difficult, I open Codex, running the Sol 5.6 model. This is the setup I reserve for heavy lifting where precision cannot be compromised:

  • Multi-file architectural refactoring: Modifying shared interfaces across several interconnected files without breaking type contracts or leaving loose ends.
  • Complex state machines & asynchronous flows: Scenarios where client-side interactions and server-side state need rock-solid synchronization and comprehensive failure recovery.
  • Relational schemas and core business rules: Ensuring every field constraint, foreign key, and transaction boundary is handled accurately.

The Sol 5.6 model does not rush. It may take a little longer to reason through the prompt, but it doesn't cut corners: it doesn't drop lines, it doesn't invent non-existent APIs, and it delivers exact, reliable code that respects the existing codebase.

3. ChatGPT as the Sounding Board

Before opening either tool for a major feature, I often spend ten minutes in ChatGPT discussing the architectural blueprint. I don't use it to generate the final code, but rather to pressure-test the underlying concept:

  • How should the database schema look to support future edge cases?
  • What potential failure modes exist when integrating a third-party webhook?

Talking through the logic upfront clarifies the architecture before I write or refactor a single file.

The Takeaway

It is easy to get caught up in exaggerated claims about AI development tools. In the trenches of building real software, success isn't about finding one magical tool to solve everything. It is about understanding what each tool does best and using them accordingly:

  • Antigravity is great for fast-paced, straightforward routine tasks where keeping momentum is priority number one.
  • Codex (with Sol 5.6) is where I turn when tasks get genuinely complicated and precision is non-negotiable.

Two distinct tools, two distinct roles—and using each where it actually shines gives me the best balance of speed and reliability in my daily work.