DEV Community: Dan Guisinger

Building a game in Unreal Engine with Kiro in two weeks (with no experience)

Dan Guisinger — Thu, 23 Jul 2026 22:00:54 +0000

I've been a professional C# and TypeScript developer for years. I know how to ship software. But game development? Unreal Engine? C++? None of that was in my vocabulary.

Twenty years since I last wrote C++. Never opened Unreal Engine. Didn't know what a GameMode was or how physics simulation worked in a game engine. I had an idea for a game and two weeks of evening time.

Just over two weeks and roughly 20,000 Kiro credits later, I have a playable 4v4 arena combat-sport game with probabilistic AI, full combat, disc physics, animation layering, in-game music, sound effects, an announcer, menus, and a match flow that runs start to finish.

This isn't a tutorial. It's what happened when I pointed an AI coding agent at a domain I knew nothing about and iterated relentlessly.

The Game

The project is a clone of DeathRow, a 2002 Xbox game by Southend Interactive. Two teams of four in a futuristic arena, throwing a disc through a goal ring to score. You can also beat your opponents unconscious. Knock someone out and their team plays shorthanded. Win by outscoring, or just KO everyone.

Here's what the original looked like:

The Setup

Kiro with Claude Opus 4.6 on macOS. Unreal Engine 5.8. The experimental Unreal MCP server connected so Kiro could interact directly with the editor: creating assets, configuring properties, placing actors in levels.

Two steering files gave Kiro permanent context: one describing the game and my background, one covering architecture decisions and project structure. No game development experience. No Unreal tutorials. No C++ refresher. Just a description of what I wanted and a willingness to iterate.

How the Iteration Works

I'd describe what I wanted at a high level. "I need a disc that bounces off walls with configurable physics and triggers a score when it enters a goal." Kiro figured out the Unreal-specific implementation. I'd play the result, describe what felt wrong. Kiro would diagnose and fix it.

The work was phased: movement, then disc physics, then teams, combat, AI, game flow, polish. Each phase had a deliverable I could test by playing. Some phases spawned sub-phases when something wasn't right. I'd describe a gap and Kiro would go as deep as needed.

I ran autopilot mode exclusively. Kiro wrote C++ classes, created Unreal assets via the MCP, configured inputs, wired up particle systems. My job was playing the result and saying "this doesn't feel right" or "what's next."

Week One: From Nothing to Playable

The first week produced the core game. Arena, movement, disc physics with auto-targeting, four-player teams with switching, a full combat system with KOs, seven AI characters running behavior trees, match flow with scoring and halftime, a menu system, controller support, and basic audio feedback.

It worked. But it felt mechanical. The AI was deterministic. Predictable patterns, robotic movement, no personality.

Week Two: Making It Feel Like a Game

I designed a probabilistic weight engine to replace the deterministic AI. I sketched out how decisions should be calculated: base weights modified by stacking multipliers for personality, team tendencies, game state, spatial awareness, and difficulty. I gave Kiro pseudo code showing the pipeline stages and how modifiers should compound. Kiro recognized the pattern, implemented it in C++, and wired it into the behavior trees.

This broke everything. The new AI exercised code paths the old deterministic system never touched, and latent bugs surfaced everywhere. Disc physics bouncing off characters instead of passing through them. Animation states leaking into the wrong context. Catch volumes too small at higher speeds. These bugs had been there from day one, just never triggered. I spent hours describing symptoms and Kiro traced each one to its root cause.

Beyond the AI, I added an energized disc mechanic. Hold the throw button to charge a power shot that instantly KOs opponents on impact (the namesake "deathrow" move). I overhauled the animation system to support priorities, interruptibility, and weighted variations. Catch animations now start before the disc arrives. The disc doesn't release until the throw animation hits its release point. Characters celebrate after scoring.

For audio I used ElevenLabs for sound effects and announcer voice lines, Suno for in-game music. Still entirely AI-created, no human artists involved yet.

Here's where it stands after just over two weeks and 20,000+ Kiro credits:

Prototype status: Combat is difficult because players move fast and there's no target lock for melee. Stamina tuning needs work. There are animation quirks and AI quirks I'm still chasing. Zero art, texturing, or modeling has been done. Everything you see is placeholder geometry and free Mixamo animations.

