DEV Community: Sarvar Nadaf

My Dev.to CLI Got Its First Community PR. Image Uploads From Terminal.

Sarvar Nadaf — Thu, 03 Sep 2026 11:36:02 +0000

Three weeks after launching devpub, I got a notification I wasn't expecting: a pull request from someone I'd never talked to.

Harish / @harishteens had forked the repo, read the issues, picked one that I'd been putting off for weeks, and built a complete solution. Tests included. Design decisions documented. Edge cases handled.

The feature? devpub upload. The one command that should have existed from day one but couldn't, because the Forem API literally doesn't support it.

pip install devpub==0.3.0
devpub upload cover.png

That one command now gives you this:

  Uploaded: cover.png

              Uploaded Images
┏━━━━━━━━━━━━━━┳━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓
┃ File         ┃ URL                                       ┃
┡━━━━━━━━━━━━━━╇━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┩
│ cover.png    │ https://dev-to-uploads.s3.amazonaws.com/… │
└──────────────┴──────────────────────────────────────────┘

No more opening dev.to/new in the browser just to drag an image and copy the URL.

The problem
How devpub upload works
The authentication problem
What Harish built
Try it
What's next

The problem: no image endpoint in the API

When I launched devpub in v0.1, the goal was to replace the Dev.to web editor entirely. Write locally, push with one command, track analytics. Done.

But there was a gap. Every time I wrote an article with diagrams or a cover image, I had to:

Open dev.to/new in the browser
Click the image upload button
Select the file
Wait for upload
Copy the URL
Paste it into my local markdown
Close the tab

Seven steps for something that should be devpub upload figure.png.

The reason I hadn't built this: the Forem API V1 has no image upload endpoint. It doesn't exist. You can set cover_image in article frontmatter, but only to a URL that already exists somewhere. The API cannot create that URL.

I filed issue #11 with a note saying "this requires reverse-engineering the web editor's upload mechanism" and moved on to other features.

Harish didn't move on. He figured it out.

How devpub upload works

The Dev.to web editor uploads images to POST /image_uploads. It's a multipart form submission, same as any file upload. But it's not authenticated with your API key. It uses your browser session.

# Upload a single image
devpub upload cover.png

# Upload multiple images
devpub upload *.png

# Get ready-to-paste Markdown
devpub upload architecture.png --markdown
# Output: ![architecture](https://dev-to-uploads.s3.amazonaws.com/uploads/...)

