Top 5 AI Agent Patterns for Frontend Devs
When I code, I prompt, wait, and see what comes back. For a bigger feature I might reach for something like spec-driven development. Either way, I'm babysitting the coding harness through every interaction. Don't get me
When I code, I prompt, wait, and see what comes back. For a bigger feature I might reach for something like spec-driven development. Either way, I'm babysitting the coding harness through every interaction.
Don't get me wrong, that can work well. But plenty of problems are too complex to solve with a single prompt. For those, I'd much rather write one prompt, walk away, and come back to finished work. The patterns in this post came out of trying to do exactly that.
There are five of them, each a step past prompting and specs, and together they keep my agent working while I'm off doing something else: scheduled jobs, memory, subagents, workflows, and bots.
I show everything in Kiro Crew, the open source coding harness I know best, and a couple of things in the Kiro IDE. Some of these patterns exist in Claude Code, Codex, and OpenClaw too, so you can check those out as well.
Here's the video if you'd rather watch:
(Full disclosure: I'm a Developer Advocate at AWS, and Kiro is an AWS product.)
How to follow along (If you want to try this yourself)
- Kiro Crew installed. The install guide covers the desktop app and the one-line CLI install.
- Optional, the Kiro IDE if you want to try memory and workflows there too.
- A frontend project to point it at. Mine are a couple of Vue and Vite+ apps.
1. Schedule
The first feature I think everyone should try out is scheduling. Kiro Crew runs on a Gateway that can live on a VPS, a Mac mini, or your laptop, and it can kick off agent runs on a timer. You can set something similarly by running your harness in the cloud as well.
I care a lot about accessibility and Lighthouse scores on my sites. A daily job can run a Lighthouse test on my frontend code and send me a report, or open a pull request with the fixes instead.
The two jobs on my Schedule page right now aren't about code at all. One researches frontend and fullstack news every morning at 7 a.m. The other is a weekly CFP finder that looks for conference talks I could submit to, every Monday at 9.

Both jobs run on their own and drop a report when they finish.
Each job is a prompt plus a schedule. Open one and you get the message, a cron expression, and a timezone. The news job is 0 7 * * *.

Run Now is handy for testing a prompt before you trust it overnight.
You don't have to write cron by hand. Ask in chat, something like "every night at 2, run Lighthouse on /pricing and tell me what dropped," and the agent creates the job for you. The scheduling docs have the CLI version too.
2. Turn on memory
Memory is how your agent remembers who you are and what you're working on. I've been using this a lot. It works really well for remembering my preferences. For example, it knows I am a Vue.js fan, so it starts every project with Vue.js or Nuxt.
In Kiro Crew, memory lives in a folder at ~/.kiro/crew/workspace/memory as plain markdown, with files for your preferences and your projects. It gets pulled into context when it's needed. You can tell it things as you chat. Maybe you like tabs over spaces, or you want the Options API in Vue for some reason. Just say "can you remember this for me?"
The Kiro IDE has memory too, and the setting has four modes.

Off is the default, so you have to turn it on.
I run Use and learn. It can learn per project or globally, so every project shares the same preferences. Here's one it saved for me during a Vite+ project. I'd asked for a diagram, it asked me a bunch of setup questions, and I told it to just make a nice looking image.

I never wrote this rule. It appeared naturally as I was creating my project.
It even saved the tooling workaround it found, so the next diagram didn't hit the same missing dependency. If your harness has memory, turn it on and start telling it your preferences. Kiro Crew will sometimes turn what it learns into a skill on its own as well.
3. Ask for subagents
When you have a few pieces of work that don't depend on each other, they don't need to wait in line. Tell the agent to split it up. "Run three subagents and research this at the same time" is all it takes. *FYI, some harnesses will do this automatically, but it's hit and miss, I would always explicitly tell it to use subagents, and if needed use worktrees
I did that for my tech news. One subagent took markets and big tech, one took AI releases, and one took dev news like Hacker News threads and Vue, Nuxt, and Vite releases.

Three subagents, 35 seconds, 1.73 credits. The main agent combines the reports at the end.
Each subagent gets its own context, so they don't fill up your main chat or trip over each other. This is a lot cleaner than what I saw people doing a while back, opening 10 terminal windows and running an agent in each one. That gets messy fast.
The current models, like Claude Opus 5.5, are good at breaking work down. Kiro Crew also lets you keep several sessions open at once, each working on a different part of the codebase or a different project in the workspace. I like having that in a GUI where I can see everything that's running.
4. Build a workflow for anything you'll do twice
Workflows are harder to describe than the others. A workflow kicks off multiple agents in a set order, fans work out to them, and checks the results.
Let me explain it by using migrations as an example. You can build one workflow and then reuse for every migration. Each step can fan out to several agents or subagents, and usually there's a judge near the end that double checks the results before it's done.
Kiro Crew has a Workflows feature, and so does the Kiro IDE. The IDE ships with recipes you can open and read. Here's feature-pipeline.

Two separate reviewers on the code loop, then an aggregator that merges what they found.
The design and code steps loop, and the code loop runs two reviewers in parallel before an aggregator combines their findings. The recipes are saved as files you can open and change.
There's also a ralph recipe, if you've heard of the Ralph loop. It runs one coding agent through a JSON checklist, one item per pass, up to 200 times, until everything on the list is done. Check the Kiro workflows docs or the Kiro Crew workflows docs for how to write your own.
5. Give one area of your app to a bot
Bots take everything above and put it in one place. A bot is a long-running agent that owns one area of your work. It has its own memory, it can run its own subagents (Kiro Crew calls them workers), it can run on a schedule, and it works toward a goal.
I made one for accessibility and called it A11y. On the Schedules tab there's Heartbeat, which wakes the bot every hour to look for work on its own. For an accessibility bot, that means checking the app every hour as people merge things in. You can add your own schedules here too.

Heartbeat stays off until the bot has a goal.
The Goals tab is where you give it the goal, something like keeping the Lighthouse score above 90. The bot proposes milestones and you confirm them, which works a lot like the steps in a workflow. You can also turn on daily, weekly, or monthly check-ins so it sends you reports.

Each bot gets its own dashboard, and you build it by asking in chat.
Each bot also gets its own dashboard. Ask it to set one up showing what it's working on and what's next, and it builds the page for you.
One thing to know before you go all in on bots. Every Heartbeat wake, every worker, and every scheduled run uses credits. Heartbeat is off by default and you pick the interval, 30 minutes up to 4 hours. Start slow. The how bots work page covers the rest.
Wrap up
If you haven't noticed, the common theme in all these is that you can stop and walk away and things still get done. Scheduled jobs run while I sleep, memory carries what I've told it into the next session, subagents and workflows split the work up, and a bot does all of it for one part of my app.
Which one are you going to try first? Let me know in the comments. I'm curious if anyone is already running bots on a project.
Links
Originally published by Dev.to WebDev. Aggregated on AIWithGhost for educational purposes — full credit and traffic to the original publisher.
