DEV Community: Jarod Stewart

How I Build Features with Agent Swarms and TDD

Jarod Stewart — Wed, 11 Mar 2026 18:35:26 +0000

Most teams using AI coding assistants are doing it wrong. They open a chat, paste some context, say "build me X," and hope for the best. The output is inconsistent. The code doesn't follow existing patterns. Tests are an afterthought. Every feature feels like a coin flip.

I had the same problem. So I built an entire software development lifecycle that runs on agents — not as a novelty, but because I was tired of rework.

The bottleneck is context, not capability

When you ask an AI agent to "build feature X," it starts coding immediately. No research. No pattern discovery. No test strategy. It invents new patterns instead of following existing ones. The output looks like code written by someone who joined the team today and skipped onboarding.

So I built a system that front-loads context before any code is written. It's a single Claude Code skill called /sdlc that orchestrates six phases:

/sdlc idea                    → 1-idea.md
/sdlc research <feature>      → 2-research.md
/sdlc plan <feature>          → 3-plan.md
/sdlc build <feature>         → 4-build.md
/sdlc review <feature>        → 5-review.md
/sdlc context <feature>       → 6-context.md

The highlights

Research swarms — 4 independent agents investigate each feature in parallel: codebase analysis, library docs, market research, and a contrarian devil's advocate. They don't coordinate. Independent perspectives surface blind spots that groupthink misses.

Pattern baselines — Before any code is written, the plan phase finds existing implementations that do the same kind of thing. Every file change in the plan references a specific "Pattern From" file and line number. The agent follows the template instead of inventing.

TDD-driven builds — Red, green, refactor for every unit. A regression gate (full test suite + lint + typecheck) runs after each unit goes green. No skipping.

Adversarial review — Not a friendly once-over. Five dimensions: plan compliance, pattern compliance, security, correctness, and performance. The verdict is SHIP, FIX AND SHIP, or BLOCK.

Baseline enforcement — A rule engine in CI that encodes every lesson into automated checks. Banned dependencies, architecture tests, and ratchets that force one-way progress on legacy patterns. The review phase feeds directly into baseline — creating a flywheel where each feature makes the next one harder to ship with bugs.

What it looks like in practice

For a medium-sized feature, the full lifecycle takes about 45 minutes of my time:

Phase	My Time	Agent Time
Idea	5 min	—
Research	4 min	5–10 min
Plan	10 min	5 min
Build	7 min	15–30 min
Review	3 min	5 min
Context	1 min	2 min

I'm a reviewer and decision-maker, not a typist. The agents do the reading, the coding, and the testing. I approve the plan and the ship decision.

Read the full post →

The full article covers the coordinator pattern, how ratchets enforce one-way progress on tech debt, the TDD rules I learned the hard way, and how the review phase's lint rule extraction creates a self-enforcing codebase.

A CI tool that stops AI from undoing your team's architectural decisions

Jarod Stewart — Wed, 18 Feb 2026 16:10:31 +0000

AI coding tools are fast. They're also confidently wrong about your team's conventions.

You migrate off moment.js. Cursor adds it back. You build a repository layer. Copilot writes db.select() directly in page.tsx. You ship a design system with a <Button> component. Claude writes a custom <button> with inline Tailwind. You ban axios. An AI assistant adds it to package.json.

They generate from training data, not from your architecture. And the legacy patterns in your codebase are the ones they see most -- so they reinforce them.

I kept seeing this across teams and decided to build something to fix it.

Baseline

Baseline is a Rust-based CLI that enforces team decisions in CI. You define rules in a single TOML file, and it catches violations before they land.

npx code-baseline scan

It covers a class of rules that ESLint can't express.

Banning patterns where they don't belong

AI loves bypassing your abstractions. Scope bans to specific paths:

[[rule]]
id = "no-db-in-pages"
type = "banned-pattern"
pattern = "db."
glob = "app/**/page.tsx"
severity = "error"
message = "Use the repository layer, not direct DB access in pages"
suggest = "Import from @/lib/repositories instead"

Banning imports and dependencies

Deprecated packages are one autocomplete away from returning:

[[rule]]
id = "no-moment"
type = "banned-import"
severity = "error"
packages = ["moment", "moment-timezone"]
message = "moment.js is deprecated — use date-fns or Temporal API"

[[rule]]
id = "no-request"
type = "banned-dependency"
severity = "error"
packages = ["request", "request-promise", "axios"]
message = "Use native fetch or undici"

The banned-dependency rule parses package.json directly -- it catches packages added as dependencies even if no source file imports them yet.

Ratcheting legacy code to zero

