Agent Driven Development

An Agile Process Framework for the AI-Enabled Age.

Welcome to Agent Driven Development (ADD), a new agile framework that harnesses the power of AI to revolutionize the software development process. In this post, we'll explore how to set up a CI/CD pipeline to leverage AI to write code, generate storybooks, and streamline your development process.

The ADD Process

  1. Structured Github Issues: ADD uses GitHub issue templates to bring structure to your issues and automatically apply labels.

  2. CI Pipeline with AI Integration: When issues are created, a CI pipeline is triggered, which calls GPT-4 to generate code, create storybooks, and open a pull request with the generated code.

  3. PR Previews: Review changes in your codebase visually through PR previews.

  4. Visual Testing: Utilize visual testing tools like Chromatic to create visual diffs of changes.

  5. Comments to Revise Changes: Update tests, storybooks, and revise changes directly by commenting

Key Components of Agent Driven Development

Github Issues Template

To initiate the process, we'll leverage GitHub issue templates to create forms that trigger code generation.

Github Action

You can take advantage of github issue templates to create forms that trigger code generation.

Use a schema to validate the generated code

To ensure the generated code meets your standards, it's a good practice to use a schema to validate it. For example, if you're generating TypeScript code, you might use the TypeScript compiler to validate the output. If the generated code doesn't meet the schema, you can feed that information back into GPT for reflection and improvement.

import { z } from 'zod';

export const rulesSchema = z.object({
    roles: z.array(z.string()),
    actions: z.array(z.string()),
    rules: z.array(z.object({
        role: z.string(),
        action: z.string(),
        decision: z.boolean(),

Use automated test to validate generated code

Running a test suite can also be used to create guardrails for the code GPT is generating. In my experience test are best run on PR creation and can be updated from a PR comment. Test should not be updated on the first pass though. Users should have to explicitly ask to have test fixed and the context surrounding the test fix.

Pre-commit hooks to format code

husky pre-commit hooks can be added to format code using formatters like prettier. This will help keep diffs to a minimum.

Reviewing generated code in a PR

When a user creates an issue using the Github Issue Template, a Github Action generates code and creates a pull request. This pull request can be previewed, allowing you to play around with what the system would be like if those rules were in place. If everything looks good, you can merge the pull request, and the new code will be shipped out to production.

Ephemeral Environments for PRs

PRs should be staged using something like Vercel/Netlify PR preview. This allows for previewing changes in an ephemeral environment before merging to production.

Visual Regression testing

Using a tool like Chromatic for visual regression testing helps ensure that changes to the UI don't break anything. Chromatic allows you to review changes and approve them before merging to production.

Comments in Ephemeral Environments drive WYSIWYG editor.

Finally, using comments in ephemeral environments can help drive a WYSIWYG editor. This allows users to visually edit components and see changes in real-time, making it easier to iterate on designs and quickly prototype new features.

Last updated