DEV Community: Matheus Guimaraes

AI in Games: Are We Drawing the Line in the Wrong Place?

Matheus Guimaraes — Wed, 02 Sep 2026 14:10:01 +0000

The games industry is going through an uncomfortable transition. Studios see the productivity gains AI may offer, while many players see almost any use of it as inherently bad. As a lifelong gamer who started his career as a game developer, I see that divide from both sides.

I understand the reaction. People are worried about artists losing work, creative jobs being devalued and models being trained on work without permission. Those concerns certainly deserve careful consideration, but I also think the conversation has become far too binary with outright rejection often treated as the only acceptable position.

When any use becomes unacceptable

The example that crystallised this for me was Clair Obscur: Expedition 33. The Indie Game Awards withdrew its Game of the Year and Debut Game awards after it emerged that generative AI had been used during production. The material appears to have been placeholder artwork that accidentally shipped and was later patched out.

There is a disclosure issue. The awards had a clear rule, and the submission reportedly stated that no generative AI had been used so, ok, I understand it from the perspective of enforcing that rule.

What I disagree with is the rule itself. Declaring a game ineligible because generative AI touched any part of production, regardless of how it was used, feels very extreme and, dare I say, very naive and counterproductive to me. It turns “AI was involved” into the entire judgement and ignores context, scale and impact.

We have seen this pattern before

When Disney blended computer-generated environments with hand-drawn characters in Beauty and the Beast, audiences marvelled. CGI transformed visual effects, and computer animation became an art form of its own. We did not judge those works by how many people might have recreated every frame by hand. In fact, Toy Story, released in 1995 as the first fully computer-animated feature film, continues to be celebrated today.

To me, AI is just another step in that long history of automation. Game development already depends on IDEs, automated testing, procedural generation, motion capture, physics engines and infrastructure that scales itself. All allow teams to do more. If replacing manual effort is the line we object to, where does that line begin?

That is not to say that every use of AI is ethical, of course. Replacing an actor’s performance without consent is not the same as generating an environmental texture. Eliminating a creative team is not the same as helping one automate repetitive work. Training data, consent, attribution, disclosure and the treatment of workers matter.

That is why I find blanket rejection, at the very least, unhelpful. It removes the nuance needed to tell responsible use from exploitative use.

Judge the outcome, and ask better questions

As a gamer, I care most about the game: Is it good? Is it original? Does it move me?

If we want to examine how it was made then we should go deeper than just “AI was used.” What was it used for? Did it replace credited work? Was source material used with permission? Did the studio mislead anyone? Did the tool help creators realise their vision, or flatten it?

I know this is a topic that probably deserves a whole post in itself, but I also feel similarly about AI-generated art.

Art communicates, provokes or makes us feel.

The creation process can affect how we value a work. I personally struggle to appreciate works created by simply throwing paint at a canvas, for example, but my reaction to that process does not necessarily mean the result isn’t art. Similarly, I do not believe that using a prompt automatically prevents the result from being art, any more than using a camera, graphics tablet, image editor, particle system or CGI package does.

My bet is that AI will become another ordinary part of how games are made and the current backlash is just a transitional state of mind while society works out the boundaries of a disruptive technology and adjusts to a new world.

We should absolutely shape those boundaries, but I hope we shape them around consent, transparency and harm, not fear of the technology itself.

Of course, that's just my perspective, not a universal answer. Where would you draw the line? Which uses of AI in game development do you consider acceptable, and which do you not? I would genuinely like to hear how players and developers see it.

Why Can't We Just Use Claude for Everything? Agent Creation vs. Agent Engineering

Matheus Guimaraes — Tue, 18 Aug 2026 16:36:11 +0000

Recently, I was talking to a friend who, much like the rest of the world, has started using AI extensively at work to create agents even though she's not a software developer or from a technical background.

She has been experimenting with Claude a lot, building useful workflows for herself and her team, and getting increasingly excited about what these systems can do.

At some point, our conversation moved onto the work I've been doing around agentic systems: agent architectures, context engineering, memory, orchestration, sub-agents and frameworks such as Strands Agents.

And her reaction was:

Why do you need all of that? I'm already creating agents.

"Great question", I thought to myself.

And what made it particularly interesting was that I'd heard almost the same question from the opposite direction.

After giving a talk about agentic architecture and building harnesses with Strands Agents SDK, a junior developer came up to me and asked:

What's the point of all of this? Why can't we just use Claude for everything?

Two people approaching the subject from completely different directions had arrived at the same question.

