this is how i rebuilt my entire unity 6 workflow around ai and it cut my scripting time in half
I have been making games in Unity for four years. For three of those years I was writing every script from scratch, digging through documentation, and spending entire afternoons debugging one error. Six months ago I decided to rebuild the whole workflow around AI tools and track whether it actually made a difference. It did. This is the exact setup I use now, what changed, what did not work the way I expected, and the honest numbers.
Unity
Game engine I have been using for four years, Personal plan free under $100k revenue
unity.com
Unity Muse
Unity's official AI tools, $30 per month, used daily for scripting questions
unity.com
Claude
Used for game design documents and complex system planning, Pro plan $20 per month
claude.ai
Marcus Webb
June 24, 2026
The numbers I tracked: before the workflow change I was spending an average of 6.2 hours per week on scripting tasks across a single side project. After six months with the AI workflow in place that number is 2.9 hours per week on the same type of tasks. The project complexity did not go down. It actually went up because I started attempting systems I would have previously considered too time intensive. Those numbers came from a Toggl log I have kept running since I started the experiment.
Why I Decided to Actually Change Things
The honest reason was frustration. I was spending entire sessions in Unity debugging a NavMesh issue that turned out to be a single incorrect bake setting. Four hours on something that a more experienced developer would have spotted in ten minutes. I knew AI tools existed and I had dabbled with ChatGPT for occasional questions but I had never committed to genuinely building them into my process. So I ran a small experiment. I picked one system in my current project, an enemy patrol and detection setup, and built the whole thing using only AI assisted code. It took two and a half hours and it worked on the first test run. The same kind of system had taken me six hours the previous time I built one from scratch. That was enough to make me take this seriously.
The Tools I Actually Use and What Each One Does
- Cursor Pro at $20 per month: This is where I write all my Unity C# now. Cursor is a code editor built on top of VS Code with AI built all the way through it. The important thing for Unity is that I open my entire project folder inside Cursor and it indexes everything. So when I am writing a new enemy controller script it already knows the architecture of my player controller, my game manager, and my audio system. The suggestions it makes reference the actual variable names and methods I am already using. That context is what makes it different from just asking ChatGPT.
- Unity Muse Chat at $30 per month for the full Muse suite: I use Muse Chat inside the Unity Editor for Unity specific questions. When I need to know the correct API for the new Input System in Unity 6 or how to set up a NavMesh Surface component, Muse Chat answers with the current Unity 6 version in mind. General AI tools sometimes give me Unity 2022 answers for Unity 6 questions. Muse Chat does not do that because it is trained on the actual Unity documentation.
- Claude Pro at $20 per month: I do not use Claude for code. I use it for thinking. When I am designing a new game system, working out how the progression should feel, or writing a brief for how a boss fight should escalate, Claude is where I work that out. The reasoning quality for design problems is better than anything else I have tried.
My Actual Day to Day Workflow
# My Unity 6 AI workflow, documented as I actually run it
## Before I open Unity
If I am starting a new system I spend about 15 minutes with Claude first.
I describe what the system needs to do and ask for the simplest architecture
that achieves it. Not code yet, just the structure. What classes do I need,
what does each one own, where does the data live.
Example prompt I used for my inventory system:
'I am building a lightweight inventory system for a 2D RPG in Unity 6.
The player can hold up to 12 item slots. Items have a name, icon, quantity,
and can be consumable or equipment. I do not want a grid UI, just a list.
What is the simplest data architecture for this that I can build incrementally?'
Claude gave me a three class structure. InventoryItem as a ScriptableObject,
Inventory as a MonoBehaviour that manages the list, and an InventoryUI
that listens to events from Inventory. Fifteen minutes before I opened Unity
and I already knew what I was building.
## Inside Unity and Cursor
I open my project folder in Cursor, not in VS Code.
The full Assets folder is the workspace root.
When I create a new script I start with a comment block describing
what the script does and what it needs to know about. Then I let
Cursor's autocomplete build the class structure. I am not copy pasting
from ChatGPT. I am typing in Cursor and accepting or rejecting completions
as I go. The difference is that each completion knows the context
of the scripts already in the project.
When I get stuck on a specific Unity API question I switch to
Muse Chat inside the Editor rather than googling. Faster and
the answer is version accurate.
## When something breaks
I paste the error and the relevant script into Cursor's chat panel.
Not the full script unless the error seems like it could be anywhere.
Just the function or block where the error is occurring plus the error
message. Cursor traces through what it knows about the project and
suggests the fix. Right about eight out of ten times on first suggestion.
## End of session
I leave a comment in whatever script I was working on describing
exactly where I left off and what the next step is. When I open the
project next time I paste that comment into Cursor and ask it to
continue from there. It reads the comment, reads the relevant code,
and picks up where I stopped. This one habit saved me the 20 minute
reorientation time I used to spend at the start of every session.The Things That Did Not Work the Way I Expected
- Cursor generating code it cannot test: Cursor writes very plausible looking code that occasionally has a subtle logic error that only shows up at runtime. I expected AI code to either work or obviously not compile. What I got instead was code that compiled fine and did something slightly wrong in specific edge cases. The lesson is that AI assisted code still needs the same runtime testing you would give to code you wrote yourself. Possibly more careful testing because it looks more finished than your own rough drafts do.
- Muse Animate not being what I needed: I subscribed to Muse expecting the animation generation to help with my character movement. It generated clips that were fine as placeholders but required more manual adjustment than just downloading a Mixamo animation and retargeting it. For animation specifically Mixamo is still faster for humanoid work. Muse Animate is something I use very occasionally for unusual motion that Mixamo does not have.
- Asking Claude to write game design and then treating it as final: Early on I would ask Claude to design a progression system and take its output as the design. The outputs were coherent and well structured but they did not feel like my game. Claude is useful for giving me a starting point to react to. Not for producing the final design. Now I use it to generate two or three options and pick what resonates, then modify heavily.
- Over prompting Cursor on simple tasks: I spent five minutes writing a detailed Cursor prompt for a function that adds an item to a list and checks for duplicates. Should have just typed it. AI tools save time on complex work and add time on simple work if you are not careful about when to use them.
What the Numbers Actually Look Like Month by Month
- Month 1: average scripting hours per week dropped from 6.2 to 5.1. I was still learning the tools and often reverting to old habits mid session.
- Month 2: down to 4.3 hours per week. The Cursor workflow was becoming natural. I started trusting the suggestions more and second guessing them less.
- Month 3: 3.8 hours per week. Introduced the Claude architecture planning step before opening Unity. This was the biggest single change.
- Month 4: 3.2 hours per week. The end of session handoff comment became habit. Sessions started faster.
- Month 5 and 6: holding at 2.9 to 3.1 hours per week. The systems I was building in months 5 and 6 were more complex than anything in month 1 so the absolute time reduction understates how much more I was getting done.
What I Would Tell Someone Starting This Now
- Start with Cursor only. Before adding Muse or Claude, spend two weeks with just Cursor and your Unity project folder open together. Learn to write with the AI suggestions rather than around them. Get comfortable with the context aware completions before you add more tools.
- Do the architecture step before the code step. Even five minutes of planning the structure in plain language before opening Unity changes how the code comes out. Claude is useful for this but a notebook works too. The planning is the habit. The AI is optional for it.
- Test everything at runtime even when it looks perfect. AI generated code can be subtly wrong in ways that only show up in specific gameplay situations. Budget test time the same way you would for code you wrote from scratch.
- Track your hours if you want to know whether this is working. I almost talked myself out of continuing in month one because it did not feel faster yet. The Toggl data showed it was already faster even when it did not feel like it.
Final Thoughts
Six months in and I am making more complex games faster than I was a year ago. The workflow change was not painless. Month one was slower and more frustrating than working the old way. The tools required learning and the habits required building. But the other side of that learning curve is real. Spending 2.9 hours on scripting tasks I used to spend 6.2 hours on means I have time for systems I would have cut from previous projects because they were too time intensive to build. That is what actually changed.