DEV Community: Sarvar Nadaf

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

🎯 What It Does

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

📊 The Problem

Crisis	Scale
Dogs overweight/obese	59-65% in

…

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.

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 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

Introducing DevPub - Open Source Dev.to CLI Tool

Sarvar Nadaf — Sat, 01 Aug 2026 12:10:00 +0000

Recently I went looking for a CLI tool to manage my Dev.to articles from the terminal. I write 4-5 articles per month, track analytics obsessively, and wanted a git-backed workflow.

I found 9 existing tools. Tried them all. Here's what happened:

devto-cli (Node): Last commit 2 years ago. Broke on install.
dev-to-git (Node): Only syncs TO local. Can't push back.
slinkity: Abandoned.
forem-cli: 3 endpoints implemented out of 40+.

Every single tool does the same thing: publish an article. That's it. Maybe pull. Maybe validate tags.

Meanwhile the Dev.to API has 40+ endpoints including analytics, semantic search, ML-powered content concepts, follower engagement, trend tracking, and reading list management. Nobody uses them.

So I built devpub.

What devpub does
What I discovered in the API
The build story
Architecture
Try it
Contributing

What devpub does (that nothing else does)

# The basics (every tool does this)
devpub push -f articles/my-post.md
devpub pull

# Analytics in your terminal
devpub stats
# Views: 246.5K | Reactions: 4.4K | Comments: 402 | Followers: 18.9K

# Full dashboard with top articles
devpub dashboard

# AI-powered search (semantic, not keyword)
devpub search "building serverless apps" --semantic

# What's trending RIGHT NOW
devpub trends

# Catch problems before publishing
devpub validate

The difference isn't one feature. It's coverage. Here's the comparison:

Capability	devpub	Everyone else
Publish/update articles	Yes	Yes
Pull articles to local	Yes	Some
Analytics (7 endpoints)	Yes	No
Semantic search	Yes	No
Trend discovery	Yes	No
Article validation	Yes	No
Rate limiting (30 req/30s)	Yes	No
Retry logic for failures	Yes	No
Concepts API (ML topics)	Yes	No

What I discovered in the Dev.to API

While building devpub, I found several API endpoints that aren't documented anywhere obvious:

1. Semantic Search -- Dev.to has a full embedding-based search system using Gemini embeddings (768-dimensional vectors) with pgvector. You can search articles by meaning, not just keywords. The endpoint returns cosine similarity scores.

2. Concepts API -- These are ML-generated topic classifications with daily metrics: page views, reactions, comments, popularity scores. Way more powerful than manual tags.

3. V1 Accept Header -- The V1 API requires Accept: application/vnd.forem.api-v1+json. Without it, you get V0 responses. I didn't see this mentioned in any competitor's code.

4. Nested analytics responses -- The analytics endpoints return nested objects like {"page_views": {"total": 246454, "average_read_time_in_seconds": 306}}, not flat integers. Every tool I checked either doesn't use analytics or would break on this structure.

The build story (what actually happened)

I built devpub's core in a day. Started at 2 PM on a Monday, had a working CLI by evening. Here's the honest timeline:

Hour 1-2: Research

Before writing a single line of code, I analyzed 9 competing tools. Downloaded them, read their source, mapped which API endpoints each one used. Found that the most "complete" tool covered 12 out of 40+ endpoints. Most covered 3-5.

Then I read the entire Forem API docs. Not the summary page that everyone reads. The full V1 spec. That's where I found semantic search, concepts, and the analytics endpoints that nobody knew existed.

Hour 3: Scaffolding

pyproject.toml, src layout, Click CLI entry point. Boring stuff but I got devpub --help working in 15 minutes. The key decision here: use httpx over requests. httpx gives you connection pooling, proper timeouts, and the async option for later without changing the interface.

Hour 4-5: The API client

This is where I spent the most time. Not because the HTTP calls are hard. Because I wanted the client to be production-grade from day one:

Rate limiting that actually works (sliding window, not just a sleep timer)
Retries with exponential backoff for 429s and 5xx
Proper error messages instead of stack traces

The first version didn't have any of this. It just called raise_for_status() and threw ugly httpx.HTTPStatusError exceptions at users. I caught that in testing when I pulled my own 86 articles and hit the rate limit at article 30. The whole thing crashed.

Hour 6: Testing against my real account

This is where things got interesting. My first devpub stats call crashed with:

TypeError: '>=' not supported between instances of 'dict' and 'int'

Turns out the analytics endpoint returns {"page_views": {"total": 246454}}, not {"page_views": 246454}. Nested dicts. No existing tool handles this correctly because no existing tool uses analytics.

The health check endpoint also surprised me. In the V1 API (with the Accept header), /health_checks/app requires authentication. Without the header, it returns 401. So I changed the health check to just call /users/me instead.

Hour 7: The push --all scare

During testing, push --all almost published my README.md to Dev.to. The original logic was: find any .md file with a title in frontmatter, push it. My README has YAML frontmatter with a title.

Fixed it by requiring both title AND published keys, and only scanning known directories (articles/, posts/, content/, drafts/). Small thing, but imagine accidentally publishing your CONTRIBUTING.md as a Dev.to article.

What I'd do differently

Start with the pull command, not push. Pull forces you to understand the API response format before you build the data model. I built the model first based on docs, then had to fix it when real responses looked different.
Mock tests from the start. I wrote all the code first, then tests. Should have written the API mock responses alongside the client methods. Would have caught the nested dict issue immediately.
Ship the rate limiter in v0.0.1. I initially thought "I'll add that later." Hit the limit within 30 minutes of real testing. Should have been there from commit one.

The architecture (for contributors)

src/devpub/
  api/        # HTTP clients with rate limiting + retries
  cli/        # Click commands + Rich terminal output  
  core/       # Business logic (articles, sync, validation, config)
  templates/  # Article scaffolding (5 templates)

Key decisions:

Python + Click + Rich -- familiar to most contributors, great terminal UX
httpx -- async-capable, built-in timeout handling
Sliding window rate limiter -- 30 requests per 30 seconds, sleeps automatically
3 retries with backoff -- handles 429s and 5xx without crashing
Frontmatter-based tracking -- article IDs stored in your markdown files, no database

57 tests, all passing

$ pytest -v
57 passed in 1.08s

Tests mock the HTTP layer with respx. No real API calls in CI. Covers:

API client (all endpoints, error codes, retries)
Article model (frontmatter round-trips, slug generation, tag parsing)
Sync logic (push new, update existing, dry run, error handling)
Validation (title length, tag count, body checks, canonical URLs)

Try it

pip install devpub
export DEVPUB_API_KEY=your_key_here
devpub doctor

Or from source:

git clone https://github.com/simplynadaf/devpub.git
cd devpub
pip install -e .

Get your API key at: https://dev.to/settings/extensions

Works with AI agents

Every command returns structured output, handles rate limits silently, and supports --dry-run. AI coding agents (Claude Code, Copilot, Cursor) can use devpub as their publishing layer. The agent writes the article, devpub validates, pushes, and tracks performance. No human needed after the initial setup.

Contributing

The project is in beta. PRs are welcome. Some things that need help:

Performance: The pull command makes one API call per article. Can we batch?
Image rewriting: Relative paths should become GitHub raw URLs on push
Terminal charts: The --graph flag is accepted but not implemented yet
Hashnode adapter: Cross-posting scaffold is ready, needs implementation

Check the issues for good first issue labels.

GitHub: github.com/simplynadaf/devpub

If this saves you time, star the repo. If something's broken, open an issue. If you want a feature, send a PR.

What's your current Dev.to workflow? Are you writing in the browser editor, or do you have a local setup? Curious what pain points people are hitting.

📺 Watch the full demo on YouTube

Built by Sarvar Nadaf - Cloud Architect
Follow me: Dev.to | GitHub | YouTube | LinkedIn

BrowserAct in 2026: The Best No-Code Web Scraping Tool That Replaced My Python Scrapers

Sarvar Nadaf — Tue, 28 Jul 2026 12:45:15 +0000

If you've been following this series, you know I've been testing BrowserAct for months now. Article 1 covered the CLI setup. Article 2 covered headless + human handoff. Article 3 was a 6-week production review.

Those were all about the CLI, the developer tool. This article is different. BrowserAct now has a cloud product called BrowserAct Agent Built where you describe what data you need, and it builds a reusable scraper for you. No terminal. No code. Just a prompt.

I tested it on five real business workflows. Here's what I found.

Every quarter I update a pricing comparison spreadsheet for my clients. I work with teams evaluating deployment platforms, and the question is always the same: "Which one should we use for this project?" The honest answer depends on workload, team size, and budget. So I maintain a comparison across Vercel, Netlify, Railway, Render, Fly.io, and DigitalOcean.

Six platforms. Six tabs. Two hours of squinting at marketing copy and copying numbers into a sheet.

I wrote Python scrapers to automate it. BeautifulSoup, Playwright, the works. They lasted three months. Then Vercel redesigned their pricing page. Selectors broke. Fixed them. Netlify changed theirs two weeks later. Fixed again. Fourth breakage in six months, I stopped maintaining the scripts entirely.