And I think that question exposes something important about where we are with agents today. We are using the same word "agent" to describe two very different activities with very different use cases.

The way I see it, there is a big difference between creating agents and engineering agents.

Agent Creation vs. Agent Engineering

Applications such as Claude, ChatGPT, Amazon Quick and others increasingly allow people to create surprisingly sophisticated agentic workflows without building the underlying infrastructure themselves.

There is still a learning curve, though. You need to provide instructions and give the system knowledge and context in a way that produces results that are within expectation (and, hopefully, without hallucinations!). You may also need to learn about tools, set up integrations, schedule work or even create subagents so multiple pieces of functionality can work together.

From the user's perspective, they have created an agent. And indeed they have! But when a software engineer looks at the same system... they see something different.

They see an application providing a highly abstracted, opinionated agent runtime operating as a black box. You have little control over how execution happens, how context is assembled and maintained, how the system scales, or even where memory lives, among other architectural concerns.

As an application user, you are creating an agent inside somebody else's agentic architecture.

And that's not a problem. In fact, this could be exactly what you need!

Developers and software architects make trade-offs between abstraction and control all the time. We don't choose the lowest-level technology simply because it gives us the most control; we use abstractions because they remove decisions we don't want to make and complexity we don't need to own.

The same principle applies here. If Claude gives you everything you need to create an agent, why wouldn't you use it?

As usual with system design, the important thing is understanding the trade-offs. The abstraction works because somebody else has made a set of architectural decisions for you. If those decisions suit your requirements, then awesome. If they don't, you may need to take ownership of some of them yourself.

That's where I find the distinction between Agent Creation and Agent Engineering useful.

For me, three things make that distinction particularly clear.

Is the agent a feature or a component?

This is perhaps my favourite way of thinking about the distinction.

Let's say I create an agent in Claude to research holidays for me. It knows my preferences, researches destinations, compares options and perhaps uses tools to build an itinerary. It could be incredibly sophisticated... but Claude is still the application. I go to Claude, interact through Claude's interface and rely on Claude's infrastructure to make everything work.

My agent is a feature of an application I'm using.

Now imagine I want to offer that same experience through my own travel website. A customer comes to my application and asks for a holiday; somewhere behind the scenes an agent researches flights and hotels, applies their preferences, interacts with booking systems and returns the result.

The capability sounds almost identical, but architecturally something fundamental has changed. The agent is now a component of a system I'm building.

Suddenly I need to decide where it runs, how my application communicates with it, how it scales, how it authenticates against other systems, what happens when it fails, how it fits into traditional application flows, and how I observe what it's doing. The AI is no longer the destination; it's now part of the system I'm responsible for.

That's very clearly Agent Engineering.

The point is really about ownership. If an agent is a feature of Claude or another application, you're limited, quite deliberately, to what that application allows you to do. If your requirements fit inside those boundaries, great. When they don't... you need another abstraction.

Do you need control over the economics?

Another reason you might choose to engineer the agent is cost.

There is a lot of conversation right now about just how many tokens agentic systems can consume, particularly as we build long-running workflows with large context windows, tool calls and multiple agents.

Moving from Agent Creation to Agent Engineering doesn't automatically make any of this cheaper, by the way. Engineering has its own cost, and it would be rather ironic to spend £100,000 in developer time to save £500 in tokens.

What engineering gives you is control.

If you own the harness around your agents, architectural decisions become available that simply aren't exposed when you're operating inside somebody else's application.

You can decide that one task doesn't need the full conversation history, cache an expensive result, retrieve memory only when it's relevant, summarize context between steps, or route simpler tasks to cheaper models.

You can start treating context and tokens as resources that you deliberately engineer.

There's a much larger conversation here around context engineering, but that's a story for another post. For now, the important point is that the abstraction determines which levers are available to you.

If you don't need those levers, there's little value in taking responsibility for them. If the economics of your system mean you do, Agent Engineering gives you that control.

Do you need to own where your data goes?

Then there is a question that tends to become important very quickly in enterprise environments: where does everything actually live?

When I create an agent inside an application, I'm accepting that application's architecture and its mechanisms for handling context, state, memory, integrations and data. Again, that may be completely acceptable.

But what if particular data cannot leave a certain environment? What if I need to know exactly where long-term memory is persisted, control which model receives which information, maintain my own audit trail, or guarantee that certain data never crosses a particular boundary?

Now the black box really matters.

This is partly a compliance question, partly a data ownership question and, yes, partly a vendor lock-in question. The more behaviour, knowledge and state I build around one application's abstractions, the more dependent I become on that platform's capabilities and constraints.

