One late evening, my UE5 character was jumping a little too floaty, so I dragged BP_PlayerCharacter.uasset into Antigravity's chat and asked, "read the jump logic in this Blueprint for me." The reply was a curt "this file is in a binary format and cannot be read." Obvious in hindsight, but on my first real UE5 project I spent half a day refusing to accept it.
I'm Masaki Hirokawa, an indie developer. Compared to Unity, the AI-assisted material for UE5 is surprisingly thin, and the more you live in Blueprints, the easier it is to assume that AI IDEs are basically a C++-only tool. After running two indie prototypes through Antigravity over the past few months, though, the right place for it has slowly come into focus. This post is what I would tell my past self about Blueprint workflows, given the constraint that the AI cannot see inside the Blueprint itself.
Why Antigravity Can't Read Blueprints
UE5 Blueprint assets (.uasset) are a proprietary binary serialization that the Unreal Editor uses to store node graphs. They are not text. Even git diff only tells you "Binary files differ." From the perspective of a code editor like Antigravity, there is nothing meaningful to parse.
This isn't a limitation of Antigravity in particular — it's the same for Cursor, Copilot, or a local Gemma 4 model. The fastest way forward is to drop the idea of "paste the Blueprint and ask the AI" entirely.
That doesn't mean the AI is useless for UE5. The C++ classes underneath your Blueprints, the Python tooling around them, and the build configuration that glues it all together — those are exactly the layers Antigravity is best at.
Four Places Antigravity Genuinely Earns Its Keep
In my own work, these four areas have produced the most reliable wins.
1. Writing Blueprint Function Libraries in C++
Common helper functions exposed to Blueprints (anything inheriting from UBlueprintFunctionLibrary) are far faster to author with Antigravity than by hand. The Blueprint side becomes a single node, and the messy logic stays out of the visual graph.
// Source/MyGame/Public/MathHelpers.h
// A "normalize angle to 0-360" utility that's callable from Blueprints
#pragma once
#include "CoreMinimal.h"
#include "Kismet/BlueprintFunctionLibrary.h"
#include "MathHelpers.generated.h"
UCLASS()
class MYGAME_API UMathHelpers : public UBlueprintFunctionLibrary
{
GENERATED_BODY()
public:
UFUNCTION(BlueprintPure, Category="Math|Angle", meta=(DisplayName="Normalize Angle (0-360)"))
static float NormalizeAngle360(float InAngle);
};Decisions like whether to mark a function BlueprintPure, what meta=(DisplayName=...) to set, or which category to file it under — Antigravity gets these right when you simply ask it to "make this convenient to call from Blueprints." I now generate four or five domain-specific helper libraries per project this way.
2. Authoring the Parent UObject / UActorComponent Classes
Blueprints inherit from a parent class and decorate it with nodes. The cleaner that parent class is in C++, the simpler the Blueprint stays. This is where Antigravity feels strongest to me.
For example: implement inventory increment, decrement, and persistence in C++; let the Blueprint handle UI binding only. The AI does the heavy logic, and you keep visual iteration fast on the Blueprint side.
3. Driving Blueprints Indirectly via UE5's Editor Python API
This corner is underused: UE5 ships a Python API for editor automation, and you can use it to mutate Blueprint properties in bulk from a script.
# tools/rename_socket_attachment.py
# Bulk-update the attach socket on every SkeletalMeshActor under /Game/Characters
import unreal
asset_paths = unreal.EditorAssetLibrary.list_assets("/Game/Characters", recursive=True)
for path in asset_paths:
asset = unreal.EditorAssetLibrary.load_asset(path)
if isinstance(asset, unreal.SkeletalMeshActor):
comp = asset.get_editor_property("skeletal_mesh_component")
comp.set_editor_property("attach_socket_name", "weapon_r_socket")
unreal.EditorAssetLibrary.save_asset(path)
unreal.log(f"Updated: {path}")The Python file is plain text, so Antigravity reads it perfectly and writes it well. Even though the AI can't touch the Blueprint directly, batch operations across many Blueprints become a sweet spot for delegation. I've moved almost all my refactor and naming-cleanup work to this pattern.
4. Maintaining .Build.cs and .uplugin
This is the most boring win of the four, but in some weeks it saves more time than the others combined.
Every time you add a new module, PublicDependencyModuleNames in .Build.cs needs an update. It's tedious and easy to get wrong. Ask Antigravity to "add OnlineSubsystemUtils to this module," and it produces a diff that respects the existing dependency ordering.
The Hybrid Split I've Settled On
After enough trial and error, my division of labor looks like this:
- C++ layer (AI writes) — Gameplay Ability System code, AIController, data-table definitions, save system, online integration, helper libraries
- Blueprint layer (I do by hand) — UMG and UI animation, level-specific Sequencer hookups, enemy spawn presentation, final tuning of player feel
- Python tooling layer (AI writes) — bulk renaming, asset audits, pre-build sanity checks
Once the boundary became this clear, I stopped freezing in front of the Blueprint editor wondering what the AI should and shouldn't do. The key, I think, is drawing a hard line around what you want to keep inside Blueprints. When the boundary is fuzzy, Antigravity will keep suggesting "let's move this into the parent C++ class," and the Blueprint side gradually loses its readability.
One practical heuristic I use: if a piece of logic might be tweaked later by a designer or a non-coder collaborator, it stays in Blueprints. If it is purely mechanical and rarely revisited, it moves to C++. This single rule has saved me from over-refactoring more times than I can count.
Teaching Antigravity About a UE5 Project With AGENTS.md
To raise the AI's accuracy on UE5 projects, I keep an AGENTS.md at the repo root that looks like this:
# About This Project
A first-person indie action game built with UE5.5.
## Directory Layout
- `Source/MyGame/` — C++ for gameplay; Blueprint parent classes live here
- `Content/` — Blueprints and assets (binary; the AI cannot read these)
- `tools/` — Python utilities run from the UE5 Editor's Python console
- `Plugins/` — first-party plugins
## Notes for the AI
- You cannot read `.uasset` files under `Content/`. If a question depends on
inspecting Blueprint internals, please say so honestly.
- For new gameplay logic, propose an implementation that lives in C++ first
(helper library, component, or Subsystem) and is then exposed to Blueprints.
- Python in `tools/` runs against the UE5 Editor's Python API.
- C++ classes use the `UMyGame` prefix; headers are split Public/Private.Since I started doing this, the rate at which Antigravity invents "pseudo-Blueprint logic" out of thin air has dropped sharply. Just telling the AI that it's allowed to say "I can't see this" makes its answers noticeably more honest.
Patterns I Tried and Then Abandoned
A few detours, in case they save you time:
- Pasting a Blueprint screenshot. Antigravity supports image input, but Blueprint node graphs are too information-dense. Variable names and pin connections get misread often enough that the cost of wrong answers outweighs the convenience. I stopped doing this.
- Asking it to read
.uassetas text. Binary serialization is binary serialization. There is no useful text in there. - Writing C++ and Blueprints in one shot. The Blueprint side has to be assembled by hand anyway, so it is faster to ask the AI to "complete the C++ side and list the function signatures Blueprints will call as comments."
One Step You Can Try Tomorrow
If you're picking up Antigravity on a UE5 project, write your AGENTS.md first with the line "Blueprints cannot be read," then ask the AI to author one small UBlueprintFunctionLibrary under Source/. That single round trip is enough to feel where the boundary between AI work and human work actually sits.
Until UE5-specific AI tooling matures further, my current conclusion is to keep the Blueprint layer respectfully untouched and let the AI work quietly underneath it in C++ and Python. If you're trying the same thing from the indie side, I hope this saves you a few of the hours I lost. Thanks for reading.
For broader context, you may also enjoy Antigravity x UE5: A Production Plugin Design Guide and Antigravity x UE5 AI NPCs for Indie Games.