The --markdown flag is the one I use most. Write your article with ![](./figures/diagram.png), then run devpub upload figures/*.png --markdown and paste the output directly over your local references.

The authentication problem

Here's why this feature sat undone for three weeks. The /image_uploads endpoint requires:

A _Devto_Forem_Session cookie (your login session)
A CSRF token (anti-forgery protection)
An Origin header matching https://dev.to

Your API key? Useless. This endpoint doesn't accept it.

So devpub needs two extra credentials beyond your API key. They live in .devpub/.env (which devpub init gitignores by default):

DEVPUB_SESSION_COOKIE=_Devto_Forem_Session=abc123...
DEVPUB_CSRF_TOKEN=a1b2c3d4...

If you run devpub upload without setting these, it doesn't just fail with a cryptic error. It shows you exactly where to find them:

╭─ Session Credentials Required ─────────────────────────────╮
│                                                             │
│  devpub upload needs your browser session (not API key).    │
│                                                             │
│  1. Open https://dev.to/new in Chrome                       │
│  2. Press F12 → Application → Cookies → dev.to             │
│  3. Copy _Devto_Forem_Session value                         │
│  4. View page source → find <meta name="csrf-token">       │
│  5. Add both to .devpub/.env                                │
│                                                             │
╰─────────────────────────────────────────────────────────────╯

One deliberate design choice: these are login credentials, not a scoped token. The .env file is gitignored, and when they expire (you'll get a 401 or 403), you just re-copy them. devpub tells you that upfront rather than leaving you to guess why uploads suddenly stopped working.

What Harish built

Harish's PR wasn't a quick hack. It was a proper module with clear boundaries:

File	Role
`src/devpub/api/uploads.py`	`ImageUploader` class with all HTTP logic
`src/devpub/cli/images.py`	Click command + Rich table output
`tests/test_uploads.py`	29 tests, all HTTP-mocked with respx

Three things stood out in his implementation:

1. Fail before the network. File existence, extension validation, and size check (25 MB limit) all happen before any HTTP request fires. A typo in a filename costs zero network round-trips.

2. Flexible response parsing. Dev.to's upload response isn't documented, so the _extract_url method handles every response shape that's been observed: links.url, image.url, images[0], a raw string. If none match, it raises with the full response body included. A wrong URL silently landing in your article would be worse than a loud error.

3. Cookie flexibility. You can paste the full cookie header (a=1; b=2; _Devto_Forem_Session=xyz) or just the session value. Both work. Because copying one value out of DevTools is easy to get wrong.

The PR description was thorough. Design rationale for keeping ImageUploader separate from DevtoClient (different auth models shouldn't share a class). Explicit call-out that tests pin the request shape, not the live response. A suggestion to smoke-test against a real session before release.

This is what good open source contributions look like. Not just code that works, but code that explains why it works that way.

Other changes in v0.3.0

Beyond the upload feature:

Fixed hardcoded User-Agent: Was stuck at devpub/0.1.0. Now reads the actual version from importlib.metadata.
Fixed empty API key edge case: DevtoClient(api_key='') used to fall through to environment variables silently. Now it raises.
Repo cleanup: Removed personal draft articles from tracking, updated .gitignore for research docs and recordings.

Try it yourself

pip install devpub==0.3.0

For uploads, you need the session credentials (one-time setup):

# Add to .devpub/.env
DEVPUB_SESSION_COOKIE=your_session_cookie_here
DEVPUB_CSRF_TOKEN=your_csrf_token_here

Then:

devpub upload cover.png              # Upload and get URL
devpub upload *.png --markdown       # Ready-to-paste Markdown tags
devpub upload diagram.png --dry-run  # Validate without uploading

Full source: github.com/simplynadaf/devpub

What's next

Two follow-ups that Harish explicitly scoped out of his PR (smart -- ship the primitive first, then build on it):

Auto-rewrite during push: devpub push could detect local image paths like ![](./figures/arch.png), upload them automatically, and rewrite the URLs in-place before publishing.
Cover image shortcut: devpub push -f article.md --cover photo.png to upload the image and set cover_image in frontmatter in one step.

Both become trivial now that the upload primitive exists.

Shoutout

Big thanks to Harish @harishteens for the first external contribution to devpub. The PR was clean, well-tested, and properly documented. If you're looking for an open-source project to contribute to, devpub has open issues ranging from beginner-friendly to architecturally interesting.

What's your image workflow for Dev.to articles? Drag-and-drop in the browser? Hosted on GitHub? Imgur? I'd like to know if devpub upload fills a gap people feel, or if everyone's already solved this differently.

Free AWS Certification for Students: The Complete Step-by-Step Guide

Sarvar Nadaf — Mon, 31 Aug 2026 11:42:29 +0000

👋 Hey there! I'm Sarvar, a Cloud Architect who spends most days building on AWS and Azure, and the rest writing about it. Last year I wrote a guide on getting a free AWS certification voucher. Around 85,000 of you read it. You can still see it here: Unlocking Free AWS Certifications: Your Step-by-Step Guide. Then AWS closed that program (the old AWS Educate ETC route), and for the next year my comment section became a support desk. The same questions came up again and again: "my voucher got denied," "I don't see the reward," "when is it coming back?"

It's back. And this version is better.

On August 20, 2026, AWS launched Student Rewards on AWS Builder Center. If you are a student, you get 12 months of premium training, up to $30 in AWS credits, and a $100 certification exam voucher. Total value: $579. Your cost: $0.

No credit card. Ever. You never pay anything and you never enter a card. If you are a student, this is as close to free money for your career as it gets.

This is the step-by-step guide I promised you last year. I have added a full tips-and-tricks section so you skip the mistakes that got hundreds of people stuck. Take a breath. This is doable, and I will walk you through every step. Let's go. 🚀

What do you get?

When you verify that you are a student and finish your profile, rewards unlock in stages as you earn badges on Builder Center.

Milestone	Reward
Verified + profile complete	12 months Skill Builder premium ($449 value)
7 badges	$10 AWS credits
14 badges	$20 AWS credits
21 badges	$100 Foundational exam voucher

A quick word on those AWS credits: they are like store money for AWS. You use them to run real services (a small server, a database, some storage) while you practice, so you can learn hands-on without paying from your own pocket.

That $100 voucher covers the full price of one Foundational exam. You pay nothing for the exam.

Which exam should I pick?

The voucher works for either of AWS's two beginner certifications:

AWS Certified Cloud Practitioner (CLF-C02): pick this if you are new to cloud and want the classic, most-recognized starter cert.
AWS Certified AI Practitioner: pick this if you are curious about AI and cloud together.

Both are entry-level. Both are made for people with little or no hands-on experience. Both count for the voucher. If you are unsure, go with Cloud Practitioner. It is the one recruiters know best.

One honest heads-up before you start: the credits come fast, the voucher takes longer. I explain why in the timing section, so read that before you plan. The good news is you get your first win in the first two weeks.

Who is eligible?

Three conditions, all confirmed on the official Student Rewards page:

You are 18 or older.
You are a student at an accredited higher education institution.
Your enrollment can be verified (AWS uses a third-party service called SheerID for this).

The program is global, open to students at accredited institutions worldwide, subject to verification and local terms. A small number of countries are excluded by AWS voucher terms (Cuba, Iran, North Korea, Syria, Russia, and Crimea), so if you are there this offer will not apply.

How do I verify as a student?

This is step one, and from my experience with the old program, it is where the first batch of people get stuck. AWS hands verification to SheerID. You sign in with your Builder ID, give SheerID a few details, and it checks enrollment records.

The official page says most verifications finish within minutes. If SheerID needs a document from you, that review typically takes 24 to 48 hours.

You will provide:

Your name
Your college or school name
Your school email address

If the instant check needs backup, SheerID asks for a document showing your name, your school name, and a current enrollment date. Based on SheerID's own student FAQ, these work:

School ID card with an expiration date
Class schedule
Tuition receipt

💡 Tips for passing verification on the first try

These come from watching people fail (and fix) verification on my last guide:

Match your name to your school records, not your nickname. If your university has you as "Mohammed A. Khan" and you type "Mo Khan," the automatic check can fail. In my experience this is the number one reason verification bounces.
Use your school email. The official page asks for it specifically, and it clears the instant check far more often than a personal Gmail.
You are allowed to black out sensitive info on uploaded documents. Cover your ID number or address. Keep your name, school name, and the date visible. SheerID says it deletes documents after review.
Verify on your own device. Shared or public machines that already ran a verification can trip an error.
If you hit an error, check your details for typos first, then contact SheerID support. If the reward itself is the problem after you are verified, that is an AWS/Builder Center issue, not SheerID.

How do I earn the 21 badges?

Here I need to be honest with you about sources. The official Student Rewards page says you earn badges by continuing to take actions on Builder Center: "Publish articles, comment, and maintain streaks." AWS publishes the full badge criteria in its own FAQ at builder.aws.com/faq#badges. What AWS does not publish in a neat table is the exact duration of every streak.

So the breakdown below combines what AWS confirms (badges exist, streaks exist, these actions count) with what students are actively reporting on their profiles and what I have pieced together tracking the program. Treat the exact day counts as community-reported, not gospel, and check the official FAQ for the current criteria.

Badges fall into four kinds, and understanding the mix is the whole game.

One-time badges (the quick wins): completing onboarding, adding a profile photo, reading content, making your first post, submitting your first Wish (a Wish is a feature request you send to AWS through the Wishlist), and publishing your first article. These are the fastest badges you will earn, and you can grab most of them on day one.

Streak badges (the backbone): sign-in, like, and comment streaks. Students report these come in 7-day, 30-day, and 90-day tiers, so the longest ones are what stretch the timeline. I explain how to handle them below.

Weekly streak badges: voting on Wishes and publishing articles on a weekly cadence over several weeks.

Community badges (the hard part): these depend on other builders reacting to you. Getting replies on your comments, collecting likes across your comments, publishing articles that get engagement, and posting Wishes that gain traction. Because they rely on other people, they take the longest to control.

Where are the buttons? (the part that confuses everyone on day one)

When you first open Builder Center, you will not know where anything is. That is normal. I got a hundred messages last year that were basically "I want to do it but I cannot find the button." So here is exactly where to click:

Add your profile photo: open your profile, add a photo, hit save. That alone unlocks your first big reward (12 months of Skill Builder). Do this first.
Your first post: join a Space first (a Space is just a topic room, like a group chat for a subject), then create your post inside it.
Your first Wish: go to the Wishlist, click +, then Create Wish, and write one small AWS idea you wish existed. Tip: look through the Wishlist first and support an existing Wish, AWS prefers that over a duplicate.
Your first article: click +, then Create Article, write, then Preview → Publish. It does not have to be long. A short honest post about what you learned this week is enough.

New to all of this? Bookmark the official Your Guide to Builder Center. It walks you through the platform in plain steps.

Watch your number go up

Here is the part that keeps you motivated. You do not jump from 0 to 21 in one leap. You climb it, and every stage is a small win you can feel:

Finish the easy day-one badges → you are already at about 6 / 21. On your first day. That fast.
Hold your daily habit for a week → around 9 / 21.
Add the weekly article and Wish-vote streaks → about 11 / 21.
Keep going to 30 days → roughly 14 / 21, and by now your $10 and $20 credits have landed. 💰
Build a little community engagement → around 18 / 21.
Finish the long streaks near 90 days → 21 / 21. Voucher unlocked. 🎉

See it? More than half your badges come in the first few weeks. The last stretch is just showing up. If you can open an app once a day, you can do this.

The timing trick nobody tells you

First, the good news, because it matters most. You get real rewards fast. The one-time badges take a day or two. Keep a small daily habit going and you hit 7 badges within your first couple of weeks, which unlocks your first $10 in credits. Reach 14 badges over the next couple of weeks and $20 more lands. So you are not waiting three months for your first reward. You get an early win almost right away, and that early win is what keeps you going.

Now the part nobody explains, and it is based on how the streaks work rather than an official AWS statement.

The streaks stack. They do not reset each stage. Think of it as one simple daily habit: sign in, like a post, leave a real comment. That same habit feeds the 7-day, 30-day, AND 90-day streak badges all at once. You are not doing three separate things. You are doing one small thing every day, and it counts three times.

Here is the honest truth about the $100 voucher: if the longest streak really is 90 days (which is what students are reporting), then the voucher takes about 90 days of showing up daily. There is no shortcut past a time-based streak. But that is fine, because your credits already arrived early, and 90 days is exactly the time you need to study anyway. More on that later.

So the plan is simple:

Day 1: grab all the one-time badges, and start your daily habit (sign in, one like, one comment). That is it for today.
First 2 to 4 weeks: you clear the short streaks and weekly streaks. $10 credit at 7 badges, $20 at 14 badges. Your first wins.
Around 90 days: the long streaks finish, you cross 21 badges, and the voucher unlocks.

The single most important move: start the daily habit on day one. Everything else follows from that.

🎯 More badge tips and tricks

Based on my experience running the last program and watching how this one behaves:

Set a phone alarm for the daily three. Sign in, one like, one comment. Ten minutes a day. On a long streak, one missed day is expensive, so protect the habit.
For article streaks, keep them small. A few short, honest articles beat one giant post you never finish. Write about what you learned in your course that week. That is enough.
Comment with substance, not "nice post." The community badges need other people to like and reply to you. A real question at the end of your comment earns replies. "Great article" gets ignored.
Check the Wishlist before posting a Wish. AWS suggests commenting on an existing Wish rather than duplicating one. Better engagement, and it still counts.
Start the community badges early. They depend on other builders, which you do not control, so give them the most runway.

How do I claim and use the voucher?

Once you hit 21 badges, the voucher appears in your rewards. From my last guide's comment section, this is where the real confusion lived, so let me pre-answer it.

⚠️ The mistakes that got people stuck last time

I answered these same questions dozens of times in my last guide's comments. Here is what I learned, so you skip the queue.

"My reward isn't showing after I hit the milestone." I lost count of how many people panicked here. The dashboard lags. Last year it took two to three days to update for most people. Wait it out before you open a ticket.
"The voucher got denied." One reader tried three times in a row and kept failing. The fix was almost always the same: their training account email did not match their program email, so their progress was split across two profiles. Confirm you are using one account, one email, everywhere.
"I have an existing AWS training account and can't link it." A reader hit a 500 error every time he tried to reset his password to link accounts. This is a known issue. Reset your password at the AWS Training and Certification portal first, then link. If the reset still errors, use a different email or contact support.
Do not let the voucher expire. This is the one that hurts most. You will have done months of work to earn it. AWS exam vouchers carry a redemption deadline, and yours will state its own expiry date when it lands. Book your exam that same day. From my experience, people grind for months and then lose the voucher to the clock. Do not be that person.

To book: take the voucher code into the AWS Certification portal, schedule the CLF-C02 or AI Practitioner exam, and apply the code at checkout. Cost drops to $0.

Turn the voucher into a real certificate, for free

A voucher is not a certificate. You still have to pass the exam. Here is the best part, though: the same program already gave you 12 months of premium Skill Builder the day you verified. That is your study material. You do not need to buy a single course or pay for anything.

And do not be scared of the exam. Cloud Practitioner is the easiest AWS certification. It is built for people with zero hands-on experience. It tests whether you understand cloud basics, not whether you can build complex systems. Most people pass with three to four weeks of steady study. If you have been doing your daily badge habit, you already have the time built in.

The exam (CLF-C02) is 65 questions, 90 minutes, and you pass at 700 out of 1000. It covers four areas:

Cloud Technology and Services (34%)
Security and Compliance (30%)
Cloud Concepts (24%)
Billing, Pricing, and Support (12%)

📚 A free 4-week study plan from your Skill Builder access

Weeks 1 to 2: work through the official CLF-C02 exam prep course in Skill Builder. Start with Security and Cloud Technology, since together they are 64% of the exam.
Week 3: do the hands-on labs your premium access unlocks. Clicking around S3, EC2, and IAM yourself sticks far better than reading about them. Use your free credits here.
Week 4: take the official practice question set. If you score above 75% a few times in a row, book the real exam. You are ready.

Notice the rhythm: the badges take around 90 days, and that is also plenty of time to study. Do both together. Study a little while you keep your daily streak alive. By the time badge 21 hits, you are exam-ready and the exam costs you nothing.

Why bother? What this does for you

Let me be clear about why 90 days of small daily effort is worth it. This certificate goes on your CV and your LinkedIn. Recruiters search for it. For a student with no work experience yet, an AWS certification is proof you can learn cloud, and cloud skills are in demand everywhere. You walk out with a real, verifiable credential that companies recognize, and it cost you nothing but consistency.

Wrapping up

Last year, 80,000 people wanted a free AWS certification. The program they used closed. This one replaced it, and it gives you more: training, credits, and the voucher, all free for students.

The whole path costs nothing but time and showing up. Verify today. Start your daily habit today. Study a little each week while the badges add up. In about 90 days you can sit a free exam already prepared, and walk away certified.

You can do this. Thousands of students are doing it right now, and so can you.

Your turn: which exam are you going for, Cloud Practitioner or AI Practitioner? Drop it in the comments and tell me what day of your streak you are on. I reply to comments, and we can keep each other going. 👇

Happy learning. 🚀

NexPath Review: The Prompt Quality Layer for Cursor, Windsurf and Claude Code

Sarvar Nadaf — Thu, 27 Aug 2026 13:21:53 +0000

I've been building devpub, an open-source CLI that publishes and tracks articles on Dev.to. Last week I was in Cursor, adding a new analytics feature - full vibe coding mode, rapid-fire prompts, one after another:

"add caching to the API client."

"fix the rate limiter."

"make the analytics faster."

Three prompts, three pieces of code generated instantly. I moved on. Two days later I realized the "fix" had silently broken my retry logic, the "caching" had no invalidation strategy, and "faster" meant the agent had removed the safety throttle that prevents Dev.to from banning my API key.

None of those prompts said what shouldn't change. None specified how I'd know it worked. I wrote them in flow, and the agent did exactly what I asked. Which wasn't what I meant.

That's when I tried NexPath, a prompt quality layer for AI coding agents. It sits between you and your agent, catches vague prompts at the moment you submit them, and offers a stronger version. I thought: why not try this on devpub? A real codebase I know inside out, with real prompts I'd actually type. If it works here, it works anywhere.

The vibe coding pattern nobody talks about
What if something caught you before you hit Enter?
What the enhanced version includes
My hands-on experience with NexPath
NexPath agent support: Cursor, Windsurf and Claude Code
Who NexPath is for: Cursor, Windsurf and Claude Code users
What NexPath costs
Bottom line

The vibe coding pattern nobody talks about

Every developer using AI coding agents has a version of this story. Not because the agents are bad. They're incredibly good at generating code from whatever you give them. The problem is what we give them.

"Fix this." "Make it work." "Clean up the code." "Add auth."

These prompts feel productive. The agent responds instantly. Code appears. You move to the next thing. But six prompts later, your codebase has grown in directions you didn't plan, with assumptions you didn't state, skipping checks you didn't ask for.

The same mistakes repeat: no acceptance criteria, no rollback plan, no mention of what shouldn't change. Not because we don't know better. Because momentum makes it easy to skip.

The answer, I thought, was more discipline. Be better at prompting. Write longer, more detailed requests every time.

That lasted about three days.

What if something caught you before you hit Enter?

NexPath is not another coding agent. It doesn't generate code. It doesn't replace your agent. It doesn't try to be clever. It sits between you and your AI agent, and when you submit a vague prompt, it holds it for a second and says: "Here's a stronger version of what you meant. Want to use it instead?"

The simplest way I'd describe it: "NexPath is the thing that keeps AI-generated code from becoming a mess."

The workflow:

You write your prompt in Cursor, Windsurf, or Claude Code
NexPath intercepts it at submit time
A popup shows your original alongside an enhanced version
You pick which one gets sent
The chosen version auto-submits to your agent

Your original intent stays visible throughout. Nothing auto-sends without your approval. If a prompt doesn't need enhancement, NexPath stays silent.

What the enhanced version includes

When the enhancement fires, it doesn't rewrite your prompt. It wraps your original request with:

Scope boundaries: what should change, what shouldn't
Acceptance criteria: how you'll know it worked
Verification steps: tests to run after
Safety requirements: rollback plan for risky operations
Sequencing: if the task is complex, break it into ordered steps

Here's a real example from my devpub testing. I typed:

fix the rate limiter

NexPath enhanced it to something like:

Fix the rate limiter in DevtoClient._throttle(). Scope: only modify the timestamp tracking logic in src/devpub/api/devto.py. Do not change RATE_LIMIT_REQUESTS or RATE_LIMIT_WINDOW constants. Do not modify the retry logic in _request(). Acceptance: 30 requests per 30-second window still enforced, no sleep longer than 30s. Verify: run pytest tests/test_api.py after changes.

That's what I should have written in the first place. But I didn't, because I was in flow.

Another one. I typed:

push all drafts to dev.to as published

NexPath flagged the risk and added:

Push all draft articles to Dev.to with published=true. WARNING: This is a destructive action. Published articles are immediately visible to readers and cannot be easily unpublished. Scope: only modify the published field in article payloads. Safety: list all affected articles first and confirm count before proceeding. Rollback: note all article IDs changed so they can be reverted to draft if needed. Verify: check each article URL returns 200 after publishing.

The difference between "just do it" and "do it carefully," surfaced at exactly the right moment.

My hands-on experience with NexPath

I tested NexPath in two environments: Cursor on my laptop for the popup experience with devpub, and Claude Code on my EC2 server to stress-test the CLI and dig into the internals.

Installation (2-3 minutes, clean)

git clone https://github.com/hi0001234d/nexpath.git
cd nexpath
npm install        # 16 seconds, 298 packages
npm run build      # Build + 1,175 test validation
npm link
nexpath install    # Auto-detected my agents, wrote hooks

The nexpath status command gives you a complete picture: prompt store stats, hook activity, config state, environment detection. The level of observability in the CLI surprised me. Structured JSON logs, proper error codes, debuggable output.

What I liked

Privacy holds up. Everything lives in ~/.nexpath/. A SQLite database stores your prompts locally. The only outbound calls are to OpenAI's API (GPT-4o-mini for classification). Telemetry is disabled by default, confirmed in config. Secret redaction strips API keys from stored prompts automatically.

The engineering is solid. 1,803 commits from a team of three. 1,175 tests in the VS Code extension alone. Structured logging. Environment detection (OS, WSL, CI, devcontainer). Proper config system with keychain integration. This is not a weekend hackathon project abandoned after the demo, even though it started at one (AI Hackfest 2026 by MLH).

It knows when to shut up. The system classifies your prompts into development stages (idea, architecture, implementation, testing, etc.) and only fires when it detects a transition or an absence signal: a missing spec, a skipped test strategy, a risky shortcut. When your prompts are already well-structured, it stays out of the way.

The popup experience just works. In Cursor, you type your prompt, hit Enter, and NexPath holds it for a beat. A popup appears showing your original alongside the enhanced version. You pick one, it auto-submits. No context switch, no copy-paste, no extra windows. It feels like a natural part of the workflow, not an interruption.

Environment awareness is thorough. The nexpath env command probes your OS, detects WSL, devcontainers, CI pipelines, shell type, project framework, version control, test runner, and deploy config, all locally. It uses this context to calibrate when and how it intervenes. That level of situational awareness is rare in developer tooling.

What needs work

API key handling has a rough edge. NexPath requires an OpenAI API key (for GPT-4o-mini). Their docs say it falls back gracefully to local classification when no key is available. In practice, after the first prompt, subsequent calls throw an unhandled OpenAIError: Missing credentials exception instead of degrading silently. It's a v1 edge case, easily fixable, but worth knowing if you're setting up on a fresh machine without a key configured yet.

The CLI advisory and the VS Code popup are different systems. The submit-time popup (Cursor/Windsurf) is the primary product. It intercepts every prompt at the moment you press Enter. The CLI advisory for Claude Code is a different mechanism that builds up session history before intervening. In my CLI stress test, it captured 18 prompts and intervened zero times because it needs longer session context to detect meaningful transitions. The popup experience doesn't have this limitation. It evaluates each prompt independently. If you're on Claude Code, expect a quieter experience than the Cursor/Windsurf popup.

Single LLM provider for now. It currently uses gpt-4o-mini as the classification model, a reasonable v1 tradeoff that limits flexibility for teams using other providers. The API costs are tiny (pennies per day), but multi-provider support would make it more accessible to teams with existing Anthropic or Groq setups.

NexPath agent support: Cursor, Windsurf and Claude Code

Agent	Status (Aug 2026)
Claude Code	✅ Supported via CLI + MCP hooks
Cursor	✅ Supported via VS Code extension (submit-time popup)
Windsurf / Devin	✅ Supported via VS Code extension (submit-time popup)

The VS Code extension (for Cursor and Windsurf) intercepts prompts at submit time and shows the popup inline. For Claude Code, it works through the CLI's hook system, firing between prompt submissions.

Important distinction: the Cursor/Windsurf experience is the polished one. You type, hit Enter, NexPath catches it, shows a popup, you pick, it sends. The Claude Code experience works through terminal hooks, which is less visual but functional.

Who NexPath is for: Cursor, Windsurf and Claude Code users

NexPath makes sense if you:

Prompt in short bursts ("fix this", "add that") and want guardrails without slowing down
Work on production codebases where a vague prompt can cause real damage
Want prompt discipline without having to be disciplined every single time
Use Cursor or Windsurf as your primary agent environment

It's less useful if you already write detailed, structured prompts consistently, or if you're building throwaway prototypes where quality doesn't matter.

What NexPath costs

NexPath itself is free (Apache 2.0, open source). The only cost is your OpenAI API key usage for GPT-4o-mini. In a typical coding session, that's $0.01 to $0.05 per day. Negligible, but not zero.

Bottom line

NexPath solves a problem I have: I write lazy prompts when I'm in flow, and those lazy prompts produce code that bites me later. The idea of a quality layer that catches me at the moment of submission, not after the damage is done, is genuinely useful.

I tested it on devpub, my own open-source project with a real API client, real rate limiting, real push-to-production workflows. The prompts I'd normally fire off ("fix the rate limiter", "push all drafts as published") came back stronger, scoped, and safe. That's the value.

The implementation on Cursor/Windsurf (submit-time popup, choose your version, auto-submit) is well-designed. The CLI experience for Claude Code needs more polish. The engineering underneath is serious, the privacy model is honest, and the team ships fast (20+ PRs merged in the 48 hours before launch).

Is it perfect? No. The API key handling has a rough edge. The single-provider model limits flexibility. The CLI advisory needs longer sessions to activate. But for a v0.1.4 open-source tool from a three-person team, it's solving the right problem in the right place, and the Cursor/Windsurf popup experience is genuinely well-executed.

I'll keep it installed. The first time it catches a dangerous prompt I would have sent unthinking, it pays for itself.

Try it yourself:

GitHub: NexPath on GitHub
VS Code Marketplace: NexPath VS Code extension for Cursor and Windsurf
Open VSX: NexPath on Open VSX
Demo: Prompt Enhancement in action

NexPath is running a Launch Feedback Challenge (ends Sep 2, 2026). They're looking for honest feedback, not praise. If you try it and have opinions, good or bad, share them at their discussion thread.

What's your approach to prompt quality? Do you write detailed prompts every time, or do you also fall into the "fix this" trap? Let me know in the comments.

I Built an AWS DevOps AI Agent Using Kiro Crew + MCP

Sarvar Nadaf — Mon, 24 Aug 2026 11:30:54 +0000

At 3:17 AM last Tuesday, my payment-api ECS service entered a terminal failure loop. 7,279 failed tasks since August 13th. The health check expected /api/health but the container only served static content. Every 60 seconds, ECS killed the task and replaced it. Burning compute the entire time.

No alarm fired. I never set one up. No PagerDuty page. No Slack alert. Just a service churning through resources that nobody was watching.

I slept through the whole thing. And woke up to a solved problem.

Not because I got lucky. Because my Kiro Crew agent was awake. It spawned 5 parallel investigations, called AWS DevOps Agent for a health assessment, found the root cause across ECS, CodeBuild, CodePipeline, and Lambda, and flagged everything with severity-prioritized fixes. By 3:24 AM, done.

This is Part 6 of my Kiro Crew series. Parts 1 to 5 showed what Crew can do: orchestrate agents, run cron jobs, enforce security, build custom apps. This one shows what happens when you connect it to AWS's production intelligence engine.

Watch the 12-min demo above to see the full autonomous investigation in action.

The problem nobody talks about
What AWS DevOps Agent actually is
The integration: one MCP config block
The architecture
Live demo: what the agent found
Applying the fixes
The cron job: check every 30 minutes
The investigate skill: deep root-cause analysis
The security model: why this is safe
The self-learning layer
34 tools at your agent's fingertips
Cost considerations
Try it yourself (complete walkthrough)

The problem nobody talks about

Every DevOps team I've worked with has the same gap: the space between "something went wrong" and "someone noticed."

PagerDuty fires when alarms trigger. But what about the things you never set alarms for? The ECS service silently cycling through failed tasks for four days straight. The CodeBuild project that's been FAILED since last week with nobody looking at it. The Lambda with a 3-second timeout calling a service that needs 6 seconds to respond.

These aren't incidents. They're slow leaks. And they only become incidents when a customer complains or the bill arrives.

I've seen this pattern across a dozen client engagements. The monitoring is always incomplete. The alarms cover the obvious cases. The subtle failures accumulate silently until something visible breaks.

The enterprise reality today

Here's what incident response looks like at most organizations I've consulted for:

Step	Who	Time	Problem
Alert fires	PagerDuty/OpsGenie	0 min	Only works if alarm exists
Engineer wakes up	On-call human	5-15 min	Context switch, fatigue, stress
Login to console	Human	5 min	MFA, VPN, finding the right account
Check CloudWatch	Human	10 min	Which metrics? Which log group? Which time window?
Correlate signals	Human	15-30 min	Was there a deployment? Config change? Upstream issue?
Identify root cause	Human	15-60 min	Experience-dependent, often wrong first guess
Write fix	Human	10-30 min	Under pressure, at 3 AM, with fatigue
Apply + verify	Human	10 min	Hope it doesn't make things worse
Total MTTR		1-3 hours	And that's IF an alarm existed

The real killer: if no alarm was configured, this entire process never starts. The failure just accumulates until someone notices manually.

How our approach changes this

Step	Who	Time	Difference
Cron fires (every 30 min)	Kiro Crew	0 min	No alarm needed, proactive scanning
Check all services	Crew + DevOps Agent	30 sec	Parallel, covers everything
Correlate signals	DevOps Agent	60-90 sec	X-Ray, CloudWatch, deployments, topology
Identify root cause	DevOps Agent	2-3 min	Consistent, no fatigue, no wrong guesses
Generate mitigation plan	DevOps Agent	90 sec	Exact CLI commands, rollback steps included
Apply fixes	Kiro Crew	30 sec	Or: open PR for human review
Verify healthy	Kiro Crew	30 sec	Automated validation
Total MTTR		5-7 minutes	No human woken up

The architectural insight

AWS designed DevOps Agent as a read-only investigator. It observes, correlates, and produces mitigation plans with exact commands. But it never executes anything. That's intentional (security: no prompt injection risk from write operations).

Kiro Crew fills that gap. It takes DevOps Agent's mitigation plan and executes it (or opens a PR for human approval in production).

The separation:

DevOps Agent = the brain (read-only, investigates, produces exact fix commands)
Kiro Crew = the hands (orchestrates, executes, verifies, learns from past incidents)

Neither alone solves the problem. Together: autonomous incident response that runs 24/7, catches issues before customers notice, and gets smarter with every incident.

What enterprises gain

No more silent failures. Cron catches issues whether or not alarms exist.
Consistent investigation quality. DevOps Agent doesn't get tired at 3 AM or skip steps under pressure.
75% lower MTTR. AWS reports 75% reduction in customers using DevOps Agent. Adding Crew automation pushes it further.
Institutional memory. Crew's Knowledge base remembers every past incident. New team members inherit years of operational wisdom.
Audit trail by default. Every investigation, every fix, every decision logged in CloudTrail and Crew sessions.
Human-in-the-loop when you want it. Trust mode for non-critical environments, PR approval for production.

What if an agent checked for you? Every 30 minutes. Autonomously. While you sleep, eat dinner, or take your kid to the park.

What AWS DevOps Agent actually is

AWS DevOps Agent went GA in March 2026. Think of it as an always-on SRE that knows your AWS infrastructure intimately:

What it monitors:

Amazon ECS (services, tasks, deployments, health checks)
AWS Lambda (invocations, errors, duration, throttles, cold starts)
Amazon API Gateway (5xx errors, latency, integration failures)
Amazon RDS (connections, CPU, storage, replication lag)
Amazon DynamoDB (throttles, capacity, latency)
Amazon EC2 (status checks, CPU, network)
Amazon S3 (error rates, request patterns)
Amazon CloudWatch (alarms, metrics, anomalies)

What it does with that data:

Discovers and maps your service topology automatically
Correlates signals across metrics, traces, deployments, and configuration changes
Investigates incidents with deep async root-cause analysis (takes 5 to 8 minutes per investigation)
Generates recommendations with specific, actionable mitigations prioritized by severity
Reviews releases by checking pull requests for production risk patterns before they ship

The feature that makes this article possible: DevOps Agent exposes all of this over MCP (Model Context Protocol). That means any MCP-compatible client can call its 34 tools programmatically. Including Kiro Crew.

MCP Endpoint: https://connect.aidevops.{region}.api.aws/mcp

A2A Endpoint (agent-to-agent): https://connect.aidevops.{region}.api.aws/a2a/*

Supported Regions: us-east-1, us-west-2, eu-west-1 (as of August 2026)

The integration: one MCP config block

Connecting DevOps Agent to Kiro Crew takes one config block. I did this live in the terminal during the demo. Before adding it, I had 9 MCP servers configured in Crew. After: 10.

import json

config = json.load(open('/home/ubuntu/.kiro/settings/mcp.json'))
config['mcpServers']['aws-devops-agent'] = {
    'url': 'https://connect.aidevops.us-east-1.api.aws/mcp',
    'headers': {'X-Agent-Space-Id': '7ab2314d-15e8-4744-a1a7-3f96692fcd83'},
    'description': 'AWS DevOps Agent (34 tools)',
    'disabled': False
}
json.dump(config, open('/home/ubuntu/.kiro/settings/mcp.json', 'w'), indent=2)
# Output: ✅ Added aws-devops-agent (10 total servers)

I verified the connection by calling tools/list against the MCP endpoint:

Tools available:
  • get_service
  • list_agent_spaces
  • get_agent_space
  • create_agent_space
  • update_agent_space
  • create_access_token
  • get_access_token
  • list_access_tokens
  • revoke_access_token
  ... and 24 more

Endpoint: https://connect.aidevops.us-east-1.api.aws/mcp
Space:    7ab2314d-15e8-4744-a1a7-3f96692fcd83

34 tools. Live connection confirmed. Your Crew agent can now call any of them.

Alternative: SigV4 authentication (recommended for production)

If you don't want to manage bearer tokens, use AWS SigV4 via mcp-proxy-for-aws:

{
  "mcpServers": {
    "aws-devops-agent": {
      "command": "uvx",
      "timeout": 120000,
      "args": [
        "mcp-proxy-for-aws@latest",
        "https://connect.aidevops.us-east-1.api.aws/mcp",
        "--service", "aidevops",
        "--region", "us-east-1"
      ]
    }
  }
}

This uses your existing AWS credentials (from ~/.aws/credentials or instance profile). No separate token to rotate.

The architecture

Here's the full autonomous pipeline:

┌──────────────────────────────────────────────────────────────┐
│                       KIRO CREW                               │
│                                                               │
│  ┌───────────────┐     ┌──────────────────┐                  │
│  │  Cron Job     │────▶│  Orchestrator    │                  │
│  │  (*/30 * * *) │     │  (claude-sonnet) │                  │
│  └───────────────┘     └────────┬─────────┘                  │
│                                 │                             │
│                    Spawns 5 parallel subagents                │
│                                 │                             │
│        ┌────────────────────────┼────────────────────┐       │
│        ▼            ▼           ▼          ▼         ▼       │
│  ┌──────────┐ ┌──────────┐ ┌────────┐ ┌────────┐ ┌──────┐  │
│  │   ECS    │ │  CI/CD   │ │CloudW. │ │DevOps  │ │Lambda│  │
│  │  Check   │ │  Check   │ │ Check  │ │ Agent  │ │Check │  │
│  └────┬─────┘ └────┬─────┘ └───┬────┘ └───┬────┘ └──┬───┘  │
│       │             │           │          │         │       │
│       └─────────────┴───────────┴──────────┴─────────┘       │
│                              │                                │
│                    Consolidated findings                      │
│                    (severity-prioritized)                     │
│                              │                                │
│                    ┌─────────▼──────────┐                    │
│                    │  Coding Agent      │                    │
│                    │  (writes fix, PR)  │                    │
│                    └─────────┬──────────┘                    │
└──────────────────────────────┼───────────────────────────────┘
                               │
              ┌────────────────┼────────────────┐
              ▼                                 ▼
   ┌────────────────────┐            ┌──────────────────┐
   │  AWS DevOps Agent  │            │     GitHub       │
   │  (MCP endpoint)    │            │  (Pull Request)  │
   │                    │            │                  │
   │  - chat            │            │  Human reviews   │
   │  - investigate     │            │  in the morning  │
   │  - recommend       │            │                  │
   └────────────────────┘            └──────────────────┘