Back to manual. Two hours, every quarter. For a spreadsheet.

But here's the thing: across my client engagements, I keep seeing the same problem in different shapes. The e-commerce team tracking competitor prices on Amazon every Monday. The agency paying for lead lists that are already stale. The HR team spending days copy-pasting salary data from job boards. Everyone needs web data. Almost nobody wants to maintain the code that collects it.

Yesterday I tested BrowserAct Agent Built on five business workflows I actually deal with across different client engagements. One prompt each. No code. No selectors. Results below.

What BrowserAct Agent Built Is (Quick Context)
Test 1: SaaS Pricing Comparison (Cloud/DevOps)
Test 2: Amazon Best Sellers (E-commerce)
Test 3: Google Maps Business Listings (Lead Generation)
Test 4: Job Listings with Salary Data (Recruitment)
Test 5: Product Hunt Reviews (Product Marketing)
The Pattern That Works Every Time
How This Compares to Traditional Approaches
Where It Fits
The Honest Review
Getting Started

What BrowserAct Agent Built Is (Quick Context)

If you read my previous articles, you know BrowserAct's CLI. Terminal commands, AI agent browser control, anti-detection, human handoff. Developer-focused.

BrowserAct Agent Built is different. It's their cloud product. You describe what data you need in plain English, and the Agent:

Opens the website in a real browser
Explores the page structure (handles JavaScript, pagination, dynamic elements)
Tests the extraction
Creates a reusable Bot

That's the Build: the Agent learns how to scrape the site and creates a Bot.

Then comes the Run: you pass your parameters (how many results, which category, what keywords) and the Bot executes the extraction. Build once, run as many times as you want with different inputs.

The Bot is the key. Once built, you run it again with different inputs. New keywords, new URLs, new categories. Same extraction logic. No rebuilding.

No code. No selectors. No local setup.

I tested it across five industries to see where it actually delivers.

Test 1: SaaS Pricing Comparison (Cloud/DevOps)

The pain: I recommend deployment platforms to clients quarterly. One of my fintech clients reviews their hosting stack every Q3 before budget planning. Pricing pages change constantly, plans get renamed, tiers appear and disappear. Manual comparison across 6 platforms takes me 2 hours, and my Python scripts broke four times in six months because every redesign killed the selectors.

My prompt:

Go to https://vercel.com/pricing
Extract all available pricing plans.
For each plan, return: plan name, monthly price, included bandwidth,
build minutes, team members allowed, and any notable limits or features.

I chose Private Browser mode (anti-detection) and default proxy region.

What happened during the build:

The Agent opened Vercel's pricing page, identified the pricing cards, scrolled through the feature comparison table, tested extraction on one plan first, then confirmed the structure with me before extracting everything. And you can watch all of this happening live. The dashboard shows a real-time browser preview as the Agent navigates, scrolls, and interacts with the page. You're not waiting blindly for a result. You see exactly what it's doing, which page it's on, what elements it's identifying. If something looks wrong, you know immediately instead of waiting for a failed output.

Build time: about 9 minutes. Used 539 credits.

The result:

Plan	Monthly Price	Bandwidth	Build Minutes	Team Members	Notable Features
Hobby	$0/mo	100 GB/month included	-	1 developer seat	Import repo, deploy in seconds; Automatic CI/CD; WAF; Global CDN; DDoS Mitigation
Pro	$20/mo	1 TB/month included; then $0.15/GB	Standard $0.014/min; Enhanced $0.028/min; Turbo $0.105/min	Developer $20/mo; Viewer: Unlimited; Billing: 1	All Hobby features + $20 usage credit; Advanced spend management; Team collaboration; Faster builds; Cold start prevention
Enterprise	Custom	Custom	Custom	Custom	All Pro features + Guest & Team access controls; SCIM; Managed WAF Rulesets; Multi-region compute; 99.99% SLA; Advanced Support

Clean. Structured. CSV download available. Ready for my client spreadsheet without any reformatting.

I stared at it for a minute thinking "that's it?" I'd mentally prepared for a debugging session.

Test 2: Amazon Best Sellers (E-commerce)

The pain: One of my clients runs an e-commerce operation. Their product team was tracking competitor pricing on Amazon every Monday. Forty products. Two hours of copy-paste into a spreadsheet. I watched them do this for three months before suggesting automation. Manual sourcing doesn't scale. You browse one product at a time, compare prices, calculate margins, and by the time you finish the list, the first prices have already changed.

My prompt:

Go to https://www.amazon.com/Best-Sellers/zgbs/electronics
Extract the top 20 products from the Best Sellers list.
For each product, return: product name, current price, star rating,
number of reviews, and product URL.
Category filter and extraction limit are configurable.

The result:

#	Product	Price	Rating	Reviews
1	Portronics Conch Theta C In-Ear Type C Wired Earphone	₹322	4.1	11,251
2	Ambrane 60W Fast Charging 1.5m Braided Type C Cable	₹149	4.0	37,892
3	OnePlus Nord Buds 3r TWS Earbuds (54H Playback, 3D Spatial Audio)	₹1,949	4.3	48,582
4	Samsung Original 25W USB Type-C Travel Adapter	₹628	4.4	22,084
5	boAt Bassheads 300C Wired Earphone, Type-C, 10mm Driver	₹549	4.0	119,873
6	Samsung Galaxy M06 5G (4GB RAM, 64GB Storage)	₹12,499	3.7	73
7	OnePlus N6 (6GB+128GB, 8000mAh Battery, 45W Charging)	₹24,999	3.4	227
8	Xiaomi Power Bank 4i 20000mAh 33W Fast Charging	₹2,299	4.2	11,948

Showing 8 of 20 results. Full dataset includes product URLs and complete names in the page's native language.

The "configurable" part matters. Next Monday, same Bot, different category. Electronics this week, Home & Kitchen next week. Click "Run," get fresh data. No rebuilding, no code changes.

Test 3: Google Maps Business Listings (Lead Generation)

The pain: I consult for a digital marketing agency that does local business outreach. They were paying $1,500/quarter for lead lists from a vendor. The data was already 3-4 months old by the time they got it. Phone numbers disconnected. Businesses closed. Half the emails bounced.

Google Maps has the data right there, public, updated in real time. But pulling it manually means: search, open listing, copy phone number, copy website, copy address, paste into CRM. Repeat 500 times. Nobody's doing that willingly.

My prompt:

Go to https://www.google.com/maps
Search for "digital marketing agency" in "Austin, Texas".
Extract the first 20 business listings.
For each business, return: business name, phone number, website URL,
star rating, number of reviews, and address.
Search keywords, location, and extraction limit are configurable.

The Agent doesn't just skim the search results page. It opens each business listing individually, pulling phone numbers, websites, and addresses directly from the detail view. Thorough, not lazy. This is why the data comes back complete. It's visiting each listing the way you would manually, just without the copy-paste fatigue.

Build time: about 19 minutes. Used 778 credits.

The result:

Business Name	Phone	Website	Rating	Reviews	Address
Blackhawk Digital Marketing	+1 512-736-0127	blackhawkdm.com	4.9	58	410 Baylor St Unit b, Austin, TX 78703
Austin SEO - Neon Ambition	+1 512-881-0187	neonambition.com	5.0	32	701 Brazos St, Austin, TX 78701
Allegiant Digital Marketing	+1 866-645-1118	allegiantdigital.com	5.0	61	106 E 6th St #900-O30, Austin, TX 78701
JS Interactive, LLC	+1 512-522-5627	js-interactive.com	5.0	64	1913 Robbins Pl, Austin, TX 78705
(un)Common Logic	+1 512-872-6935	uncommonlogic.com	4.9	37	5926 Balcones Dr Unit 130, Austin, TX 78731
Idea Peddler	-	ideapeddler.com	4.9	53	1023 Springdale Rd #4e, Austin, TX 78721
Fahrenheit Marketing	+1 512-206-4220	fahrenheitmarketing.com	4.9	27	2500 W William Cannon Dr STE 205, Austin, TX 78745
Direction	+1 737-510-2477	direction.com	5.0	35	4005 Guadalupe St Ste B, Austin, TX 78751

Showing 8 of 20 results. Full dataset available as CSV download.

Configurable inputs again. Same Bot. Swap "Austin, Texas" for "Denver, Colorado." Swap "digital marketing agency" for "accounting firm." Fresh local lead list in minutes instead of buying stale data from a vendor.

For agencies doing cold outreach, this is the difference between "we have a generic list" and "we pulled this data yesterday, specifically for your industry and city."

Test 4: Job Listings with Salary Data (Recruitment)

The pain: A startup client asked me to help them benchmark cloud engineering salaries before setting their hiring budget. Their HR team of two was manually searching Indeed, scrolling through listings, copy-pasting salary ranges into a Google Doc. Took them three days to cover five job titles across three locations.

Hiring market data goes stale fast. And most small HR teams don't have engineering resources to build scrapers. They need the data, they don't want to maintain the code.

