Rick Vu

Game design lifecycle vs software lifecycle in the age of AI coding

,

TRY THEN KEEP

AI coding makes me want to change the order of work. Get something I can try in front of me sooner. See how it feels. Edit it while the idea is still taking shape. Let an agent do the code.

The comparison I keep coming back to is game design. A game can do everything its design document says and still be boring. You have to play it to find out. I want to bring that habit into software development.

What are we trying to prove?

A software lifecycle gives us a way to turn a need into a system we can release and maintain. Requirements, design, implementation, testing, and operation all have a place. Even when we work in small iterations, there is a temptation to treat a finished feature as evidence that we chose the right feature.

Game design makes that gap harder to ignore. Imagine a jump that reaches exactly the intended height. It passes a technical check. But does it feel good? Does the player understand where they can land? Do they want to try again after missing?

Software has its own version of those questions. A form can save every field correctly and still ask for too much. A dashboard can show accurate numbers and still leave someone unsure what to do next.

Both disciplines iterate. The difference I care about is what I ask during each iteration. Alongside “does it work?”, I want to ask “is this an experience worth keeping?”

Try the vibe first

By vibe, I mean the experience I can judge by using it. How many steps does an action take? Does the screen make the next move clear? Does a response arrive when I expect it?

Suppose I want to build a small daily planner. Before deciding its database schema or listing every feature, I can ask an agent for one usable screen. Add a task. Put it on today. Mark it done. Use sample data so I can change the idea without a migration.

Then I try it. Maybe dragging tasks around feels like work, while a single “Today” button feels right. That is a design decision I can make with the prototype open. A longer specification would not answer it for me.

I want the first version to answer one question about the experience. Once it does, I can keep the useful part and throw away the rest.

Edit on the go

When an agent can turn a small instruction into a working change, I can give feedback while using the product. “Keep the input open after I add a task.” “Show the unfinished tasks first.” Each change gives me something specific to try again.

The loop I want is short:

  1. Pick one interaction to explore.
  2. Let the agent build a version I can use.
  3. Try it and describe what gets in the way.
  4. Change it, then try the same interaction again.

I still need to choose a direction. If I change five things at once, I lose track of which change helped. Small edits make my feedback more useful to the agent and my own judgment easier to check.

Let the agent do the code

I want to spend more attention on intent and feedback while the agent handles implementation. That means giving it a clear task, enough context, and a way to check the result.

For the planner, “make it nicer” leaves too much unstated. “Let me add another task without clicking the input again, and verify that both tasks appear” names a behavior I can judge.

The agent can write the change, run tests, and prepare a diff for review. I still own the decision to keep it. A passing test can tell me that the tasks saved. Using the planner tells me whether I want to use it tomorrow.

Keep the software lifecycle

Once an interaction feels worth keeping, I need to make it dependable. Sample data has to become real storage. Failed requests need understandable responses. Access rules need checks. I need to review what the agent wrote and understand what happens when I release it.

I can postpone those commitments in a disposable prototype. As soon as people depend on the product or trust it with their data, those requirements become part of the design.

My preferred lifecycle is to try the experience early, revise it through use, then develop and verify the version I want to keep. After release, actual use gives me the next question to explore.

AI coding makes the time between an idea and something I can try feel shorter. I want to use that time to make more deliberate choices. Try the vibe first. Edit on the go. Let the agent do the code, and keep judging what the code does for the person using it.