12 Months of Unity Dev with Claude Code transcript

The play test has been I think out for about 3 4 months and I received about five feedback. It doesn't sound like much but those five feedback have been some of the most useful information that I've gotten for the game. Just know the play test is public so the moment you request access you'll get access. If you have the time I would really appreciate it if you join the play test. So one thing I really wanted to talk about I am an artist and I'm using cloud code to do stuff that traditionally an artist wouldn't jump into and this is a discussion that I've seen some very experienced developers talk about and it's always fascinating because I'm going to make some guesses here as an artist and if I'm wrong please correct me in the comments.

I I'm making some guesses here educated guesses. So in my case if I'm starting at almost near zero and it bumps me into average code the multiplier is insane. I find that most games are perfectly fine with average code. Look at any game if the game was actually outsourced to be made the code base is very likely to be average. They were making sacrifices with in quality for optimizing for cost but I think my game can definitely be fully functional being very average.

Now going back to the bell curve as the AI orchestrator is going to be very hard for me to try to talk Claude out of providing outputs that are outside of the average result. Just because Claude code has an average output that kind of lands you in the center of the bell curve that doesn't mean you can't get super lucky or unlucky. Sometimes the output might just be like whoa where did you get that? But it would not be the average result.

There could be outliers. And somebody who's more experienced might be able to identify the outliers and keep them, but someone like me wouldn't. So, if I keep using the tool, I will converge on very average code base, and that's fine. And that doesn't create friction for me. But, if you're a developer that's kind of like on the high end of code quality, the code base is super clean. The moment you start feeding that through Claude Code, if you do that long enough without too much pruning or just making sure that you reject a bunch of stuff, eventually, it will just be very average.

That is not a fun workflow. The fun workflow is being on the left side of the curve and using Claude Code. If you're on the right side of the curve, um the top 20 percentile of you're trying to create a clean code base, and you're using Claude Code, I don't know what that workflow looks like that isn't extremely frustrating. And I think that's where a lot of discussion that I hear about people talking about, "Oh, I'm a 10x engineer, but I I've been 10x'd or 100x'd or 1,000x'd." What whatever you want to use, right?

They're Those are all made-up numbers. It just really depends where were you in relation to the average training data set that determines how much are you being amplified. And in the end, you're always being amplified to the average. Now, there are exceptions to the case where you can find edge cases where the average is actually fine, even if you're like a super productive engineer that has a super clean code base. I think where I've seen a lot of people talk about is like tools, right?

Throwaway tools. It doesn't really matter if it's average, below average, whatever. If it works, it works, and you throw it away. It doesn't really interact with your code base. Both can be true. Someone can get 100x'd if they're like absolutely They're as close as you can get to zero without it being zero. You can get 100x'd. You're getting close to average. If you're an engineer that is like I was uh what's his name?

Jonathan Blow? There's just some engineers that I watch on YouTube. I have no idea what like they're way smarter than me and they're talking about opinions on AI. I'm not sure if they would actually be sped up. If the idea is that the code quality needs to be of quality that Claude code cannot output without significant oversight, you might as well just do it yourself. I would imagine most experts do are not okay with average.

An average if you're it's like basically trash code base, right? And I can understand why when I when I'm browsing YouTube, I can see developers who are forced into uh this mode of work being very frustrated because they're forced to work in a way you're amplified in speed. But it's always to the average. And if your project or you personally do not like working in the average code, your quality bar is just higher, then I I I'm not aware of a workflow that resolves that.

You just have to improve the training set. Claude code is always pulling everything towards the average. Average art, average code, average anything it touches it's average. Everything in my code base is designed where there's no expectations of it ever being above average in the code base quality and where you are on the curve will really determine your perception of how you're being amplified. Cuz not everybody's being amplified.

Like maybe there's a workflow that someone created that I'm not aware of. I I just don't have the skill sets to even find that workflow that would actually amplify a skilled engineer. All right, so today I want to work on adding a character. So I've created a temporary folder where I have a character asset that I purchased from the Unity's asset store. If I do end up liking this asset, what I would do is I would build this character myself.