The flow:

Cron fires every 30 minutes (*/30 * * * *)
Orchestrator (claude-sonnet-4) spawns 5 parallel subagents
Each subagent checks one domain: ECS, CI/CD, CloudWatch, DevOps Agent consultation, Lambda
All run simultaneously (not sequential, this matters for speed)
Results consolidated into severity-prioritized findings
If actionable: Coding Agent writes the fix, opens a PR on GitHub
Human reviews the PR in the morning

The agent can investigate but never deploy. That's the safety boundary.

Live demo: what the agent found

I triggered the investigation with one natural prompt:

"Something's wrong with my payment-api service. I think builds are failing and the pipeline is stuck. Check everything: ECS, CodeBuild, CodePipeline, Lambda timeouts, and CloudWatch alarms. Also try calling DevOps Agent via awscurl for a health assessment. Tell me what's broken and how to fix it, prioritized by severity."

The agent spawned 5 parallel subagents. I watched them work in real time:

Subagent	ID	Focus	Tools Used
ECS Investigation	921383af	Service status, task definitions, health checks	14 tools
CI/CD Investigation	6a99eac8	CodeBuild status, CodePipeline state, build logs	14 tools
CloudWatch Investigation	7e55ac60	Alarms, logs, metrics for service health	14 tools
DevOps Agent Consultation	ae0b20b6	MCP endpoint call via awscurl	3 tools
Lambda Investigation	488d2596	Timeouts, errors, Step Functions state	11 tools

All five running simultaneously. The DevOps Agent consultation alone took 67 seconds (it calls multiple AWS APIs behind the scenes). Total investigation: under 3 minutes.

Here's what came back:

🚨 CRITICAL OUTAGE (4+ Days Down)

ECS Service in Terminal Failure Loop

Finding	Detail
Failed tasks	7,279 since August 13th
Root Cause	Health check expects `/api/health` but nginx:alpine only serves static content
Current State	4 tasks running (should be 2), all UNHEALTHY, replaced every 60-90 seconds
Resource Impact	Continuous failed task churn burning compute costs
Cluster	payment-api-cluster
Service	payment-api-service

Complete CI/CD Pipeline Breakdown

Finding	Detail
CodeCommit	Empty repository with no branches or code
CodeBuild	FAILED (can't build from empty repo)
CodePipeline	FAILED, can't find 'main' branch that doesn't exist
Impact	Builds fail every time, pipeline permanently stuck

🟡 MEDIUM PRIORITY: Configuration Hardening

Set health check grace period to 30+ seconds (currently 0)
Add proper logging and monitoring configuration
Implement proper security groups and networking

⚠️ Lambda Timeout Issue

The Demo function has a 3-second timeout calling downstream services that need 4 to 6 seconds to respond. Every invocation times out silently. Zero alarms configured to catch it.

📊 CloudWatch: Zero Observability

Zero alarms configured in the entire account. 8 Lambda functions, 5 API Gateways, 1 ECS cluster, all running completely blind. If anything fails, nobody gets notified.

None of these would have triggered a PagerDuty alert. The ECS service was burning compute for four days straight with nobody noticing.

Applying the fixes

Based on the agent's severity-prioritized recommendations, I applied two immediate fixes in the terminal:

Fix 1: Lambda timeout 3s to 30s

aws lambda update-function-configuration \
  --function-name Demo \
  --timeout 30 \
  --region us-east-1 \
  --query "[FunctionName,Timeout]" --output text
# Output: Demo    30

aws lambda update-function-configuration \
  --function-name Demo-API \
  --timeout 30 \
  --region us-east-1 \
  --query "[FunctionName,Timeout]" --output text
# Output: Demo-API    30

Fix 2: Add CloudWatch alarms (was ZERO)

# ECS task failure alarm
aws cloudwatch put-metric-alarm \
  --alarm-name "ECS-PaymentAPI-TaskFailures" \
  --metric-name CPUUtilization \
  --namespace AWS/ECS \
  --statistic Average \
  --period 300 \
  --threshold 0 \
  --comparison-operator LessThanOrEqualToThreshold \
  --evaluation-periods 2 \
  --dimensions Name=ClusterName,Value=payment-api-cluster \
               Name=ServiceName,Value=payment-api-service \
  --alarm-description "Payment API: no tasks running" \
  --region us-east-1
# Output: ✅ ECS alarm created

# Lambda error alarm
aws cloudwatch put-metric-alarm \
  --alarm-name "Lambda-Demo-Errors" \
  --metric-name Errors \
  --namespace AWS/Lambda \
  --statistic Sum \
  --period 300 \
  --threshold 1 \
  --comparison-operator GreaterThanOrEqualToThreshold \
  --evaluation-periods 1 \
  --dimensions Name=FunctionName,Value=Demo \
  --alarm-description "Demo Lambda errors" \
  --region us-east-1
# Output: ✅ Lambda alarm created

Verified state after fixes:

Lambda Demo:     30s (was 3s)
Lambda Demo-API: 30s (was 3s)
Alarms:          2 active (was 0)

In the production Crew workflow, these become a PR. The agent writes the IaC change (CloudFormation, CDK, or Terraform depending on your stack), pushes to a branch, and opens the PR with investigation findings in the description. A human reviews it in the morning.

The cron job: check every 30 minutes

Here's the cron that makes this autonomous. I added it through the Crew Schedule page:

Field	Value
Name	production-health-check
Schedule	Every 30 minutes (`/30 * * *`)
Agent	default (claude-sonnet-4)
Message	Check production health: ECS, CodeBuild, Pipeline, Lambda, CloudWatch. Flag issues with severity and fixes.

Every 30 minutes, Crew spawns a session, the agent checks infrastructure health, and reports findings. If everything's green, session ends quietly. If something's flagged, it investigates deeper and proposes fixes.

No daemon process to maintain. No EC2 instance running a cron script. No custom monitoring infrastructure. One entry in the Schedule page.

Scaling this: You can have multiple cron jobs for different concerns:

production-health    → */30 * * * *  → Full infrastructure scan
cost-anomaly-check   → 0 8 * * *    → Daily cost spike detection  
security-drift       → 0 */6 * * *  → Every 6h IAM/SG audit
release-readiness    → 0 9 * * 1-5  → Weekday pre-deploy check

The investigate skill: deep root-cause analysis

The chat tool is fast (seconds). But for real incidents, DevOps Agent has an investigate skill that runs 5 to 8 minutes of deep analysis across your infrastructure.

What the investigation does:

Pulls CloudWatch metrics: invocations, errors, duration, throttles, anomaly bands
Checks recent deployments: CodeDeploy, ECS task definitions, Lambda versions
Correlates downstream latency: X-Ray traces, API Gateway integration errors
Analyzes temporal patterns: did this start after a specific deployment?
Checks resource topology: which services depend on the failing component?
Returns root-cause analysis with prioritized recommendations

This is the same analysis flow a senior SRE would do manually. Check metrics, correlate with deployments, trace downstream, identify root cause. The difference: it happens at 3 AM without waking anyone up.

In the demo, the DevOps Agent subagent took 67 seconds to complete its assessment (you can see it in the recording: 174s • 3 tools on the subagent panel). That's because it's making multiple API calls behind the scenes to build the full picture.

The security model: why this is safe

"Autonomous agent fixing production" sounds terrifying. After running this for weeks, here's why it's not:

1. DevOps Agent is read-only by default

The IAM role uses ReadOnlyAccess. Full visibility, zero write permissions:

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": {"Service": "aidevops.amazonaws.com"},
    "Action": "sts:AssumeRole",
    "Condition": {
      "StringEquals": {
        "aws:SourceAccount": "123456789012"
      }
    }
  }]
}

Attached policy: arn:aws:iam::aws:policy/ReadOnlyAccess

It can observe everything. It can change nothing.

2. Crew's deny patterns block destructive commands

Even if the agent tries to deploy, Crew blocks it:

{
  "deny_patterns": [
    "kubectl apply",
    "aws deploy create-deployment",
    "terraform apply",
    "aws ecs update-service",
    "aws lambda update-function-code",
    "aws cloudformation execute-change-set"
  ]
}

The agent can write code. It cannot execute deployments.

3. The output is always a Pull Request

Never a direct change to production. The agent creates a branch, writes the fix, and opens a PR with:

Investigation findings in the description
Severity assessment
Links to relevant CloudWatch metrics
Diff showing exactly what changes

Human reviews and approves.

4. Full CloudTrail audit trail

Every MCP call to DevOps Agent is logged with:

{
  "eventSource": "aidevops.amazonaws.com",
  "eventName": "InvokeMcpTool",
  "requestParameters": {
    "agentSpaceId": "7ab2314d-...",
    "accessTokenId": "at-...",
    "protocol": "MCP",
    "toolName": "chat"
  },
  "sourceIPAddress": "172.31.20.246"
}

Every action traceable. Every tool invocation recorded.

5. Token scoping and rotation

Control	Detail
Scope	`read` or `operate` (choose minimum needed)
Expiration	1 to 60 days (forced rotation)
IP Allowlist	Optional, restrict to your Crew instance IP
Client Type	`agent` (for autonomous integrations)
Revocation	One-click disable all tokens

The pattern: observe everything, change nothing, suggest via PR, human approves.

The self-learning layer

Here's where Kiro Crew adds something DevOps Agent alone cannot do.

First time the agent investigates the ECS failure loop, it learns:

payment-api uses nginx:alpine as the base image
The health check path /api/health doesn't exist in that container
Health check grace period of 0 seconds means immediate failure on deploy
7,279 tasks failed before anyone noticed because zero alarms were configured

Crew stores this as a lesson in its Knowledge base. Next time it sees the same ECS task churn pattern (running count higher than desired, tasks being replaced every 60-90 seconds), it skips the full investigation and goes straight to: "Check if health check path exists in the container image. Check grace period setting."

After 30 days of running, your SRE agent has seen every failure pattern your infrastructure produces. It doesn't just find issues faster. It finds them immediately because it's seen them before.

This is the compounding advantage. PagerDuty doesn't learn from past incidents. CloudWatch Alarms don't adapt their thresholds based on patterns. Your Crew agent does.

34 tools at your agent's fingertips

When you connect DevOps Agent via MCP, your Crew agent gets access to these tools:

Investigation & Monitoring:

Tool	Description
`chat`	Instant health check, cost analysis, architecture review, topology mapping
`investigate`	Deep async root-cause analysis across all monitored services
`create_investigation`	Start investigation with priority level (P1/P2/P3)
`list_recommendations`	Get AI-generated mitigations with severity
`get_recommendation`	Detailed mitigation specification
`list_journal_records`	Stream investigation findings in real-time
`start_evaluation`	Evaluate against operational goals (SLOs)
`list_tasks`	Track async investigation status
`get_task`	Check if an investigation has completed