Where Kiro Carried Me

I didn't know Unreal's class hierarchy, macro system, or memory model. Kiro wrote thousands of lines of C++ across dozens of files spanning every layer of the engine's framework. I never wrote a line of C++ myself.

The things that would have taken me months to learn from documentation, Kiro just did. When the Unreal MCP couldn't handle something (and the experimental tool has plenty of gaps), Kiro explained exactly what I needed to do manually in the editor, step by step.

The steering files grew with the project. Every time I hit a recurring failure pattern, I'd document it so Kiro would recognize the symptoms immediately in future sessions instead of rediscovering the fix from scratch.

What I Actually Did

My contribution was design and direction, not code. I wrote the game design. I played and described what felt wrong. I designed the probability system and gave Kiro pseudo code to implement. I made architecture decisions when options were presented. I generated audio with ElevenLabs and Suno. I followed Kiro's instructions for the manual editor steps. I said "good enough, move on" when polish wasn't worth more time.

The Numbers

About 20,000 credits over two weeks of evening work, Claude Opus 4.6 exclusively. Over 80 C++ files. 150+ property-based tests (written by Kiro). Zero lines of C++ written by me.

At current pricing that's the Kiro Power tier ($200/month for 10,000 credits, overages at $0.04/credit). For two weeks of what would otherwise be many months of learning, I'd make that trade every time.

The Takeaway

The hard part isn't getting something working. It's getting it working well. The first week was fast because everything was new and "it does the thing" was the bar. The second week was slower because the bar became "it does the thing and feels right," and that meant chasing bugs that had been invisible until the AI started exercising edge cases.

The skill that mattered most wasn't programming. It was describing what I was seeing clearly enough that Kiro could diagnose it. "The disc bounces backward off a teammate" leads to a fix. "Passing doesn't work" leads to a conversation.

Calling a Public API Gateway Custom Domain from a Private VPC (Without Reconfiguring Your Clients)

Dan Guisinger — Wed, 28 Jan 2026 20:43:54 +0000

Originally published on Medium

There’s a deceptively simple requirement that AWS API Gateway still doesn’t support cleanly:

Use a public, regional API Gateway with a custom domain, and allow private VPC workloads to call that same domain without changing client configuration.

If you’ve tried this, you’ve probably been sent in circles—by documentation, AI tools, and even AWS recommendations—toward solutions that either don’t deploy or don’t work.

This post documents what actually breaks, why most suggested approaches fail, and the pragmatic workaround that finally solved it.

The setup

You have a public API Gateway endpoint exposed as:

https://api.yourdomain.com

That domain is used everywhere:

Browsers
External consumers
Shared SDKs

You also have private workloads (Lambda, ECS, EC2) running in isolated subnets with no NAT gateway. Those workloads need to call the same hostname, not an execute-api URL, and not an environment-specific variant.

Changing the base URL internally would fracture client configuration and defeat the point of having a stable public domain.

Why the obvious solutions fail

The first approach most people try is an interface VPC endpoint for execute-api, combined with a Route 53 private hosted zone that resolves api.yourdomain.com to the endpoint inside the VPC.

DNS-wise, this works. Traffic routes privately. The request never touches the internet.

But the TLS handshake fails.

At that point, nothing reaches API Gateway:

No API is identified
No routing occurs
No authentication runs

TLS negotiation fails before HTTP exists.

“Just use private custom domains”

This recommendation comes up constantly—and it’s simply incorrect for this scenario.

API Gateway private custom domains only work with private API endpoints. Domain associations explicitly require the API itself to be private. You cannot attach a private custom domain to a public regional API.

CloudFormation rejects it.
The console won’t allow it.
There is no workaround.

This is a product limitation, not a configuration error.

“Use the execute-api endpoint internally”

That works technically, but it forces:

Different base URLs per environment
API IDs and stage names in clients
Special-case logic in shared SDKs

For systems designed around a single public domain, this is architectural debt.

The real problem

Once you strip away the noise, the issue is very small and very specific.

When you access API Gateway through a VPC endpoint, the endpoint presents a TLS certificate for:

*.execute-api.{region}.amazonaws.com

Even if you connect using:

https://api.yourdomain.com