But vendor lock-in isn't, by itself, a reason to engineer everything from scratch. We accept varying degrees of lock-in throughout modern software architecture because managed abstractions can provide enormous value.

The question is simply whether that trade-off is acceptable for the requirements in front of you.

So... Can't We Just Use Claude For Everything?

A useful spreadsheet can eventually become an application, but that doesn't mean the spreadsheet was a mistake. It may have been exactly the right abstraction for the problem at the time, and it may even have helped us understand the problem well enough to know what was worth engineering later.

I think Agent Creation and Agent Engineering should be seen in much the same way: not as levels on a maturity ladder, and certainly not as a journey where every agent should eventually become an engineered one, but as different architectural choices about how much of the underlying system we need to own. We might happily create an agent inside Claude for one task while engineering another from the ground up, perhaps even within the same system.

Sometimes an agent created inside Claude, ChatGPT, Amazon Quick or another application will remain there because it does everything we need. Sometimes our requirements will mean taking ownership of the architecture ourselves and we'll find ourselves reaching for Strands Agents SDK or another agent harness.

And perhaps the next time someone asks me, "Why can't we just use Claude for everything?", my answer will simply be...

You can! For as long as its decisions are compatible with yours.**

Understanding Async Programming

Matheus Guimaraes — Mon, 17 Aug 2026 16:01:25 +0000

Async programming, short for asynchronous programming, is one of those concepts that might sound intimidating at first but becomes surprisingly intuitive once you understand the problem it is trying to solve.

And that problem is mostly waiting.

Modern applications spend a lot of time waiting for things to happen. They wait for APIs to respond, databases to return queries, files to be read or written, and data to travel across a network. Async programming gives us a way to avoid blocking while that happens, allowing other useful work to make progress instead.

In this post, I’ll cover the basic concepts behind async programming rather than focusing on a particular language. The exact implementation differs between languages and runtimes, but the underlying ideas are largely the same. So if you’re new to async, or have used async and await without ever being completely sure what they’re doing, this is a good place to start.

What is Async Programming?

At its core, async programming allows your program to start an operation that may take some time and avoid blocking while it waits for that operation to complete.

This contrasts with synchronous programming, where execution waits for an operation to finish before continuing past that point.

Imagine you’re making an API call, a very common task in modern applications. Your application sends a request across the network and then has to wait for a response. Even if that response takes only a fraction of a second, that's a long time in computer terms.

The important thing is that your application isn't necessarily doing useful computation during all that time. A lot of it is simply waiting for something external to happen.

This is where async programming shines. Rather than blocking an execution resource while waiting for the API call to complete, asynchronous execution can allow other work to make progress and then continue the original operation when its result becomes available.

Async Doesn't Necessarily Mean Faster

One of the most common misconceptions about async programming is that it's about improving performance. A lot of people think that using async makes their code run faster. However...

Async does not necessarily make the operation itself any faster.

Your API call might take exactly the same amount of time to complete whether you call it synchronously or asynchronously. What async changes is what your application can do while it waits. Instead of being blocked by that wait, it can potentially make progress on other work.

When is Async Programming Useful?

There are three main benefits to using async programming:

Improved throughput: Because your application doesn't have to block on one operation before making progress on other work, it can often handle more work over the same period of time. This is particularly valuable in applications such as web servers that may be handling many requests concurrently.
Better resource utilization: Waiting for I/O doesn't necessarily require a thread to sit blocked until the operation completes. With asynchronous I/O, execution resources can potentially be used for other work while the application waits for the database, network, filesystem or another external resource.
Better responsiveness: Async programming can also help applications remain responsive while longer-running operations are taking place. In a user interface, for example, you generally don't want the entire application to freeze while it waits for a network request or file operation to complete.

The common thread between all three is the same: making better use of time that would otherwise be spent waiting.

Sync vs. Async: When to Use Each

Async programming sounds great, but that doesn't mean everything should be asynchronous.

The distinction becomes clearer when we think about I/O-bound and CPU-bound work.

I/O-bound operations spend a significant amount of their time waiting for something outside the CPU: network requests, database calls, file operations and similar tasks. These are often excellent candidates for async programming because there is useful time to reclaim while the application waits.

CPU-bound operations are different. If you're performing a heavy calculation, for example, the CPU is actively doing the work rather than waiting for something else to happen. Making that code asynchronous doesn't suddenly make the computation faster.

CPU-bound work may instead benefit from parallelism, where computation is divided so that multiple pieces of work can execute at the same time, potentially across multiple CPU cores.