But, for prototyping, it makes a lot more sense for me to just save myself a lot of prototyping hours to spend $10, get this character, put it into the game, see if I like it, see if the time investment required to actually build this out myself is worth it. Just to give you an idea of what it looks like, it does play. If I press space bar, you'll notice that it is working. And so, that's the walk. This is a prime example of scope creep.

So, now you'll see that when I'm in the game and I move around my character, it's only a dino and there's no humanoid walking around with it. So, the hope is that when I'm done asking Claude to implement the character into my game, that character would show up right next to my dino party. I want everyone who's watching this to remember, I'm not using any custom tooling with Claude for it to actually do all of the wiring for me in Unity.

You don't need to use Unity AI. There's no There's no like external tool that you need to get this working. Claude code works out of the box. You don't need to modify it to actually get any of this working. So, I'm going to copy the path of this prefab. Now, I'm inside of Claude code. What I'm going to do is I'm going to copy paste the prefab. And then, and now I'm just going to talk. Hey Claude, in my game right now, I have a party formation that supports only dinos in my game.

The thing that I want you to add and fully implement is a character that only follows my party around. For now, our focus is only on getting the run movement working. I don't want you to worry about anything else. All I should have to do is play the game and verify that you've fully handled all of the implementation requirements. And here's a prompt I like to just add into whatever I'm prompting. It just helps Claude pause at the end and give me an implementation plan just get final approval on before we actually proceed in implementing the ask.

It looks like the implementation plan is ready. And before I bother reading all of it in detail, one thing that I like to do is run a custom skill that I made. I named it ask clarifying questions. The main thing that I like to point out with how I created this ask skill versus how I see other people doing it. My goal is I don't like getting grilled by the AI. When people are agentic coding, especially non-technical people, they like to run a command that basically tries to prime the AI to be critical of the work that was done or being done.

The idea and the hope is that by making the AI take a critical stand on the implementation plan, that it would surface faulty assumptions or problematic ideas. And my thing is I really really do not like that approach. Generally speaking, I don't like priming the AI to waste my time. The preferred amount of questions the AI should ask me should be zero. If the AI can answer the question it has by simply reading the code base, basically, don't be lazy, then that is not an appropriate question to ask me.

And most of the time when I am using Claude code, I am at my full capacity. Really dumb questions can distract me, can cause me to lose focus. Probably one of my favorite features of this ask clarification questions skill that I created. And it's nothing fancy, but it asks Claude to only ask me one question at a time, wait for me to respond, and that gives it a chance to recalibrate its follow-up questions. If you don't do this, Claude code might have a faulty assumption, and it might generate seven or maybe even 10 questions all back-to-back.

And the problem is, one, that is very token heavy, and if the baseline is incorrect, that means it will have to regenerate all 10 questions again. Claude, please do not make any claims on that are simply not true. I know you can handle the wiring. Now, I do not mind using a tool to handle the wiring, but do not make false claims. You're fully capable of fully 100% handling all the wiring requirements without creating tools.

That does not mean I am asking you to not create the tool, but do not make any inaccurate or faulty claims that are simply not true. Be honest. One thing that I need to clarify, Claude claimed that it can't wire a new prefab and attach the components. This is a false claim. This is where I needed to step in and correct Claude. I know for a fact it can do it. I trust that you will wire it correctly. Don't worry, we've done this hundreds of times and I don't recall you ever making a mistake.

So go ahead, the plan is approved. Let's go with your recommendation. Now here I am doing a slight priming where I am telling Claude code, "Hey, it's all right. You've done this so many times before and I don't recall you making mistakes." It's mostly true. Sometimes it makes mistakes, but here I just want it to be primed in a more positive leaning so that it is more likely to actually do what I'm asking it to. The first check is to go into Unity and then go into the console tab and see if there are any errors.

All right, I I don't see any. So next test is launching the game. Pressing continue. There it is. A little too small. But I mean that works. Up, yep, it's moving. It's moving. Okay, that's that's kind of funny, but let's That's cute. Maybe that's the scale we go with, huh? These are dinosaurs. Hey Claude, so it it is looking great. Can you go ahead and make the character that is spawning four times larger, please? And it looks like the scale is baked into the prefab of the Retinite that Claude made.