This is the feature I'm most proud of. Say you have 200 calls to legacyFetch() and want to migrate to apiFetch():

[[rule]]
id = "ratchet-legacy-fetch"
type = "ratchet"
severity = "error"
pattern = "legacyFetch("
max_count = 200
glob = "src/**/*.ts"
message = "Migrate to apiFetch"

Set the ceiling at 200. Next sprint, migrate some, lower it to 180. The number only goes down. Any PR that adds new legacy calls fails CI.

ESLint is pass/fail. It can't count occurrences across your codebase and enforce a decreasing ceiling over time.

Tailwind + shadcn enforcement

If you use Tailwind with shadcn/ui, AI will write bg-white and text-gray-900 everywhere. Your design system says bg-background and text-foreground. Dark mode breaks silently.

Baseline ships two rules for this:

Dark mode enforcement flags color classes missing a dark: variant:

7:21  error  Missing dark: variant for color class: 'bg-white'
  │ <div className="bg-white border border-gray-200 rounded-lg">
  → Use 'bg-background' instead — it adapts to light/dark automatically

Semantic token enforcement bans raw color classes entirely and suggests your tokens. Ships with 130+ default mappings.

Both rules understand className, class, cn(), clsx(), cva(), and twMerge().

Proximity rules

Enforce that related patterns appear near each other:

[[rule]]
id = "org-scoped-deletes"
type = "window-pattern"
severity = "error"
pattern = "DELETE FROM"
condition_pattern = "organizationId"
max_count = 80
glob = "src/**/*.ts"
message = "DELETE queries must include organizationId within 80 lines"

Presets

Get started in one line instead of writing rules from scratch:

[baseline]
extends = ["ai-codegen", "security", "nextjs"]

Preset	What it catches
`ai-codegen`	`as any`, empty catch, console.log, TODO, placeholder text, var, require in TS, and more (12 rules)
`security`	Hardcoded secrets, eval, dangerouslySetInnerHTML, .env files, http:// URLs (10 rules)
`nextjs`	Use next/image, next/link, next/font; no next/head or next/router in App Router (8 rules)
`shadcn-strict`	Dark mode enforcement, theme tokens, no inline styles, no CSS-in-JS (5 rules)

What the output looks like

src/utils/helpers.ts
  1:0  error  moment.js is deprecated — use date-fns  no-moment
    │ import moment from 'moment';
    → import { format } from 'date-fns'

src/components/BadCard.tsx
  7:21  error  Missing dark: variant for 'bg-white'  enforce-dark-mode
    │ <div className="bg-white border border-gray-200 rounded-lg">
    → Use 'bg-background' instead

✗ 9 violations (7 error, 2 warning)

CI integration

Ships a GitHub Action that annotates violations inline on PR diffs:

- uses: stewartjarod/baseline@main
  with:
    paths: 'src'

On PRs it automatically scans only changed files. Outputs GitHub annotations, SARIF for Code Scanning, and markdown summaries.

The technical bits

Written in Rust. Single binary, no Node runtime.
Tree-sitter for AST-aware rules (component size, nested components, useState/useEffect analysis)
Parallel scanning via rayon
Respects .gitignore automatically
Also runs as an MCP server so AI tools can query your rules directly
Available on crates.io and npm

Install

# Run instantly
npx code-baseline scan

# Or install
npm install -g code-baseline
cargo install code-baseline

Linters catch syntax. Formatters fix whitespace. Baseline enforces the decisions your team has already made -- especially the ones AI keeps ignoring.

MIT licensed. Feedback and contributions welcome.

GitHub: stewartjarod/baseline

Is this vibe coding?? I built an AI email template editor in 2 days

Jarod Stewart — Thu, 11 Dec 2025 18:26:46 +0000

What I built

An email template editor where you describe what you want and the AI builds it.

Generate:

"Create a welcome email for new users"
Full template in 5 seconds — header, personalized greeting, CTA, footer

Iterate:

"Make the button green"
"Add a section about our mobile app"
"Show a discount code only for new users"

Then edit visually or in code. Chat → Visual → Code. Same template.

