Week 6: Starting to Actually Make Things

Week 6: Starting to Actually Make Things

Experience

The crit this week was pretty straightforward and honestly a little humbling. I presented where I was at and the feedback from the group was unanimous. Everyone said the same thing: you need to start your experiments. Not think about them more, not plan them out further. Actually make something. That was the message across the board and I did not have much of a defence against it because they were right.

Coming out of the crit I decided to go wider before going deeper. I had been circling the same concept direction for a couple of weeks and I was starting to feel the trap of getting too attached to one idea before I had tested anything. So I went back to the double diamond as a process framework. The idea behind it is simple: you go wide first to discover what is out there, then you narrow down to define the real problem, then you go wide again to develop ideas, and then you narrow down again to deliver something. Two diamonds, each one a diverge-then-converge cycle. Jed actually mentioned it by name when we talked about design methodologies, and it felt like the right frame for where I was at. I needed to diverge before I could justify converging.

So that is what this week became. A proper diverging week. Three different experiments across three different areas, none of them finished products, all of them useful.

The first thing I experimented with was Claude Code. I had been hearing a lot about it and wanted to understand what it actually was before trying to use it for the capstone. I watched tutorials, spent a few hours learning how it works, and tried to get a feel for how to prompt it effectively. A few things stood out pretty quickly. Being vague with Claude Code does not work - you have to tell it exactly what you are building, what it should look like, and what you want it to do. It helps to think of it less like a search engine and more like a collaborator that needs context. The more you front-load about your project, the better the output. I also found that iterating in small steps worked better than trying to get the whole thing right in one go. You prompt for one thing, see what it builds, then layer on the next thing from there. Having a clear structure in your head before you open Claude Code makes a real difference too, because you are essentially directing something and if you do not have a clear vision yourself the output reflects that.

To get a feel for the tool I built a simple assignment tracker. It was not capstone-related, it was just something that felt useful right now and would give me a realistic sense of what Claude Code could actually do.

https://www.loom.com/share/bd192f50e4904f1da2c932406c8b565d

Demo of the tool ^

It worked. And more importantly it gave me a real read on the tool and how to work with it.

From there I started thinking about how this could connect to the brief. I struggled with this for a bit. The capstone had been living in my head as a video project and trying to translate that into something buildable with a coding tool felt like a stretch at first. But then an idea came up that changed how I was thinking about the whole thing, which I will get to in the theory section.

The second experiment was image and video generation. I wanted to see what tools like Higgsfield and Gemini could actually produce when given concept ideas I had in my head. My goal was not to make anything final. It was to see how these tools perform as a way of getting ideas out of your head and into something visual quickly.

What I found early on was that describing things naturally, the way you would explain an idea to a person, does not translate well into these tools at all. The outputs were way off. The better process I found was to first explain the idea to Claude and get it to write a proper prompt, then take that prompt into the image generator. That extra step made a huge difference in the quality and accuracy of the output.

I had some ideas for a storyboard on a project I was working on in my own free time and this is what it came up with. The prompt was something along the lines of creating a university friendly garden space with Aotearoa native plant species.

I also tried using the tools to add elements to existing images and footage, which is where things got interesting from a production standpoint. Some of it held up, some of it did not, but either way it was useful data.

Reflection on Action

The crit feedback stung a little in the moment but it was the right call. I have a tendency to stay comfortable in thinking mode for longer than I should. There is a version of planning that is productive and a version that is just avoidance dressed up as being thorough, and I had drifted into the second one. Hearing it from peers rather than a tutor made it harder to rationalise away.

The double diamond helped me give the week some structure without pre-determining where I was going to land. That felt important. Going in with a methodology rather than just vibes meant I could treat each experiment as information rather than a commitment.

The Claude Code learning process was also interesting to reflect on from a positionality angle. I came into it with more comfort around AI tools than most people would, because of what I do day to day. But Claude Code is genuinely different from prompting a chatbot. It requires you to think architecturally about what you are building before you start, which is a different skill. I had to slow down and actually plan before prompting, which is not always how I operate.

The image generation experiment surfaced something I keep coming back to: the tool rewards people who already have a clear vision. If you know what you want, it can help you get there faster. If you do not, it just produces confident-looking noise. That feels like an important observation for the capstone given that my whole project is about what happens to creatives who let the tool think for them instead of developing their own thinking first.

Theory

The question I keep coming back to is not just about AI replacing creatives. It is more specific than that. It is about the moment a creative person stops trusting themselves and starts defaulting to the machine instead of doing the hard thinking themselves. That shift is subtle and it is already happening. People who used to sit with a blank page now open an AI tool before they have even tried. The tool becomes the first move rather than a last resort.

The concern is not that the machine produces bad output. Often it does not. The concern is what happens to the human in the process when they stop practising the hard part.

That is the tension I want to put someone inside. Not explain. Actually put them inside it. And that is where a reference point I kept coming back to became important. Emily is Away is a game where the entire experience takes place inside a fake AIM messenger interface set in 2006. No cutscenes, no traditional gameplay, just a conversation window. And yet it is one of the most emotionally effective pieces of interactive storytelling I have come across, because the interface itself is the world. You are not watching someone have a conversation. You are inside one.

That format clicked for me in the context of this project. What if the player is a creative in future Aotearoa, and the game takes place entirely inside a chat interface with an AI tool? They are working on something - a film, a concept, a creative project - and at every turn they face choices about whether to lean on the AI or trust themselves.

The tension is not about AI being bad. It is about that specific moment when a creative stops thinking for themselves. Each time the player hands something over to the AI, things move faster but something gets lost. Each time they resist and sit in the discomfort of not knowing, it is slower but it feels more like theirs. By the end, depending on the path they took, they either have something that does not feel like them anymore or something rougher and harder-won that does.

The responses in the game will be pre-written, not AI-generated. I am in control of the emotional arc. The AI inside the game world is a character, not a live system. The emerging technology I am engaging with in the making of it is Claude Code. What I find genuinely interesting about that is the tension it creates: using an AI coding tool to build something whose entire subject is what happens when creatives rely on AI tools instead of their own thinking.

This fits the brief in a way that feels cleaner to me than anything I had been considering before. The brief talks about placing an audience inside a speculative scenario rather than just describing one. A film shows you the future. This puts you inside it.

Preparation

The crit made it clear that the standard I need to hit by Week 9 is having three strong, presentable prototypes. Not rough sketches or half-started ideas, but things I can actually put in front of people and get real feedback on. That is the target everything from here gets measured against.

Step one is to map the branching structure of the game before I write a single line of dialogue. I need to know the key decision points, what each path feels like emotionally, and what the possible endings look like. Once that skeleton exists I can start building it in Claude Code. The goal for this experiment is a working scene or two, enough for someone to actually sit down and play through it and tell me whether the tension lands.

Step two is to push the image and video generation experiments further. This week taught me that the prompting process matters as much as the tool itself. Using Claude to write the prompt before taking it into Higgsfield or Gemini made a real difference in output quality. I want to refine that workflow and get to a point where I can use it reliably for generating concept visuals and short clips that could support the world-building behind the final deliverable.

Step three is to start a third experiment I have not begun yet. I want at least one more direction tested before Week 9 so I am not showing up to that crit with only variations on the same two ideas.

The thing I need to improve most coming out of this week is the speed of my making. The crit feedback was about starting. The next feedback will be about depth. I need to move from experiments that test whether something is possible to experiments that tell me something specific about what the final work should actually be.