"Antigravity made my development faster." I've written that sentence in a handful of articles myself. But after two months of picking it up every day, the thing that surprised me most wasn't the speed. It was noticing, quietly and almost in hindsight, that the way I write code had shifted into something different from what it used to be.
Today I want to put those quiet shifts on record, from the perspective of day-to-day iOS work. The convenience story lives in my other posts — here I want to focus on one question only: how did my own code actually change?
My functions got shorter
The first thing that shifted was function size. The old me was comfortable saying, "It's fine to keep a full screen's worth of logic inside a ViewController. I'll understand my intent when I reread it." I bought that reasoning.
Then I started delegating work to Antigravity, and suddenly those long functions became a source of friction. I'd point at a thirty-line method and ask, "Please fix this part," and the agent would edit unrelated sections, or subtly miss the intent.
The cause was obvious once I saw it. A human can carry context through a long function, but an AI agent gets confused when multiple responsibilities live under the same roof — it can't always tell which context it should be operating in. So I started trimming functions down to fifteen or twenty lines each, small enough to fit on one screen. And here's the funny part: they turned out to be dramatically easier for humans to read, too. What I did for the AI's sake left me with cleaner design than I had six months ago. That was the real outcome.
Comments shrank, and I invested more in names
The second shift was in how I relate to comments.
My old rule was simple: "If in doubt, leave a comment." But Antigravity reads context from function names, variable names, and type names far more than from comments. Writing // Check if the membership is expired has noticeably less effect on the agent than renaming the function to isMembershipExpired(for:asOf:).
That observation changed how I write Swift. I rewrote almost every vague signature like func check(_ user: User) -> Bool. Swift's labeled arguments let you build function names that read like English sentences. I hadn't been leaning on that properly because, in my head, "as long as I can read it myself, it's fine" had quietly become my default. Laziness disguised as independence.
What I tidied for the AI ended up helping my future self too. That realization was still vague when I wrote the Antigravity prompt engineering guide; only later, during real work, did I find the words for it.
Writing tests first stopped feeling heavy
The third shift was my relationship with tests.
The reasons I skipped tests in solo projects were always the same. "I'm alone, as long as it runs it's fine." "I'll write them when I refactor." "The spec isn't locked down yet." The excuses are endless.
Then I started asking agents in Antigravity to add features, and writing tests first became dramatically easier. The reason is simple: to tell an agent "please write code that satisfies this behavior," I have to pin down the behavior in words first. And those words happen to make an excellent test.
Instead of explaining in natural language that "a cancelled paid member should still access premium articles until their expiry date," it's faster and less ambiguous to write three lines of XCTest and say, "Please make this test pass."
// Write the test first — the spec in concrete form
func testCancelledMemberKeepsAccessUntilExpiry() {
let member = Member(status: .cancelled, expiresAt: .now.addingTimeInterval(3600))
XCTAssertTrue(member.canAccessPaidArticle(at: .now))
XCTAssertFalse(member.canAccessPaidArticle(at: .now.addingTimeInterval(7200)))
}Hand that test over, and the agent usually nails canAccessPaidArticle(at:) on the first try. The end result is an unexpected inversion: a solo project with test coverage that keeps going up. I wrote more about the TDD mindset in the practical TDD guide with Antigravity, but honestly, the habit took hold before the article did.
Throwing away UI code became cheap
The fourth shift was about SwiftUI views.
I used to struggle to throw out a view I'd built. You assemble the layout, tune the spacing, polish the animation, and somewhere in that process you start to feel attached. "It would be a waste to redo all of this" — and you keep something you already sense is off.
With Antigravity, rewriting an entire view takes about ten minutes. I just ask, "Change this view from a list to large cards, and pin a search bar to the top," and a new structure comes back. Once the cost of throwing things away drops, you spend more tries searching for a better UI. The versions I ship to the App Store look noticeably better for that reason alone.
The discipline here is not to take the agent's output as final. Swift details — especially SwiftUI's lifecycle and the difference between @State, @StateObject, and @Observable — are areas where AI tends to slip. I keep re-reading skills worth knowing when writing SwiftUI with Antigravity precisely as a reference for drawing the line between "delegate this" and "don't delegate this."
Design habits get rewritten by the tools we use — quietly
Two months is short, looking back on it. And yet, the experience of watching my design habits change alongside my tools showed up more clearly than I expected. I'm still a little surprised at how visible it is.
If you're about to bring Antigravity into your iOS workflow, I want to say one thing in advance. When you feel "this is faster" in the first week, please don't stop there. The interesting part starts around month two, when your own code begins shifting in ways you don't immediately notice yourself.
If you want to try something today, pick the single longest function you have right now and ask the AI, "Please split this to be more readable." Don't judge the output too hard. Sit with the split for a while, and you'll start to see how much "only-a-human-can-read-this" code you've been carrying. That realization is a good starting point for your own next two months.