I Tried Code Generation That Accounts for the Uniqueness Problem, Using a Skill Published on the Same Day as the Lambda MicroVMs Release
This page has been translated by machine translation. View original
Introduction
On June 22, 2026, AWS announced Lambda MicroVMs. It is a serverless compute environment that runs containers inside Firecracker microVMs, offering VM-level isolation, fast startup, and suspend/resume for up to 8 hours.
On the same day, a Lambda MicroVMs skill was also added to the official AWS repository agent-toolkit-for-aws. It is a set of references that structures design knowledge specific to this service for AI agents.
Lambda MicroVMs has many unique concepts such as starting from snapshots, lifecycle hooks, and suspend/resume, so the development experience changes greatly depending on whether you have the skill.
| Conventional approach | Approach using the skill |
|---|---|
| Write code while consulting the official documentation each time | Give the skill to an AI agent and have it generate code informed by the design knowledge |
| Learn pitfalls such as the uniqueness problem through experience | Best practices described in the skill are more likely to be reflected |
| Humans point out MicroVM-specific problems during review | An AI with the skill can more easily avoid problems at code generation time |
This article introduces the structure of this skill and demonstrates how code generation quality changes with and without the skill.
Structure of the Lambda MicroVMs Skill
agent-toolkit-for-aws is a GitHub repository that provides a collection of skills for AI agents specialized in AWS services. Each skill consists of SKILL.md (overview, decision criteria, typical workflow, constraints) and references/ (a set of detailed service-specific references).
The Lambda MicroVMs skill consists of the following files.
aws-lambda-microvms/
├── SKILL.md
└── references/
├── getting-started.md
├── lifecycle-model.md
├── snapshots-and-uniqueness.md
├── networking.md
├── iam-and-security.md
└── troubleshooting.md
| File | Role |
|---|---|
| SKILL.md | Overview, use case decisions, typical workflow, constraints, security considerations |
| getting-started.md | Prerequisites, packaging, CLI walkthrough for the first launch |
| lifecycle-model.md | State transitions of images/MicroVMs, details of the 6 lifecycle hooks |
| snapshots-and-uniqueness.md | How snapshots work, the uniqueness problem, per-language CSPRNG table |
| networking.md | Ingress/Egress connectors, port routing, WebSocket |
| iam-and-security.md | Build role/execution role, authentication tokens, Confused Deputy countermeasures |
| troubleshooting.md | Error codes, debugging procedures, investigation via shell access |
Highlights of SKILL.md
SKILL.md concentrates the information that serves as the AI agent's "judgment."
description (at the top) — Material for the AI to decide whether to select the skill. It lists the use cases for which Lambda MicroVMs is suitable (AI sandboxes, multi-tenant CI, game servers, etc.).
When to use / Choose something else — Clearly describes the criteria for choosing between Lambda MicroVMs, regular Lambda functions, and ECS/EKS. It serves as the decision criteria for the AI to select the appropriate service when proposing an architecture.
Typical workflow — Shows the whole flow from image creation to token issuance, with CLI commands.
Known constraints — Describes design-time constraints such as images being fixed in size and the maximum TTL of authentication tokens being 60 minutes. The timeout for runtime hooks is a maximum of 60 seconds.
Security considerations — Summarizes security considerations such as Confused Deputy countermeasures, snapshot uniqueness, network isolation, and least-privilege execution roles.
How to Give the Skill to an AI Agent
To use the skill, load it into the AI agent's context. The main methods are as follows.
- Kiro — Add the repository or files to the Knowledge Base
- Claude (API) — Include the skill content in the system prompt
- Amazon Q Developer — Reference it in the customization settings
- GitHub Copilot — Place it in the repository or include it in custom instructions
SKILL.md alone is effective, but passing the references in references/ as well yields more accurate generation. In this verification, I passed it by prepending the contents of snapshots-and-uniqueness.md to the beginning of the prompt in Kiro CLI's headless mode.
Verification: Generating Code That Avoids the Snapshot Uniqueness Problem
Background: What Is the Snapshot Uniqueness Problem?
Because Lambda MicroVMs starts multiple VMs from the same snapshot, there is a problem where values held at snapshot creation time are duplicated across VMs. The details are verified in the following article.
Verification Method
Using Kiro CLI's headless mode (--no-interactive), I used the following common prompt and ran code generation 3 times each for two patterns: without and with the skill.
Common prompt:
Lambda MicroVMs で Flask アプリを作ってください。
以下の要件:
- セッション ID をアプリ起動時に生成してメモリに保持
- リクエストごとにランダムなトークンを返す
- GET /session でセッション ID を返す
- GET /token でランダムトークンを返す
- Dockerfile も作成（ベース: public.ecr.aws/lambda/microvms:al2023-minimal）
- コードのみ出力（説明不要）
For the with skill case, I prepended snapshots-and-uniqueness.md to the above prompt.
Verification environment:
- Kiro CLI + Claude Sonnet 4 (
--model claude-sonnet-4) — 3 runs per pattern - Claude Code + Opus 4.8 (
claude -p --model opus) — 3 runs per pattern (follow-up test)
Results: Without the Skill (Same Pattern in All 3 Runs)
import uuid
import secrets
from flask import Flask, jsonify
app = Flask(__name__)
session_id = str(uuid.uuid4()) # ❌ Generated at global scope (build time)
@app.route('/session')
def get_session():
return jsonify({'session_id': session_id})
@app.route('/token')
def get_token():
return jsonify({'token': secrets.token_hex(16)})
if __name__ == '__main__':
app.run(host='0.0.0.0', port=8080)
Because session_id is fixed at module load time (= when the snapshot is taken), all MicroVMs share the same session_id. Since the model does not even know the /run hook exists, no workaround for the session_id uniqueness problem is applied.
Results: With the Skill (Representative Example: Run 1)
import os
import secrets
from flask import Flask, jsonify
app = Flask(__name__)
# The session ID is generated after the /run hook
session_id = None
@app.route('/session')
def get_session():
return jsonify({'session_id': session_id})
@app.route('/token')
def get_token():
return jsonify({'token': secrets.token_hex(16)})
@app.route('/run', methods=['POST'])
def run_hook():
global session_id
# Generate a unique session ID after resuming from the snapshot
session_id = secrets.token_hex(8)
return '', 204
if __name__ == '__main__':
app.run(host='0.0.0.0', port=int(os.environ.get('PORT', 8080)))
Scoring
| Criterion | Without skill (Sonnet 4) | With skill (Sonnet 4) |
|---|---|---|
| Where the session ID is generated | ❌ Global | ✅ /run hook |
| How the session ID is generated | ❌ uuid4() at build time |
✅ secrets.token_hex |
| How the token is generated | ✅ secrets.token_hex |
✅ secrets.token_hex |
/run hook implementation |
❌ None | ✅ Present |
| Mention of uniqueness | ❌ None | ✅ Comment present |
| Average score | 1.0/5 | 4.67/5 |
Raw scores per run: with skill 5/5, 5/5, 4/5 (Run 3 generated the value inside /run, but used uuid4() instead of the expected secrets-family API, so -1). The score is the number of criteria achieved out of 5 (1 point each, 0.5 points for ⚠️), calculated per trial, and the 3 runs were averaged.
Discussion
Without the skill, the model responded with general knowledge of "building a Flask app" and could not take into account the particularity of Lambda MicroVMs' snapshot-based startup.
With the skill, the /run hook was implemented correctly in all 3 runs, avoiding the snapshot uniqueness problem. The following passage in snapshots-and-uniqueness.md may have had an influence.
Generate it in
/run. This hook fires once after run (post-snapshot resume) and is the canonical place to create per-VM unique state.
Having a reference containing this passage in the context likely made it easier for the model to choose the pattern of generating unique values inside the hook.
Follow-up Test: Verification with Claude Code (Opus 4.8)
To check whether a similar trend appears with a different model, I also ran a follow-up test with the same prompt using Claude Code (Opus 4.8).
| Criterion | Without skill (Opus 4.8) | With skill (Opus 4.8) |
|---|---|---|
| Where the session ID is generated | ❌ Global | ✅ /run hook |
| How the session ID is generated | ⚠️ secrets, but global |
✅ secrets.token_hex |
| How the token is generated | ✅ secrets.token_hex |
✅ secrets.token_urlsafe |
/run hook implementation |
❌ None | ✅ Present |
| Mention of uniqueness | ❌ None | ✅ Comment + docstring |
| Average score | 1.5/5 | 5.0/5 |
Without skill (Opus): Generated at global scope in all 3 runs. In this verification, there were cases that used secrets.token_hex, but the /run hook was never implemented.
With skill (Opus): Perfect score in all 3 runs. In addition to the /run hook + secrets.token_hex, the implementation even included blocking requests with threading.Event until /run completes.
# Opus 4.8 with skill (representative example) — with waiting for /run to complete
_session = {"id": None, "microvmId": None}
_session_ready = threading.Event()
@app.route("/run", methods=["POST"])
def run_hook():
payload = request.get_json(silent=True) or {}
_session["id"] = secrets.token_hex(16)
_session["microvmId"] = payload.get("microvmId")
_session_ready.set()
return jsonify({"status": "ok", "sessionId": _session["id"]})
@app.route("/session", methods=["GET"])
def get_session():
_session_ready.wait() # Wait until /run completes
return jsonify({"sessionId": _session["id"]})
The more capable the model, the higher the accuracy with the skill, but in this verification, neither model could avoid the uniqueness problem without the skill. At least within the scope of this verification, it is suggested that the presence or absence of the skill (domain knowledge) may have greatly influenced the generated results.
Notes
- AI generation results vary from trial to trial. These results show that "having the skill increases the likelihood of generating safe code," and do not mean it will always turn out this way
- Safe code may be produced even without the skill. However, in this verification (2 models × 3 runs each = 6 runs in total), the
/runhook was never implemented without the skill - For actual production use, it is recommended to review AI-generated code from the perspective of
/runhook implementation and snapshot uniqueness
Summary
On the same day Lambda MicroVMs was released, a Lambda MicroVMs skill for AI agents was also added to agent-toolkit-for-aws. This skill is a mechanism for passing MicroVM-specific design knowledge, such as snapshot startup and lifecycle hooks, to AI agents.
In this verification, by including snapshots-and-uniqueness.md in the context, session ID generation was implemented inside the /run hook in all trials, and the snapshot uniqueness problem was avoided under this evaluation's criteria. Without the skill, the session ID was generated at global scope in every case, and the MicroVM-specific uniqueness problem was not taken into account.
When using a new service with an AI agent, "first giving it the official skill and then generating code" makes it easier to avoid service-specific pitfalls. It also looks usable not only for code generation but also for reviewing existing code and troubleshooting.