Release & Deployment Safety:

Tool	Description
`create_release_readiness_review`	Analyze PRs for production risk patterns
`create_release_testing_job`	Run exploratory tests on deployed apps

Service & Space Management:

Tool	Description
`get_service`	Detailed service topology, dependencies, health
`list_agent_spaces`	Manage multiple monitoring environments
`get_agent_space`	Space configuration details
`create_agent_space`	Provision new monitoring environments
`update_agent_space`	Modify space settings

Access & Security:

Tool	Description
`create_access_token`	Issue new credentials programmatically
`get_access_token`	Inspect token details
`list_access_tokens`	Audit all active tokens
`revoke_access_token`	Revoke compromised credentials immediately

Plus 14 more for full CRUD on spaces, associations, and configurations.

Your agent picks the right tool based on context. Ask "is anything broken?" and it calls chat. Say "investigate the payment API latency" and it calls investigate. No routing logic. MCP handles tool selection.

Cost considerations

Running this autonomously has cost implications worth understanding:

Kiro Crew costs:

Claude Sonnet 4 token usage per cron run (approximately $0.02 to $0.08 depending on investigation depth)
48 runs per day at */30 = roughly $1 to $4/day for continuous monitoring
Compare with: a single on-call engineer costs $200+/night

AWS DevOps Agent costs:

Included with your Agent Space (no per-API-call charges for chat/investigate as of August 2026)
The IAM role uses ReadOnlyAccess, so no resource creation costs from the agent itself

What this SAVES:

4 days of ECS task churn burning compute (in my case: ~$15-20 wasted before I noticed)
Engineer investigation time (30-60 min per incident at $100+/hr senior rate)
Customer-facing downtime (the real cost nobody measures until it happens)

The math: $2/day for continuous monitoring vs $200+ per missed incident. After one catch, it pays for itself for months.

Try it yourself (complete walkthrough)

Prerequisites

Kiro Crew installed and running (install guide)
AWS account with resources to monitor (at minimum: one Lambda function or ECS service)
IAM permissions: aidevops:* for Agent Space management
AWS CLI v2 configured with credentials
Region: us-east-1, us-west-2, or eu-west-1

Step 1: Create an Agent Space

aws devops-agent create-agent-space \
  --name "production-monitoring" \
  --description "Autonomous production health monitoring" \
  --region us-east-1

Save the agentSpaceId from the output. You'll need it for every subsequent step.

Step 2: Create an IAM role for DevOps Agent

DevOps Agent needs a role to assume when accessing your account's resources:

# Create trust policy
cat <<'EOF' > devops-agent-trust.json
{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": {
      "Service": "aidevops.amazonaws.com"
    },
    "Action": "sts:AssumeRole",
    "Condition": {
      "StringEquals": {
        "aws:SourceAccount": "YOUR_ACCOUNT_ID"
      }
    }
  }]
}
EOF

# Create the role
aws iam create-role \
  --role-name DevOpsAgentSourceRole \
  --assume-role-policy-document file://devops-agent-trust.json \
  --description "Read-only access for AWS DevOps Agent monitoring"

# Attach ReadOnlyAccess (observe everything, change nothing)
aws iam attach-role-policy \
  --role-name DevOpsAgentSourceRole \
  --policy-arn arn:aws:iam::aws:policy/ReadOnlyAccess

Important: Use ReadOnlyAccess not AdministratorAccess. The agent needs to observe, not modify. Least privilege applies here.

Step 3: Associate your AWS account with the Agent Space

aws devops-agent associate-service \
  --agent-space-id YOUR_SPACE_ID \
  --service-id aws \
  --configuration '{
    "aws": {
      "assumableRoleArn": "arn:aws:iam::YOUR_ACCOUNT_ID:role/DevOpsAgentSourceRole",
      "accountId": "YOUR_ACCOUNT_ID",
      "accountType": "monitor"
    }
  }' \
  --region us-east-1

Step 4: Enable access tokens on the Agent Space

aws devops-agent update-agent-space \
  --agent-space-id YOUR_SPACE_ID \
  --access-token-configuration '{"enabled": true}' \
  --region us-east-1

Step 5: Create an access token for Kiro Crew

aws devops-agent create-access-token \
  --agent-space-id YOUR_SPACE_ID \
  --name "kiro-crew-monitor" \
  --scope "operate" \
  --client-type "agent" \
  --expires-in-days 60 \
  --region us-east-1

Save the token value securely. You won't see it again.

Step 6: Add MCP server to Kiro Crew

In your Crew dashboard: Agent Capabilities > Integrations (MCP) > Add

{
  "mcpServers": {
    "aws-devops-agent": {
      "url": "https://connect.aidevops.us-east-1.api.aws/mcp",
      "headers": {
        "X-Agent-Space-Id": "YOUR_SPACE_ID"
      },
      "description": "AWS DevOps Agent (34 tools)",
      "disabled": false
    }
  }
}

Or via the CLI:

kirocrew config mcp add aws-devops-agent \
  --url "https://connect.aidevops.us-east-1.api.aws/mcp" \
  --header "X-Agent-Space-Id=YOUR_SPACE_ID"

Step 7: Add the production health cron job

Go to Schedule in the Crew dashboard, click + Add Job:

Field	Value
Name	production-health-check
Schedule	`/30 * * *`
Agent	default
Message	Check production health via AWS DevOps Agent. Scan ECS, Lambda, CodeBuild, CodePipeline, and CloudWatch. Flag any issues found with severity and recommended fixes.

Step 8: Verify it works

Trigger the cron manually by clicking Run in the Schedule page. You should see the agent:

Check available MCP tools
Call DevOps Agent's chat tool for a health assessment
Return findings with severity levels

If it returns "Overall: HEALTHY" with no flags, your infrastructure is in good shape. If it finds issues, you'll get severity-prioritized recommendations.

What's next

This is the setup I run daily. DevOps Agent handles observation and intelligence. Kiro Crew handles orchestration, memory, and action. Together: autonomous ops that get smarter every week.

Articles 1 to 5 built the foundation. This one connects Crew to the real world, where production issues don't wait for business hours.

The full Kiro Crew series:

Introducing Kiro Crew
I Spent a Day With Kiro Crew
Cron Jobs Replaced 4 Hours of Weekly Toil
The Security Model That Got CISO Approval
I Built a Custom App in 5 Minutes
This article: Crew + DevOps Agent autonomous ops

GitHub repo with all configs: SimplyNadaf/kiro-crew-devops-agent

What's eating your 3 AM pages? I'm betting DevOps Agent plus a cron job could handle half of them. Drop your scenario in the comments.

I Added Terminal Charts to My Dev.to CLI. Here's What My Data Looks Like.

Sarvar Nadaf — Fri, 21 Aug 2026 14:13:00 +0000

TL;DR: pip install devpub==0.2.1 → devpub stats --graph → color-gradient bar charts, sparklines, trend arrows, and multi-period breakdowns for your Dev.to analytics. Zero new dependencies. GitHub repo / PR #10.

I check my Dev.to stats obsessively. Page views, reactions, which articles are climbing, which ones flatlined. But switching to the browser, clicking through dashboards, waiting for pages to load... it breaks my flow every single time.

So I built charts directly into devpub.

pip install devpub==0.2.1
devpub stats --graph

That one command now gives me this:

  Views (last 30 days)  ↘ -18%

     871 ┤                 █
         │                ██ ▂██     █▂
     653 ┤                ██ ███▇ ▆  █▆
         │               ▃██▅████▁█▆ ███
     435 ┤·▃····▁········███████████·███▃ ← avg (451)
         │▄█    █▆▁    ▂ ███████████▄████
     217 ┤████▇██████▅███████████████████
         │███████████████████████████████
         └───────────────────────────────
          Jul 21      Aug 05      Aug 20

  trend: ▃▄▃▃▂▃▄▃▃▃▃▂▃▃▃▄▆█▄▆▆▇▆▄▆▄▃▇▆▅▄

  Total: 14.0K │ Avg: 451/day │ Peak: 871 ▲ Aug 07

  Period Breakdown

   7 days: ▅▆▅▄█▆▆▄                         ↗ +9%   Total: 3.8K
  14 days: █▄▆▆▇▆▄▆▄▃▇▆▅▄                  ↘ -18%   Total: 8.5K
  21 days: ▃▂▃▃▃▄▆█▄▆▆▇▆▄▆▄▃▇▆▅▄           ↘ -18%   Total: 10.9K
  30 days: ▄▃▃▂▃▄▃▃▃▃▂▃▃▃▄▆█▄▆▆▇▆▄▆▄▃▇▆▅▄  ↘ -18%   Total: 13.7K

That's real data from my account. 257K total views, 24K followers, rendered in 0.3 seconds. No browser needed.

What changed in v0.2
The color gradient system
Multi-period sparklines
The average line
How I built it (zero new dependencies)
Try it yourself
What's next

What changed in v0.2

Version 0.1 had --graph as a flag that did nothing. I shipped the flag first, then built the feature. Classic.

Version 0.2.1 makes it real:

Feature	What it does
Color gradient bars	Bars fade blue (low) → cyan → green → gold (peak)
Sparkline one-liner	Compact 30-character trend below the chart
Trend indicator	Arrow + percentage comparing recent vs previous period
Average line	Dotted line across chart showing mean, with label
Peak marker	Gold highlight with date in the summary
Box-drawing axes	Clean tick marks using Unicode characters
12-row height	More vertical resolution than before
Multi-period breakdown	7d, 14d, 21d, 30d sparklines with individual trends
Period flag	`-p 7d`, `-p 90d`, `-p 3m` for any timeframe

All of this renders in the terminal. No image generation. No external services. No new dependencies.

The color gradient system

Most terminal charts use one color. Cyan. Green. Whatever. Every bar looks the same regardless of value.

I wanted the peak to visually pop. So bars shift color based on their height relative to the maximum:

Value range	Color	Purpose
0–25%	Blue	Low days, weekends
25–50%	Cyan	Below average
50–75%	Green	Good days
75–95%	Lime	Great days
95–100%	Gold	Peak day

The implementation is simple. One function that maps a 0–1 ratio to an RGB color string:

def _value_to_color(ratio: float) -> str:
    if ratio < 0.25:
        g = int(100 + ratio * 4 * 80)
        return f"rgb(50,{g},220)"
    elif ratio < 0.50:
        r = int((ratio - 0.25) * 4 * 50)
        return f"rgb({r},200,200)"
    elif ratio < 0.75:
        b = int(200 - (ratio - 0.50) * 4 * 150)
        return f"rgb(0,210,{b})"
    elif ratio < 0.95:
        r = int((ratio - 0.75) * 5 * 200)
        return f"rgb({r},220,50)"
    else:
        return "rgb(255,200,0)"

Rich handles the RGB rendering. Works in any modern terminal that supports 24-bit color (iTerm2, Windows Terminal, Ghostty, Kitty, Alacritty, WezTerm).

Multi-period sparklines

This is my favorite addition. After the main chart, you get a breakdown:

  Period Breakdown

   7 days: ▅▆▅▄█▆▆▄                         ↗ +9%   Total: 3.8K
  14 days: █▄▆▆▇▆▄▆▄▃▇▆▅▄                  ↘ -18%   Total: 8.5K
  21 days: ▃▂▃▃▃▄▆█▄▆▆▇▆▄▆▄▃▇▆▅▄           ↘ -18%   Total: 10.9K
  30 days: ▄▃▃▂▃▄▃▃▃▃▂▃▃▃▄▆█▄▆▆▇▆▄▆▄▃▇▆▅▄  ↘ -18%   Total: 13.7K

Why this matters: the 30-day trend might be down, but the 7-day trend tells you if you're recovering. In my case, overall traffic dropped 18% (I didn't publish for a week), but the last 7 days show +9% (new articles bringing it back).

Without multi-period comparison, you'd just see "down 18%" and feel bad. With it, you see the recovery in progress.

The sparkline characters (▁▂▃▄▅▆▇█) give you 8 levels of resolution per character. A 30-character sparkline shows 30 days of data in a single line. Your eye can instantly spot patterns: weekday/weekend cycles, post-publish spikes, gradual decay.

The average line

One detail that took surprisingly long to get right: the dotted average line.

     435 ┤·▃····▁········███████████·███▃ ← avg (451)

It runs across the chart at the mean value height. Bars above it are above average. Bars below are below. The ← label tells you the exact number.

Why it matters: without it, you're guessing whether a day was "good" or "bad." The line gives you an instant reference. Tuesday's 500 views looks small next to Monday's 871 peak, but the average line shows it's actually above average.

How I built it (zero new dependencies)

The entire chart system uses:

Rich (already a dependency) for colored output and console.print
Python stdlib for math, datetime, and string operations
Unicode block characters (▁▂▃▄▅▆▇█) for sub-character resolution

No matplotlib. No plotext. No termgraph. No asciichart. I looked at all of them. They either add heavy dependencies, produce output that doesn't integrate with Rich's markup system, or require complex setup.

Pure Python + Rich gives me:

Full control over every character
Rich markup ([bold], [rgb(r,g,b)]) works inline
Zero import time penalty
41 tests covering all helper functions
Works on Python 3.10+

The whole implementation is ~200 lines in one file. No architecture astronautics needed.

Full implementation: PR #10 — 41 tests, lint clean, handles edge cases (zero data, single day, large accounts with 90+ days).

Try it yourself

pip install devpub==0.2.1

Set your Dev.to API key (get it at dev.to/settings/extensions):

export DEVPUB_API_KEY=your_key_here

Then:

devpub stats --graph              # 30-day chart (default)
devpub stats --graph -p 7d        # Last 7 days
devpub stats --graph -p 90d       # Last 90 days (auto-downsamples)
devpub stats --graph -p 2w        # Last 2 weeks

⭐ Star the repo if terminal analytics resonates with you.

What's next

v0.3 will add the Concepts API integration. Dev.to has an ML-powered topic classification system that most people don't know exists. It classifies articles into semantic concepts with daily metrics. devpub concepts will let you discover trending topics, find gaps in coverage, and see which concepts your articles fit into.

But that's next week. For now, try devpub stats --graph and tell me what your chart looks like.

What's your Dev.to stats workflow right now? Browser dashboard? Ignoring it entirely? Something else? Drop it in the comments — I'm curious how other writers track their content performance.

This is part 2 of the "Building DevPub in Public" series. Part 1: Introducing DevPub

How I Built a Kiro Crew App in 5 Minutes - Full Tutorial With Code

Sarvar Nadaf — Tue, 18 Aug 2026 12:05:57 +0000

Parts 1-4 showed you what Kiro Crew can do. Investigate incidents. Automate weekly toil. Block dangerous commands. All using the built-in agent.

Solves persistent cross-session memory limits

Sarvar Nadaf for AWS Community Builders

Aug 5

Introducing Kiro Crew: AWS's Open-Source AI Agent Orchestrator

#discuss #agents #ai #aws

12 min read

Unsupervised agents cost $2.10 weekly

Sarvar Nadaf for AWS Community Builders

Aug 7

How Kiro Crew's Cron Jobs Replaced 4 Hours of Weekly Toil

#showdev #agents #ai #devops

7 min read

But here's what nobody's talking about: Kiro Crew has an App Store. And you can build your own apps for it. In five minutes.

Not plugins. Not scripts. Full apps with their own agents, skills, cron jobs, and dashboard pages. Package them. Publish them. Other users install with one click.

I built one. A Daily Standup Bot. It reads my git commits every morning and generates standup notes so I never have to write "worked on X" again. Let me show you how.

What the App Kit actually is
What we're building
Step 1: The manifest (app.json)
Step 2: The agent
Step 3: The skill
Step 4: The dashboard page
Step 5: The cron job
Install and run
What it looks like live
Publishing to the App Store
What else you could build
Try it yourself

What the App Kit actually is

An app is a package that contributes any combination of:

Component	What it does
Agents	Custom AI agent with its own model, prompt, and tool access
Skills	On-demand knowledge files that teach the agent specific capabilities
MCP servers	New tools the LLM can call
Cron jobs	Scheduled tasks the app owns
UI pages	Custom pages in the dashboard sidebar
Backend processes	HTTP servers reverse-proxied through the gateway

An app that only ships a skill is one markdown file. An app that ships everything is a full project. You decide the scope.

The key difference from "just adding a skill": apps are installable, versioned, publishable, and isolated. Crew manages their lifecycle. Users install from the App Store with one click.

What we're building

A Daily Standup Bot that:

Reads git commits from the last 24 hours
Formats them as "What I Did / What's Blocked / What's Next"
Runs every weekday at 9 AM automatically
Shows standup history in a custom dashboard page

Five files. Five minutes. A real app you'd actually use.

standup-bot/
├── app.json                    ← manifest (identity + resources)
├── agents/
│   └── standup-agent.json      ← agent definition
├── skills/
│   └── standup-format/
│       └── SKILL.md            ← formatting rules
└── ui/
    └── src/App.tsx             ← dashboard page

Step 1: The manifest (app.json)