The certificate chain is valid.
The issuer is trusted.
The only failure is hostname mismatch.

And because TLS fails, API Gateway never sees the request at all.

The pragmatic workaround

If you accept that:

You are connecting to an AWS-owned service
Over a VPC endpoint
Using AWS-issued certificates
With DNS fully under your control

…then the fix is to explicitly accept execute-api certificates when the only TLS error is a name mismatch.

This preserves:

One public domain
One client configuration
Private routing without NAT
Full encryption in transit

Applying this in .NET

Configuring the HTTP client

This is the missing piece you called out earlier.
The TLS behavior must be applied when registering the HttpClient.

services.AddHttpClient("ApiClient")
    .ConfigureForVpcEndpoint();

Any SDK or service using this client will now tolerate API Gateway’s certificate when accessed via a VPC endpoint.

The HTTP client handler

public static IHttpClientBuilder ConfigureForVpcEndpoint(
    this IHttpClientBuilder builder)
{
    return builder.ConfigurePrimaryHttpMessageHandler(() =>
        new SocketsHttpHandler
        {
            SslOptions = new SslClientAuthenticationOptions
            {
                RemoteCertificateValidationCallback =
                    ValidateApiGatewayCertificate
            }
        });
}```
{% endraw %}


## Certificate validation
{% raw %}


```csharp
private static bool ValidateApiGatewayCertificate(
    object sender,
    X509Certificate? certificate,
    X509Chain? chain,
    SslPolicyErrors sslPolicyErrors)
{
    if (sslPolicyErrors == SslPolicyErrors.None)
        return true;

    if (sslPolicyErrors == SslPolicyErrors.RemoteCertificateNameMismatch &&
        certificate != null)
    {
        var subject = certificate.Subject;

        if (subject.Contains("execute-api", StringComparison.OrdinalIgnoreCase) &&
            subject.Contains("amazonaws.com", StringComparison.OrdinalIgnoreCase))
        {
            return true;
        }
    }

    return false;
}

This does not disable TLS validation. It narrowly allows a known, trusted AWS certificate that fails hostname validation only because API Gateway cannot present your custom-domain certificate over a VPC endpoint.

Why this isn’t as scary as it looks

This is safe because it’s constrained:

The trust chain is still validated
Only AWS API Gateway certificates are accepted
DNS is private and controlled

Traffic never leaves AWS’s network

This is not a blanket “ignore SSL errors” hack—it’s compensating for a missing feature.

The real takeaway

There is currently no supported way to combine:

A public regional API Gateway
A custom domain
Private VPC access
A single, stable hostname
Correct TLS without client changes

Until AWS fills that gap, this workaround is the cleanest solution I’ve found—and the only one that doesn’t require re-architecting clients around internal-only URLs.

Sometimes the hardest problems aren’t misconfigurations.
They’re the seams where cloud abstractions stop.

About the author: Dan Guisinger is a consultant specializing in system and security architecture on AWS.

Building FluentDynamoDB in 45 Days with Kiro - A Hackathon Story

Dan Guisinger — Thu, 04 Dec 2025 07:45:11 +0000

This is the story of how a massive .NET DynamoDB library went from an empty repo to production-ready in 45 days.

When I started building FluentDynamoDB, I expected it to take months or even a year to reach a usable state. It’s an extremely large .NET library: source generators, expression translation, composite keys, geospatial indexing, encryption, stream handling, and thousands of tests across nine packages.

Instead… it took 45 days.

The only reason that was possible is Kiro.

This post covers what I built, how Kiro enabled it, and why the project literally could not exist without an AI-augmented workflow.

Project Overview: FluentDynamoDB

FluentDynamoDB is a modern, strongly-typed DynamoDB toolkit for .NET. It includes:

Source-generated entity models
Lambda-expression to DynamoDB request translation
Composite key modeling
Encryption + S3-backed blob storage
A complete stream-processing framework
Geospatial lookup via GeoHash, S2, and H3
Thousands of automated tests
Nine NuGet packages that work together as a unified ecosystem

This is not a “weekend hackathon” project.
It is a production-grade library, built fast — because the workflow was different.

The Kiro Workflow — Requirements → Design → Tasks

Kiro’s “Spec” system is the most important part of how this project got built.

requirements.md → What the system must do

