Kiro Web: Cloud Automations, Autonomous Agents, and What We Actually Built With It

Most AI coding tools require you to sit in front of them. You prompt, they respond, you iterate — and the moment you close the tab, it all stops. Kiro Web changes that equation by giving you an agentic development environment that runs in your browser, works autonomously when you need it to, and can execute tasks on a schedule while you sleep. I've been using it daily, and the feature that changed my workflow most isn't the chat — it's cloud automations.

What is Kiro Web?

Kiro Web is the browser-based interface for AWS's agentic development platform. No local install, no IDE plugin — just open a browser, connect your GitHub or GitLab repos, and you have a full cloud sandbox with an AI agent that can read your code, run commands, call APIs, and push changes. It's the same Kiro intelligence you'd get in the IDE or CLI, but accessible from anywhere.

Two modes: Vibe and Autonomous

Kiro Web operates in two distinct modes, and knowing when to use each is the key to getting real leverage from it:

• Vibe mode — interactive, back-and-forth collaboration. You and the agent work together like pair programming. You guide, it executes, you review in real time. Great for exploration, debugging, and tasks where you want to stay in the loop.
• Autonomous mode — you describe the goal, the agent asks clarifying questions upfront, builds a plan, delegates to specialized sub-agents, and opens a pull request when done. You review the outcome, not the process.

The mental model: Vibe mode is for thinking together. Autonomous mode is for delegating. Both produce pull requests, but the workflow to get there is fundamentally different.

Cloud Automations: the game-changer

This is the feature that turns Kiro Web from a tool you use into a system that works for you. Cloud Automations let you describe a recurring task, point it at your repositories, set a schedule (daily, weekly, or a custom cron expression), and Kiro runs it autonomously — no session required. Each run gets its own cloud sandbox, clones your repos, executes the work, and opens a PR with the results.

• Up to five schedules per automation — different cadences for different needs.
• Each run is independent — isolated sandbox, no shared state between runs.
• Output is always a pull request — you review when you're ready, the next run is already queued.
• Edit anytime — change the schedule, update the prompt, swap repos. Changes apply to the next run.
• Disable without deleting — pause an automation and re-enable when you're ready.

What I actually built: a self-running job search pipeline

Theory is nice, but the proof is in what you build. Here's the real system I created with Kiro Web — a fully automated job search pipeline that searches for opportunities, validates them, and populates a Notion database on a schedule:

• Searches multiple job boards for Splunk Architect and Full-Stack Developer roles that accept applications from the Philippines.
• Validates each posting — verifies the URL links directly to the job (not a search page), confirms it's actively hiring, and checks PH eligibility.
• Scores each job against my resume and certifications (Fit Score 1–100).
• Estimates compensation based on listed salary or market rates.
• Writes qualifying entries to a Notion database with status '-' (unreviewed).
• Cleans up entries I've marked as Expired, Not Interested, or Not Working.
• Commits an activity log and opens a PR so I can review what changed.

The entire system lives in one GitHub repo. A steering file defines the rules. A shared Python utility handles Notion API operations. The automation config documents the exact prompt and schedule. Every component is version-controlled, testable, and transparent.

The architecture: one repo, multiple automations

Rather than scattering automations across multiple repos, I consolidated everything into a single repository structured for scale:

kiro-web-skills/
├── .kiro/steering/           # Rules loaded into every session
│   ├── workflow-guide.md     # How to create automations
│   └── job-search-rules.md  # Job search specific rules
├── automations/              # Config docs (prompt + schedule)
│   └── job-search/config.md
├── scripts/                  # Helper scripts
│   ├── shared/notion_api.py  # Reusable Notion wrapper
│   └── job-search/           # Automation-specific code
└── logs/                     # Activity logs per run

The steering files use "inclusion: always" in their frontmatter, so when the automation fires and clones the repo, the agent automatically loads all the rules, database IDs, candidate profile, and quality criteria into its context. No prompt engineering gymnastics required — the context is baked into the repo itself.

Steering files as project memory

This is the pattern that makes automations work on the first try. A steering file is markdown that the agent reads before doing anything. For the job search automation, it contains:

• Notion database ID and API configuration — so the agent knows where to write.
• Database schema — every property, its type, and expected format.
• Candidate profile — my skills, certifications, location, and tech stack for fit scoring.
• Eligibility rules — strict criteria for what counts as PH-eligible.
• Quality rules — URL validation, freshness checks, duplicate detection, and status-based cleanup.
• Search sources — prioritized list of job boards to check.

The agent doesn't need to be told these things every run. It reads the steering file, understands the constraints, and executes within them. That's the difference between an automation that works once and one that works reliably every time.

Practical tips for Kiro Web automations

• Test in Vibe mode first — simulate the full automation interactively before setting it loose. Catch issues while you can still iterate.
• Invest in steering files early — they're the single highest-leverage thing you can do. A well-written steering file eliminates 90% of prompt debugging.
• Keep secrets in environment variables — NOTION_KEY, API tokens, anything sensitive goes in secrets, never in code.
• Use the PR as a review checkpoint — automations always produce a PR. That's your control layer. Review, merge, or reject.
• Start with a simple schedule — run it Monday/Wednesday/Friday before going daily. Watch the output quality first.
• Document the automation config — version-control your prompt and schedule in an automations/ folder so you can reproduce the setup if needed.
• Build shared utilities — if multiple automations talk to Notion (or any API), extract a shared module once and reuse it everywhere.

Who should use Kiro Web

• Solo developers who want leverage — automate the recurring work so you can focus on the creative stuff.
• Small teams that need recurring tasks handled — dependency updates, doc drift, stale TODO cleanup, data pipeline checks.
• Anyone already in the AWS ecosystem — Kiro slots in naturally, and the cloud sandbox means zero local setup.
• Developers who think in systems, not just code — if you like building things that work while you sleep, this is your tool.

The best automation isn't the one with the cleverest prompt — it's the one with the clearest rules. Write the steering file well and the automation follows.

Kiro Web is available now for Pro, Pro+, Pro Max, and Power subscribers. If you're already building with Kiro CLI or the IDE, the web interface gives you automations and autonomous mode on top of everything you already know. And if you're figuring out how to structure automations for your own workflows — whether it's job searching, content management, or infrastructure maintenance — that's exactly the kind of system design I enjoy helping with. Reach out and let's build it.