Why this works (and most AI editors don't)

Most AI-to-email tools generate raw HTML. You get a blob of code, maybe it works, probably it breaks in Outlook, and you can't easily edit it.

This editor does something different: the AI generates editor structure, not HTML.

Specifically, it outputs TipTap JSON that maps to React Email components:

{
  "type": "doc",
  "content": [
    {
      "type": "emailSection",
      "content": [
        {
          "type": "emailHeading",
          "attrs": { "level": 1 },
          "content": [
            { "type": "text", "text": "Welcome, " },
            { "type": "variable", "attrs": { "name": "firstName", "fallback": "there" } },
            { "type": "text", "text": "!" }
          ]
        }
      ]
    }
  ]
}

This structure is:

Editable — click any element, change it visually
Validated — only known node types allowed, hallucinations get caught
Portable — serialize to React Email, HTML, or plain text

The AI architecture

Constrained generation

The system prompt tells Claude exactly which node types exist:

const VALID_NODES = [
  'emailSection',
  'emailHeading', 
  'emailText',
  'emailButton',
  'emailImage',
  'emailDivider',
  'emailSpacer',
  'emailRow',
  'emailColumn',
  'variable',
  'conditional'
]

Each node has a spec: what props it accepts, what's required, examples of valid output.

Claude can only use these nodes. If it tries to invent emailCarousel or fancyWidget, the validator rejects it before it hits the editor.

Iterative editing

When you say "make the button green", the AI receives:

Your message
The current template JSON
Instruction to make targeted edits, not regenerate everything

So it finds the button node, updates style.backgroundColor, returns the modified JSON. Fast and predictable.

Brand kit integration

The system prompt includes the user's brand kit:

Primary Color: #5046e5
Font Family: Inter, sans-serif
Button Style: rounded (4px radius)
Company Name: Acme Inc
Logo URL: https://...

Generated templates automatically use these defaults. Less manual fixing.

The stack

Editor:         TipTap (ProseMirror-based)
Email output:   React Email
AI:             Vercel AI SDK + Claude Sonnet
State:          Zustand
Framework:      Next.js 16
Database:       PostgreSQL + Drizzle
UI:             shadcn/ui + Tailwind

Why TipTap?

TipTap lets you define custom nodes for your domain. Each React Email component (<Button>, <Section>, <Heading>) gets a corresponding TipTap node with its own schema and rendering.

The editor doesn't know it's building emails — it just knows it has nodes with certain attributes. The serializer handles the React Email conversion at export time.

Why React Email?

It outputs HTML that actually works in email clients. Outlook, Gmail, Apple Mail — the hard stuff is handled. And the component model maps cleanly to editor nodes.

Is this vibe coding?

Here's what I had before writing any code:

Database schema (templates, versions, blocks, brand kits, AI conversations)
State management design
API routes spec
Component architecture
Full list of TipTap extensions needed
AI system prompt and validation strategy

The AI didn't write any of that. I did — based on almost two years at SendGrid seeing what breaks in email infrastructure.

AI helped me implement fast. Describe a component, get 80% of the code, fix edge cases, move on. But the architecture? The constraints that make the AI output actually usable? That's experience.

The unlock: build at the speed of your ideas.

If you have the ideas, AI is a multiplier. If you don't, you get fast spaghetti.

What this is part of

This editor is one piece of Wraps.

The problem: AWS SES is cheap (~$1/10k emails) but painful. 90% of developers abandon during domain verification.

The alternative: SaaS tools (Resend, Postmark) have great DX but cost 10-100x more and lock you in.

Wraps: SaaS-quality developer experience, but deploys to YOUR AWS account. You own it. You pay AWS directly. If you stop paying us, your email keeps working.

The template editor lets you build emails with AI, edit visually, and send tests through your own SES.

More coming: SMS, background jobs, team dashboard, real-time collaboration.

wraps.dev

Questions?

Happy to go deeper on:

The TipTap → React Email serialization
How the AI validation works
The conditional block implementation
Anything else

Roast the architecture in the comments.

GraphQL for Consumer IoT Applications

Jarod Stewart — Fri, 06 Sep 2019 01:12:12 +0000

At Yonomi, we have to satisfy a wide array of requirements from our customers. We are savvy in event-based architecture, pub/sub protocols, and we work within the limitations of hardware: memory, battery, and internet availability. We also have to iterate quickly and expand functionality across a myriad of devices.

In the last year, we have learned a lot about GraphQL and have discovered some great features that may benefit the IoT industry and specifically, our customers in consumer IoT.

Enter GraphQL

Powerful Schema

GraphQL has a powerful built-in schema and a strong type system that serves as basic documentation for the API. The schema is facilitated by the GraphQL Schema Definition Language (SDL), which allows us to define a device’s type. You can learn more about SDL here. Once defined, the client and the server have a contract on parameters and values.

For example, a Light device type may need to define the device’s name that the end-user calls their light, whether the light is on or off, and what brightness the bulb is currently set to.

type Light {
  id: ID!
  name: String!
  power: Boolean!
  brightness: Int
}

With custom schema directives, we can take this a step further and define which attributes are stateful for a device type. In such cases, we can make a mutation request to set the state of that attribute on the device. When the device accepts and acts on that request it can respond with the new state of that attribute.

The custom schema directives let the client and server know which attributes are statefully managed by the device. Users can request to set the state of those attributes but, in the end, the device manages the actual state that it is in.

type Light {
  id: ID!
  name: String!
  power: Boolean! @state
  brightness: Int @state
}

Self-documenting APIs makes GraphQL ideal for consumer IoT where you need to control device’s attributes and states. The schema functions as a contract that both the client and server have to fulfill while exposing how the device functions. In the example of the Light type above, the Light’s name has to be a string, and the power and brightness attributes are stateful where only the device can report its state to the cloud. A user can tell the device to set a state but ultimately, the device is the source of truth on whether the request is accepted or not.

Data Relations

We initially considered GraphQL when our customers wanted more control over the data they requested. They also wanted access to related data with as few requests as possible for mobile applications. GraphQL is a natural choice for this because of its ability to refer to related data through the type definitions that define the schema of the object/model.

A great use case for this would be associating devices to locations. In consumer IoT, we associate devices to rooms within a house for products that are wanted in many rooms, like light bulbs. Our mobile app, in this case, would list devices that are in rooms all associated with a single house location. When a user wants to make sure the lights are off while on vacation, they can check the status of all the lights throughout the home and only make one API request.

Query {
  Location(id: "my_house") {
    devices {
      id
      ... on Light {
        power
        brightness
      }
    }
  }
}

This problem is commonly referred to as the over/under-fetching problem. In a RESTful architecture, you would normally make at least two requests to be able to obtain all of this data (under-fetching) and would have obtained more information than what you really needed (over-fetching). Over-fetching data could be extremely detrimental to a device that cannot handle unknown attributes or is limited in memory. By over-fetching data, a device is susceptible to buffer overflow, which overruns the buffer's boundary and overwrites adjacent memory locations. Letting devices control which data they want to work with and not having to worry about receiving more data than what was requested alleviates this problem entirely.

Mobile developers have also become innately aware of data consumption and strive to use as little as possible when they can. GraphQL enables minimizing data use through data relations that are defined in the schema and allowing the clients to be selective in their queries.

Subscriptions

As a cherry on top, Apollo server supports subscriptions out of the box. Subscriptions are GraphQL operations that watch events emitted from Apollo Server. The native Apollo Server supports GraphQL subscriptions without additional configuration.

GraphQL clients can get near real-time information on device’s states as they change. No need to poll for the device’s current state, just subscribe and listen for those changes as they happen. This works really well for app-clients that want to show device status changes as soon as they are available.

GraphQL Gotchas

Although these features of GraphQL are nice, there are some caveats when selecting relatively new software for production environments.

Tooling

Apollo and Prisma have been pumping out an impressive amount of tooling for GraphQL and things are only getting better with community support. Yet, there are a few things that are still hard to do, and everyone is doing things differently. Namely, acceptance testing.

At Yonomi, we are working on our own acceptance test tooling and one day we hope to share these with the community.

200 OK

In GraphQL everything is 200 OK.

Did you make a bad Query or Mutation? 200 OK.

Internal Server Error? 200 OK.

Not permitted to access that data? 200 OK.

As long as you hit the GraphQL server you will receive a 200 OK. As cloud experts, we have learned to rely on HTTP statuses to provide helpful and standard information. GraphQL has decidedly been remiss on some of the golden standards of HTTP.

Nullability

In GraphQL, every field is nullable by default. There are many ways for things to go wrong when interacting with n-number of databases, services, etc. to perform a single GraphQL request. So, if any of them fail, GraphQL will simply return null for that attribute or parent attribute. Although this is a design choice, it is something worth noting when working with GraphQL. If your clients rely on null values to mean more than the value simply wasn’t returned by your API, you might run into problems. The wonderful people at Apollo offer sound advice on this here. Be consistent and thoughtful and use non-nullables as diligently as possible.

Many benefits of GraphQL for Consumer IoT

GraphQL has the ability to self-document with its schema, can simplify API interactions to only one request, allows requests to specific fields, and it provides simple to use subscriptions to access real-time information. Although it has some weakness when considering available tooling and thinks everything is 200 “OK”, GraphQL provides a lot of power for use-cases specifically required by the internet of things. At Yonomi, we are continuing to learn and explore more on how GraphQL can better suit the needs of our customers now and in the future.

Originally published @Yonomi GraphQL for Consumer IoT Applications