My prompt:

Go to https://in.indeed.com/jobs
Search for "Senior Cloud Engineer" in "Remote".
Extract the first 15 job listings.
For each listing, return: job title, company name, salary range
(when shown), location, and job URL.
Search keywords, location, and extraction limit are configurable.

Build time: about 13 minutes. Used 686 credits. The Agent handled a Cloudflare security check on its own, explored the DOM structure, verified selectors across multiple cards, and even added retry logic for transient server errors. All without me writing a line of code.

The result:

Job Title	Company	Salary Range	Location
Senior Staff Engineer, Cloud	Nagarro	-	Remote
AWS Cloud Engineer	Hafman Consulting	₹10,00,000 - ₹25,00,000/year	Remote
AWS Cloud Support Engineer	smartcoders consulting pvt. ltd.	₹5,00,000 - ₹15,00,000/year	Remote
Cloud Infrastructure Engineer	SupplyHouse.com	-	Remote
Senior DevOps Engineer	Mactores	₹15,00,000 - ₹35,00,000/year	Remote
Senior Site Reliability Engineer	NENI TECHSYSTEMS INC.	₹1,50,000 - ₹2,00,000/month	Remote
Cloud Security Engineer	zb.io	₹20,00,000 - ₹30,00,000/year	Remote

Showing 7 of 15 results. Salary field left empty when listing doesn't publish one. That's expected, not a failure.

Next week: swap "Senior Cloud Engineer" for "DevOps Lead." Change "Remote" to "New York." Same Bot. Different query. Same structured output.

Test 5: Product Hunt Reviews (Product Marketing)

The pain: For my own content strategy and for a client's product marketing team (a B2B SaaS company with 3 competitors), I track what users say about competing tools. What are the common complaints? What features get praised? This used to mean scrolling through review pages manually. Copying quotes into docs. Categorizing feedback. Forty reviews across three competitor products, every month.

In Article 3, I covered BrowserAct hitting #1 on Product Hunt. But manually reading through 629+ upvotes and comments to find patterns? That's a different problem. I wanted structured data from those reviews (ratings, text, dates), not just a scroll session.

My prompt:

Go to https://www.producthunt.com/products/browseract/reviews
Collect the 10 most recent reviews.
For each review, return: reviewer name, star rating, review title,
review text, and review date.
Maximum review count is configurable.

What happened:

The Agent navigated to the page, cleared a Cloudflare check on its own, and then reported back: the reviews on Product Hunt required sign-in to access. Since I didn't use the login assistance feature during this build, the extraction couldn't proceed.

Worth noting: BrowserAct Agent Built does support login-required websites. During a run, the Agent can guide you through a login process via a remote-assist link. I simply didn't use this feature for this particular test, so the build stopped when it encountered the authentication gate. No credits wasted on a doomed extraction, and no bad data returned.

The takeaway: This specific Product Hunt workflow required authentication and couldn't proceed without it in this test. The failure mode was clean - I knew immediately what happened, and no garbage data was returned. For review aggregation from Product Hunt specifically, you'd either use the login-assist feature or target a site with publicly accessible reviews (Trustpilot, Capterra, app stores).

This one's interesting because it shows what happens when you skip a feature. Four out of five tests worked perfectly on first attempt. The fifth hit an authentication gate that I could have handled with the login-assist feature but chose not to for this test. That's exactly the kind of honest result you need before relying on any tool for production workflows.

The Pattern That Works Every Time

Five different industries. Five different sites. Five different data types. But every prompt followed the same structure:

Target URL (where to go)
What records to find (products, plans, businesses, jobs, reviews)
What fields to return (name, price, rating, URL)
What's configurable (keywords, limits, categories, locations)

Bots are reusable because of that fourth point. Build once, change the inputs on every future run. Different keywords. Different categories. Different cities. Same extraction logic.

Tips I learned after building five Bots:

Be specific about the URL. "Go to Amazon" is vague. "Go to https://www.amazon.com/Best-Sellers/zgbs/electronics" tells the Agent exactly where to start.
Name your fields explicitly. "Extract product information" gives you whatever the Agent decides. "Return: product name, current price, star rating, number of reviews, and product URL" gives you the exact columns you need.
Include configurable parameters. Adding "search keywords and extraction limit are configurable" makes your Bot reusable with different inputs.
Start narrow. My first Vercel prompt asked for plan-level data. Once that worked, I could expand to feature-level details.
If a page has toggles or dynamic elements (monthly/yearly pricing switch), mention them. "Extract prices for the monthly billing option."
I wasted a build early on with a vague prompt ("get me competitor data from this page"). The output didn't match what I needed - lesson learned: the more specific your field names, the better the output.

What didn't work: Vague prompts without specific URLs. Asking for data buried behind multiple navigation steps without specifying the path. Skipping the login-assist feature on sites that require authentication (as I did with Product Hunt).

A note on localization: I ran these tests from India, which means some sites served localized content: Hindi labels on salary ranges, ₹ pricing on Amazon, regional job boards. The Agent handled all of it without any language configuration from me. It reads the page as-is, extracts the structured fields, and returns clean data regardless of what language the site renders in.

How This Compares to Traditional Approaches

I've used all three methods over the years. Here's how they actually stack up for recurring data collection:

Dimension	Manual (Copy-Paste)	Python Script	BrowserAct Agent Built
Setup time	0 (but 2hrs every time)	4-8 hours per site	~2 min to write prompt + 9-19 min Agent build
Recurring effort	Full time every run	5 min if script works	5 min (click Run)
When site changes layout	You deal with it live	Fix selectors (30-60 min)	Rebuild Bot (new prompt + 9-19 min build)
JavaScript-rendered pages	You see them fine	Need Playwright/Selenium setup	Handled automatically
Multi-site coverage	Tab switching	Separate script per site	Separate Bot per site
Output format	Copy-paste to spreadsheet	CSV/JSON with custom code	CSV/JSON/Markdown built in
Integration with tools	Manual paste	Custom webhook/API code	Make, n8n, Zapier support (documented, not personally tested)
Code required	No	Yes (Python/JS)	No
Cost	Your time	Your time + hosting	Credits (per workflow step)
Code-level control	N/A	Full control	None (trade-off)

That last row matters. With a Python script, I control everything. Retry logic, edge cases, custom parsing, error handling. With BrowserAct Agent Built, I describe what I want and trust the Agent to figure it out. For 90% of my use cases, that trade-off is fine. The remaining 10% are edge cases where I need very specific programmatic logic that's hard to express in a prompt.

Traditional scripts still have a place if your team specifically needs to own every line of extraction logic. But for most recurring data collection tasks, the time-to-value difference is significant.

Where It Fits

After testing across five industries:

Works well for:

Pricing page monitoring (SaaS, e-commerce, travel)
Competitor feature tracking (public product pages, changelogs)
Lead generation from business directories (Google Maps, Yelp, industry directories)
Job listing aggregation (Indeed, LinkedIn public listings, Glassdoor)
Review aggregation (Product Hunt, G2, Capterra, Trustpilot, app stores)
Product catalog extraction (Amazon, marketplace listings)
Login-required sites (Agent guides you through login during the run)
Complex, dynamic websites with JavaScript rendering, pagination, and filters
Any "check 5+ sites weekly, collect the same type of data" workflow

My decision rule: If a proper API exists, use the API. If you'd normally open the site and copy data into a spreadsheet, BrowserAct Agent Built can do it for you.

The Honest Review

What worked:

Natural language prompts required genuinely zero learning curve. Describe what you want, get it.
JavaScript-rendered pages handled without any extra configuration from me.
Structured output came back clean. Ready to use in spreadsheets or downstream tools.
Bot reuse model makes recurring tasks trivial. Click Run, get fresh data.
Four out of five site types worked on first attempt. The fifth required login-assist which I didn't use in that test.
I didn't write or debug a single line of code.

What I'd improve:

Build time isn't instant. You wait 9-19 minutes while the Agent explores and builds. That's a one-time investment per site - once built, each Run takes just minutes. Worth it for any task you'll repeat weekly or monthly.
It's a black box. I can't see the extraction logic the Agent built. When it works, great. When something fails, I can't debug it the way I'd debug my own script. I can only re-describe and retry.
No way to validate output automatically. With my Python scripts, I could add assertions ("if price is $0, flag it"). Here, if the Bot returns stale or wrong data after a site update, I won't know until I look at the output manually. For anything feeding into client deliverables, I still eyeball the results before using them.
60-minute confirmation window caught me off guard. Started a build, got pulled into a meeting, came back to a timeout. Had to restart. Keep an eye on it.
Credit costs scale with usage. At roughly $0.003 per workflow step, my 5 quarterly Bots cost maybe $1-2/year. For heavier usage, check their pricing page for current rates and volume options.

What I haven't tested yet (being honest):