Async programming can also introduce additional complexity and some runtime overhead, so there's little benefit in making code asynchronous simply for the sake of it. It is most useful when your application would otherwise spend meaningful time blocked waiting for I/O.

Async Isn't the Same as Parallelism

The distinction between async and parallelism is an important one. Async is primarily about allowing other work to make progress while something is waiting. Parallelism is about performing multiple pieces of work at the same time.

And async doesn't necessarily mean multithreaded either. Different languages and runtimes implement asynchronous execution in different ways, so you shouldn't assume that an async operation means another thread is somewhere doing the work.

This is why async can provide concurrency without necessarily providing parallelism: multiple operations can make progress over the same period of time without their code actually executing at the exact same moment.

How Does Async Work in Code?

The exact mechanics vary between programming languages, but many modern languages provide the familiar async and await keywords to make asynchronous code easier to write and reason about.

At a conceptual level, async identifies code that participates in asynchronous execution, while await marks a point where that code depends on the result of an asynchronous operation.

If that result is already available, execution may simply continue. If it isn't, the function can yield rather than blocking there, allowing other work to make progress. Once the awaited operation completes, execution can continue from that point.

You can think of await as saying: "I need the result of this operation before I can continue from here, but there's no reason to block everything else while I'm waiting for it."

The precise details of what happens underneath, whether that involves an event loop, tasks, promises, futures, state machines or something else, depend on the language and runtime. But you don't need to understand all of those implementation details to understand the basic async mental model.

Ready to Dive Deeper?

If async still feels a little abstract, I also explain the same ideas visually in the companion video below. Sometimes seeing the synchronous and asynchronous flows side by side is what finally makes the concept click.

Running Kiro Crew in Docker on Windows

Matheus Guimaraes — Wed, 12 Aug 2026 20:12:47 +0000

I've been playing with Kiro Crew recently, and when I went to get it running on my Windows machine I had a decision to make.

Kiro Crew doesn't currently have a Windows desktop app. You can still run it natively on Windows, but the documented route involves installing and running the Gateway from source.

But then, while looking through the Kiro Crew GitHub repository, I noticed another option that immediately caught my attention: there's an official Docker image!

Docker is already a familiar part of the development workflow for many of us, and a container felt like a nice, clean way to get Kiro Crew running without installing it from source.

So that's the route I took.

It worked, but along the way I ran into an interesting security detail that made the setup slightly less straightforward than simply running a container.

And, as it turns out, that's actually a good thing.

What we're going to do

By the end of this post, we'll have Kiro Crew running in Docker on Windows, with its agent sandbox enabled and without giving the container more privileges than it actually needs.

I'm using Docker Desktop with WSL 2, so you'll want to have those installed before following along.

You can check your WSL installation with:

wsl --version

With that out of the way, let's get Kiro Crew running.

Starting with the official container image

The Kiro Crew team publishes a public container image, so we don't need to build anything ourselves or even authenticate with a container registry. Nice and easy.

Before doing anything else, I created a directory to keep the files for this setup together:

mkdir kiro-crew
cd kiro-crew

Now, at first glance, running Kiro Crew looks like it should be as simple as starting the official image.

And technically, the Gateway itself will run.

But there's another security boundary inside that container that we need to understand before we can start it properly.

Wait... a sandbox inside a container?

This was the interesting part for me.

We're already putting Kiro Crew inside a Docker container, which gives us an isolation boundary between Kiro Crew and our Windows host.

But Kiro Crew adds another boundary of its own.

Agent commands aren't simply executed with access to everything available to the main Kiro Crew process. On Linux, Kiro Crew creates an internal user-namespace sandbox for those commands.

Conceptually, our setup looks something like this:

Windows
└── Docker container
    └── Kiro Crew
        └── Agent sandbox

Why sandbox an agent that's already inside a container?

Because the two boundaries are protecting different things.

The container isolates Kiro Crew from our host. The inner sandbox isolates agent commands from sensitive state available to Kiro Crew itself.

For example, Kiro Crew's sandbox hides credential directories such as ~/.aws and ~/.ssh from agent subprocesses by bind-mounting empty directories over them. So if an agent-executed command tries to access one of those directories, it simply sees an empty directory rather than our AWS credentials or SSH keys.

That means the Gateway can have the credentials it needs to do its job without automatically making those credentials readable by commands executed by an agent.

That's a pretty important distinction when we're giving an AI agent the ability to execute commands.

Where Docker gets in the way

There's one complication.

To create that inner sandbox, Kiro Crew needs Linux system calls including:

