
Kiro Best Practices: A Field Guide for Development Teams
A practical guide to getting the most out of Kiro: CLI vs IDE selection, context window optimization, credit efficiency, memory management, steering files, spec-driven development, and agent hooks. Focused on enduring best practices verified against official documentation.
Your team just got access to Kiro , the agentic IDE from AWS. The first week is exciting: everyone is prompting, generating code, watching specs materialize from natural language. By week two, the questions start: "Why did I burn through my credits so fast?" "Should I use the CLI or the IDE?" "My machine slowed to a crawl; what happened?"
This post is the field guide I wish I had on day one. It covers the practices that separate teams who get consistent, high-quality output from Kiro from teams who get frustrated and revert to manual coding. Everything here is verified against Kiro's official documentation and focused on enduring best practices that apply regardless of which model or pricing tier you are on.
Kiro ships updates frequently; typically bi-weekly releases. For the latest features, model availability, and pricing, always check the Kiro Changelog and Kiro Pricing .
Understanding How Kiro Works
Kiro is not autocomplete with a chat window. It is an agentic IDE: it can plan, reason across multiple files, execute multi-step tasks, and maintain structured context about your project. It ships in two forms:
- Kiro IDE: a full desktop editor based on VS Code, with visual spec management, hook configuration, and extension support
- Kiro CLI: a terminal-native agent for building features, fixing bugs, and analyzing code directly from the command line, locally or over SSH
Both share the same AI backend, the same credit system, and the same steering/MCP configuration. The difference is in the interface and how they consume system resources.
The key architectural concept across both is the context window: the total information Kiro can hold in memory for any given request. Everything you feed Kiro (steering files, agent resources, conversation history, code context) competes for space in this window. Managing it well is the single biggest lever for both output quality and credit efficiency.
CLI vs IDE: Choosing the Right Interface
This is the first decision your team needs to make, and most teams get it wrong by defaulting everyone to the IDE without considering the tradeoffs.
When to Use the IDE
The Kiro IDE is the right choice when your workflow is visually oriented and involves frequent context switching between files:
- Spec-driven development: the IDE provides a visual panel for managing specs, reviewing generated requirements/design/tasks, and tracking progress with hunk-based code review for granular change acceptance. This is significantly harder to manage in a terminal.
- Hook management: creating and configuring hooks through the IDE's visual panel is more intuitive than editing
.kiro.hookfiles manually.
- Multi-file refactoring: seeing diffs inline, stepping through changes, and approving or rejecting individual edits is more efficient in a visual editor.
- Document-heavy workflows: the IDE supports attaching documents (PDF, CSV, DOC, XLSX, HTML, TXT, Markdown) directly in chat for the AI to reason over.
- New team members: the IDE's visual affordances (spec panels, hook UI, MCP status indicators) reduce the learning curve.
- Front-end development: preview panes, style inspection, and component-level work benefit from the visual environment.
Memory considerations: The IDE runs as an Electron-based application (like VS Code). On a typical project, expect 1.5-3 GB of RAM depending on extensions, open files, and workspace size. With MCP servers running, add another 200-500 MB per server process.
When to Use the CLI
The Kiro CLI is the right choice when your workflow is terminal-native or when system resources are constrained:
- SSH and remote development: the CLI runs anywhere you have a terminal. No desktop environment required. This is critical for working on remote servers, cloud instances, or containers.
- CI/CD integration: embed Kiro in build pipelines for automated code review, test generation, or spec validation.
- Resource-constrained machines: the CLI has a fraction of the IDE's memory footprint. On an 8 GB machine where the IDE struggles, the CLI runs comfortably.
- Quick, focused tasks: bug fixes, one-off queries, code analysis. When you do not need the visual spec management or hook UI, the CLI is faster to start and faster to finish.
- Custom agents: the CLI supports creating specialized agents with
/agent create, which AI-generates configurations from natural language descriptions. Useful for building reusable workflow-specific agents.
- Inline file references: use
@pathsyntax to include files directly in your prompt without leaving the terminal.
- Mid-session adjustments: the CLI's session settings tool lets you adjust preferences mid-conversation without editing config files.
- Scripting and automation: chain Kiro CLI commands with shell scripts for batch operations.
Memory considerations: The CLI process itself uses 150-300 MB of RAM. No Electron overhead, no extension host, no renderer process.
Installation
The CLI installs with a single command on macOS and Linux:
Bash
curl -fsSL https://cli.kiro.dev/install | bash
Then navigate to your project and run
kiro-cli .Side-by-Side Comparison
Factor | IDE | CLI |
|---|---|---|
RAM baseline | 1.5-3 GB | 150-300 MB |
Startup time | 5-15 seconds | 1-3 seconds |
Spec management | Visual panels with hunk-based review | Text-based (functional but less visual) |
Hook configuration | Visual UI with templates | Manual .kiro.hook file editing |
Custom agents | Standard agent chat | /agent create with AI-generated configs |
File references | Drag and drop, Open VSX | @path inline syntax |
Document attachments | Up to 5 documents in chat | Up to 5 documents in chat |
MCP status | Visual indicators in panel | /mcp command output |
Diff review | Inline visual diffs | Terminal diff output |
SSH/remote | Requires remote extension setup | Native; works anywhere |
CI/CD integration | Not applicable | Direct integration |
In-chat search | Cmd+F / Ctrl+F | Standard terminal search |
Best for | Visual workflows, specs, new users | Terminal workflows, remote, automation |
The Hybrid Approach
Many experienced teams settle on a hybrid: IDE for spec-driven feature work, CLI for everything else. Developers use the IDE when planning and building new features (where the spec panel and visual diffs add real value) and switch to the CLI for bug fixes, quick queries, code review, and remote work.
Both tools read from the same
.kiro/ directory, so steering files, hooks, and MCP configurations stay synchronized regardless of which interface you use.Credit Efficiency: Making Every Request Count
Kiro uses credits as the billing unit, not raw tokens. Understanding what drives credit consumption is essential for teams that want to stay within their allocation. Credit usage is updated at least every 5 minutes in the subscription dashboard within the IDE.
What Consumes Credits
Not all interactions cost the same. Credit consumption scales with:
- Model selection: higher-capability models cost proportionally more per request. The difference between the lightest and heaviest model can be 5x or more. Default to Auto mode, which uses intent detection and caching to route between models, balancing quality with cost. Kiro's Auto agent has been continuously optimized to reduce credit consumption without sacrificing quality.
- Context window size: the more context loaded into a request (steering files, agent resources, conversation history, code), the more expensive it is. This is why context management matters for cost, not just quality.
- Task complexity: a simple question costs a fraction of a credit. A full spec generation (requirements + design + tasks) costs significantly more. A multi-file refactoring with inline diffs costs more still.
- Hook executions: every hook trigger consumes credits. A broadly-targeted hook that fires on every file save across your entire project can silently drain your allocation.
- Spec refinement loops: iterating on requirements and design documents consumes credits with each round. Get to 80% confidence and start implementation rather than polishing specs endlessly.
Credit Optimization Tactics
Choose models deliberately. Use lightweight models for interactive queries and rapid iteration. Reserve high-capability models for genuinely complex tasks: architecture decisions, multi-service refactoring, difficult debugging. See the Kiro documentation for current model options and their credit multipliers.
Minimize always-loaded context. Every file in Agent Resources and every
always -included steering file gets sent with every request. If you have 10 steering files all set to always , you are paying for 10 files of context on a simple "what does this function do?" query. Move domain-specific steering to fileMatch and large references to Knowledge Bases.Start new sessions for new topics. Conversation history accumulates in the context window. A 50-message conversation about a database migration, followed by a question about a React component, means the AI is processing (and you are paying for) irrelevant database context. Start fresh.
Use
/compact proactively. Do not wait until you hit the context limit. When a conversation exceeds 15-20 exchanges, compact it. This summarizes older messages, freeing context space and reducing the token cost of subsequent requests.Scope hooks precisely. Instead of:
Plain text
# Triggers on every file save in the entire projectfilePattern: "**/*"
Use:
Plain text
# Triggers only when API route files changefilePattern: "app/api/**/*.ts"
Reference existing patterns in specs. When generating a new API endpoint, point the spec at an existing endpoint as a reference. This reduces the tokens Kiro needs to "discover" your patterns and produces more consistent output.
Memory and System Performance
Kiro is a resource-intensive application. Understanding where memory goes, and how to control it, prevents the "my machine is unusable" complaints that derail adoption.
Where Memory Goes
IDE memory breakdown (typical project):
Component | RAM Usage | Notes |
|---|---|---|
Electron shell + renderer | 400-600 MB | Base cost of the desktop app |
Extension host | 200-500 MB | Scales with number of active extensions |
Language services | 200-400 MB | TypeScript, Python LSP, etc. |
File indexing/watcher | 100-300 MB | Scales with workspace file count |
MCP server processes | 200-500 MB each | Each server is a separate process |
AI context buffer | 100-200 MB | Active conversation and context window |
Total typical | 1.5-3 GB | Can spike higher during heavy operations |
CLI memory breakdown:
Component | RAM Usage | Notes |
|---|---|---|
CLI process | 100-200 MB | Core agent runtime |
AI context buffer | 50-100 MB | Active conversation and context |
MCP server processes | 200-500 MB each | Same as IDE; servers are external processes |
Total typical | 150-300 MB | Plus MCP servers if configured |
Note: Recent Kiro updates introduced MCP server connection sharing across sessions, which reduces the total memory footprint when multiple sessions reference the same MCP server.
Memory Optimization for the IDE
Disable unused extensions. Every extension runs in the extension host process and consumes RAM whether you are actively using it or not. Audit your extensions quarterly. If you have not used an extension in the past month, disable it.
Exclude large directories from watching. Kiro (like VS Code) watches your workspace for file changes.
node_modules , build/ , dist/ , .git/objects , and other generated directories should be excluded from file watching:JSON
{"files.watcherExclude": {"**/node_modules/**": true,"**/build/**": true,"**/dist/**": true,"**/.git/objects/**": true,"**/coverage/**": true}}
Limit open editors. Each open tab consumes memory for the file buffer and language service state. Close files you are not actively working on:
JSON
{"workbench.editor.limit.enabled": true,"workbench.editor.limit.value": 10}
Restart after MCP configuration changes. MCP server processes can accumulate stale state. After adding, removing, or reconfiguring servers, restart for a clean slate.
Use workspaces, not monorepos opened at root. If your monorepo has 50 packages, do not open the root directory. Open the specific package you are working on. This dramatically reduces the file count Kiro indexes and watches.
Memory Optimization for the CLI
The CLI is inherently lighter, but there are still wins:
Start new sessions frequently. Unlike the IDE where you might keep a project open all day, CLI sessions should be short-lived and focused. Each new session starts with a clean context, consuming minimal memory.
Be selective with MCP servers. MCP servers are external processes that consume memory regardless of whether you are using the IDE or CLI. Only configure the servers you actively need. Use workspace-scoped MCP configs so servers only load when relevant.
Monitor with system tools. Use
htop , top , or Activity Monitor to watch Kiro-related process memory. If a CLI session is consuming more memory than expected, start a new one.Machine Sizing Guidance
Machine RAM | Recommended Setup |
|---|---|
8 GB | CLI only, or IDE with minimal extensions and 1-2 MCP servers max |
16 GB | IDE comfortably with moderate extensions and 2-3 MCP servers |
32 GB+ | IDE with full extensions, multiple MCP servers, and large workspaces |
If your development team is on 8 GB machines, default to the CLI and reserve IDE usage for spec-driven feature work.
Context Window Management: The Quality Lever
If credit efficiency controls cost, context management controls quality. Everything loaded into the context window competes for space. Bloated context means the AI has less room for what actually matters about your current request.
The Four Context Approaches
Approach | Token Impact | Persistence | Best For |
|---|---|---|---|
Agent Resources | Always loaded every request | Persistent | Essential project files only; use sparingly |
Skills | Loaded on demand | Persistent | Large guides, reference documentation |
Session Context | Always loaded | Session only | Temporary files for the current task |
Knowledge Bases | Only when searched (semantic) | Persistent | Large codebases, extensive documentation |
The critical insight: Agent Resources consume tokens on every single request, whether the AI references them or not. Files loaded here are limited to 75% of the model's context window.
Anti-Patterns
Plain text
# Loads entire codebase into context; burns tokens constantly/context add src/**/*.py# Overly broad patterns/context add **/*# Everything set to "always" inclusioninclusion: always # for every steering file
Correct Patterns
Plain text
# Semantic search; only loads what is relevant per request/knowledge add src/ --include "**/*.py"# Specific, targeted patterns/context add src/components/**/*.tsx# Conditional inclusion; loads only when working on matching filesinclusion: fileMatchfileMatchPattern: "api/**/*"
Essential Commands
Command | Purpose | When to Use |
|---|---|---|
/context show | Shows percentage breakdown of context window usage | Regularly; this is your diagnostic tool |
/compact | Summarizes older messages to free context space | When conversations exceed 15-20 exchanges |
/knowledge add | Indexes content for semantic search | Large codebases and reference material |
/mcp | Verifies loaded MCP servers | After configuration changes |
Make/context showa habit. If your context window is more than 60% full before you have started typing, you have a problem. Move agent resources to Knowledge Bases and steering files fromalwaystofileMatch.
MCP Servers: Extending Context Without Bloating It
Model Context Protocol (MCP) servers connect Kiro to external tools, documentation, databases, and APIs. When used correctly, MCP servers improve token efficiency: they provide the AI with precise, on-demand context from external sources instead of forcing you to load large reference material into the context window directly.
However, MCP servers are external processes that consume system memory. The key is choosing well-maintained, token-optimized servers and scoping them appropriately.
Configuration
MCP configs live in JSON files at two scopes:
- Workspace:
.kiro/settings/mcp.json, for project-specific servers
- User:
~/.kiro/settings/mcp.json, global across all projects
Workspace settings take precedence when both exist.
Example: AWS Documentation Server
JSON
{"mcpServers": {"awslabs.aws-documentation-mcp-server": {"command": "uvx","args": ["awslabs.aws-documentation-mcp-server@latest"],"env": { "FASTMCP_LOG_LEVEL": "ERROR" }}}}
Choosing Reputable MCP Servers
Not all MCP servers are created equal. Poorly designed servers with verbose tool descriptions (exceeding 10,000 characters) will slow responses and waste context tokens. When selecting MCP servers:
- Prefer servers from AWS Labs MCP : these are maintained by AWS, follow consistent patterns, and are optimized for token efficiency. The collection includes servers for AWS documentation, CloudFormation, EKS, ECS, Lambda, serverless development, and more.
- Check tool description size: servers with concise, well-structured tool descriptions consume fewer context tokens per request.
- Verify active maintenance: stale servers may have compatibility issues with newer Kiro versions.
- Use
${VAR_NAME}for credentials: never hardcode API keys or tokens in MCP configuration files.
Note: I contributed the openapi-mcp-server to AWS Labs MCP. It dynamically generates MCP tools from any OpenAPI specification-compliant REST API, achieving 70-75% reduction in token usage through intelligent prompt generation compared to loading full API specs into context. It supports Basic Auth, Bearer Token, API Key, and Cognito authentication. If your team works with REST APIs, this server can connect the AI to your API endpoints without manually describing each one.
MCP Best Practices
- Use workspace scope for project-specific servers and global scope for universal utilities (like AWS docs)
- Restart after config changes for a clean server state
- Monitor with
/mcpto verify server status and loaded tools
- For enterprises: Kiro supports MCP registries: admin-controlled JSON files that define which MCP servers the organization is allowed to use. This addresses security and data residency concerns.
Steering Files: Teaching Kiro Your Standards
Steering files are markdown documents that provide persistent knowledge about your project: coding standards, architecture decisions, framework choices, and conventions. They live in
.kiro/steering/ (workspace scope) or ~/.kiro/steering/ (global scope). Workspace files override global ones when conflicts arise.Inclusion Modes
This is where most teams get it wrong. Every steering file has an inclusion mode that determines when it gets loaded into the context window, and therefore when it costs you tokens:
Mode | Token Impact | Trigger | Use For |
|---|---|---|---|
always | Every request | Automatic | Universal standards only: tech stack, security policies |
fileMatch | Only when matching files are open | File glob pattern | Domain-specific rules (API conventions, test patterns) |
auto | AI decides based on request | Description match | Contextual guidance that may or may not be relevant |
manual | On demand only | #steering-name in chat | Rarely needed references |
The rule: Only use
always for information the AI genuinely needs on every single request. Everything else should be fileMatch or auto . Teams that set everything to always waste 20-40% of their context window on rules that apply to 10% of their requests.Example: Conditional Steering
Markdown
# .kiro/steering/api-standards.md---inclusion: fileMatchfileMatchPattern: "app/api/**/*"---# API Standards- Use RESTful conventions with consistent resource naming- Return consistent error format: { error: string, code: number }- All endpoints require authentication middleware- Validate request bodies using schema validation
This file only loads when you are working on files inside
app/api/ ; zero cost when you are editing a React component or a test file.Recommended Starter Set
File | Inclusion | Content |
|---|---|---|
product.md | always | Product overview, users, key features, business goals |
tech.md | always | Frameworks, libraries, technical constraints |
structure.md | always | File organization, naming conventions, architecture |
code-conventions.md | auto | Naming patterns, imports, common patterns |
testing-standards.md | fileMatch ( *.test.* ) | Test patterns, coverage requirements, mocking approach |
api-standards.md | fileMatch ( app/api/** ) | REST conventions, error formats, middleware |
security-policies.md | always | Authentication, validation, sanitization rules |
Kiro can generate foundational steering files for you. Open a project and ask: "Generate steering files for this project."
Global Steering: Stop Repeating Yourself
If your coding style, testing methodology, and security practices are the same across projects, put them in
~/.kiro/steering/ as global steering files . These apply across all workspaces automatically.Plain text
~/.kiro/steering/├── style.md # Formatting, language preferences├── testing.md # Test structure and coverage├── security.md # Security essentials├── docs.md # Documentation standards├── git.md # Commit message formats└── accessibility.md # Accessibility requirements
For teams, maintain a shared repository with company standards. Developers clone during onboarding and symlink to
~/.kiro/steering/ . Updates propagate automatically.Security note: Never include API keys, credentials, database connection strings, internal URLs, or customer data in steering files. Stick to patterns, conventions, and standards.
Spec-Driven Development: Think Before You Code
Specs are what separate Kiro from "vibe coding." Instead of jumping straight to code generation, specs create a structured plan: requirements, architecture, then sequenced tasks. This creates natural pause points where humans review and approve direction before the AI invests credits in implementation.
The Three Phases
Every spec generates three files:
- requirements.md: user stories with acceptance criteria (or bug analysis for bugfix specs)
- design.md: architecture, sequence diagrams, technology choices, error handling strategy
- tasks.md: discrete, sequenced implementation tasks mapped to requirements
Spec Types
Type | Starting Point | Flow |
|---|---|---|
Requirements-First | Natural language prompt | Prompt → Requirements → Design → Tasks |
Design-First | Architecture decisions | Architecture → Kiro derives requirements → Tasks |
Bug Fix | Bug description | Current behavior → Expected behavior → Root cause → Fix tasks |
When to Use Specs vs. Chat
Use Specs for: Complex features spanning multiple files, bugs where regressions are costly, work that needs team review, features where requirements need iteration before coding.
Use Agentic Chat for: Quick exploratory coding, simple well-understood changes, one-file modifications, codebase questions.
Spec Best Practices
- Use modular specs: one spec per feature, not one giant spec for the whole sprint
- Review generated specs before execution: the review phase is where you catch misunderstandings cheaply
- Execute tasks one at a time: this gives you control and lets you course-correct early
- Use hunk-based review: in supervised mode, review and accept changes at the hunk level rather than accepting entire files blindly
- Reference existing patterns: point the spec at similar code in your project to reduce token consumption
- Get to 80% and start: spec refinement consumes credits; do not iterate endlessly on requirements
Agent Hooks: Automate the Repetitive
Agent hooks are automated triggers that execute AI prompts or shell commands when specific events occur in your workspace.
Available Triggers
Trigger | Event |
|---|---|
fileEdit | A file is modified and saved |
fileCreate | A new file is created |
fileDelete | A file is deleted |
userTriggered | Manual activation |
Hooks support GLOB file patterns for precise targeting. Configuration files live in
.kiro/hooks/ with the .kiro.hook extension, making them version-controllable and team-shareable.Practical Examples
- Auto-generate unit tests when a source file is saved
- Update API documentation when endpoint files change
- Run linting after spec task completion
- Validate API contracts when schema files change
Hook Best Practices
- Start simple: basic file-to-file relationships before complex chains
- Use precise file patterns: every hook execution consumes credits; broad patterns waste money
- Share hooks like code: version control them so the whole team benefits
- Monitor via chat history: review hook outputs to refine prompts over time
Privacy Considerations
Kiro's privacy model varies by how you authenticate:
- Paid tiers via AWS IAM Identity Center: content is NOT used for model training. No telemetry collected from users. Enterprise admins can configure user activity reports.
- Free Tier and individual subscribers (social login / Builder ID): content may be used for service improvement, with opt-out available.
- Amazon Q Developer Pro subscribers: content is not collected for service improvement when accessed with the same credentials.
Team Adoption Roadmap
Week 1: Getting Started
- Decide IDE vs CLI vs hybrid approach based on team machines and workflows
- Install the CLI for all developers:
curl -fsSL https://cli.kiro.dev/install | bash
- Generate foundational steering files (
product.md,tech.md,structure.md)
- Set all developers to Auto model as the default
- Set up shared MCP servers from AWS Labs MCP and commit
.kiro/to version control
Weeks 2-3: Optimization
- Audit steering file inclusion modes; move everything possible from
alwaystofileMatch
- Set up Knowledge Bases for large codebases instead of loading entire directories into context
- Create hooks for standard workflows (test generation, doc updates, linting)
- Train team on
/context showand/compactas daily habits
Ongoing
- Review steering files during sprint planning; they should evolve with your codebase
- Track credit usage per developer to identify optimization opportunities
- Share effective hook configurations across the team
- Treat
.kiro/directory as code; require code reviews for changes
The Optimization Checklist
- [ ] Interface chosen: IDE, CLI, or hybrid based on workflow and machine resources
- [ ] Default model set to Auto for all team members
- [ ] Steering files use
fileMatchfor domain-specific rules, notalwaysfor everything
- [ ] Knowledge Bases configured for large reference material and codebases
- [ ] Context monitored regularly with
/context show
- [ ]
/compactused proactively in conversations exceeding 15-20 exchanges
- [ ] Steering files split into focused, single-domain files
- [ ] Agent resources contain only essential files; large guides moved to Skills
- [ ] File patterns are specific, not overly broad globs
- [ ] New sessions started for new topics
- [ ] IDE memory optimized: unused extensions disabled, watchers excluding build artifacts
- [ ] MCP servers from reputable sources (AWS Labs), scoped appropriately, token-optimized
- [ ] Privacy model understood: team aware of data handling based on authentication method
- [ ]
.kiro/directory version-controlled and shared across team
Additional Resources
- Kiro Documentation : full product documentation
- Kiro Pricing : current tiers, credits, and enterprise options
- Kiro Changelog : latest features and updates
- AWS Labs MCP Servers : official AWS MCP servers for documentation, infrastructure, and more
- openapi-mcp-server : connect any OpenAPI-compliant REST API to Kiro with 70-75% token reduction
- Making your Kiro credits go further : Auto agent optimization
- Stop repeating yourself: global steering : global steering setup
- From chat to specs: a deep dive : spec-driven development
- Agent hooks guide : hook setup and examples
- The bug fix paradox : why AI agents break working code and how specs prevent it
Conclusion
Kiro is not a tool you install and forget. The teams that get the most value from it make three deliberate choices: they pick the right interface for each workflow (CLI for speed and remote work, IDE for specs and visual tasks), they manage their context window as carefully as they manage their code, and they treat
.kiro/ configuration as a first-class project artifact.Start with the right interface for your team's machines, three foundational steering files, and
/context show as a daily habit. Everything else (specs, hooks, MCP servers) builds on that foundation.
About the Author
Abhijeet Patil is a Senior Solutions Architect at AWS, focused on helping enterprise engineering teams adopt AI-powered development tools to accelerate delivery and improve code quality. He is a contributor to the AWS Labs MCP project, including the openapi-mcp-server for connecting OpenAPI-compliant REST APIs to AI agents.
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article