All right, that looks better. For now I can just call this good enough. Oh, wait, Wait a minute. Wait a minute. We found a bug. The character is just idling. Okay, so that's a bug. It needs to run. All right, Claude. So, one thing is I've noticed that the character it is not using its run animation. So, one thing I want you to do is add a debug.log and I'll play the game and reproduce this issue and copy paste the log back to you.

It created a tag for me. I'm going to copy this. Go back into the game and in my console here, I'm going to add this tag. This tag allows me to just focus only on the console log output for this bug we're trying to fix. Adding this search tag allows me to filter only the stuff that I want to copy paste over for debugging purposes with Claude code. Okay, press play. I see a bunch of stuff happening. I'm going to play the game.

Okay, that's enough. And I'm going to copy paste all this to Claude code. All right, so it looks like the issue may have been resolved. I'm going to exit and then replay. Press continue. Yep. Looks good. The character is now using their run animation. Yes, Claude, that did the trick. You are now free to remove the debug.logs and clean it up in preparation for committing. One of the most powerful things about using Claude code is the commit history.

And just for context, here are all of the files that we will be committing. Basically, my commit history serves as my documentation. Future Claude will always reference my commit history when working on new features. I just wanted to make games as a 3D artist and feel like I'm respected and I get to make the games that I'm excited to make. When I started out working professionally in like 2014, that was a real possibility.

I was younger and the game industry was actually much healthier. There was less outsourcing. And a lot of that changed over time. And I got laid off I forgot a few years ago. I don't know what it was. And it just put such a bad taste in my mouth, but I feel like I got I got extracted all along the way. I think there's something wrong about when a lot of these companies like optimize for just treating people like cogs and the people start feeling that way, it's really hard to be a creative in these companies.

Before LLMs were useful, there was a lot of things in game development that was being outsourced outside of US. And usually the trade-off that was being made was that these are the things that we can sacrifice quality on and optimize for cost. A lot of this stuff that's happening didn't just start happening because of AI. AI just is just another layer on top of what was already happening, the trend. At least from the perspective of US.

Certain types of coding could be one of them. Certain types of art can be one of them. Very rarely are you able to outsource everything and still create like a decent product. When I was job searching was brutal. Originally when I started out as a 3D artist, the biggest barrier for me was skill. So, that was very easy for me to resolve cuz I'm like, I'll just become one of the best or you know, with the Pokémon theme song running in my head.

And I did that for eight years. Eventually I became a professional and eventually I I could I had the skill to work anywhere as a 3D artist. The thing that I don't have much control over is my cost of living in the place that I live in the US. So, what ends up happening is it's a it's a global market, right? So, the call there's a minimum quality bar that most game studios need and it's usually not all that high. You just need somebody who's pretty average average professional.

At most studios, it becomes after a certain quality bar, management don't notice and a lot of players don't notice either. All of a sudden, where you start competing with is other realms. Whether it's do you have the right personality, the right temperament, do you interview well, where are you based? Cost. All these other elements that are not related to skill. I had this idea that once I get the skill, I can go in an interview and I can work at my dream studios, the game studios.

And at this point, I'm old enough, I've pretty much interviewed at every studio that was my dream studio. And for whatever reason, I didn't make it to the final cut. It's not like I'm all that persistent, you know, after the third time, you know, I'm probably good cuz often times these interviews go on for a long time and at this point, a lot of the dream studios that I had, they're no longer dream studios because they're all outsourcing.

If I were to guess, I wouldn't be shocked if in the US, majority of people making the US-based games are outsourced. It only took me like eight different job interviews before I checked that and I'm like, "Look, if this is what I'm working with, I have some savings. Let me see what I can do." The game is getting there. I really want to make the best game I can, and I think a big part of that is receiving feedback. And that's the missing piece right now.

I want more, and I feel like the game's in a good spot now to receive it. So, get into play test.