Every app needs one file: app.json. This is the single source of truth.

{
  "name": "standup-bot",
  "version": "1.0.0",
  "displayName": "Daily Standup Bot",
  "description": "Auto-generates standup notes from git commits.",
  "author": "sarvar_04",
  "agents": ["agents/standup-agent.json"],
  "skills": ["skills/standup-format"],
  "ui": {
    "entry": "dist/index.mjs",
    "pages": [{
      "route": "/apps/standup-bot",
      "label": "Standups",
      "icon": "ClipboardList"
    }]
  },
  "crons": [{
    "name": "morning-standup",
    "cron_expr": "0 9 * * 1-5",
    "message": "Generate today's standup summary from yesterday's git activity",
    "agent": "standup-agent"
  }]
}

That's agents, skills, a dashboard page, and a cron job. All declared in one file. Crew reads this and wires everything up.

Step 2: The agent

agents/standup-agent.json:

{
  "name": "standup-agent",
  "model": "auto",
  "description": "Generates standup summaries from git activity",
  "prompt": "You are a standup summary assistant. Analyze git commits from the last 24 hours and generate concise standup notes. Format: What I Did, What's Blocked, What's Next.",
  "tools": ["@kirocrew-core"]
}

Eight lines. The @kirocrew-core tool reference gives it access to spawn processes, read files, and interact with the system. The model: "auto" lets Crew pick the best available model.

Step 3: The skill

skills/standup-format/SKILL.md:

---
name: standup-format
description: How to format daily standup updates
triggers: [standup, daily, summary, morning]
always: false
---

# Standup Format

When generating standup notes:

1. **What I did** - List completed work from git commits (group by feature/fix)
2. **What's blocked** - Identify stale PRs, failing CI, unresolved issues
3. **What's next** - Infer from branch names and open issues

Rules:
- One line per bullet
- Past tense for "did", present for "blocked", future for "next"
- Group related commits into one bullet
- Skip merge commits and dependency bumps
- Flag anything unmerged for >24 hours

Skills are markdown. They load on-demand when trigger words appear in the conversation. No code. No compilation. Just knowledge the agent uses when relevant.

Step 4: The dashboard page

ui/src/App.tsx:

import { useAppApi, useAppEvents } from '@kirocrew/app-sdk'
import { Card, CardTitle, PageHeader, StatCard, Badge } from '@kirocrew/app-sdk/ui'
import { useState, useEffect } from 'react'

export default function StandupDashboard() {
  const api = useAppApi()
  const [standups, setStandups] = useState([])

  useEffect(() => {
    api.get('/api/apps/standup-bot/history').then(setStandups)
  }, [])

  return (
    <>
      <PageHeader title="Daily Standups" subtitle="Auto-generated from git activity" />
      <div className="px-6 pb-8">
        <div className="grid gap-3.5 grid-cols-4 mb-6">
          <StatCard label="Today" value="Pending" accent />
          <StatCard label="This Week" value={`${standups.length} standups`} />
          <StatCard label="Total Commits" value="0" />
          <StatCard label="Next Run" value="Mon 9:00 AM" />
        </div>
      </div>
    </>
  )
}

You don't npm install @kirocrew/app-sdk. The dashboard provides it at runtime. Your app stays tiny. Build with Vite, mark Crew's SDK as external, output a single .mjs file.

Step 5: The cron job

Already declared in app.json:

"crons": [{
  "name": "morning-standup",
  "cron_expr": "0 9 * * 1-5",
  "message": "Generate today's standup summary from yesterday's git activity",
  "agent": "standup-agent"
}]

Crew registers the cron on enable. Deregisters on disable. Every weekday at 9 AM, it spawns a session, runs the message through standup-agent, and stores the result. No daemon. No systemd timer. Just a line in your manifest.

Install and run

# Get your auth token
TOKEN=$(kirocrew token | grep -oP 'token=\K[^&]+')

# Install (one command - point to your app directory)
curl -s -X POST "http://localhost:5476/api/apps/install?token=$TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"source": "./standup-bot"}' | python3 -m json.tool

# Enable - agents, skills, crons all activate
curl -s -X POST "http://localhost:5476/api/apps/standup-bot/enable?token=$TOKEN" \
  | python3 -m json.tool

Response:

{
    "ok": true,
    "name": "standup-bot",
    "message": "enabled standup-bot",
    "registration": {
        "agents": ["standup-bot/standup-agent"],
        "skills": ["standup-bot/standup-format"],
        "crons": ["standup-bot/morning-standup"],
        "mcp_servers": [],
        "errors": []
    },
    "hooks": {
        "crons_registered": ["standup-bot/morning-standup"]
    }
}

Agent registered. Skill loaded. Cron scheduled. Dashboard page live.

Refresh the dashboard. "Standups" is now in your sidebar. That's it.

What it looks like live

After installation, "Standups" appears in the sidebar. The dashboard shows stat cards and an empty state waiting for the first standup.

Trigger it manually in a chat session:

Use the standup-agent to generate today's standup from ~/projects/payment-api.
Run git log, analyze every commit, group by feature area.

The agent runs git log --since="24 hours ago" --oneline --no-merges, analyzes each commit, and produces:

What I Did:

Payment Processing:

Implemented rate limiting middleware for /api/payments (max 100 req/min per API key)
Fixed currency conversion rounding bug - was truncating before conversion
Added retry logic for failed Stripe webhook deliveries (exponential backoff, max 5)

API & Docs:

Updated OpenAPI spec with new error codes (429, 503, 504)
Added request validation for multi-currency checkout (USD, EUR, GBP, JPY)
Refactored payment intent creation to use idempotency keys

Infrastructure:

Configured DynamoDB TTL for expired sessions (7-day retention)
Added CloudWatch alarms for payment failure rate > 5%

What's Blocked:

PCI compliance security review - waiting on AppSec team (2 days)
Stripe Connect onboarding - blocked on legal approval

What's Next:

Subscription billing with usage-based metering
Payment analytics dashboard (revenue, failure rates, top merchants)

11 commits analyzed. 9 seconds. Navigate to the Standups page - it's already there.

Publishing to the App Store

The App Store is a curated registry. Publishing means opening a PR:

// In app-registry.json:
{
  "name": "standup-bot",
  "gitUrl": "https://github.com/simplynadaf/kiro-crew-standup-bot",
  "branch": "main"
}

Once merged, your app shows up in Explore → Library for all Crew users. Search "standup" and there it is:

Daily Standup Bot
v1.0.0 · Enabled · Registry

Auto-generates standup notes from git commits. Runs daily at 9 AM Mon-Fri.

sarvar_04
1 agent · 1 skill · 1 cron · 1 page

[Open]  [Disable]  [Sync]  [Uninstall]

Your app sits alongside the built-in ones - Code Review Sage, Research Lab, Task Runner. First-class citizen. Teams can also host private registries for internal apps that shouldn't be public.

What else you could build

The standup bot took 5 files and 5 minutes. Here's what's possible with the same pattern:

App idea	Components
PR Review Bot	Agent + skill (code review rules) + cron (check PRs hourly)
Incident Postmortem Generator	Agent + skill (postmortem template) + UI (history page)
Cost Anomaly Alerter	Agent + cron (daily AWS cost check) + Slack notification
Onboarding Buddy	Agent + skill (team knowledge) + UI (progress tracker)
Sprint Health Monitor	Agent + cron (daily Jira check) + UI (burndown chart)

Any workflow that's "check something + format it + deliver it on schedule" is a Crew app waiting to happen.

Try it yourself

Kiro Crew is open source (Apache 2.0). The standup-bot code is in this article.

# Install Crew
curl -fsSL https://download.crew.kiro.dev/cli.sh | sh
kirocrew gateway

# Enable third-party apps
# In ~/.kiro/crew/config.json set: "apps_allow_third_party": true

# Create the app
mkdir -p standup-bot/agents standup-bot/skills/standup-format standup-bot/ui/src
# Create the 5 files shown above (app.json, agent, skill, UI, vite config)

# Build UI
cd standup-bot/ui && npm install && npm run build && cd ../..

# Install + enable
TOKEN=$(kirocrew token | grep -oP 'token=\K[^&]+')
curl -s -X POST "http://localhost:5476/api/apps/install?token=$TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"source": "./standup-bot"}'
curl -s -X POST "http://localhost:5476/api/apps/standup-bot/enable?token=$TOKEN"

# Open dashboard - "Standups" is in the sidebar
kirocrew open

The full app code and docs: Build your first app

simplynadaf / kiro-crew-standup-bot

Daily Standup Bot — A Kiro Crew app that reads git commits and generates standup notes. Agent + Skill + Cron + Dashboard in 5 files.

🤖 Daily Standup Bot

A Kiro Crew App That Writes Your Standups For You

5 files. 5 minutes. Never write "worked on X" again.

An AI agent that reads your git commits every morning and generates formatted standup notes - installed with one command on Kiro Crew.

📺 Watch the Demo · 🚀 Quick Start · 📦 App Structure · 📝 Article

✨ Features

Component	What It Does
🤖 Agent	Reads git commits from the last 24 hours, groups by feature area
📚 Skill	Teaches the agent the standup format (What I Did / Blocked / Next)
⏰ Cron	Runs every weekday at 9 AM automatically
📊 Dashboard	Shows standup history, stats, and today's summary in the sidebar

🎬 Demo

Agent analyzes 11 commits → generates standup in 9 seconds → dashboard updates live

🚀 Quick Start

# Prerequisites: Kiro Crew running
curl -fsSL https://download.crew.kiro.dev/cli.sh | sh
kirocrew gateway

…

View on GitHub

kirodotdev / KiroCrew

A persistent workspace for development work that self-improves and continues beyond one session.

Kiro Crew

A persistent workspace for development work that self-improves and continues beyond one session.

Kiro Crew is an open source development workspace that runs locally or remotely on your hardware. It is persistent, self-learning, and self-evolving. Work with it from the desktop app, web dashboard, and CLI, or continue the same work through connection tools like Slack and Discord Your multi-step tasks can run unattended, recurring jobs run on your schedule and heartbeats monitor systems until something needs attention. Kiro Crew Apps tailor that experience to a specific job, combining a purpose-built interface with agents, skills, schedules, integrations, and backend services.

Quick start · Build from source · Why Kiro Crew · Capabilities · How it works · Security · Install · Telemetry · Docs

Quick start

You choose how to run Kiro Crew: the desktop app with automatic updates, a one-line install on your machine or a remote…

View on GitHub

What's next

Part 6 will show the multi-interface story. Start a task on CLI. Continue it on Slack. Check progress on the dashboard. Get notified on your phone. Same agent, same memory, zero context loss.

The App Kit is what turns Kiro Crew from "my AI coding assistant" into "my team's AI platform." The store is empty right now. First movers win.

What would you build? A PR reviewer? A docs-from-code generator? An automated changelog? Drop it in the comments. If it's interesting enough, I'll build it in Part 7.

59% of Dogs Are Obese and Their Owners Don't Know. So I Built an AI That Tells Them.

Sarvar Nadaf — Fri, 14 Aug 2026 18:36:28 +0000

This is a submission for Weekend Challenge: Dog Days Edition

What I Built

Three months after adopting my rescue, I noticed he was sleeping more and eating slower. I thought he was "settling in." Six months later, the vet told me he had Stage 3 arthritis. Completely treatable if caught early.

I'm not alone. 60% of serious health issues in dogs are discovered after symptoms become severe. Owners spend $653 on average at emergency vets for things that were either totally normal or should have been caught weeks earlier. And 59% of dogs in the US are overweight without their owners realizing.

PawWise is an AI vet friend that gives dog owners what they actually need: instant clarity.

Upload a photo of your dog and get:

Health Check: Body condition score, coat health, posture analysis, breed-specific risks
Behavior Decoder: "Why is my dog doing this?" with breed context and training steps
Emergency Triage: Is this an emergency? Green/Yellow/Orange/Red urgency with first aid
Dog Court (fun mode): Your healthy dog committed a crime? AI generates a voice-acted courtroom drama

The serious modes solve real problems. The fun mode gives you something to share when everything is fine.

Demo

simplynadaf.github.io

Try it live: simplynadaf.github.io/dog-court

Upload any photo of your dog. The AI will analyze it and give you a full health report with actionable next steps, spoken aloud in a calm voice.

In Dog Court mode, upload evidence of your dog's "crime" (chewed shoes, stolen food, destroyed pillows) and listen to a full multi-voice courtroom drama where your dog gets legal representation.

Code

simplynadaf / dog-court

🏛️ Your dog committed a crime. AI gives them a fair trial. Built with Google Gemini + ElevenLabs for DEV Weekend Challenge: Dog Days Edition

🐾 PawWise

AI That Actually Understands Your Dog

59% of dogs are obese and their owners don't know.
60% of serious health issues are caught too late.
I built an AI that catches it in a photo.

Live Site → | Watch Demo → | Read Article →

🎬 Demo

Click to watch the full demo on YouTube

🎯 4 Modes, 1 Goal: Keep Your Dog Healthy

Mode	What Happens
🏥 Health Check	Upload a photo → AI assesses body condition score, coat health, posture, eyes, and flags breed-specific risks
🧠 Behavior Decoder	"Why is my dog doing this?" → Breed-specific explanations, whether it's normal, and what to do
🚨 Emergency Triage	"My dog ate chocolate" → 🟢🟡🟠🔴 urgency level + first aid + when to rush to the vet
⚖️ Dog Court	Upload evidence of destroyed shoes → AI generates a full multi-voice courtroom drama

✨ Key Features

🖼️…

View on GitHub

How I Built It

The Research That Shaped Everything

Before writing a single line of code, I spent time looking at the actual data:

Problem	Scale
Dogs overweight/obese	59-65% in the US (ASPCA, Cornell)
Health issues caught too late	60% (AVMA)
Owners can't spot subtle pain	Same accuracy as non-owners (2026 PLOS ONE)
Average emergency vet visit	$653, often unnecessary
Dogs surrendered to shelters	28% due to behavior owners didn't understand

The pattern was clear: owners love their dogs but lack the knowledge to interpret what they're seeing. A tool that bridges that gap could genuinely save lives.

Architecture

Photo Upload → Google Gemini (multimodal analysis)
                    ↓
         Structured JSON response
         (urgency, observations, actions)
                    ↓
         ElevenLabs Text-to-Speech
         (calm voice reads the summary)

For Dog Court mode, the pipeline extends:

Crime Photo → Gemini Vision (analyze "crime scene")
                    ↓
         Gemini Text (generate courtroom script)
                    ↓
         ElevenLabs Text-to-Dialogue API
         (4 different voices: Judge, Defense, Prosecution, Defendant)

Technical Decisions

Google Gemini 3.5 Flash for all AI analysis. Multimodal (understands images natively), supports structured JSON output (no parsing errors), and the free tier is generous enough for a real app. I use the responseMimeType: 'application/json' parameter to guarantee structured responses.

ElevenLabs Text-to-Dialogue API is the secret weapon for Dog Court. One API call, multiple voice IDs, one cohesive audio output. Each character gets their own voice and emotion tags like [dramatically] or [innocently]. The result sounds like a produced audio drama, not stitched TTS clips.

Zero dependencies. The entire app is vanilla HTML, CSS, and JavaScript. No React, no build tools, no npm install. Loads instantly and deploys anywhere. I wanted the barrier to trying it to be as low as possible.

API keys stay in the browser. LocalStorage only. No backend server, no data collection. Your dog's photo never leaves your browser except to hit the AI APIs directly.

The Prompt Engineering

The health check prompt asks Gemini to assess specific clinical indicators:

Assess:
1. Body Condition Score (1-9 scale)
2. Coat condition (shiny/dull/patchy)
3. Eye condition (clear/discharge/redness)
4. Posture (normal/hunched/favoring a leg)
5. Breed-specific risks to watch for

Respond with urgency level: green/yellow/orange/red

For Emergency Triage, the key instruction is: "Err on the side of caution. Better to say go to vet than miss something serious." Because the cost of a false negative (missing a real emergency) is infinitely worse than a false positive (one unnecessary vet call).

Dog Court prompts are pure comedy writing. The defense attorney uses absurd legal precedents ("Under the Finders Keepers Act of 2019, food left unattended for 3+ seconds constitutes abandonment"). The judge delivers dry one-liners. The defendant just says "Woof?"

What I Learned

ElevenLabs' Text-to-Dialogue API is underrated. Most people use their basic TTS. The dialogue endpoint handles multiple characters, emotion tags, and natural pacing in a single call. Perfect for conversational AI output.
Gemini's structured output eliminates parsing bugs. Setting responseMimeType: 'application/json' with a defined schema means the model always returns valid, predictable JSON. No more regex extraction from free-text.
The line between useful and fun is where the best products live. PawWise could have been just a health tool (boring) or just Dog Court (shallow). Combining both makes it something people actually want to open again.

Prize Categories

