How to Use Claude or ChatGPT to Write C++ in Unreal Engine

A general-purpose AI like Claude or ChatGPT is genuinely good at C++. Point it at Unreal Engine C++, though, and it gets noticeably shakier: it invents engine functions that do not exist, forgets the reflection macros that make a function visible to Blueprint, or hands you code that will not compile because a module is missing from your build rules. None of that means the model is useless for Unreal. It means Unreal C++ has a handful of conventions a generic model does not assume, and once you feed it those, the quality jumps.

This guide is about closing that gap: what makes Unreal C++ different from the C++ these models were mostly trained on, what context to hand the assistant, the prompts that actually work, and how to keep the edit-build loop tight. It is provider-neutral. Claude (from Anthropic) and ChatGPT (from OpenAI) are both more than capable here, and everything below applies to either.

Why Unreal C++ trips up a general AI

Most C++ in a model’s training data is standard-library, application, or systems code. Unreal is its own dialect layered on top, and four things in particular catch a model that does not know it is writing for Unreal:

• Reflection macros. Classes are declared with UCLASS(), members with UPROPERTY(), and functions with UFUNCTION(), and a GENERATED_BODY() macro sits inside the class. These are what let the engine see your code: serialize it, replicate it, and expose it to Blueprint. A model that omits them gives you plain C++ that compiles but is invisible to the editor.
• The BlueprintCallable contract. To turn a C++ function into a Blueprint node you need UFUNCTION(BlueprintCallable) (often with a Category). Miss the specifier and the node never appears, which is the single most common “the AI’s code does nothing” surprise.
• Module and build rules. Unreal code lives in modules, and using a class from another module means adding it to PublicDependencyModuleNames in your .Build.cs. A model cannot guess your build file, so it will reach for APIs you have not linked.
• A huge, version-shifting API surface. Engine types (AActor, UObject, FVector, TArray) and their methods change across UE versions. A model’s memory of the API is approximate and can lag the version you are on, which is where hallucinated or renamed functions come from.

Knowing these four is most of the battle. The rest is feeding them to the model deliberately instead of hoping it remembers.

Give the model the right context

The quality of Unreal C++ you get back is almost entirely a function of the context you send. More is not better; relevant is better, and relevant context also keeps your token usage (and bill) down.

For a typical “write me a function” request, the model wants:

• The class declaration it is adding to, including the UCLASS() line and what it derives from. “Add this to a UCLASS deriving from AActor” tells the model which base APIs are legal and that it must use reflection macros.
• The handful of relevant includes or member variables it will interact with, not the whole file. If the function touches one component, paste that member, not all twelve.
• The Unreal version and module, when it matters. “UE 5.x, and this is an editor-only module” steers it away from runtime-only or deprecated APIs.

The opposite mistake is pasting an entire 800-line file and asking a vague question. You pay for every token of that, and the model often anchors on the wrong part. Select the function or the few lines you actually care about and ask about those.

Prompts that actually work

A good Unreal C++ prompt names the reflection intent explicitly. Compare:

“Write a function that returns a string.”

against:

“On a UCLASS deriving from AActor, write a UFUNCTION(BlueprintCallable) named GetCustomString that returns an FString. Include the declaration for the header and the definition for the cpp.”

The second gets you something you can paste straight in:

// Header (.h), inside the UCLASS body
UFUNCTION(BlueprintCallable, Category = "Custom")
FString GetCustomString() const;

// Implementation (.cpp)
FString AMyActor::GetCustomString() const
{
    return TEXT("Hello from C++");
}

A few patterns that consistently land:

• “Explain this engine function.” Paste a built-in you do not understand and ask what it does and when to call it. This is the safest use of AI on Unreal C++ because you are reading, not generating, so a hallucination cannot reach your codebase.
• “Expose this to Blueprint.” Hand it a plain C++ function and ask for the UFUNCTION specifiers and category to make it a node.
• “Convert this Blueprint logic to C++.” Describe the node graph and ask for the equivalent C++, then sanity-check the APIs before trusting them.
• “Stub the definition for this declaration.” Once you have a header signature, ask for the matching .cpp body so you are not retyping the signature by hand.

Three ways to actually run this

How you get the code from the model into the engine matters as much as the prompt. There are three common setups, and they trade convenience against friction:

1. Copy-paste into a web chat. Free and immediate, but you are manually ferrying context in and code out, you lose the surrounding class unless you paste it every time, and it is the easiest way to drop a hallucinated API straight into your project. Fine for the occasional question, tedious as a workflow.
2. AI inside your IDE. Tools layered into Visual Studio or Rider see your files and are excellent for sustained work. The catch for Unreal specifically is the loop: you are outside the engine, so you still alt-tab back to Unreal to build and test, and the IDE does not know which Blueprint node you were looking at.
3. AI inside the Unreal editor. Editing the C++ behind a node without leaving the engine collapses that loop. You read the code next to the graph that calls it, generate against the real class as context, and build in place. It is the lowest- friction option for the small, frequent edits that make up most Unreal C++ work, and the weakest for large refactors (that is still IDE territory).

None of these is “the” answer. Most people end up using the web chat for one-off questions, a full IDE for heavy lifting, and an in-editor assistant for the quick stuff.

Keep the edit-build loop tight

Whatever route you pick, the thing that makes AI-assisted Unreal C++ pleasant is fast iteration. Unreal’s Live Coding (the compile-and-patch system, by default Ctrl + Alt + F11) recompiles changed C++ and patches it into the running editor without a full restart, so you can generate a function, build, and see the node appear in seconds. The shorter that loop, the more you can treat the model as a collaborator you correct in real time rather than a one-shot oracle you have to get right first try.

This is exactly where editing in the engine pays off. If you want to see the whole loop in motion, read Edit C++ With AI Inside Unreal Engine, which walks through generating a BlueprintCallable function with an AI assistant and building it into a usable node without leaving the editor.

Pitfalls to watch for

• Hallucinated or renamed APIs. If a function the model used does not autocomplete in your editor, assume it is wrong before assuming your setup is. Ask the model to double-check against your UE version.
• Missing reflection macros. If generated code compiles but the node never shows up in Blueprint, you are almost certainly missing UFUNCTION(BlueprintCallable) or a UPROPERTY().
• Unlinked modules. A linker error after pasting AI code usually means the class lives in a module you have not added to PublicDependencyModuleNames in your .Build.cs.
• Oversharing context. Do not paste secrets, license keys, or an entire proprietary codebase into a chat. Send the slice the question needs. It is safer and cheaper.
• Trusting generation over reading. The model is most reliable when it explains existing code and least reliable when it invents new API calls. Lean on the first, verify the second.

Wrapping up

Claude and ChatGPT are both strong Unreal C++ assistants once you stop treating Unreal as generic C++. Tell the model it is writing for a UCLASS, ask for the UFUNCTION specifiers by name, give it the relevant slice of the class instead of the whole file, and keep a fast Live Coding loop so you can correct it quickly. Do that and the hallucinations mostly fall away.

If you would rather keep all of this inside the engine, the AI Node Code Editor plugin (shipped on FAB as Quick Code Editor) puts a C++ editor and an AI assistant right next to your Blueprint graph: pick a node, see its .h and .cpp, ask Claude or ChatGPT on your own API key, generate and stub functions, and build with Live Coding without ever alt-tabbing out. The documentation covers setup.