Every major feature begins with EARS-style requirement statements defining:

expected behaviors
constraints
edge cases
business rules and functional intent

design.md → How it should be built

This is where architectural decisions took shape:

source generation boundaries
lambda-expression normalization rules
composite key representation
consistency models
geospatial data structures
AOT safety considerations

tasks.md → What Kiro should implement

Each task references:

the requirement it fulfills
the design decision that governs how it should be implemented

Kiro then generates the implementation while staying aligned to the spec.

Working alone, that scale is nearly impossible without something like Kiro.

The Hardest Part: Geospatial Encoding with Multiple LLMs

I had zero geospatial background going in. I knew GeoHash existed, but that was the extent of it.

Kiro made it possible to build a complete geospatial feature set — but not without major challenges.

Phase 1: Auto Model + GeoHash

Using Kiro’s default “Auto” model, it implemented GeoHash reasonably well. But during development, Kiro suggested:

“You may also want to consider Google S2 or Uber H3 for geospatial precision.”

Great idea... in theory.

Phase 2: First Attempts at S2 and H3 (Failure)

I let Kiro implement S2 and H3, and both implementations failed badly. It produced:

inconsistent cell conversions
mismatched bit shifts
incorrect spherical coordinate handling
decoding errors on specific edge-case coordinates

Auto-mode models simply got lost in the complexity.

Phase 3: Switching to Claude Opus 4.5 + the Clear-Thought MCP

When Anthropic released Claude Opus 4.5, I retried the work with a different approach:

1. Break the problem into steps

Using the clear-thought MCP plugin, I forced structured workflows:

normalization rules
intermediate coordinate transforms
step-by-step verification
invariants for S2 and H3 cell relationships

2. Opus’s reasoning was noticeably stronger

It could explain concepts coherently:

Hilbert curves
space-filling patterns
face/cell transformations
spherical geometry relationships

3. But we still had edge cases

A handful of stubborn coordinates would not encode/decode correctly.

Phase 4: Deep Debugging Using Reference C Code

This is where Kiro became absolutely essential.

I loaded the original Google S2 and Uber H3 C reference code into the Kiro workspace and had Opus:

read them side-by-side
trace execution paths
compare intermediate values
identify mismatched conversions
reason through floating-point differences
reconcile the two implementations

After several cycles, it found the issues - subtle mathematical transformation details I could not have discovered without deep math knowledge.

Result

S2 + H3 now both work in FluentDynamoDB.

And I will be very blunt:

I do not have the mathematical or domain background to implement S2 or H3 manually. This feature simply would not exist in FluentDynamoDB without Kiro.

It also consumed over 1,000 Kiro credits on this set of Specs alone — but it was worth every one.

Steering Documents: Quietly Powerful

This project didn’t need as many steering rules as full-stack work,
but one rule was essential:

“After any public API change, update the corresponding documentation and append a note to the documentation changelog.”

Why?

Because I have a separate Kiro workspace that:

reads that changelog
updates the web documentation
keeps everything in sync

This is still an experiment, but so far it has been extremely successful.
It ensures documentation never lags behind the code.

Project Scale (Powered by Kiro)

Here’s what was produced during Kiroween:

160,000+ lines of C#
100,000+ lines of documentation, specs, and steering documents
~4,000 automated tests
9 NuGet packages
5 example applications
40+ Specs
Used Multiple LLMs per feature
Over 10,000 Kiro credits consumed

This is the output of a multi-team engineering project —
delivered by one person using AI-augmented development —
for a total cost of around $400.

Kiroween Hackathon Video

GitHub

What I Learned During Kiroween

1. AI-assisted engineering isn’t the future, it’s the present.

This wasn’t theory. This was shipping real software.

2. Distributed system features become accessible to developers who lack domain expertise.

The S2/H3 experience is proof.

3. Specs > prompts.

Kiro’s structured workflow is genuinely transformative.

4. Good engineering + good AI > either alone.

What’s Next

FluentDynamoDB’s first stable NuGet release is coming soon.
We'll be continuing to:

add runtime DynamoDB schema validation
improve our FluentResults coverage over the full API surface
build more sample applications
keep scaling the spec-driven development workflow

If you’re participating in Kiroween, I’d love to compare notes.

— Dan