I have been using Kiro for my daily development tasks and POCs for a while now. Instead of having one IDE, I typically have five or six Kiro CLI sessions open at the same time, across different terminals. Each can be working on a different project, or sometimes on different parts of the same one. The CLI allows me to do this while keeping resource consumption low. No fan noise, no memory pressure, just lightweight sessions humming along.
I can have different workspaces in different folders. I can even have a folder containing multiple workspaces working on the same area. My terminal layout on any given day looks something like:
Terminal 1: ~/vishal/projects/user-service → API development
Terminal 2: ~/vishal/projects/user-service → test writing
Terminal 3: ~/vishal/projects/order-service → feature work
Terminal 4: ~/vishal/projects/shared-libs → dependency updates
Terminal 5: ~/vishal/projects/infra → terraform changes
Terminal 6: ~/vishal/projects/docs → documentation
This setup already felt productive. But there was a gap I kept hitting.
The Problem Nobody Talks About
Last month I was deep into migrating a monolithic Node.js service to microservices. Three repos, a shared Postgres database being split into per-service schemas, and about 47 things that could go wrong at each step.
Day one across those terminals went great. I explained the architecture, the constraints, the naming conventions I wanted. Everything generated beautifully.
Day two? Brand new sessions. Zero memory. I spent 15 minutes re-explaining the same context in each terminal. "No, the user-service owns the auth table." "Yes, always run npm run lint before marking a step done." "The database migration scripts go in db/migrations, not scripts/."
By day four, I was spending more time priming sessions than actually shipping code. The multi-terminal setup gave me parallelism, but each session started fresh every single time. Close the terminal, lose the brain. Every morning I was back to square one, and the agent made the same mistakes I already corrected yesterday.
I needed something that could hold context across days, learn from my corrections, and keep running tasks even when I closed my laptop for the night. Something that respected the multi-workspace way I already worked, but added persistence and learning on top.
Kiro Crew jumped in to help me out!
Kiro Crew is an open source, persistent development workspace that runs locally on your machine. The key word there is persistent. Sessions survive restarts. Corrections become lasting lessons. Repeated patterns become reusable skills. And long-running tasks checkpoint themselves so they resume from where they left off.
For my migration project, Instead of downloading a pacakged executable file, I cloned the repo and built from source because I wanted to poke around:
git clone https://github.com/kirodotdev/KiroCrew.git
cd KiroCrew
make build
source .venv/bin/activate
kirocrew setup
kirocrew doctor
kirocrew gateway
kirocrew doctor is genuinely useful. It checks that kiro-cli is on PATH, that you are logged in, that MCP servers are responding, and that the embedding model has downloaded. Caught a stale config on my first try and told me exactly what to run.
The Migration, Take Two
With Kiro Crew running, I started the same migration project across my usual terminal setup. But this time I structured it as a task:
<!-- migrate-user-service.md -->
# Migrate User Service
## Steps
1. Extract user-related tables from the monolith schema
2. Create the user-service repo with the standard template
3. Generate Prisma schema from extracted tables
4. Write migration scripts in `db/migrations/`
5. Add API routes matching the existing monolith endpoints
6. Run `npm run lint` and `npm test`
7. If tests pass, create the PR description
## Constraints
- Naming convention: kebab-case for files, PascalCase for types
- Always validate with lint before marking a step complete
- Stop and report if any test fails
Then kicked it off:
kirocrew run migrate-user-service.md
And walked away. Literally went to grab chai ☕.
When I came back, it had completed steps 1 through 4, hit a test failure on step 5 (a missing foreign key reference), stopped, and left me a clear report of what went wrong and where it paused. The checkpoint meant I could fix the issue and resume from step 5 without replaying the whole thing.
My Favourite Part: It Actually Learns
Here is the thing that made me stop and genuinely appreciate what is happening under the hood.
On day two of using Kiro Crew, I corrected it: "No, always run the frontend checks before calling a change done." I said it once. Just once.
From that moment on, every single session, every single task, it ran the frontend checks before marking completion. Not because I reminded it. Not because I added it to the task spec. Because that correction became a durable lesson scoped to my workspace.
Remember my six-terminal setup? Now the corrections I make in one terminal carry over to the other terminals working in the same folder. The migration workspace and the test-runner workspace in ~/projects/user-service share the same learned context. But the infra workspace has its own lessons about Terraform conventions that do not bleed into the Node.js projects. The isolation is intentional and it keeps things clean.
But the magic is in what happens over time. The memory system runs embeddings in-process (no external API calls for retrieval), maintains preferences, active project context, decaying history summaries, and those durable lessons. After a week, my Kiro Crew instance knew:
My naming conventions across three repos
That I prefer Prisma over raw SQL for new services
That db/migrations/ is where scripts go (not scripts/db/)
That failing tests mean stop, do not attempt a fix without asking
And the self-evolving part? The repeated pattern of "extract tables, generate Prisma schema, write migrations, add routes, lint, test" became a synthesized skill. By the third microservice extraction, it already had the workflow templated.
You can inspect all of this from the dashboard. Every lesson, every skill, every memory item is visible and editable. Nothing is a black box.
Running It Like Infrastructure
Once I saw how well this worked for the migration, I set up a recurring job for something I always forget: checking for dependency vulnerabilities in my repos.
kirocrew cron "Every weekday at 9am, check for critical npm audit findings in the user-service and order-service repos and summarize what needs attention"
That is it. Natural language scheduling. It delivers the summary to Slack (or Telegram, or Discord, wherever you connect it). I get a morning briefing without lifting a finger.
For the paranoid (I include myself here), the security model is not an afterthought. There are 137 bundled deny patterns blocking destructive commands. OS-level sandboxing is available on Linux and macOS. Credential redaction strips sensitive patterns from output. And every tool call goes through an approval flow that you control:
kirocrew security events # see what happened
kirocrew security audit # review the audit trail
kirocrew security verify # validate integrity
The approval_mode: "interactive" setting means I review tool requests in the dashboard before they execute. Once I trust a pattern in a session, I can approve it for the session scope without changing the underlying deny rules. Trust is earned per-session, not granted globally.
**Subagents for Parallel Research
One more scenario that sold me. I was evaluating three different queue solutions for an event-driven architecture: SQS, EventBridge, and a self-hosted Redis Streams setup.
kirocrew spawn run "Research SQS for our event pipeline. Evaluate cost, latency, DLQ handling, and integration complexity with our Node.js services."
kirocrew spawn run "Research EventBridge for our event pipeline. Same criteria."
kirocrew spawn run "Research self-hosted Redis Streams. Same criteria."
Three isolated subagents ran in parallel, each with their own context. When they finished, the parent session synthesized the tradeoffs into a single comparison. What would have been an afternoon of tab-switching became a 20-minute background job.
If you are working on anything that spans more than one session (migrations, refactors, recurring reviews, incident playbooks), give Kiro Crew a spin:
curl -fsSL https://download.crew.kiro.dev/cli.sh | sh
Open http://localhost:5476, start a conversation, and teach it something. Correct it once and watch it remember tomorrow.
Links:
GitHub: github.com/kirodotdev/KiroCrew
Docs: kiro.dev/docs/crew
Download: kiro.dev/crew
Discord: discord.gg/kirodotdev
The thing I keep coming back to is this: my multi-terminal, multi-workspace setup was already good. Kiro Crew made it remember. And that freed up headspace to focus on the actual engineering decisions instead of the ceremony around them.
If you try it, let me know what workflow you hand off first. I am genuinely curious. Meanwhile, I am trying out other Kiro Crew features!
Top comments (0)