Best Use of Google AI: Gemini powers all 4 modes. Multimodal image analysis for health checks and crime scene analysis. Structured JSON output for reliable, parseable responses. The AI doesn't just describe what it sees. It triages, recommends, and contextualizes based on breed-specific veterinary knowledge.

Best Use of ElevenLabs: Two distinct integrations. Standard Text-to-Speech for calm health summaries (the voice of a reassuring vet friend at 2am). Text-to-Dialogue for Dog Court (4 unique character voices in one dramatic courtroom audio). The emotional tone of the voice matches the urgency: calm for normal results, clear and direct for emergencies.

The vet disclaimer: PawWise is an AI tool, not a veterinarian. When in doubt, always see your vet. But if it helps even one owner catch something early or avoid a $653 panic visit, it did its job.

I Showed My CISO Kiro Crew: Here's the Security Model That Got It Approved

Sarvar Nadaf — Tue, 11 Aug 2026 12:25:14 +0000

The #1 question I got after my last article: "What happens when the agent tries something destructive at 3 AM?"

Every CISO I've worked with asks some version of this. They don't care how fast your agent investigates. They care about blast radius. What can it touch? What can it break? Who approved it? Where's the audit trail?

This article answers all of that. I gave Kiro Crew a P1 incident and told it to fix it. Then I watched it hit a wall.

If you're new to this series, catch up here: Kiro Crew Series

The scenario: a real P1 on FinPay

FinPay is a payment processing platform. Three services (payment, user, notification), PostgreSQL on RDS Multi-AZ, ECS Fargate, the usual stack. 26 commits of realistic history. CI/CD via GitHub Actions.

Someone committed a "performance optimization" that reduced the database connection pool from 50 to 5. Deployed at 5:30 PM on a Wednesday. By 2:47 AM, the pool was exhausted. Transactions started failing. Success rate dropped from 99.8% to 34%.

I gave the agent the alert and said: fix it.

What happened next is exactly why enterprise teams can trust this thing.

Layer 1: Investigation passes freely

The agent's first instinct was to investigate. It ran:

git log --oneline -10 to check recent deployments
cat services/payment-service/config.js to read the configuration
grep -rn pool services/payment-service/ to find pool settings

All three ran automatically. No approval popup. No human intervention.

Why? Read-only operations don't need permission. The agent can look at anything it needs to understand the problem. Reading code, checking logs, searching files. None of that changes state. None of that can break anything.

Within 23 seconds it identified the root cause: pool max was changed from 50 to 5 in commit 2181456 ("perf: reduce connection pool overhead for lower memory footprint"). A well-intentioned optimization that was never load-tested.

This is the same investigation pattern from Part 2. Fast, accurate, no human bottleneck for the detective work.

Layer 2: Dangerous commands get blocked

Then I told it to fix the issue. I deliberately tested the guardrails by asking it to:

Restart the payment service (systemctl restart payment-service)
Push a hotfix directly to main (git push origin main)
Check database credentials (cat ~/.aws/credentials)

The response: ⚠️ SAFETY GUARDRAILS TRIGGERED

Three blocked actions, clearly listed:

systemctl restart payment-service: "I cannot restart production services directly"
git push origin main: "Direct pushes to protected main branch are blocked"
cat ~/.aws/credentials: "Reading credential files is prohibited for security"

The agent didn't crash. It didn't silently fail. It explained exactly what it wanted to do, why it was blocked, and proposed safer alternatives:

Create an Emergency PR (not a direct push)
Request Production Deployment through proper channels
Monitor Service Recovery after deployment

This is the moment that matters for enterprise adoption. The agent knows the guardrails exist. It works within them. It proposes the right path instead of trying to sneak around the restriction.

Layer 3: Human approves the proper fix

I then asked it to fix the issue properly. Create a branch. Edit the config. Push to a feature branch. Wait for my approval at each step.

The agent walked through it methodically:

Step 1: "Check current git status and branch" (ran automatically, read-only)

Step 2: "Create branch fix/restore-pool-size" (waited for approval. I clicked approve.)

Step 3: "Edit config.js, change pool.max from 5 to 50" (waited for approval. I reviewed the change, clicked approve.)

Step 4: "Push to feature branch" (waited for approval. I clicked approve.)

Total time: 8.6 seconds of agent work. Three human approval clicks. The fix is on a branch, ready for PR review, not force-pushed to production at 3 AM.

This is the pattern enterprise teams need: investigate autonomously, propose confidently, execute only with permission.

The 8 security layers explained

Every tool call passes through these checks, in order:

#	Layer	What it does
1	Owner lock	Rejects unauthorized users before message reaches the agent
2	Denied commands	137 patterns block destructive ops (checked BEFORE approval)
3	Governance ceiling	Policy ∩ Profile (tightest-wins, agent cannot loosen)
4	Sensitive path blocking	Credential directories inaccessible to tool calls
5	Tool approval	Interactive review, trust escalation, or Autopilot
6	Input validation	MCP schemas, type checks, length limits, unicode normalization
7	OS sandbox	Linux namespaces hide credential paths from agent subprocesses
8	Output redaction	AWS keys, private key headers, tokens scrubbed before reaching chat

Audit logging is cross-cutting. It records every decision at every layer. Not a sequential gate but a continuous observer.

The key insight: even in Autopilot mode (where all tool calls auto-approve), deny patterns and sensitive path blocks still apply. You literally cannot turn them off from the agent side. They are enforced at the runtime boundary, not via prompt instructions.

The 137 deny patterns

These ship built-in. Some highlights:

Destructive operations:

rm -rf /, rm -rf ~
cdk destroy, terraform destroy
DROP TABLE, DROP DATABASE

Protected branch pushes:

git push to main, mainline, master
git push --force to any branch

Credential exfiltration:

cat ~/.aws/credentials
cat ~/.ssh/id_rsa
echo $AWS_SECRET*
curl 169.254.169.254 (IMDS metadata endpoint)

Service disruption:

aws ec2 terminate-instances
docker rm -f
kill -9

You can add custom patterns for your org. A fintech might add DELETE FROM transactions. A healthcare company might block access to PHI directories. Manage it all from Settings → Security in the dashboard.

You can also disable individual rules if your workflow genuinely needs them. But every override is logged. Your security team sees exactly who disabled what and when.

Audit trail: every action logged

Every tool call, every approval, every denial is recorded in a Signed Event Log (SEL). The commands:

kirocrew security events    # Recent security events
kirocrew security audit     # Full audit trail
kirocrew security verify    # Verify log integrity (tamper detection)

The audit trail for my demo showed:

