Same Spec, Different Game: What AI-DLC Makes Repeatable

A sprite-based Swift game built through an AI-driven development workflow on a Mac.

Dr. Ryan Ries here. Last week I wrote about a lesson I learned the hard way at our Utah event: moving faster with AI does not remove the need for governance and validation. If anything, it makes those disciplines more important.

This week, I want to take the next step and talk about what we are actually doing to put that idea into practice.

A lot of organizations have introduced AI into software development by giving developers coding assistants. That is useful, but it is still largely the old software development lifecycle with AI inserted into one step. AI-DLC, or the AI-Driven Development Lifecycle, is a larger change. AI participates across planning, specification, design, construction, testing and refinement, while people retain responsibility for intent, validation, risk and what ultimately ships.

Couple quick updates before I jump in:

• Our team just wrote a blog post all about data validation with Amazon Bedrock AgentCore. Check it out if you’re interested in how we build an expert-level validation system for a data migration firm.
• Our team is hosting a spooky season webinar at the end of the month all about tokenomics, the spookiest thing of all. Save your spot here.
• Last but certainly not least, check out where Mission Cloud will be all throughout re:Invent. Make sure you sign up for our events early, they fill up quick these days. Details here.

Three Pieces of an AI-DLC

I have started thinking about an AI-DLC implementation as three connected layers: Advisory, Harness and Compute.

Advisory is about the people and the process. Teams have to learn how to work differently with AI: how to express intent, develop useful specifications, establish acceptance criteria, validate what the system produces, and understand where human decisions need to remain in the lifecycle.

The harness makes that process operational. It assembles specifications, agents, skills, tools, plugins and MCP servers into a repeatable development environment. Instead of every developer starting with a blank AI chat and inventing a workflow, the harness provides a structured path from an idea to a specification, to tasks, to construction and finally verification.

Compute is where the models actually run and where model roles are assigned. The same development workflow should not depend on one model or one location. Models might run through a cloud service, on enterprise infrastructure, or locally on a sufficiently capable system. The methodology and governance remain consistent even as the underlying compute choices change.

Same Goal. Different Interpretation.

Both runs preserve the core jetpack-game concept and playable behavior, but each model interprets the visual design differently. The comparison illustrates variation, not a ranking of model quality.

One model went full minimalist: dark space, plain columns, geometric obstacles, and an abstract jetpack pilot. The other built a richer world with a fully formed character, a scoring system, and a more developed playfield. In later iterations, I fed in extra sprite assets to see how far the visual experience could stretch.

Same intent and methodology. Similar gameplay. But TOTALLY different interpretation. To be clear, I am studying variation here. Not ranking model quality.

Repeatable Does Not Mean Identical

Generative AI systems are nondeterministic. We shouldn’t expect two models, or even two runs of the same model, to make every design decision identically.

What we CAN make repeatable is the process surrounding those decisions.

• Did we establish what we were building?
• Did we create specifications and acceptance criteria?
• Did the system decompose the work into manageable tasks?
• Did we test the result?
• Did a person review important decisions?
• Did we capture what happened so the next iteration could improve?

That is where an AI-DLC harness becomes important. The goal is not to make every AI produce the exact same pixels. The goal is to put enough structure and governance around a probabilistic system that teams can consistently produce software meeting the intended outcome.

That distinction becomes far more serious when the thing you’re building isn’t a silly jetpack game.

From First Playable to Polished Experience

The progression inside a single run is just as revealing as the comparison between models. The sequence below shows the movement from an early playable build through task completion and then into a more visually developed sprite-based experience.

1. FIRST PLAYABLE: This is where the core interaction and obstacle pattern show up.
2. FUNCTIONAL MILESTONE: Then, I reached a milestone where scoring, badges, restart behavior, and the core game loop came alive. I won’t show a screenshot for this step or 3 because it really looked the same as the first screenshot.
3. BEFORE SPRITES: Mechanics locked in and some simple geometric assets were added.
4. FINAL SPRITE PASS: Now here’s the fun part. Visual assets were added to bring in character and texture while maintaining the underlying concept.

From Experimentation to an Engineering Discipline

The screenshots are fun, but what I’m most interested in is the machinery behind them.

We’re testing different models, prompts, compute configurations and ways of structuring the handoff between people and AI. Where does a coding model shine? When should a reasoning model take the wheel? How much does the specification shape the final product? Where does human intervention pay off most?

The game makes those differences visible, but the lesson is broader. A model can be creative and still operate inside a governed workflow. A team can allow variation in implementation while requiring consistency in outcomes, validation and decision rights. And a development organization can learn from every run instead of treating each AI interaction as an isolated experiment.

Some Final Thoughts

AI-DLC is about turning AI experimentation into an engineering discipline.

It is not about eliminating human judgment. It is not about pretending nondeterministic systems suddenly became deterministic. And it’s not simply asking an AI to “build me an app” and hoping for the best.

Instead, it is about creating a governed system around AI so organizations can take advantage of its speed and creativity without giving up the rigor that good software engineering requires.

Sometimes the easiest way to see that transformation is to build two jetpack games and ask why they came out so differently.

If you want help figuring out where AI-DLC fits in your organization, let me know. Schedule a time with our team here. We’re happy to help.

Until next time,
Ryan

Now, time for this week’s AI-generated image and the prompt I used to create it.

Create an image of me wearing a jetpack and launching through a game experience. I included my image to use my likeness and also included a screenshot of what the game should look like. Make me a 16bit style character.