Kiro vs AWS Transform Custom: Building the Future vs Modernizing the Past
Two AWS-powered AI tools. Completely different jobs. Here's how to know which one you need.
Introduction
AWS now offers two powerful AI-driven developer tools that sound similar on the surface — both use agentic AI, both work with your code, and both promise to save engineering time. But they solve fundamentally different problems.
Kiro is an agentic IDE for building software — new features, new applications, greenfield projects — with structure, traceability, and persistent context.
AWS Transform Custom is an AI-powered modernization agent for transforming existing software at scale — crushing tech debt, upgrading runtimes, migrating frameworks, and translating languages across hundreds of repositories.
Think of it this way: Kiro helps you write the code. Transform Custom helps you upgrade the code you already wrote.
This post breaks down when to use each, with concrete use cases and examples so you can make the right call for your team.
What Is Kiro?
Kiro is an agentic IDE built on Code OSS that integrates AI deeply into the development workflow. Unlike traditional AI coding assistants that just autocomplete lines, Kiro introduces structured, spec-driven development — turning ideas into requirements, designs, and implementation tasks before writing code.
Core Capabilities
Feature | What It Does |
|---|---|
Specs | Structured 3-phase workflow: Requirements → Design → Tasks. Generated in .kiro/specs/<name>/ as markdown files. |
Steering | Persistent rules versioned in your repo ( .kiro/steering/ ). Tells the AI your architecture, conventions, patterns, and anti-patterns. |
Hooks | Event-driven triggers that execute agent prompts or shell commands when files change, specs run, or tools execute. |
Vibe Mode | Natural conversation — "refactor this function", "add tests for this service", "explain this CDK stack". |
MCP | Model Context Protocol — connects Kiro to external tools, APIs, and knowledge bases. |
Skills & Powers | Portable instruction packages and installable bundles that group MCP tools + steering + hooks into reusable units. |
When Kiro Shines
- Building a new microservice from scratch
- Adding a feature that touches security, networking, or IAM (where you want formal specs before code)
- Maintaining coding standards across a team via steering files
- Automating repetitive dev tasks (lint → test → fix) via hooks
- Any project where you need traceability from requirement to implementation
What Is AWS Transform Custom?
AWS Transform Custom is an agentic AI service designed for large-scale code modernization. It automates custom code transformations — version upgrades, runtime migrations, framework transitions, language translations — and executes them consistently across hundreds of repositories.
The key insight: you define a transformation once, and the agent applies it everywhere.
Core Components
Component | What It Does |
|---|---|
Transformation Definition | Define transformations via natural language chat, documentation, and code samples. The agent generates a reusable transformation definition. |
Execution Engine | Apply transformations across codebases — interactively (human-in-the-loop) or autonomously (batch CLI). |
Continual Learning | The agent improves from every execution and developer feedback. Knowledge items are auto-generated and reviewable. |
AWS-Managed (OOB) Transformations | Pre-built, AWS-vetted transforms for common scenarios — ready to use with no setup. |
Out-of-the-Box Transformations
- Java runtime version upgrades (e.g., Java 8 → 17)
- Python runtime version upgrades (e.g., Python 3.9 → 3.13)
- Node.js runtime version upgrades (e.g., Node 16 → 20)
- Java AWS SDK v1 → v2
- Python Boto2 → Boto3
- Node.js AWS SDK v2 → v3
- Vue.js version upgrades
- Angular → React migration
- Java x86 → Graviton (early access)
- Log4j dependency remediation
- Lambda runtime end-of-life upgrades
When Transform Custom Shines
- Upgrading runtime versions across 50+ repositories
- Migrating AWS SDKs organization-wide
- Translating between frameworks (Angular → React, Vue 2 → 3)
- Reducing tech debt that's been accumulating for years
- Any transformation that needs to be repeatable, consistent, and scalable
Side-by-Side Comparison
Dimension | Kiro | AWS Transform Custom |
|---|---|---|
Purpose | Build new software with AI assistance | Modernize existing software at scale |
Metaphor | AI pair programmer who knows your repo | AI modernization factory that learns your patterns |
Scope | One project at a time | Hundreds of repos in a campaign |
Interface | IDE (desktop) + CLI | CLI + Web (campaign management) |
AI Interaction | Conversational — chat, specs, steering | Define once — execute everywhere |
Context Model | Steering files, specs, hooks (versioned in repo) | Transformation definitions + continual learning |
Learning | Steering rules you write and maintain | Auto-learns from executions and feedback |
Pre-built | General-purpose coding agent | 6+ OOB transforms (Java, Python, Node.js, SDKs) |
Custom | Any coding task via natural language | Custom transforms via chat + docs + code samples |
Validation | Hooks (lint, test, review) | User-defined build/test commands per transformation |
Team Scale | Individual developer / small team | Enterprise-wide modernization campaigns |
Code Ownership | You own everything | You own all transformed code |
Five Use Cases That Make the Choice Obvious
Use Case 1: "We need to build a new API service"
→ Use Kiro
You're building a new REST API with Lambda, API Gateway, and DynamoDB. You want formal requirements, a technical design, and tracked implementation tasks.
In Kiro:
- Start a Spec session: describe what the API should do
- Kiro generates
requirements.mdwith user stories and acceptance criteria
- Then
design.mdwith architecture decisions
- Then
tasks.mdwith discrete implementation steps
- Execute tasks one by one, with Kiro writing code that follows your steering rules
Your steering file ensures every Lambda follows your team's conventions:
Markdown
# Steering - Backend Lambda Microservices- Use Node.js 20 in all Lambdas- Group functions by domain: backend/services/<domain>- Thin handlers: parse event, call domain services, build response- Business logic lives in services testable in isolation- DynamoDB: one table per domain; justify each secondary index
Why not Transform? There's no existing code to transform. You're building from scratch.
Use Case 2: "We have 200 Lambda functions stuck on Node.js 16"
→ Use AWS Transform Custom
Node.js 16 is end-of-life. You need to upgrade 200+ Lambda functions to Node.js 20 across dozens of repos. Doing this manually would take months.
With Transform Custom:
- Use the OOB Node.js runtime upgrade transformation — no setup needed
- Run a pilot on 5 representative repos to validate results
- Set up a campaign in the web experience to track all 200
- Execute autonomously via CLI, scripted into your pipeline
- Review transformed code in PRs — the agent creates branches with changes
Real-world proof: Air Canada upgraded thousands of Lambda functions from Node.js 16 → 20 with 90% efficacy and 80% reduction in time and cost.
Why not Kiro? Kiro works on one project at a time. You need fleet-wide, repeatable execution across 200 repos.
Use Case 3: "We're migrating from AWS SDK v1 to v3 in our Go services"
→ Use AWS Transform Custom
You have 900+ Go repositories using AWS SDK v1. The migration is mechanical but tedious — updating imports, changing API call patterns, handling new error types.
With Transform Custom:
- Define a custom transformation: provide migration docs, before/after code samples, and natural language instructions
- Test on 10 repos interactively, providing feedback when the agent gets something wrong
- The agent learns from your feedback and improves
- Scale to all 900+ repos autonomously
Real-world proof: Twitch built a Go SDK v1 → v2 transformation and projected saving ~2,876 developer days (~11 developer years) across 913 repositories.
Why not Kiro? You could use Kiro to migrate one repo at a time, but you'd lose the "define once, transform everywhere" efficiency and the continual learning across executions.
Use Case 4: "We need to add observability to our existing services"
→ It depends on scale
Small scale (5-10 services): Use Kiro. Open each project, use steering to define your observability standards (structured logging, X-Ray tracing, CloudWatch metrics), and let Kiro instrument each service following your rules.
Large scale (100+ services): Use AWS Transform Custom. Define a custom "add observability instrumentation" transformation with your standards as documentation, provide before/after code samples, and execute across your fleet.
This is the one use case where both tools are viable — the deciding factor is scale.
Use Case 5: "We're building a new feature AND upgrading the framework it depends on"
→ Use both, sequentially
Your team needs to:
- Upgrade Spring Boot 2.x → 3.x across 40 services (tech debt)
- Build a new payment processing feature on the upgraded codebase
Step 1 — Transform Custom: Define a Spring Boot upgrade transformation. Pilot on 5 services, then scale to all 40. The agent handles dependency updates, deprecated API replacements, and configuration changes.
Step 2 — Kiro: Once the codebase is modernized, open the payment service in Kiro. Create a Spec for the new payment feature. Let steering enforce your team's security and coding standards. Use hooks to auto-run tests on every change.
This is the ideal workflow: Transform Custom clears the tech debt runway, Kiro builds the new feature on clean ground.
Decision Framework
Ask yourself these questions:
Plain text
┌─────────────────────────────────────────────────────┐│ Am I building something NEW or changing something ││ that already EXISTS? │├──────────────────────┬──────────────────────────────┤│ NEW │ EXISTS ││ → Kiro │ ││ │ How many repos? ││ ├──────────────┬───────────────┤│ │ 1-5 repos │ 10+ repos ││ │ → Kiro │ → Transform ││ │ │ Custom │└──────────────────────┴──────────────┴───────────────┘
Question | Kiro | Transform Custom |
|---|---|---|
Am I building from scratch? | ✅ | ❌ |
Am I upgrading runtime versions at scale? | ❌ | ✅ |
Do I need formal specs and traceability? | ✅ | ❌ |
Do I need to transform 50+ repos consistently? | ❌ | ✅ |
Am I migrating frameworks (Angular → React)? | ❌ | ✅ |
Am I adding a feature to one project? | ✅ | ❌ |
Do I need the transformation to improve over time? | ❌ | ✅ (continual learning) |
Do I need persistent project context (steering)? | ✅ | ❌ |
They're Better Together
The most powerful pattern is using both tools in your development lifecycle:
- Transform Custom modernizes your existing fleet — upgrades runtimes, migrates SDKs, remediates vulnerabilities, reduces tech debt
- Kiro builds new features on the modernized codebase — with specs for traceability, steering for standards, and hooks for automation
Transform Custom keeps your foundation current. Kiro builds the future on top of it.
Quick Reference
| Kiro | AWS Transform Custom |
|---|---|---|
Website | kiro.dev | aws.amazon.com/transform/custom |
Docs | kiro.dev/docs | AWS Transform FAQ |
Access | Download IDE or use CLI | CLI + Web Console |
Pricing | kiro.dev/pricing | aws.amazon.com/transform/pricing |
Interactive Demo | First Project Tutorial | Storylane Demo |
Both tools are AI-powered, both are from AWS, and both save engineering time. The difference is simple: Kiro builds. Transform Custom modernizes. Know which job you're doing, and you'll pick the right tool every time.
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article