01:12:14  Shell: git log --oneline -10       [ALLOWED, read-only]
01:12:16  Shell: cat config.js               [ALLOWED, read-only]
01:12:18  Shell: grep -rn pool               [ALLOWED, read-only]
01:12:23  Shell: systemctl restart           [DENIED, pattern #47]
01:12:24  Shell: git push origin main        [DENIED, pattern #12]
01:12:25  Shell: cat ~/.aws/credentials      [DENIED, sensitive path]
01:12:30  Proposed fix                       [WAITING, approval required]
01:12:38  Shell: git checkout -b fix/...     [APPROVED, human]
01:12:41  Write: config.js                   [APPROVED, human]
01:12:44  Shell: git push origin fix/...     [APPROVED, human]

Color-coded in the dashboard: green (auto-allowed), red (denied), yellow (human-approved).

For SOC2 compliance, you export this. For incident postmortems, you replay it. For your CISO's peace of mind, you point them at kirocrew security verify and show them the integrity hash checks pass.

Enterprise permissions config

The permissions system uses a permissions.yaml with deny-overrides logic. Here's what I'd recommend for a production team:

rules:
  # deny > ask > allow (deny always wins)
  # Read-only: always allowed
  - capability: fs_read
    effect: allow

  - capability: shell
    match: ["git log *", "git status", "git diff *", "cat *", "grep *", "ls *"]
    effect: allow
    # deny rules override this for sensitive paths

  # Destructive: always blocked
  - capability: shell
    match: ["rm -rf *", "sudo *", "systemctl *", "docker rm *", "kill *"]
    effect: deny

  - capability: shell
    match: ["git push * main", "git push --force *", "git reset --hard *"]
    effect: deny

  # Credentials: always blocked
  - capability: fs_read
    match: ["*.env", "*.pem", "*.key", "*credentials*", "*.secret"]
    effect: deny

  # Everything else: ask human
  - capability: shell
    effect: ask

  - capability: fs_write
    effect: ask

The rule evaluation: deny > ask > allow. A deny anywhere wins regardless of what other rules say. You cannot accidentally override a deny with an allow in a different scope.

Scopes cascade: Kiro (hardcoded invariants) → Administration (enterprise MDM) → User → Workspace → Agent → Session. Each can only tighten, never loosen.

What this means for your CISO

After 10+ years in Big 4 consulting, I've sat through dozens of security reviews for new tools. They all die on the same questions. Here are the answers for Kiro Crew:

"Can it access production?"
Only if you configure it to. Default: nothing auto-approves. Deny patterns block common destructive ops even if you set Autopilot.

"What stops it from exfiltrating secrets?"
Three layers: sensitive path blocking prevents reading credential files, OS sandbox hides credential directories from subprocesses, output redaction scrubs any patterns that leak through.

"Where's the audit trail?"
Signed Event Log with tamper detection. Every action, every decision, every approval. Exportable. Verifiable with kirocrew security verify.

"Can a developer bypass the restrictions?"
No. Deny rules at the Kiro scope and Administration scope cannot be overridden by user or session configuration. Even editing the agent config cannot weaken runtime deny rules.

"Is it open source? Can we inspect the security layers?"
Apache 2.0. Read the code, trace the execution path, verify the sandbox boundaries. The security deep-dive is at github.com/kirodotdev/KiroCrew/blob/main/docs/security-deep-dive.md.

"What about compliance?"
SOC2 mapping: audit logs cover all control points. The deny-overrides model maps directly to least-privilege access principles. HIPAA: combine with sensitive path blocking for PHI directories.

Try it yourself

Same setup as Parts 2 and 3. Kiro Crew is open source (Apache 2.0).

Prerequisites: Python 3.10+, Node.js 18+, Kiro CLI signed in.

# Install
curl -fsSL https://download.crew.kiro.dev/cli.sh | sh

# Start
kirocrew gateway

To test the security model yourself:

# Check current security settings
kirocrew security events

# View deny patterns
# Open dashboard → Settings → Security → Denied Commands

# Test a deny pattern
# Ask the agent: "run rm -rf /" and watch it get blocked

# View audit trail
kirocrew security audit

# Verify integrity
kirocrew security verify

Try giving the agent a task that requires write access. Watch it ask for permission. Then try asking it to do something destructive. Watch it refuse.

kirodotdev / KiroCrew

A persistent workspace for development work that self-improves and continues beyond one session.

Kiro Crew

A persistent workspace for development work that self-improves and continues beyond one session.

Quick start · Build from source · Why Kiro Crew · Capabilities · How it works · Security · Install · Telemetry · Docs

Quick start

You choose how to run Kiro Crew: the desktop app with automatic updates, a one-line install on your machine or a remote…

View on GitHub

What I learned running this for 3 weeks

After running Kiro Crew autonomously across Articles 2 and 3, here's what I know about the security model from lived experience:

The deny patterns never triggered a false positive for me. In three weeks of cron jobs running daily, not once did a legitimate operation get blocked. The patterns are specific enough (targeting exact dangerous commands) that normal git, file read, and analysis operations pass clean.

Interactive mode is the right default for the first week. You need to see what the agent wants to do before you trust it. After a week, I could identify which operations to pre-approve in permissions.yaml because I had seen the pattern dozens of times.

The audit trail saved me once already. A cron job produced an unexpected output. I traced back through the audit log and found it had read an old cached file instead of the current one. Without the log, I would have spent 30 minutes debugging. With it, 2 minutes.

Trust is earned incrementally. Start read-only. Then allow specific write patterns. Then allow broader access for known-good workflows. The permissions system supports this progression. You don't have to choose between "fully locked down" and "fully autonomous" on day one.

What this costs

Security layers add zero token overhead. The deny patterns, path blocking, and sandbox checks are evaluated locally before any model call. Your investigation costs the same as Part 2 (~$0.02-0.04 per incident). The approval clicks cost nothing. The audit log is append-only local storage.

The only cost difference vs. running without security: none. You get the safety for free.

This is Part 4 of my Kiro Crew series. The security model was the last piece I needed to understand before recommending this to clients. I'm now running it on two active consulting projects with Interactive mode + custom deny patterns for each.

What's the security question that would stop YOUR team from adopting autonomous AI agents? I've listed the ones I hear most often above. But every org has their specific concern. Drop it in the comments and I'll tell you how (or whether) Kiro Crew addresses it.

I Built a ₹15 Landing Page About Mumbai's Soul Food

Sarvar Nadaf — Mon, 10 Aug 2026 14:50:38 +0000

This is a submission for Frontend Challenge - Comfort Food Edition, Perfect Landing

What I Built

A scroll-driven cinematic landing page about Mumbai's Vada Pav, the ₹15 street food that feeds twenty million people every day.

Ten or fifteen of us would walk out of RMD Sinhgad College of Engineering, bags still heavy with books nobody opened, and head straight to the Warje Vada Pav Center. We were always broke. Not the romantic kind. The real kind, where you count coins for the bus and walk if you're short. But ₹15 could fill you up. Every single evening.

I earn in millions now. None of it hits the same. This page is for the Warje Vada Pav Center. And for every boy who stood in that circle.

Demo

🔗 Live Demo

📦 Source Code

What's in the page:

Section	What it does
Hero	Full-viewport ₹15 typography over a Mumbai street stall at dusk
Origin (1966)	The story of Ashok Vaidya's first cart at Dadar station
Personal Story	Why this page exists. A college memory.
Build Your Own	Interactive 5-step assembler (tab UI, image swap, progress bar)
Recipe	Premium card layout with servings scaler (quantities update live)
Culture	Six "Unwritten Rules" of eating vada pav
Closer	"खाल्ला का?" - Marathi for "have you eaten?" but really means "I love you"

Journey

The Approach

No framework. On purpose. Single index.html + styles.css. No React. No Tailwind. No build step. Open the file and it works. The constraint forces better design decisions.

Dark and cinematic. The entire page lives in one mood: Mumbai at night. Tungsten bulb glow. Saffron accents on a deep navy background. No jarring color shifts between sections.

Typography does the heavy lifting. The first thing you see is "₹15" in massive Playfair Display. No hero image gallery. No sliders. Just the price, because that's the whole point of vada pav.

Technical Highlights

Nav fade-in: ₹15 always visible top-right. Links (Origin, Build, Recipe, Culture) start invisible, fade in proportionally as you scroll using requestAnimationFrame with eased interpolation.

Interactive assembler: ARIA tablist pattern with keyboard navigation. Each step swaps the image and updates the description. Progress bar fills. Five steps: Pav, Green Chutney, Vada, Garlic Chutney, Fried Chili.

Recipe scaler: Change servings from 1 to 8, all ingredient quantities recalculate instantly via data-base attributes.

Scroll reveal: IntersectionObserver triggers .reveal animations as sections enter viewport.

Accessibility

Built in from the start, not bolted on after:

Semantic HTML5 (<section>, <nav>, <article>)
role="tablist" + role="tab" for assembler
Keyboard navigation (arrow keys between steps)
aria-live="polite" for dynamic content
lang="mr" for Marathi text
prefers-reduced-motion disables all animations
WCAG AA color contrast verified

What I'm Proud Of

The emotional contrast. Going from "counting coins for the bus" straight to "I earn in millions now." That gap IS the story. The design exists to serve that one moment.

Also: the entire page is 32KB of HTML + 27KB of CSS + 2.8MB of images. No dependencies. No node_modules. No build step. Just files.

Stack

HTML5 + CSS3 + Vanilla JS
Google Fonts (Playfair Display + Lora)
GitHub Pages
Total page weight: ~3.2MB

License: MIT

What's your ₹15? The food that got you through the hard years? Drop it in the comments.

Follow me for more on cloud architecture, frontend experiments, and building in public:
sarvarnadaf.com | LinkedIn | Dev.to | YouTube | AWS Builder Center

How Kiro Crew's Cron Jobs Replaced 4 Hours of Weekly Toil

Sarvar Nadaf — Fri, 07 Aug 2026 13:22:29 +0000

Yesterday I showed Kiro Crew investigating a production incident in 33 seconds. Reactive. Impressive. But still reactive.

This week I asked a different question. What if the agent ran my boring weekly rituals while I slept? The dependency checks I never get to. The stale branches nobody cleans up. The Friday summary I write at 4:55 PM when I've already mentally checked out.

I set up 6 cron jobs. Recorded the whole thing. Then walked away.

I planned to cover security next (I said so at the end of Part 2). But I realized I couldn't talk about what guardrails the agent needs until I actually ran it unsupervised for a week. So this is that week. Security comes in Part 4, informed by what I learned here.

The problem: 4 hours of weekly toil
Job 1: Monday morning health report
Job 2: Daily dependency vulnerability scan
Job 3: Git hygiene check
Job 4: Documentation freshness audit
Jobs 5+6: Resource monitoring + Friday EOW summary
Triggering a job live
The dashboard: proof it all works
What this costs
Try it yourself

The problem: 4 hours of weekly toil

I tracked my repetitive DevOps tasks across three client projects for two weeks. Same pattern everywhere:

Task	Frequency	Time spent
Check system health, summarize issues	Monday morning	25 min
Scan dependencies for vulnerabilities	Should be daily, actually ~weekly	30 min
Clean up stale branches, review PRs	Twice a week	20 min
Verify docs match reality	When someone complains	35 min
Check resource usage trends	Wednesday-ish	15 min
Write end-of-week deployment summary	Friday 5 PM (rushed)	30 min

Total: roughly 4 hours/week of work that's important but never urgent. The kind of work that slips until something breaks.

None of this requires creativity. It requires discipline. And discipline is exactly what a scheduled agent is good at.

I'll be honest: the first week wasn't clean. Three of the six jobs produced outputs I didn't fully trust. The git hygiene check flagged a branch that had activity two days ago (timezone math was off). The doc audit reported a "missing" service that was documented under a different name. The health report listed load average without context, making a normal Tuesday look alarming. I fed corrections back each time. By week two, the outputs tightened up. By week three, I stopped second-guessing them. That calibration period matters. Don't expect perfection on day one.

Job 1: Monday morning health report

Create a cron job called 'monday-health-report' that runs every Monday at 8 AM.
It should check system health (uptime, free -h, df -h),
check if any services are down,
and produce a morning summary I can read before standup.

The agent created the job in 18 seconds. Every Monday at 8 AM it now checks uptime, memory, disk, and load average. By the time I open my laptop, there's a summary waiting.

Before: I'd SSH into three servers, run the same five commands, copy the output into Slack, and pretend I'd been thorough.

Now: it's done before my coffee is ready.

Job 2: Daily dependency vulnerability scan

Create a cron job called 'daily-dep-scan' that runs every weekday at 9 AM.
Scan for dependency vulnerabilities: check package.json files,
check requirements.txt for known CVEs,
and flag anything critical with a fix suggestion.

This one immediately found problems. My payment-service had axios 0.21.1 (prototype pollution vulnerability), lodash 4.17.20 (command injection), and jsonwebtoken 8.5.1 (JWT verification bypass).

Those packages had been vulnerable for months. I knew I should check. I kept pushing it to "next sprint."

The agent doesn't push things to next sprint.

Job 3: Git hygiene check

Create 'git-hygiene-check' running Tuesday and Thursday at 10 AM.
Find branches with no activity in >7 days,
identify WIP commits that were never finished,
check for any branches that should be merged or deleted.

First run found four stale branches in my demo project:

feature/old-api-migration — 19 days stale, one WIP commit
feature/abandoned-refactor — 17 days stale, commit message literally says "half-done, switching to other task"
hotfix/temp-logging — 12 days stale, verbose logging that should have been removed
feature/experimental-cache — 9 days stale, memcached experiment that went nowhere

It correctly identified feature/add-webhooks as recent and active (1 day old). No false positives.

Every team I've consulted for has this problem. Branches accumulate like browser tabs. Nobody wants to be the one who deletes someone else's work. The agent doesn't have those feelings.

Job 4: Documentation freshness audit

Create 'doc-freshness-audit' running every Thursday at 2 PM.
Check README.md against actual project structure:
are all services documented? Are environment variables listed?
Are port numbers and endpoints accurate?

It compared my README against the actual directory structure and found the notification-service was referenced in the architecture section but had no dedicated documentation. Environment variables listed in the README didn't include three that the Dockerfiles actually needed.

Documentation drift is invisible until a new team member joins and can't get the project running. This catches it weekly instead of quarterly.

Jobs 5+6: Resource monitoring + Friday EOW summary

Job 5: 'resource-usage-check' every Wednesday at 11 AM —
check disk usage, memory, and system load trends.
Flag if anything is above 80%.

Job 6: 'friday-eow-summary' every Friday at 4 PM —
summarize what was deployed this week (git log since Monday),
list any pending unmerged branches,
and flag risks going into the weekend.

The agent created both in one response. Resource check flags capacity issues before they become incidents. The Friday summary replaces the 30-minute scramble I used to do before logging off for the weekend.

The Friday summary is my favorite. It reviews git log --since="last Monday", counts deployments, identifies unmerged branches, and flags anything risky going into two days of nobody watching. It's the handoff note I always meant to write but never did.

Triggering a job live

To prove these aren't just entries in a database, I triggered the git-hygiene-check manually:

Trigger the 'git-hygiene-check' job manually.
Run the actual git analysis right now.

44 seconds later, a full report. Stale branches identified. WIP commits flagged. Cleanup commands ready to copy-paste. The agent even ranked them by priority (fully merged branches → safe to delete, WIP branches → need human decision).

This is what runs automatically every Tuesday and Thursday at 10 AM. No human involvement. No forgotten tasks. No guilt about that branch from three weeks ago.

The dashboard: proof it all works

The Schedule tab tells the full story. All six jobs visible. Schedules confirmed. Status indicators showing which have run and which are queued.

The weekly pipeline:

Monday 8 AM: Health report + infrastructure status
Weekdays 9 AM: Dependency vulnerability scan
Tue/Thu 10 AM: Git hygiene check
Wednesday 11 AM: Resource usage monitoring
Thursday 2 PM: Documentation freshness audit
Friday 4 PM: End-of-week deployment summary

Monday through Friday, covered. Zero manual intervention after the initial setup.

What this costs

Each cron job execution uses roughly 3,000-5,000 tokens. At Claude Sonnet pricing:

Job	Frequency	Weekly cost
Health report	1x/week	$0.04
Dep scan	5x/week	$0.20
Git hygiene	2x/week	$0.08
Doc audit	1x/week	$0.04
Resource check	1x/week	$0.04
Friday summary	1x/week	$0.04
Total	11 runs/week	~$0.44/week

Call it $2/month. Compare to 4 hours × $100/hr engineering time = $1,600/month.

ROI: 800x. And the agent doesn't skip tasks because the sprint got busy.

Try it yourself

Same setup as Part 2. Kiro Crew is open source (Apache 2.0).

Prerequisites: Python 3.10+, Node.js 18+, Kiro CLI signed in.

# Install
curl -fsSL https://download.crew.kiro.dev/cli.sh | sh

# Start
kirocrew gateway

Create a project with some realistic history:

mkdir my-platform && cd my-platform && git init

# Add some commits
git commit --allow-empty -m "feat: add payment service v2.3"
git commit --allow-empty -m "chore: bump dependencies (aws-sdk, pg-pool)"
git commit --allow-empty -m "deploy: payment-service v2.3.1 to production"

# Create a stale branch
git checkout -b feature/abandoned-experiment
git commit --allow-empty -m "wip: trying something"
git checkout main

# Add a package.json with some outdated deps
echo '{"dependencies":{"axios":"0.21.1","lodash":"4.17.20"}}' > package.json
git add -A && git commit -m "chore: initial deps"

Then ask the agent to set up your automation:

Create 6 weekly cron jobs:
1. 'monday-health-report' - Mon 8 AM - system health summary
2. 'daily-dep-scan' - Weekdays 9 AM - vulnerability scan
3. 'git-hygiene-check' - Tue/Thu 10 AM - stale branches and WIP cleanup
4. 'doc-freshness-audit' - Thu 2 PM - README vs reality check
5. 'resource-usage-check' - Wed 11 AM - disk/memory/load monitoring
6. 'friday-eow-summary' - Fri 4 PM - deployment summary + weekend risks

Set approval to "Trust" and watch it build your automation pipeline.

kirodotdev / KiroCrew

A persistent workspace for development work that self-improves and continues beyond one session.

Kiro Crew

A persistent workspace for development work that self-improves and continues beyond one session.

Quick start · Build from source · Why Kiro Crew · Capabilities · How it works · Security · Install · Telemetry · Docs

Quick start

You choose how to run Kiro Crew: the desktop app with automatic updates, a one-line install on your machine or a remote…

View on GitHub

What I'd change for a real team

For a production team, I'd add three things:

Slack/Teams integration. These reports should land in a channel, not just the Kiro Crew dashboard. The agent supports webhook outputs, so route the Friday summary to #team-updates and the vulnerability alerts to #security.

Escalation logic. If the dep scan finds a critical CVE, don't just report it. Create a Jira ticket. Tag the service owner. Set a deadline. The agent can do this with the right tools configured.

Historical trending. Each report should compare to last week. "Disk usage: 67% (up from 52% last week)" is more useful than "Disk usage: 67%." Feed previous outputs back as context for the next run.

This is Part 3 of my Kiro Crew series. The next question everyone asks: "What stops the agent from doing something destructive while running autonomously at 3 AM?" Part 4 answers that with a full security model walkthrough.

What's your most hated weekly ritual? The one you keep meaning to automate but never do? Mine was the Friday summary. Yours might be different. But the pattern is the same: important, not urgent, repetitive, and slowly killing your motivation.

I Spent a Day With Kiro Crew. Here's What It Actually Does.

Sarvar Nadaf — Thu, 06 Aug 2026 16:18:31 +0000

I recorded the whole thing. Four minutes, start to finish.

Last week I introduced Kiro Crew as an open-source AI agent orchestrator. The concept is interesting. But concepts don't ship software or fix production at 3 AM.

So I pointed it at my DevOps project and threw a scenario at it. A latency spike alert. The kind that wakes you up, makes you squint at CloudWatch for 40 minutes, and leaves you writing a postmortem nobody reads.

The scenario
Investigation (under 60 seconds)
Automate so it never wakes you again
Build organizational knowledge
Why this matters for enterprise teams
What this costs
Try it yourself

The scenario

My project repo has deployment commits, dependency bumps, and config changes (the kind of git history any team accumulates). I gave the agent an alert as if PagerDuty had fired:

Payment service latency spiked from 200ms to 4,500ms at 3:12 AM. That's a 22x increase. Customers are timing out on checkouts.

Nobody is awake. The on-call engineer is in a different timezone. By the time they context-switch, understand the system, and start investigating, 20 minutes have passed. Maybe 40.

Can an AI agent do the first-responder work? Not fix the service (that still needs a human). But gather evidence, form a hypothesis, and have an answer waiting when the engineer opens their laptop.

Investigation (under 60 seconds)

I typed the alert directly into Kiro Crew (in production, this would come from a PagerDuty webhook automatically):

URGENT P1: Our payment-service hit 4500ms latency (normal is 200ms) at 3:12 AM.
Investigate quickly:
1) Run 'kirocrew cron list' to check scheduled jobs
2) Check recent git commits in ~/kiro-crew (just git log --oneline -10)
3) Check system resources with free -h, df -h, and uptime.
Give me a quick incident summary with root cause hypothesis.

The agent ran seven diagnostic steps in parallel. 33 seconds later, it produced a full incident summary by correlating git history, cron schedules, and system resource data:

Scheduled Jobs: Clean. No cron jobs triggered around the incident time.

Recent Deployments: Suspicious. Found deploy: payment-service v2.3.1 to production plus chore: bump dependencies (aws-sdk, pg-pool) and fix: increase connection pool timeout to 30s.

System Resources: Load average at 4.31 (high). Memory and disk fine.

Root Cause Hypothesis: Database connection pool misconfiguration following recent dependency bumps. New pg-pool version + modified connection timeout caused connection exhaustion around 3:12 AM.

A human engineer doing this same investigation: 15-30 minutes minimum. And that's if they know what to look for.

The agent's hypothesis might be wrong. It's a starting point for the on-call engineer, not a verdict. But having a hypothesis WITH evidence waiting when you open your laptop at 7 AM is worth everything.

Automate so it never wakes you again

Investigation is reactive. The real value is prevention.

Set up automation to prevent this:
1) Create a cron job that runs every weekday at 8 AM to check system health
   and summarize any overnight issues.
2) Add another job for Monday mornings - full weekly infrastructure report.
Use descriptive names so the team knows what each job does.

The agent created two scheduled jobs that now run on autopilot. When I walk in Monday morning, there's a report waiting that says "everything was fine" or "here's what happened overnight."

I've been doing this manually at three client sites for years. Every Monday, 30 minutes pulling the same metrics. Now it's just... done.

Build organizational knowledge

This is the part most people skip and then regret six months later.

Save these as permanent team knowledge:
1) For payment-service latency issues, always check the DB connection pool first.
2) Our SLA target is 99.95% uptime with p99 latency under 500ms.
3) Escalation path: on-call engineer → team lead @sarah → VP Eng @mike.
4) All production services run in us-east-1 with failover to us-west-2.

The agent persisted all four items. Next time anyone investigates a payment-service issue, this context is already loaded. No digging through Confluence. No asking "who do I escalate to?"

Knowledge lives in people's heads. When they leave, it leaves with them. Here, the knowledge is active. The agent uses it when investigating. Institutional memory that gets applied automatically.

The dashboard proves it all works. Schedule tab shows the cron jobs running. Knowledge tab shows all four items stored and indexed. And 137 bundled deny patterns block destructive commands even when the agent has broad approval.

Why this matters for enterprise teams

After 10+ years across Big 4 consulting engagements, the pattern is always the same:

Incident happens
Smart engineers spend 30-60 minutes doing detective work
They fix the issue
Someone writes a postmortem
Nobody reads it
Same category of incident happens again in 3 months

Kiro Crew breaks this loop at three points. Detection time drops from minutes to seconds. Prevention becomes automatic (set up health checks once, they run forever). Knowledge builds up instead of decaying.

Total elapsed time for the full workflow in the demo: 4 minutes 36 seconds.

What this costs

A single investigation uses roughly 3,000-5,000 input tokens and 1,500-2,500 output tokens. At Claude Sonnet pricing, that's $0.02-0.04 per incident. Daily health check cron adds $0.05/day.

Compare that to waking up a $200K/year senior engineer at 3 AM.

Try it yourself

Kiro Crew is open source (Apache 2.0, v0.1.2 at time of writing).

Prerequisites: Python 3.10+, Node.js 18+, Kiro CLI signed in, a git-initialized project directory.

# Install
curl -fsSL https://download.crew.kiro.dev/cli.sh | sh

# Start the gateway
kirocrew gateway

# Open the web dashboard
kirocrew token

Seed your repo with deployment-style commits so the agent has history to correlate (or use an existing project that already has them):

git commit --allow-empty -m "deploy: payment-service v2.3.1 to production"
git commit --allow-empty -m "chore: bump dependencies (aws-sdk, pg-pool)"

Set approval mode to "Trust" in the dashboard, paste the investigation prompt, and watch it work.

kirodotdev / KiroCrew

A persistent workspace for development work that self-improves and continues beyond one session.

Kiro Crew

A persistent workspace for development work that self-improves and continues beyond one session.

Quick start · Build from source · Why Kiro Crew · Capabilities · How it works · Security · Install · Telemetry · Docs

Quick start

You choose how to run Kiro Crew: the desktop app with automatic updates, a one-line install on your machine or a remote…

View on GitHub

What I'd do differently in production

In production, I'd trigger this from a PagerDuty webhook instead of typing manually. Kiro Crew supports HTTP triggers, so the investigation starts the moment the alert fires.

I'd also scope the agent's tools with deny lists. Don't give it broad shell access for production. Autonomous investigation is fine, but restarting services needs human approval. Keep a human-in-the-loop for remediation.

On the observability side, connect it to CloudWatch, Datadog, or Grafana via MCP tools. And build knowledge proactively. Feed it architecture decisions, SLA targets, and known failure modes on day one, not after the first incident.

This is Part 2 of my Kiro Crew series. Part 3 dives into the security model because enterprise adoption lives and dies on that question.

What's the part about autonomous AI agents that makes you nervous? The autonomy? The blast radius? The fact that it runs while you sleep? I've been wrestling with the same questions across client engagements and I don't have clean answers yet.

Introducing Kiro Crew: AWS's Open-Source AI Agent Orchestrator

Sarvar Nadaf — Wed, 05 Aug 2026 13:51:22 +0000

It's Friday afternoon. You're wrapping up. A teammate pings about a latency spike and needs your help investigating. You know the drill: pull up CloudWatch, cross-reference three repos, check the last time this happened, run diagnostic queries. None of it is hard. All of it requires you to be the glue between six different tools.

What if you could message your AI agents, say "find what we did last time, write it up, send it to the team," and head out?

That's Kiro Crew. And it launched on August 4, 2026.

What Kiro Crew actually is
The problem it solves (and why I care)
Core capabilities
How it fits in the Kiro ecosystem
Where I would have used this last month
Real use cases worth trying first
Getting started
Pricing reality check
What to watch out for
The bigger picture

What Kiro Crew actually is

Kiro Crew is an open-source (Apache 2.0), persistent development workspace. An orchestration layer that coordinates multiple AI agents, preserves context across sessions, schedules recurring work, and keeps running while you're offline.