unshare(CLONE_NEWUSER)
unshare(CLONE_NEWNS)

Docker's default seccomp security policy blocks those operations.

So if the Kiro Crew container can't create its inner sandbox, it doesn't quietly shrug its shoulders and run agent commands without one.

It fails closed, meaning that when the security mechanism can't be established, access is denied rather than silently falling back to a less secure mode.

The Gateway and dashboard can still run, but agent command execution remains disabled.

I actually really like this design! What initially looks like an extra hurdle in getting the container running is Kiro Crew refusing to silently weaken its security model.

So how do we fix it?

The tempting solution and the better solution

There are a few ways we could approach this.

One option is to simply tell Kiro Crew that we accept running agent commands without the inner sandbox. Kiro Crew provides an environment variable for exactly that:

KIROCREW_ALLOW_UNSANDBOXED=1

We could pass that into our container and Kiro Crew would allow agent execution, leaving Docker itself as our only isolation boundary.

We could also reach for the rather large hammer:

--privileged

That would make the sandbox work, but it does so by granting the container extremely broad privileges and removing many of Docker's normal isolation restrictions.

That's a much bigger security concession than we actually need.

What we really want is much narrower:

Allow the operations Kiro Crew needs to create its sandbox while keeping the rest of Docker's security restrictions in place.

And this is another nice detail about the Kiro Crew implementation: the team already provides a seccomp profile specifically for this!

So we don't have to create one ourselves.

Downloading the Kiro Crew seccomp profile

From the kiro-crew directory we created earlier, download the official Kiro Crew seccomp profile:

curl -fsSL https://raw.githubusercontent.com/kirodotdev/KiroCrew/main/docker/seccomp/kirocrew-seccomp.json \
  -o kirocrew-seccomp.json

You should now have:

kiro-crew/
└── kirocrew-seccomp.json

Having trouble downloading it from WSL?

I happened to be dealing with a DNS issue in my WSL environment when I did this, so curl couldn't resolve GitHub. If you happen to run into the same thing, there's nothing special about downloading the file through curl: you can download kirocrew-seccomp.json directly from the Kiro Crew GitHub repository in your browser and place it in this directory manually, which is what I did.

Now we can start the container using that profile.

Running Kiro Crew

Run:

docker run -d --name kirocrew \
  -p 127.0.0.1:5476:5476 \
  -v kirocrew-home:/home/kirocrew \
  --security-opt seccomp=kirocrew-seccomp.json \
  ghcr.io/kirodotdev/kirocrew:stable

There are a couple of things worth noticing here.

We're only publishing port 5476 on the host's loopback interface, so the dashboard isn't being exposed to the rest of our network.

We're also creating a named Docker volume:

kirocrew-home

Kiro Crew keeps its persistent state under /home/kirocrew, including its configuration and Kiro CLI credentials. That means our state can survive replacing or upgrading the container.

And, most importantly for what we've just discussed, we're passing the Kiro Crew seccomp profile with:

--security-opt seccomp=kirocrew-seccomp.json

The container can now create the inner namespace sandbox while Docker's other default security restrictions remain in place.

Let's open it

At this point I did what I imagine most developers would do.

I opened:

http://localhost:5476

And instead of the Kiro Crew dashboard, I was greeted by a message telling me I was missing a token.

Another security measure!

Simply being able to reach port 5476 isn't enough to get access to the dashboard. Kiro Crew also requires a bearer token, so someone who can reach the Gateway still needs to authenticate before they can use it.

So, there's one more part of the setup we need to do.

Actually, two.

Authenticating Kiro CLI

Kiro Crew's agent runtime uses kiro-cli, so first we need to authenticate the CLI running inside our container.

We can do that without opening an interactive shell ourselves:

docker exec -it kirocrew kiro-cli login

Follow the authentication flow and log in with the identity you use for Kiro.

Once authentication succeeds, those credentials are stored in the kirocrew-home volume we created earlier, so they survive container upgrades.

But that authenticates the agent runtime.

We still need access to the dashboard.

Getting our dashboard token

Every request to the Kiro Crew dashboard requires a token.

We can mint a temporary login link from the running container:

docker exec kirocrew kirocrew token --ttl 2h

Kiro Crew will print a URL containing the token.

It will look roughly like:

http://localhost:5476/?token=...

Open that URL in your browser and...

We're in!

And with that, we have Kiro Crew running nicely inside Docker on Windows, without having to build it from source and without unnecessarily weakening either of its isolation boundaries.

Now I just need someone to explain why the Solarized theme is green instead of yellow. 😄