How it handles a major site redesign (haven't waited long enough to see a rebuild scenario)
Performance at serious scale (I tested 5 sites, not 500)
The Make/n8n/Zapier integrations (mentioned in their docs, didn't try yet)
Sites that actively fight scraping beyond Cloudflare-level protection

Getting Started

If you want to try this for your own business data collection:

Go to BrowserAct and sign in
Write a prompt: target website + what records to find + what fields to return + what's configurable
Choose browser mode (Private for stealth, Standard for simple pages)
Hit Build. Confirm when the Agent asks.
Get structured data.
Click "Run" next time you need fresh data.

For developers who want full browser control via CLI (AI agent integration, anti-detection, human handoff): github.com/browser-act/skills. That's what I covered in my previous three articles.

Previous Articles in This Series

I Gave My AI Agent a Real Browser (CLI setup, 7 hands-on demos)
My AI Agent Hit a Login Wall (headless servers, human handoff)
BrowserAct Hit #1 on Product Hunt (6-week production review)

The Bottom Line

Five industries. Five prompts. Zero lines of code. Four worked on the first attempt. One needed the login-assist feature I skipped.

SaaS pricing comparison that used to take 2 hours? Five minutes. Amazon product tracking? Click Run every Monday. Google Maps leads? Fresh list in any city, any industry. Job salary data? Minutes instead of days. Product Hunt reviews? Would work with login-assist enabled - I just didn't test that path.

It's not magic. Build times vary and you trade code control for convenience. But for structured data extraction from websites, for the "I just need this data, I don't want to maintain a scraper" use case?

It saved me real time. Measured in hours per quarter across five different workflows.

That's enough to keep using it.

If you try it on a use case I didn't cover here, drop it in the comments. I'm curious what industries and sites people automate first.

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

Sentry's Span Hierarchy Exposed a Silent Retry in My 5-Agent Pipeline. One Agent Took 22.6s, the Others Took 5.

Sarvar Nadaf — Fri, 24 Jul 2026 05:48:09 +0000

This is a submission for DEV's Summer Bug Smash: Clear the Lineup powered by Sentry.

Project Overview

I built an AWS Security Posture Agent: five specialist AI agents that scan your AWS account for security misconfigurations, map findings to CIS benchmarks, score risk, and generate copy-paste fix commands.

The agents run sequentially on CrewAI with Amazon Bedrock Nova Pro as the LLM:

1. ResourceDiscovery    → inventories EC2, S3, Lambda, IAM, SGs, API GW, DynamoDB
2. SecurityScanner      → finds open ports, public buckets, admin roles, insecure configs
3. ComplianceChecker    → maps to CIS AWS Foundations Benchmark
4. RiskScorer           → severity × blast radius × exploitability
5. RemediationPlanner   → generates AWS CLI fix commands

Each agent has custom boto3 tools that make real AWS API calls against a live account with 90 IAM roles, 14 S3 buckets, 9 security groups, and 7 Lambda functions. Not test data. Real findings.

simplynadaf / aws-security-posture-agent

Multi-agent AI system that scans AWS accounts for security misconfigurations using CrewAI + Amazon Bedrock, instrumented with Sentry AI Agent Monitoring. 5 specialist agents discover resources, analyze security, map to CIS benchmarks, score risk, and generate fix commands.

AWS Security Posture Agent

Five AI agents scan your AWS account. Find misconfigurations. Score risk. Get fix commands.

Quick Start | Architecture | Screenshots | Performance Fix

The Problem

Most AWS accounts accumulate security debt silently. Open SSH ports from testing. S3 buckets without encryption. IAM roles with full admin access that nobody remembers creating. Manual audits miss things. AWS Config rules cost money. SecurityHub is noisy.

This agent scans your account in 60 seconds, finds real issues, maps them to CIS benchmarks, scores risk, and gives you the exact AWS CLI command to fix each one.

What It Finds

On a real AWS account (90 IAM roles, 14 S3 buckets, 9 security groups, 7 Lambda functions):

97 security findings
├── CRITICAL: open SSH/RDP from 0.0.0.0/0, IAM users without MFA
├── HIGH:     admin roles, unencrypted EBS, missing public access blocks
├── MEDIUM:   deprecated Lambda runtimes, missing versioning, stale SGs
└──

…

View on GitHub

Demo

Here's the full scan running against my AWS account. The scan portion is sped up 4x, results walkthrough is at normal speed:

Bug Fix or Performance Improvement

My first instinct was to blame Bedrock latency. Every time something is slow you blame the LLM, right?

The SecurityScanner agent was taking 22.6 seconds while every other agent averaged 5-10 seconds. Without visibility into what was happening inside each agent's execution, I would have added time.time() calls and guessed.

Sentry's trace waterfall told a different story. The real problem wasn't Python execution time or network latency. It was the LLM getting a context payload it couldn't process cleanly on the first attempt.

The root cause: my IAMAnalyzer tool was fetching all 90 IAM roles from the account (59 after filtering service-linked roles), serializing them into a 27KB JSON blob, and handing that entire payload to the LLM as tool output. The context window got overwhelmed. CrewAI's internal retry logic kicked in, burning tokens on a second attempt with even more context.

One tool. Wrong default. The entire pipeline suffered.

Code

PR with the fix:

fix: paginate IAM analysis and add token budget guard #1

simplynadaf posted on Jul 20, 2026

What

The IAMAnalyzer tool was fetching every single role in the account (90 of them, 59 after filtering service-linked ones) and dumping the full details into a single JSON blob. That blob hit 26,980 characters. The LLM choked on it, CrewAI retried the task, and the SecurityScanner agent ended up taking 22.6s while every other agent finished in 5-10s.

How I found it

Added Sentry spans to each agent and tool. The trace waterfall made it obvious: SecurityScanner was twice as wide as everything else. Drilled into the tool spans and saw result_length_chars: 26980 on iam_analyzer vs ~4000 on the other tools.

7x output disproportion. That was the problem.

What I changed

Three things in iam_analyzer.py:

Paginate and sort roles by RoleLastUsed date, only analyze the top 20 most active ones. The rest are stale roles nobody has touched in months.
Skip 31 service-linked roles upfront (you cannot modify them anyway, auditing them is noise).
Token budget guard at the end: if the JSON output exceeds 4000 chars, trim the role_summary down to just names and policy lists.

Numbers

Tool output: 26,980 chars down to 15,532 (42% smaller)
SecurityScanner: 22.6s down to 17.8s (21% faster, no more LLM retry)
API calls to IAM: 59 down to 20
Total pipeline: 62s down to 57.7s
Findings: still 27. No coverage loss because the top-20 most active roles contain all the problematic ones (AdminRole, Bedrock-Lambda-Role, etc are all heavily used).

View on GitHub

The core change lives in src/security_posture/tools/iam_analyzer.py. Here's the before and after:

Before (the bug):

# Fetches ALL roles without pagination limit
roles = iam.list_roles(MaxItems=100)
role_details = []

for role in roles["Roles"]:
    role_name = role["RoleName"]
    if role.get("Path", "").startswith("/aws-service-role/"):
        continue
    # Analyzes every single role...
    attached = iam.list_attached_role_policies(RoleName=role_name)
    # ...builds massive JSON output

This produces 26,980 characters of JSON for an account with 90 roles. The LLM chokes on it.

After (the fix):

# FIX: Paginate and sort by relevance
all_roles = []
paginator = iam.get_paginator("list_roles")
for page in paginator.paginate():
    all_roles.extend(page["Roles"])

# Filter service-linked roles (31 roles, can't modify anyway)
auditable_roles = [
    r for r in all_roles
    if not r.get("Path", "").startswith("/aws-service-role/")
]

# Sort by last used date (most active first)
auditable_roles.sort(key=_last_used_sort_key, reverse=True)

# Take only top 20 roles
roles_to_analyze = auditable_roles[:max_roles]

Plus a token budget guard at the end:

# Token budget guard: truncate if output exceeds threshold
if len(output) > 4000:
    result["role_summary"] = [
        {"role_name": r["role_name"], "policies": r.get("attached_policies", [])}
        for r in role_details
    ]
    result["note"] = "Role details truncated to stay within token budget"
    output = json.dumps(result, indent=2, default=str)

Three changes. Pagination, relevance sorting, and a safety valve. The SecurityScanner stopped retrying.

My Improvements

Results first:

Metric	Before	After	Improvement
IAM tool output	26,980 chars	15,532 chars	42% smaller
SecurityScanner time	22.6s	17.8s	21% faster
IAM API calls	59	20	66% fewer
Total pipeline	62.0s	57.7s	7% faster
Security findings	97	97	No coverage loss

The 21% improvement on the SecurityScanner came from the LLM completing analysis in a single pass instead of retrying.

How I found it:

The fix itself is simple. The interesting part is how Sentry pointed me straight to it.

Without the trace waterfall, all I would have seen is "pipeline takes 62 seconds." The trace said otherwise:

Wrap each agent execution in a gen_ai.invoke_agent span
Wrap each tool call in a gen_ai.execute_tool span
Run the pipeline and look at the trace waterfall
The SecurityScanner span was visually obvious: twice the width of everything else
Inside it, the iam_analyzer tool span showed a result_length_chars of 26,980
Compare to security_group_analyzer at 4,200 chars and s3_config_checker at 3,800 chars

The disproportion was the clue. If the tool output is 7x larger than its siblings, reduce it.

Best Use of Sentry

I used Sentry's AI Agent Monitoring to instrument a multi-agent CrewAI pipeline from scratch. This isn't a web app or API. It's five autonomous AI agents making LLM calls and executing custom tools. Standard APM wouldn't help here.

What I instrumented

Every pipeline run creates a Sentry transaction with this span hierarchy:

Transaction: "Security Posture Scan" (57s)
├── gen_ai.invoke_agent: ResourceDiscovery
│   └── gen_ai.execute_tool: aws_resource_scanner
├── gen_ai.invoke_agent: SecurityScanner
│   ├── gen_ai.execute_tool: security_group_analyzer
│   ├── gen_ai.execute_tool: s3_config_checker
│   ├── gen_ai.execute_tool: iam_analyzer
│   ├── gen_ai.execute_tool: ec2_security_checker
│   └── gen_ai.execute_tool: lambda_security_checker
├── gen_ai.invoke_agent: ComplianceChecker
├── gen_ai.invoke_agent: RiskScorer
└── gen_ai.invoke_agent: RemediationPlanner

The instrumentation code

For each agent (in main.py):

with start_span(
    op="gen_ai.invoke_agent",
    name=f"invoke_agent {agent_name}",
) as agent_span:
    agent_span.set_data("gen_ai.operation.name", "invoke_agent")
    agent_span.set_data("gen_ai.agent.name", agent_name)
    agent_span.set_data("gen_ai.request.model", "amazon.nova-pro-v1:0")
    agent_span.set_data("gen_ai.pipeline.name", "security-posture-scan")

    task_output = task_obj.execute_sync(
        agent=task_obj.agent,
        context=context,
        tools=task_obj.agent.tools,
    )

    agent_span.set_data("duration_seconds", round(elapsed, 2))
    agent_span.set_data("output_length_chars", len(str(task_output)))

For each tool (decorator in monitoring.py):

def trace_tool(tool_name: str):
    def decorator(func):
        @functools.wraps(func)
        def wrapper(*args, **kwargs):
            with start_span(
                op="gen_ai.execute_tool",
                name=f"execute_tool {tool_name}",
            ) as span:
                span.set_data("gen_ai.tool.name", tool_name)
                result = func(*args, **kwargs)
                span.set_data("result_length_chars", len(result))
                try:
                    data = json.loads(result)
                    if "findings_count" in data:
                        span.set_data("findings_count", data["findings_count"])
                except (json.JSONDecodeError, KeyError):
                    pass
                return result
        return wrapper
    return decorator

What Sentry revealed

The trace waterfall made the bottleneck visually obvious. The SecurityScanner span was nearly twice the width of any other agent, 22.6 seconds while others averaged 5-10s.

Inside it, the iam_analyzer tool span showed result_length_chars: 26980 while s3_config_checker showed 3,800 and security_group_analyzer showed 4,200. The granularity goes down to individual boto3 calls. Every GetPublicAccessBlock, ListRoles, and ListAttachedRolePolicies shows up as its own span.

Before the fix (SecurityScanner dominates the trace at 22.6s):

After the fix (all agents proportional, no single bottleneck):

The iam_analyzer output dropped from 26,980 chars to 15,532, and the SecurityScanner stopped triggering retry logic.

Sentry features used

Feature	How I Used It
Distributed Tracing	Full pipeline trace from start to final report
AI Agent Monitoring	`gen_ai.invoke_agent` spans for all 5 agents
Tool Execution Tracing	`gen_ai.execute_tool` spans for all 5 boto3 tools
Custom Span Data	Token counts, output sizes, duration, finding counts
Error Monitoring	Exception capture with `sentry_sdk.capture_exception()`
Breadcrumbs	Agent completion events via task callbacks
Transaction Metadata	Model name, pipeline config, agent count

Why this matters for AI agent observability

Standard logging tells you an agent "finished." It doesn't tell you which tool inside which agent returned a 27KB payload that triggered a retry you never asked for.

With five agents each making their own LLM calls and tool executions, you need span-level visibility. Sentry's gen_ai.invoke_agent and gen_ai.execute_tool conventions gave me exactly that. I could see the problem in the trace waterfall before I even looked at the code.

That's the difference between "add some logging" and actual AI observability.

If you're running multi-agent pipelines, what's your observability setup? Curious if anyone else has hit similar tool-output-size problems with CrewAI or LangGraph.

The agent found 97 real security findings in my AWS account. The fix is in production.

4 Silent Failures, 2 Undocumented APIs, and a Container That Crashed Because of a Missing User Directive

Sarvar Nadaf — Mon, 20 Jul 2026 18:20:15 +0000

This is a submission for DEV's Summer Bug Smash: Smash Stories powered by Sentry.

I spent a week deploying a CrewAI agent to AWS Bedrock AgentCore. The SDK wasn't on PyPI. The error messages were 200 OKs. The container crashed without logs. And the naming regex rejected hyphens without telling me why.

This is the full debugging trail. Every failure was silent. Every fix required reading source code nobody documented.

The Project
Failure 1: The SDK That Doesn't Exist on PyPI
Failure 2: The 200 OK That Means Failure
Failure 3: The Container That Crashed With No Logs
Failure 4: The Naming Regex Nobody Documented
The Two-Client Split Nobody Mentions
What I Learned

The project

I built a resume-tailoring AI agent with CrewAI and Amazon Bedrock. It takes a job description, analyzes your resume, identifies gaps, and rewrites bullet points to match what the role actually needs.

Locally it worked perfectly. CrewAI orchestrates the agents, Bedrock Nova Pro handles the LLM calls, and the output is solid. Deploying it to production was the problem.

AWS launched Bedrock AgentCore in June 2026 as a managed runtime for AI agents. You containerize your agent, push the image, and AgentCore handles scaling, memory, and invocation. Sounds simple.

It was not simple.

Failure 1: The SDK that doesn't exist on PyPI

The docs say to install bedrock-agentcore-client. I ran:

pip install bedrock-agentcore-client

It installed successfully. No errors. That's because there's a placeholder package on PyPI with that name. It installs, imports fail silently, and your container builds successfully with a broken dependency inside.

The real SDK lives in AWS's CodeArtifact registry. You need to configure pip to pull from a private index:

aws codeartifact login --tool pip \
  --domain amazon-agent-runtimes \
  --repository agent-runtimes-pypi \
  --domain-owner 600427722194

Then install from there. The PyPI package is a trap. Nobody warns you.

Hours lost: 3. The error only appears at runtime when the container tries to import the module. The build succeeds. The push succeeds. The deployment succeeds. The invocation returns an empty payload.

Failure 2: The 200 OK that means failure

After fixing the SDK, I deployed and invoked the agent:

aws bedrock-agentcore-control invoke-agent-runtime \
  --agent-runtime-id abc123 \
  --payload '{"job_description": "..."}'

Response: HTTP 200. Payload: empty string.

Not a 500. Not a 400. Not an error message. A successful HTTP response with nothing inside.

I checked CloudWatch. No logs. I checked the container status. Running. I checked the agent runtime status. Active.

The problem: my IAM role was missing bedrock:GetAgentRuntime permission. Without it, the invocation endpoint accepts the request, routes it nowhere, and returns a 200 with an empty body.

There is no error message. There is no log entry. The service returns success when it fails.

Hours lost: 5. I tried different payloads, different content types, different SDK versions, curl vs boto3, synchronous vs streaming. All 200 OK, all empty. The fix was one IAM permission that produces zero error signal when missing.

{
  "Effect": "Allow",
  "Action": "bedrock:GetAgentRuntime",
  "Resource": "*"
}

Failure 3: The container that crashed with no logs

Next failure. Container starts, passes health checks for 30 seconds, then dies. No exception in CloudWatch. No crash log. Status shows "Failed" with no reason.

I added every logging statement I could think of. Print statements. Structured logging. Exception handlers wrapping every import. Nothing appeared in CloudWatch because the container never got far enough to initialize the logging framework.

The cause: missing USER 1000 directive in the Dockerfile.

# This crashes silently
FROM python:3.12-slim
WORKDIR /app
COPY . .
RUN pip install -e .
CMD ["python", "-m", "my_agent"]

# This works
FROM python:3.12-slim
RUN useradd -m -u 1000 agentuser
WORKDIR /app
COPY . .
RUN pip install -e .
USER 1000
CMD ["python", "-m", "my_agent"]

AgentCore requires the container to run as UID 1000. If it doesn't, the runtime kills the container. The error message in the console says "Failed." Just "Failed." No mention of user directives, permissions, or UID requirements.

I found this by reading the AgentCore team's GitHub sample repos. Not the docs. The sample Dockerfile.

Hours lost: 4.

Failure 4: The naming regex nobody documented

I wanted to name my agent runtime resume-tailor-agent. Deployment failed:

An error occurred (ValidationException): 
  Name must match pattern: ^[a-zA-Z0-9_]+$

No hyphens allowed. Fine. I renamed to resume_tailor_agent and moved on.

But the error message only appears if you use the control plane client. If you use the console, it just... doesn't submit. No red border, no error toast, no validation message. The button does nothing.

Hours lost: 1. Small one, but the pattern: silent failures.

The two-client split nobody mentions

Here's where it gets architectural. AgentCore has TWO Python clients:

bedrock-agentcore-control for managing runtimes (create, update, delete)
bedrock-agentcore for the runtime SDK (what runs inside your container)

The documentation uses both interchangeably. Code samples import from one in the setup section and the other in the invocation section. They have different install paths, different CodeArtifact repositories, and different API surfaces.

If you install the wrong one, nothing tells you. Your code runs until it hits an import that doesn't exist in the package you installed. And since both packages have overlapping module names in some versions, the error might be an AttributeError deep in a function call, not a clean ImportError at the top.

I mapped out which client does what:

Client	Purpose	Install From
`bedrock-agentcore-control`	Create/manage runtimes	CodeArtifact (domain: amazon-agent-runtimes)
`bedrock-agentcore`	Runtime SDK (inside container)	CodeArtifact (same domain)
`boto3` (bedrock-agent)	Invoke from outside	Standard pip

This table doesn't exist in any documentation I found.

What I learned

Five days of debugging. Four distinct silent failures. Zero useful error messages.

Every single problem shared the same pattern: the system accepted the bad input, returned success, and failed somewhere downstream without signaling what went wrong. The 200 OK that means failure. The build that succeeds with a placeholder SDK. The container that crashes without logs.

If I'd had Sentry in the container from day one, I would have caught the import failure, the UID crash, and the empty response pattern within hours instead of days. Observability isn't optional for agent deployments. The infrastructure actively hides failures from you.

Three principles I'm carrying forward:

1. Never trust a 200 OK from a new service. Validate the response body. If it's empty, something broke silently upstream.

2. Test imports at container startup, before anything else. A try/except around every critical import with an explicit log line. If the SDK is fake, you'll know in the first second.

3. Read the sample repos, not just the docs. The Dockerfile in AWS's example repo had USER 1000. The documentation never mentioned it. The sample code is sometimes the real documentation.

I've since added Sentry to my agent pipeline for my security posture scanner project. The trace waterfalls catch problems in seconds that would have taken me hours with print statements. Lesson learned the hard way.

All errors described above are from July 2026 on AgentCore's GA release. Some may be fixed by the time you read this. The patterns of silent failure in new AWS services are probably eternal.

Introducing AWS SimuLearn Badges: Free Proof That You Can Actually Build in the Cloud

Sarvar Nadaf — Fri, 17 Jul 2026 15:47:29 +0000

If someone asked me ten years ago what it takes to break into cloud, I would have said "get certified and hope someone gives you a chance."

I was wrong. And I watched dozens of freshers follow that exact advice, collect a certification, then sit in interviews unable to explain why they chose one architecture over another.

The problem was never knowledge. It was proof. Proof that you can gather requirements from a confused client, design something that works, and actually build it with your own hands.

AWS just launched something that helps close that gap. And two of these credentials cost nothing.

What AWS SimuLearn Badges Actually Are
Why This Matters More Than Another Certification
The 12 Badges Available Right Now
The Free Starting Path I Would Follow Today
The LinkedIn Advantage Nobody Is Talking About
For Career Switchers: Your Existing Skills Are the Cheat Code
My Honest Take After 10 Years in Cloud

What AWS SimuLearn Badges Actually Are

SimuLearn is not another video course. Not another multiple-choice exam.

You sit in a simulated client meeting powered by generative AI. A virtual customer explains their business problem. You ask questions, uncover requirements, handle objections, and propose an architecture. The AI evaluates your communication, your technical accuracy, and your decision-making in real time.

Then you build the solution. In a live AWS environment. Not a sandbox with three buttons. The real console.

After that, an automated validation confirms your solution actually works.

Complete every assignment in a learning plan, and AWS issues you a badge through Credly. Automatically. No exam booking. No proctored test. Just demonstrated capability across the full workflow.

Each badge represents the entire journey: customer conversations, architecture design, hands-on building, and validated outcomes. Not a single quiz. Not one lab. The whole thing.

Why This Matters More Than Another Certification

I hold 7 AWS certifications. Let me tell you what they prove: I can answer questions about cloud services under time pressure.

What they do NOT prove: that I can sit with a client, understand their problem, design something appropriate, and build it without breaking things.

That gap is exactly where freshers struggle. You study for months, pass the exam, and then face an interviewer who asks "Tell me about a time you designed a solution for a customer." You have nothing.

Last year I sat across from a candidate with three AWS certifications. I asked him to walk me through a time he gathered requirements from a non-technical stakeholder. Thirty seconds of silence. Three certs, zero stories. That is the gap SimuLearn closes.

Here is how the credential types compare:

Certifications prove you KNOW it. Knowledge of services, best practices, theory.

Microcredentials prove you can DO it. Specific hands-on skills in a live environment. No multiple choice.

SimuLearn Badges prove you can DELIVER it. The full cycle from client conversation to working solution.

For someone with zero professional cloud experience, that third one is useful. It gives you something concrete to discuss in interviews. "I gathered requirements from a retail client who needed personalized recommendations, designed a serverless pipeline, and built it in the console." That sentence alone makes you more memorable than someone who just lists a cert.

The 12 Badges Available Right Now

Two of these are completely free. No subscription. No credit card. Nothing.

Free:

With Skill Builder subscription ($29/month or $299/year):

Solutions Architect
Serverless Developer
AI Architect
Machine Learning
Security
Networking
Data Analytics
Healthcare
Manufacturing and Automotive
Financial Services

The free ones cover cloud fundamentals and AI. The two hottest entry points in cloud right now.

The Free Starting Path I Would Follow Today

If I were starting from zero in 2026, here is exactly what I would do.

Month 1-2: Build the foundation (cost: $0)

Start with the SimuLearn Cloud Practitioner learning plan. Take your time. The platform offers two modes: Scripted mode guides you through the conversation with prompts, and Open Dialogue mode lets you drive the meeting yourself. Begin with Scripted to see how a proper client conversation flows, then switch to Open Dialogue once you feel ready.

The customer conversations will feel awkward at first. That is normal. Real client meetings are awkward too. You are practicing that discomfort in a safe environment.

When you finish, you have your first verified badge.

Month 3: Add the AI layer (cost: $0)

Complete the AI Practitioner learning plan. Generative AI shows up in most cloud job descriptions now. This badge tells employers you understand how AI fits into cloud architecture. Not just theory. You built something.

Month 4: Take the certification exam (cost: $100)

Now take the Cloud Practitioner certification. You already have hands-on practice from SimuLearn. The exam covers some ground you have already worked through, though it also tests pricing models, support plans, and global infrastructure that SimuLearn may not cover in depth. Study those gaps, but you will not be starting from zero.

Total investment: $100 and four months.

What you have at the end: 2 SimuLearn badges and 1 certification. Three verified AWS credentials on your LinkedIn profile. All proving different things. All verifiable by any recruiter who clicks the link.

Bonus: AWS also made microcredentials free in April 2026. Four are available: Serverless, Agentic AI, Application Networking, and Incident Response. These are pure hands-on assessments. If you want to stack more credentials after your certification, these are worth looking at.

Many people spend those same four months watching tutorials and collecting notes they never revisit. This path gives you something verifiable at the end of each month.

The LinkedIn Advantage Nobody Is Talking About

Every badge issued through Credly becomes a verified credential on LinkedIn. Not a self-declared skill. Not a line on your resume anyone could type. A verified badge that links back to exactly what you did to earn it. Anyone can click it and confirm it is real.

When a recruiter clicks your badge, they see:

Who issued it (Amazon Web Services)
What it represents (full learning plan completion)
What skills it validates (specific, detailed)
When you earned it

This cannot be faked. That matters when you have no work experience to reference.

When you share a badge as a LinkedIn post, your network sees it. People engage with achievement posts. That engagement puts your name in front of people who might not have found you otherwise. For freshers with a small network, a badge post can be good visibility.

How effective is this model? AWS says Cloud Quest badge earners share their accomplishments "at rates well above industry benchmarks." Across the broader AWS Education Programs (Academy, Educate, re/Start), Credly's survey data shows 99% of badge earners consider them valuable, 42% got a new job, and 85% received a raise, promotion, or new role. Those programs include full training and career support, not just a badge. SimuLearn follows the same Credly model, but these numbers are not guaranteed outcomes for every badge earner.

Verified badges on your profile send a signal: this person is actively investing in cloud skills, and they can back it up.

For Career Switchers: Your Existing Skills Are the Cheat Code

If you are moving into cloud from another field, SimuLearn gives you something certifications never could: a way to leverage what you already know.

Coming from sales or consulting? The customer conversation component is YOUR strength. You already know how to ask questions, handle objections, and translate technical concepts into business value. SimuLearn lets you combine that with new technical skills and prove both in one credential.

Coming from healthcare, manufacturing, or finance? Look at those industry-specific learning plans. A SimuLearn Healthcare badge tells employers: "I understand compliance, I understand the domain problems, AND I can build cloud solutions for them." I have seen people transition from clinical roles into cloud at consulting clients. The combination of domain knowledge plus technical proof is what gets them past the resume screen when pure technologists cannot.

The subscription costs $29/month. Subscribe for three months, earn your role-specific or industry-specific badge, cancel. You spent $87 total. Compare that to a bootcamp at $10K or a master's degree at $40K.

That $87 gets you a verified AWS credential on LinkedIn, hands-on experience in a live console, and client simulation practice you can reference in every interview. For a career pivot, that is a solid starting investment. One honest note: the paid badges are newer to the market than certifications. Not every recruiter will recognize them yet. But the hands-on experience you gain is yours regardless of badge recognition.

My Honest Take After 10 Years in Cloud

I have not personally completed a SimuLearn learning plan yet. Full disclosure. I also do not know how long each plan takes to finish. AWS does not publish that number anywhere I could find. Could be 10 hours, could be 60. That matters if you are working full time and planning your evenings around this.

What I do know: SimuLearn badges are the first AWS credential that evaluates both your communication skills and your technical ability in one package. That combination is what the actual job requires. Every architecture review I have ever been in required both.

But let me be honest about limitations too. This is still a simulation, not real client work. A hiring manager who has never heard of SimuLearn might not know what the badge means yet. These are new, launched July 2026. It will take time for the market to recognize them the way it recognizes AWS certifications.

These badges will not replace certifications. Hiring managers still filter by cert. But they fill a gap that certifications cannot: evidence that you practiced the full job, not just the exam.

If you are a fresher reading this, your path is clearer than it was a year ago. Start with the free plans. Build the habit of doing, not just studying. Earn something verifiable before you spend a single dollar on an exam.

The old way: study, memorize, pass, hope.

The new way: build, prove, share, get noticed.

Start here:

AWS SimuLearn Cloud Practitioner (free)
AWS SimuLearn AI Practitioner (free)

Have you tried SimuLearn yet? What was your experience with the customer simulation part? I am genuinely curious whether the Open Dialogue conversations feel realistic or scripted. Drop your thoughts below.

If this helped clarify the credential landscape, a ❤️ helps other beginners find it too.

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

Kiro CLI Gets Worse After an Hour. Here's How I Fixed It.

Sarvar Nadaf — Thu, 16 Jul 2026 14:37:01 +0000

Two hours into a Kiro CLI session, it gave me a generic IAM trust policy example. We had literally set up the OIDC provider together 30 minutes earlier. It forgot.

This is not a bug. It has a name: context rot. And once I understood the mechanics, I stopped fighting it and started managing it.

I use Kiro CLI every day. Checking CloudWatch alarms, debugging IAM policies, reviewing security groups, looking at cost reports, setting up infrastructure. It is my go-to tool for anything AWS.

But after a few weeks I noticed the pattern. The longer I keep a session going, the worse Kiro gets. Early in the session it is sharp. Finds the right file, gives the right answer, runs the right command. Two hours later it starts doing odd things. It re-reads files it already looked at. It gives vague answers. It suggests things I already tried.

What actually happens when context fills up

Kiro has up to a 200k token context window (depending on model). Every message you send, every response it gives, every file it reads, every command output: all of it goes into that window. It adds up fast.

A typical morning for me looks like this:

"Check if there are any CloudWatch alarms firing in us-east-1"
"Show me the IAM policy attached to the lambda-processor role"
"Why is this S3 bucket policy denying access from the VPC endpoint"
"Look at the cost explorer data for the last 7 days"
"What EC2 instances are running in the staging account"

Each of those triggers multiple tool calls. Kiro reads files, runs AWS CLI commands, processes the output. By the fifth question, the context window has maybe 30-40% filled.

Sounds fine. That's the trap.

I keep going. I debug a CloudFormation deployment. I check a few security groups. I look at some ECS task definitions. By lunch, I am at 60-70% context usage and Kiro starts struggling.

What struggling looks like:

It runs aws sts get-caller-identity again even though it already knows which account I am in
It re-reads the same terraform files it read an hour ago
Responses get longer and less useful (more filler, less action)
It starts suggesting solutions to problems I already fixed earlier in the session

If you manage 5+ AWS accounts across environments, context fills 3x faster because every describe-instances call across accounts dumps more output into the window.

Why this happens (and why "try harder" does not fix it)

The model can see everything in the context window but it cannot focus on everything equally. Research calls this the "Lost in the Middle" problem. A Stanford paper (Liu et al., 2023) demonstrated that LLMs exhibit a U-shaped attention pattern. They attend strongly to information at the beginning and end of their context window. Everything in the middle gets reduced attention.

A 2025 follow-up study found the effect is strongest when inputs fill up to 50% of the context window. Beyond that, primacy bias weakens and recency bias dominates, meaning the model increasingly favors whatever you talked about in the last few minutes over the rules and context from the start of your session.

The Kiro team calls this phenomenon "context rot." Anthropic's own engineering docs define it directly: "Context must be treated as a finite resource with diminishing marginal returns."

Here is what that means in practice. When the window is full of old conversations about IAM policies, cost reports, and security groups, and you ask about an ECS deployment, the model has to sort through all that irrelevant context to find what matters. It cannot selectively ignore the old stuff. Every token participates in every inference step, regardless of whether it is relevant to your current question.

The really frustrating part: the model does not know it is degraded. It will confidently tell you it is following all your instructions while demonstrably not doing so. You cannot fix this by telling it to "try harder" or "pay more attention." The degradation is architectural, not motivational.

When the context hits 100%, Kiro auto-compacts. It summarizes the old conversation to make room. The problem is that summaries lose detail. That IAM policy you debugged earlier? After compaction, Kiro only remembers "we fixed an IAM issue," not the specific policy ARN or the condition key that was wrong. In measured sessions, auto-compaction can reduce 132,000 tokens to about 2,300, a 98% reduction. The token count is small. The cognitive capital destroyed is enormous.

The 5 failure modes (in order of how often I hit them)

Context rot is the foundation, but it cascades into other behaviors. Once you recognize these patterns, you stop blaming yourself or the model:

1. Context rot itself. Attention on your early instructions fades as the window fills. The model stops following rules it was given at the start. You told it "never modify production resources without asking first" in minute 1. In minute 90, it just runs the command.

2. Pattern matching over reasoning. Instead of checking what actually exists, Kiro copies patterns from earlier in the conversation. It writes an IAM role that duplicates one you already created three prompts ago. It is coding from its conversation context, not from your actual files.

3. Completion bias. When you push back on a bad result, the model does not get more careful. It gets more agreeable. It ships something that looks different but is equally wrong. The angrier you get, the faster it produces plausible-looking garbage to end the conflict.

4. Re-verification loops. The model forgets it already verified something. It calls aws sts get-caller-identity again. It re-reads your terraform state file. It asks "which region are you working in?" for the third time. Each redundant call wastes context and accelerates the rot.

5. Advisory compliance decay. Early in a session, Kiro respects guardrails: "I'll ask before modifying production resources." Late in a session, it rationalizes around them: "Since we've been working in this account, I'll go ahead and apply the change." The constraint fades because the instruction that set it is now buried in the middle of a bloated context window.

What I do now

One task per session

This is the biggest change. I used to keep one session open all day. Now I start a new session for each distinct task.

Debugging a CloudFormation stack failure? New session.
Checking cost reports? New session.
Writing a new Lambda function? New session.

Each session stays focused, context stays small, and Kiro stays sharp. Each wasted minute re-explaining context is a minute I am not solving the actual problem. Over a week, that adds up to 30-60 minutes of lost productivity.

To start a new session in Kiro CLI, just exit and re-enter:

exit
kiro-cli

This gives you a completely fresh session. The old one stays on disk if you need to go back to it.

If you just want to reset the conversation without leaving the process, use /clear:

/clear

The difference: exit + kiro-cli starts a brand new session with a new ID. /clear wipes the conversation but keeps the same process running.

Use /compact before it auto-triggers

If I am in a session that has been going for a while and I am not done yet, I run /compact manually before Kiro does it automatically.

/compact

Why? Because when I trigger it myself, I know what just got summarized. I can immediately re-state the important bits.

After compacting, re-state the important context:

We are debugging a CloudFormation stack called prod-api-gateway that failed 
on an AWS::ApiGateway::RestApi resource. The error was "Invalid stage identifier specified".

Now Kiro has a fresh context with only the relevant details. The same question that took 12 seconds before compaction takes 3 seconds after.

Put persistent context in steering files (the biggest token saver)

Things I tell Kiro every single session (which AWS accounts I work with, naming conventions, preferred regions) go in steering files. Kiro supports three scopes:

Workspace steering (.kiro/steering/), applies to one project:

mkdir -p .kiro/steering

# .kiro/steering/aws-environment.md

## AWS Environment
- Production account: 111111111111 (us-east-1)
- Staging account: 222222222222 (us-east-1)
- Default profile: production
- All infrastructure is in Terraform under /infra

## Preferences
- Use AWS CLI v2 commands
- Always specify --region explicitly
- Check CloudTrail before making IAM changes
- Never modify production resources without asking first

Global steering (~/.kiro/steering/), applies to ALL your workspaces:

# ~/.kiro/steering/aws-defaults.md

## Global AWS Conventions
- Always use --output json for parseable results
- Prefer least-privilege IAM policies (never use * in Resource)
- Tag all resources with Environment, Team, and CostCenter
- Use ap-south-1 as default region unless specified

Global steering is loaded in every session regardless of which project you are in. If workspace steering conflicts with global steering, workspace wins. This is where I put my org-wide standards.

Team steering: you can push steering files to your entire team via MDM or a shared repository. Everyone gets the same conventions without explaining them:

# Team lead pushes to shared repo
git clone internal-repo/kiro-steering ~/.kiro/steering

Kiro automatically loads everything in .kiro/steering/ at the start of every session. Verify what is loaded with /context show.

The difference this makes: my baseline context went from wasting 15-20% on repeated instructions to 0%. Every new session already knows my environment.

Use conditional steering with fileMatch

Not all context is needed all the time. Kiro supports inclusion modes that load steering only when relevant:

---
inclusion: fileMatch
glob: "infra/**/*.tf"
---

# Terraform Conventions
- Use modules for all repeatable infrastructure
- State stored in S3 with DynamoDB locking
- Never hardcode AMI IDs, use data sources

This file only loads when Kiro reads a .tf file under the infra/ directory. When I am working on Lambda code, these Terraform conventions do not eat my context window.

Three modes:

always (default): loaded every session
fileMatch: loaded only when a matching file is in context
manual: loaded only when you invoke it with a slash command

I split my steering into 5 focused files with appropriate modes instead of one giant file. Token usage for steering dropped from 8% of my context to about 3%.

Watch the percentage

Kiro shows context usage in the sidebar. You can also check it explicitly:

/context show

This shows a breakdown: how much your steering files use, how much tools use, how much your conversation uses. My rule of thumb:

Under 40%: keep going, no issues
40-60%: finish current task, then start fresh
Over 60%: responses are getting worse, wrap up now

If you find yourself repeating instructions or Kiro starts re-reading files, do not fight it. Start fresh.

Use knowledge bases for large reference material

If you work with big Terraform repos or lots of CloudFormation templates, do not add them as context files. They will eat your context window on every single request, even when you are not asking about them.

Kiro's /knowledge feature (experimental, enable it first) indexes your files locally and only pulls in relevant chunks when you ask about them:

# Enable the feature
kiro-cli settings chat.enableKnowledge true

# Add your infrastructure code
/knowledge add --name "terraform-infra" --path /path/to/infra --include "**/*.tf" --exclude ".terraform/**"

# Add documentation
/knowledge add --name "runbooks" --path /path/to/runbooks --include "**/*.md" --index-type Best

Two index types matter here:

Fast (lexical/bm25): for code, configs, logs. Quick keyword matching.
Best (semantic): for documentation and runbooks. Understands natural language queries.

I use Fast for my Terraform code (I search by resource names and module names) and Best for our runbooks and architecture decision records (I search by questions like "how do we handle cross-account access").

My baseline context dropped from 35% to 12% after moving Terraform files out of steering and into the knowledge base. Kiro searches your files when needed without them sitting in context all the time.

The knowledge base persists across sessions. Index once, use forever. Run /knowledge update periodically when your files change, or /knowledge update with no arguments to re-index everything at once.

Delegate exploration to sub-agents

This one is underused. When Kiro needs to investigate something (scan a directory, read multiple files, research an error) it can delegate to a sub-agent with its own isolated context window.

Why this matters: if the main session reads 20 files to debug an issue, all 20 files stay in your context forever. If a sub-agent does that exploration, it returns a focused summary and your main context stays clean.

I noticed Kiro does this automatically for some tasks, but you can nudge it:

Investigate why the ECS task is failing to pull from ECR. 
Check the task definition, the ECR repository policy, and the VPC endpoints. 
Give me a summary of the root cause. Do not dump all the raw output.

The key phrase is "give me a summary." It signals that you want focused results, not raw exploration dumped into your session.

A real example

I am currently testing Terraform code for an upcoming EKS article in my Terraform series. The setup is complex: VPC with private subnets, EKS cluster, managed node groups, IAM roles for service accounts, security groups, and add-ons like CoreDNS and kube-proxy.

I started a Kiro session asking it to help me structure the modules. Then I asked it to write the VPC config. Then the EKS cluster resource. Then the node group. Then I asked it to review the IAM OIDC provider setup.

By this point the session had all the previous Terraform code, all the plan outputs, and all my back-and-forth corrections in context.

When I asked "add the aws-load-balancer-controller IAM role with the correct trust policy," Kiro gave me a generic example from the docs. It did not reference my actual cluster name or OIDC provider ARN that we had set up 30 minutes earlier. Gone.

It was like talking to someone who forgot the last hour of conversation.

I ran /clear, started fresh, and said:

I am building a production EKS cluster with Terraform. The cluster is called 
prod-platform in us-east-1. The OIDC provider is already set up. I need an 
IAM role for aws-load-balancer-controller with the correct trust policy that 
references my cluster's OIDC issuer. Here is my existing oidc provider ARN: 
arn:aws:iam::111111111111:oidc-provider/oidc.eks.us-east-1.amazonaws.com/id/ABCDEF123456

Kiro immediately gave me the exact trust policy with my ARN, my namespace, my service account name. No generic examples. No confusion with earlier VPC or node group context.

Total time wasted before clearing: 15 minutes of re-explaining.
Time to get the right answer after clearing: 20 seconds.

The context budget cheat sheet

Context Usage	What's Happening	Action
Under 30%	Sharp, focused, fast	Keep working
30-50%	Still good, starting to accumulate noise	Finish current task, then evaluate
50-70%	"Lost in the Middle" kicks in hard	Wrap up NOW or `/compact`
Over 70%	Active degradation: repeating, re-reading, vague answers	Start fresh. Do not push through.
Auto-compaction triggers	98% information loss incoming	You waited too long. `/compact` earlier next time.

What this is NOT

I want to be clear about something. This is not a Kiro-specific bug. Every AI coding tool with a context window has this problem: Claude Code, Cursor, Copilot Chat, Windsurf. The architecture is the same transformer attention mechanism underneath.

The difference is whether you manage context deliberately or let it manage you. Most developers do not think about context at all. They open a session, work for 3 hours, get frustrated that "the AI got dumb," close it, and start fresh the next day.

That cycle wastes an hour of degraded work every single day. Across a team of 5 engineers, that is 25 hours per week of suboptimal AI output. The fix takes zero extra tools. Just awareness and a habit change.

I shared this approach with two engineers on my team. Both had been complaining about Kiro "getting dumb" by afternoon. Turns out they were running single sessions for 4-5 hours straight. Once they switched to session-per-task, the complaints stopped within a day.

The model is not getting dumber. Your context window is getting noisier. Fix the noise, and the model stays as sharp at hour 3 as it was at minute 1.

Links:

Kiro CLI context management: kiro.dev/docs/cli/chat/context/
Steering files documentation: kiro.dev/docs/cli/steering/
Knowledge management (experimental): kiro.dev/docs/cli/experimental/knowledge-management/
/compact command changelog: kiro.dev/changelog/cli/1-24/
Ralph Loop technique: developer.mamezou-tech.com
"Lost in the Middle" research: arxiv.org/abs/2307.03172
Context rot whitepaper (Empromptu): empromptu.ai/resources/context-rot-progressive-prompt-ephemerality

How do you manage long sessions with AI coding tools? Do you start fresh or push through? Drop your approach in the comments. I am genuinely curious if others hit the same wall around the 50% mark or if it depends on the type of work.

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

DEV Community: Sarvar Nadaf

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

What I Built

Demo

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

🎬 Demo

🎯 What It Does

📊 The Problem

How I Built It

The Research That Shaped Everything

Architecture

Technical Decisions

The Prompt Engineering

What I Learned

Prize Categories

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

The scenario: a real P1 on FinPay

Layer 1: Investigation passes freely

Layer 2: Dangerous commands get blocked

Layer 3: Human approves the proper fix

The 8 security layers explained

The 137 deny patterns

Audit trail: every action logged

Enterprise permissions config

What this means for your CISO

Try it yourself

kirodotdev / KiroCrew

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

Kiro Crew

Quick start

What I learned running this for 3 weeks

What this costs

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

What I Built

Demo

What's in the page:

Journey

The Approach

Technical Highlights

Accessibility

What I'm Proud Of

Stack

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

Table of Contents

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

kirodotdev / KiroCrew

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

Kiro Crew

Quick start

What I'd change for a real team

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

Table of Contents

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

kirodotdev / KiroCrew

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

Kiro Crew

Quick start

What I'd do differently in production

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

Table of Contents

What Kiro Crew actually is