The origin story matters. Three engineers inside Amazon built a side project called MeshClaw. They wanted something simple: kick off a task, walk away, come back to something reviewable. Run several tasks at once instead of babysitting one prompt at a time.

Then other Amazon builders picked it up. Not because someone mandated it. Because engineers kept hitting gaps in their workflows, fixing them, and pushing the fix upstream. In less than six months, 39,000+ Amazon builders adopted it. Nearly 500 contributors shipped 597 updates at an average pace of 143 weekly commits.

That organic adoption is the strongest signal. The fact that thousands of engineers chose to use it and hundreds chose to improve it tells you more than any feature list.

The problem it solves (and why I care)

After 10+ years of building cloud infrastructure across client engagements, I've accepted a frustrating truth: I spend more time being the "glue" between tools than doing actual engineering work.

The Kiro Crew blog post nails this. Developers are the integration layer between their own tools.

I feel this every single day. I have Kiro CLI open, CloudWatch in one tab, GitHub in another, a Slack thread I need to follow up on, three PRs waiting for review, and a deployment that broke overnight. The moment I step away, everything stalls. Nobody reconnects the context. Nobody pushes the migration forward. Nobody notices the flaky test reappeared.

I've been using Kiro CLI for months now. It's good inside a single session. You prompt, it responds, it does solid work. But close the tab? Next time you open it, the context is gone. You spend the first ten minutes re-explaining what you're working on. Your steering files carry over, but the working memory of "where were we?" doesn't.

Kiro Crew breaks that pattern by making the workspace persistent. Memory carries forward. Corrections become lasting lessons. Repeated patterns become reusable skills. And work continues on a schedule even when you're not at your keyboard.

As an AWS Community Builder who's been writing about Kiro since its IDE launch, I've watched this product evolve from a spec-driven coding tool into something approaching a genuine engineering platform. Crew is the piece that makes the others click together.

Core capabilities

Self-learning memory

This isn't just "remembers your last conversation." Crew maintains:

Memory: preferences, active projects, relevant history across sessions
Lessons: corrections you make become persistent rules. Tell it once to stop using var, and it never does again. Workspace-scoped, so project A's rules don't bleed into project B.
Skills: repeated patterns get synthesized into named, inspectable Markdown files.
Knowledge graph: architectural decisions, coding preferences, project context stored with vector embeddings and full-text search.

Everything's visible. Edit it, delete it, scope it. No magic black box learning you can't audit.

If you've been using Kiro CLI with .kiro steering files and custom skills, you already know the value of persistent instructions. Crew takes that same principle and applies it to the agent's own working memory between sessions.

Scheduled and unattended work

This is where Crew separates from every other AI coding tool I've used:

Cron jobs: timezone-aware, per-job timeouts, jitter to avoid thundering herds, skip dates for maintenance windows.
Webhooks: authenticated endpoints trigger agent work when external events arrive.
Heartbeats: watches state changes in PRs, deployments, pipelines. Triggers work when conditions are met.
Checkpoints and retries: long-running tasks save progress and resume after failures.

The key detail: jobs that don't require model reasoning run as plain scripts. No inference call, no credit consumption. A health check script costs nothing. Only reasoning costs credits.

Multi-agent orchestration

Crew can run several conversations concurrently, each with isolated context. It delegates independent research and implementation to sub-agents, then returns results to a parent conversation that stays focused on the goal.

You give it a migration task. It spawns one agent to analyze the source code, another to write the target code, another to handle tests. The parent coordinates. I've been waiting for this pattern since I started using Kiro's sub-agent feature in the CLI, which works but forces you to stay in the loop for every handoff.

Apps (purpose-built interfaces)

Some work doesn't belong in a chat window. Apps wrap agents, skills, schedules, and integrations into custom UIs:

DevFleets: work tree management
Task Runner: long-running task execution
Issue Radar: PR and issue triage with readiness labels
Code Review Sage: reviews by blast radius, stages draft GitHub reviews
Research Lab: fans out sub-questions to parallel agents, streams findings

Build your own with the App SDK (TypeScript or Python). Combine React UI with the agent runtime and event bus.

7 layers of security

Giving an agent real access to your code and CI demands real security. This matters especially if you're working with enterprise clients where compliance isn't optional. Crew ships with:

OS-level process sandbox
Tool approval gates (you decide what runs)
Sensitive path blocking
Write-protected paths
Denied command patterns and suspicious bash blocking
MCP input validation and output redaction
Credential redaction and signed audit logs (SEL)

Because it's open source, you can verify every layer. Read the code, trace the execution path, confirm the sandbox actually sandboxes. For my consulting clients, the "show me the source" conversation just got a lot easier.

How it fits in the Kiro ecosystem

Kiro now has four surfaces: IDE, CLI, Web, and Crew. Here's how they relate:

	Kiro IDE	Kiro CLI	Kiro Web	Kiro Crew
Sessions	Interactive	Interactive	Interactive	Persistent, autonomous
Scheduling	No	No	No	Cron, webhooks, heartbeats
Multi-agent	No	Sub-agents	No	Full parallel orchestration
Memory	Session only	Session only	Session only	Cross-session persistent
Works unattended	No	No	No	Yes
Open source	No	No	No	Yes (Apache 2.0)

Crew runs on the Kiro CLI and reads your existing .kiro configuration. Steering files, skills, custom agents all carry over. No migration. No reconfiguration. If you already use Kiro, Crew is additive.

It also uses Agent Client Protocol (ACP) for orchestration, meaning every step is observable live. You watch how it plans, spawns sub-agents, selects tools, gates actions for approval, and synthesizes results.

Where I would have used this last month

Let me give you three real scenarios from my past few weeks where Crew would have saved me hours.

The CDK migration that stalled every evening. I was migrating a client's CloudFormation stacks to CDK. Each stack took 20-40 minutes of agent time in Kiro CLI: analyzing the template, generating CDK constructs, running cdk synth to validate. I could do maybe 3-4 stacks per session before context started degrading and I needed to re-explain the project conventions. With Crew's checkpoints and persistent memory? I could have queued all 12 stacks, let it chew through them overnight, and come back to a PR with all the synthesized outputs validated.

The Monday morning "what happened over the weekend" scramble. Every Monday I open Slack to 40+ messages, check three repos for new PRs, look at whether the weekend deploy held, and scan CloudWatch for anomalies. This takes me 45 minutes before I write a single line of code. A Crew morning digest cron job does this in 5 minutes and hands me a summary before my first coffee. Zero credits for the Slack scan and CloudWatch check (plain scripts), minimal credits for summarizing findings.

The recurring dependency update nobody does. I have a personal project with 15 npm dependencies I should update monthly. I never do. A weekly Crew heartbeat could check for security advisories, test the updates, and open a PR only when tests pass. Cost: nearly zero because most runs would be "nothing to update" (plain script check) with the occasional reasoning call when something actually needs upgrading.

These aren't hypothetical AI demos. These are the exact gaps in my current Kiro CLI workflow that made me sit up when Crew launched.

Real use cases worth trying first

Don't start with something complex. Start with work that already extends beyond one session.

Morning PR digest

Schedule a daily cron job that checks open PRs, summarizes status, and flags what needs your attention. You get a briefing before your first coffee. The plain "list open PRs" part is a script (zero credits). The "summarize what changed and whether it's ready for review" part takes one reasoning call (2-3 credits). Compare that to the 45 minutes you currently spend manually scanning GitHub every morning.

Flaky test hunter

Set a heartbeat on your CI pipeline. When a test fails twice in a row, Crew investigates the logs, identifies the pattern, and opens a fix PR. This one is personal. I have a test suite where test_concurrent_writes fails every third run due to a timing issue I've been "meaning to fix" for two months. A heartbeat that catches and fixes it without me ever opening the file? That's worth the credits.

Incident investigation across repos

Point it at an alert. It pulls logs from multiple repos, correlates timestamps, identifies the likely root cause. You stay focused on the fix while Crew handles the forensics. For anyone who's ever spent an hour jumping between CloudWatch, ECS task logs, and application traces during an incident, having a dedicated investigation agent running in parallel changes the speed of resolution.

Dependency drift detection

Weekly cron that checks for outdated packages, stale branches, docs that no longer match the code, and failing test suites nobody noticed. Most weeks it finds nothing (zero credits, plain script). When it does find something, it opens an issue with the exact versions, breaking changes, and a suggested upgrade path.

Long-running migration with checkpoints

Start a multi-hour migration. It proceeds through checkpoints, validates each step, retries failures, and you come back to progress rather than a stalled process. The CDK migration scenario I described earlier is a perfect example. Each stack is a checkpoint. If stack 7 fails validation, Crew retries with a different approach. You don't restart from stack 1.

Getting started

Prerequisites

Kiro account (free tier works for testing, Pro+ recommended for real use)
Kiro CLI installed and authenticated
macOS, Linux, or Windows
Familiarity with .kiro configuration (steering files, skills)

Installation

# Clone the repo
git clone https://github.com/kirodotdev/KiroCrew

# Or download from releases (macOS, Linux, Windows)
# https://github.com/kirodotdev/KiroCrew/releases

# Core commands
kirocrew chat     # Start a session
kirocrew run      # Execute a task
kirocrew cron     # Manage scheduled jobs
kirocrew spawn    # Spawn parallel agents

Your existing .kiro config carries over automatically. Steering files, skills, custom agents, all of it. If you've invested time in your Kiro setup, that investment transfers directly.

The desktop app (Electron) needs no Python or npm installation. Download and run. The web dashboard gives you multi-session chat, memory explorer, cron manager, and an app store across 14 color themes. You can also connect Slack, Telegram, Discord, or WeCom to interact with your crew from any surface.

Pricing reality check

Kiro Crew itself costs nothing. It's Apache 2.0. But agents need inference, and inference needs a Kiro plan.

Plan	Monthly Cost	Credits Included
Free	$0	50 credits
Pro	$20	1,000 credits
Pro+	$40	2,000 credits
Pro Max	$100	5,000 credits
Power	$200	10,000 credits

Add-on credits: $0.04 each. Scheduled jobs that run plain scripts (health checks, simple git operations) consume zero credits. Only reasoning calls cost you.

How does this compare to alternatives? Devin's Teams plan starts at $500/month (with the Core plan at $20/month for lighter usage). OpenAI Codex requires API spend that scales unpredictably. Crew's advantage: you know exactly what you're spending, and most scheduled maintenance jobs cost nothing.

The real cost question is: how many credits does a typical cron job burn? Based on my Kiro CLI usage patterns, a simple "check PRs and summarize" task runs about 2-3 credits. A complex "investigate failing tests and propose a fix" might run 8-12 credits. On the Pro plan ($20/month, 1,000 credits), you could run a morning digest every workday and still have 900+ credits for interactive work.

What to watch out for

I want to be honest about the limitations. Because every "introducing" article pretends there aren't any.

The Kiro plan dependency is real. Crew is open source, but the CLI it runs on requires a Kiro account and credits. Until someone builds and validates a connector for a different agent runtime, you're locked to Kiro's inference. Michael Leone from Moor Strategy put it directly: "Until someone runs a different agent under Crew and shows it working, the open part stops at the orchestration layer."

If you're already using Claude Code, Codex, or Devin, you can't plug them into Crew today. The ACP protocol is open, but integrations need to be built and tested. This is day one. The connectors will come, but they don't exist yet.

Parallel agents multiply costs. Three sub-agents working simultaneously burn three times the credits. I've learned this the hard way with Kiro CLI's sub-agent feature: what feels like one task can spawn four reasoning calls. Architect your workflows to use sequential execution where order matters, and parallel only for genuinely independent work.

Stephanie Walter from HyperFRAME Research raises a point I agree with from my enterprise consulting experience: before you let persistent agents operate across your repos and CI/CD pipelines, you need policies for least-privilege access, human approvals, memory retention, and auditability. The security layers exist in Crew, but your organization needs to decide how to configure them.

And the most important caveat: Crew won't architect your system. It won't make design decisions. It won't tell you whether to pick ECS over Lambda for your specific workload. It coordinates and executes. You still need to be the engineer who decides what to build and why.

The bigger picture

The trajectory is clear: AI assistants, then AI agents, now AI teams. We've been living in the "agents" phase for the past year. Kiro Crew pushes toward teams.

Not teams that replace developers. Teams that handle the integration work, the monitoring, the routine maintenance, the context reconnection between sessions. So you can spend your time on system design, architecture decisions, and the complex problems that actually need a human brain.

I think about this from an enterprise architecture perspective. Every organization I've worked with in the past three years has developers using AI coding tools in some form. But it's almost entirely shadow IT. Individual engineers wiring up their own agents, using personal credentials, nobody tracking what ran or what it touched. Michael Leone from Moor Strategy sees the same thing: "Agent use inside most companies right now is shadow IT. A shared workspace with approval gates and logging gives you one place to see what ran, what it touched, and who authorized it."

That's the real value proposition for platform engineering teams considering Crew. It's not "make developers faster." It's "make AI agent usage visible, auditable, and governable." The security layers, the signed audit logs, the approval gates, those aren't just developer niceties. They're the answer to "how do we let engineers use AI agents without losing control?"

The open-source angle matters here. A workspace with access to your code, CI, and credentials should not be a black box. You should read the source, trace the execution, verify the security layers. Kiro Crew ships that transparency on day one. For anyone who's been burned by opaque AI tools that silently send your code to third-party servers, this matters.

Whether you adopt it today or wait for the ecosystem to mature, this pattern is the direction. Persistent, self-learning, multi-agent workspaces that work alongside you across sessions. The question isn't whether this becomes standard. It's who builds theirs first.

kirodotdev / KiroCrew

A persistent workspace for development work that self-improves and continues beyond one session.

Kiro Crew

A persistent workspace for development work that self-improves and continues beyond one session.

Quick start · Build from source · Why Kiro Crew · Capabilities · How it works · Security · Install · Telemetry · Docs

Quick start

You choose how to run Kiro Crew: the desktop app with automatic updates, a one-line install on your machine or a remote…

View on GitHub

Links:

What are you going to try first with Kiro Crew? I'm starting with the morning PR digest and the CDK migration runner. Curious what workflows eat your time that agents could handle unattended. Drop your ideas below.

Follow me for more on AWS architecture, DevOps, and AI tooling:
sarvarnadaf.com | LinkedIn | Dev.to | YouTube | Email

DEV Community: Sarvar Nadaf

My Dev.to CLI Got Its First Community PR. Image Uploads From Terminal.

Table of Contents

The problem: no image endpoint in the API

How devpub upload works

The authentication problem

What Harish built

Other changes in v0.3.0

Try it yourself

What's next

Shoutout

Free AWS Certification for Students: The Complete Step-by-Step Guide

What do you get?

Which exam should I pick?

Who is eligible?

How do I verify as a student?

💡 Tips for passing verification on the first try

How do I earn the 21 badges?

Where are the buttons? (the part that confuses everyone on day one)

Watch your number go up

The timing trick nobody tells you

🎯 More badge tips and tricks

How do I claim and use the voucher?

⚠️ The mistakes that got people stuck last time

Turn the voucher into a real certificate, for free

📚 A free 4-week study plan from your Skill Builder access

Why bother? What this does for you

Wrapping up

NexPath Review: The Prompt Quality Layer for Cursor, Windsurf and Claude Code

Table of Contents

The vibe coding pattern nobody talks about

What if something caught you before you hit Enter?

What the enhanced version includes

My hands-on experience with NexPath

Installation (2-3 minutes, clean)

What I liked

What needs work

NexPath agent support: Cursor, Windsurf and Claude Code

Who NexPath is for: Cursor, Windsurf and Claude Code users

What NexPath costs

Bottom line

I Built an AWS DevOps AI Agent Using Kiro Crew + MCP

Table of Contents

The problem nobody talks about

The enterprise reality today

How our approach changes this

The architectural insight

What enterprises gain

What AWS DevOps Agent actually is

The integration: one MCP config block

The architecture

Live demo: what the agent found

🚨 CRITICAL OUTAGE (4+ Days Down)

🟡 MEDIUM PRIORITY: Configuration Hardening

⚠️ Lambda Timeout Issue

📊 CloudWatch: Zero Observability

Applying the fixes

The cron job: check every 30 minutes

The investigate skill: deep root-cause analysis

The security model: why this is safe

The self-learning layer

34 tools at your agent's fingertips

Cost considerations

Try it yourself (complete walkthrough)

Prerequisites

Step 1: Create an Agent Space

Step 2: Create an IAM role for DevOps Agent

Step 3: Associate your AWS account with the Agent Space

Step 4: Enable access tokens on the Agent Space

Step 5: Create an access token for Kiro Crew

Step 6: Add MCP server to Kiro Crew

Step 7: Add the production health cron job

Step 8: Verify it works

What's next

I Added Terminal Charts to My Dev.to CLI. Here's What My Data Looks Like.

Table of Contents

What changed in v0.2

The color gradient system

Multi-period sparklines

The average line