「Antigravityを使い始めたら開発が速くなりました」— そんな記事を、私自身もいくつか書いてきました。けれど、2ヶ月毎日触り続けてみて一番驚いたのは、速度の話ではありません。気づかないうちに、私のコードそのものの書き方が、以前とは別物になっていたことでした。
今日はその「静かな変化」を、iOSアプリ開発の現場から記録しておこうと思います。便利さの話は他の記事にも書いていますので、ここでは「結局、自分のコードがどう変わったか」にだけ焦点を当てます。
関数が短くなりました
最初に変わったのは、関数のサイズです。以前の私は「1画面ぶんのロジックはViewControllerの中に書いても別にいい」と思っていました。読み返せば自分の意図はわかる、そう納得していたのです。
ところがAntigravityに仕事を任せ始めてから、この「長い関数」に対してエージェントが妙に誤読することが増えました。30行の関数に対して「この部分を直してください」と頼むと、関係ない箇所まで書き換えてきたり、微妙に意図を外してくるのです。
原因は明確でした。人間には文脈が伝わっても、AIエージェントは関数の中に複数の責務が混ざっていると、どの文脈で動いていいのか判断を誤ります。そこで私は、1関数は画面に収まる15〜20行までに収める癖をつけました。すると面白いことに、人間が読んでも圧倒的にわかりやすい。AIのために整えた結果、半年前の自分より設計がきれいになった、というのが現実でした。
コメントが減り、命名への投資が増えました
2つ目の変化は、コメントとの付き合い方です。
以前は「迷ったらコメントを書く」が基本でした。ところがAntigravityは、コメントよりも関数名・変数名・型名から文脈を拾ってきます。コメントに // 会員の有効期限をチェックする と書くより、関数名を isMembershipExpired(for:asOf:) にしておく方が、エージェントの判断精度が目に見えて上がります。
この気づきは私自身のSwiftの書き方を変えました。func check(_ user: User) -> Bool のような曖昧な名前は、ほぼ全部書き直しました。Swiftはラベル付き引数のおかげで、英語の文として読める関数名を書きやすい言語です。これを活かしきっていなかったのは、結局「自分一人で読めればいい」と甘えていたからでした。
AIに読ませるために整えたはずのコードが、実は未来の自分のためにも効いている。この気づきは、Antigravityのプロンプトエンジニアリング完全ガイドを書いたときにはまだ漠然としていた感覚が、実作業の中で言語化されたものでした。
テストを先に書く心理的ハードルが消えました
3つ目は、テストとの関係です。
個人開発でテストを書かない理由はいつも同じでした。「1人なんだから動けばいい」「リファクタリングのときに書けばいい」「仕様がまだ固まっていない」。言い訳は無限にあります。
ところがAntigravityでエージェントに機能追加を任せるようになってから、テストを先に書くのが圧倒的に楽になりました。理由はシンプルで、エージェントに「この振る舞いを満たすコードを書いてください」と頼むには、先に振る舞いを明文化する必要があるからです。その明文化が、そのままテストコードになります。
たとえば「有料会員が解約しても、期限までは課金済み記事にアクセスできる」という仕様を自然言語で伝えるより、XCTestで3行書いて「このテストが通るように実装してください」と言った方が、エージェントも私も迷わないのです。
// 先に書くテスト（仕様の明文化）
func testCancelledMemberKeepsAccessUntilExpiry() {
let member = Member(status: .cancelled, expiresAt: .now.addingTimeInterval(3600))
XCTAssertTrue(member.canAccessPaidArticle(at: .now))
XCTAssertFalse(member.canAccessPaidArticle(at: .now.addingTimeInterval(7200)))
}このテストを先に渡しておくと、エージェントは canAccessPaidArticle(at:) の実装をほぼ一発で当ててきます。結果として、個人開発なのにテストカバレッジが上がるという逆転現象が起きています。テスト駆動開発の考え方についてはAntigravityでTDDを回すための実践ガイドで詳しく書いていますが、実感としてはその記事を書くより前に、癖として定着していました。
UIコードを気軽に捨てられるようになりました
4つ目は、SwiftUIのビューコードへの距離感です。
以前の私は、一度書いたビューを捨てるのが苦手でした。レイアウトを組んで、余白を整えて、アニメーションを調整して、という積み重ねに愛着が出てしまうのです。「これを全部作り直すのはもったいない」と、違和感を感じつつも使い続けてしまう。
ところがAntigravityを使うようになってから、ビューを丸ごと書き直すのが10分で終わるようになりました。「このViewを、リスト表示から大きなカード型に変えて、検索バーを上部に固定してください」と頼むだけで、構造が変わった新しいビューが出てきます。捨てるコストが下がると、より良いUIを探索する回数が増える。結果として、App Storeに出す版のUI品質が上がりました。
ここで気をつけているのは、エージェントに書かせたビューを鵜呑みにしないことです。Swiftの実装詳細、特にSwiftUIのライフサイクルや @State・@StateObject・@Observable の使い分けは、AIが間違えやすい領域でもあります。AntigravityでSwiftUIを書くときに押さえておきたいスキルは、こうした「任せる／任せない」の線引きを考える材料として何度も読み返しています。
設計の癖は、使う道具が静かに書き換える
2ヶ月という時間は、振り返ってみれば短いはずです。それでも、道具が変われば設計の癖まで変わるという体験は、ここまで明確に現れるものかと、自分でも驚いています。
これからAntigravityをiOSアプリ開発に取り入れる方に、1つだけ先にお伝えしておきたいことがあります。最初の1週間で「速くなった」と感じたら、そこで満足しないでください。本当に面白いのは、2ヶ月目あたりから、自分のコードが自分でも気づかないうちに変わっていく過程です。
もし今日すぐ試すなら、手元の一番長い関数を1つだけ選んで、AIに「読みやすく分割してください」と頼んでみてください。出てきた提案の善し悪しよりも、その分割を眺めているうちに、自分が今までどれだけ「人間にしか読めないコード」を書いてきたかに気づけるはずです。その気づきが、次の2ヶ月の出発点になります。