How to build AI automation for your SDLC

Most teams use AI agents synchronously. You open a chat, ask, wait, read, ask again — pinned to the conversation for as long as the work takes. It’s a faster way to type and a better way to look things up, but you are still the one doing the work, one thing at a time.

The alternative is to hand work over and walk away. The agent picks up a task, works on its own, and you come back to something finished to review. Your job shifts from driving the work to specifying the outcomes and judging the result, and many pieces can be in flight at once. The surprise is how few parts it takes to build.

The basics of what you need

Practical steps to do this yourself

Most of these are systems you already have in place — they just need to be wired together differently. The three parts above expand into five practical steps.

Use the tracker you already have

GitHub Issues is enough to start. Linear, Jira and other work-management tools expose MCP servers you can connect agents to if that’s where your work lives, and AI-native alternatives like PandaOS and Multica are appearing.

Whichever you pick, define how work is organized: use status columns, labels or tags to mark what an agent should pick up and what is waiting on a person to review.

Change what a ticket contains

This is the part teams underestimate, and requires team discipline. A colleague picking up a vague ticket asks you a question; an agent makes an assumption, and you find out three hundred lines later.

Build a specification: the outcome to be achieved, complete with use cases, requirements, acceptance criteria, and what’s explicitly out of scope. The detail you’d normally leave implicit is now the interface.

Discuss the specification with both the agent and the humans on the ticket, so that context isn’t lost.

Run/trigger the agent headlessly

Whether it’s Claude Code, Codex, OpenCode or another harness, configure it to run non-interactively. There are two architectural patterns. Either an event triggers the run — a label added or a pull request opened in GitHub firing a GitHub Action — or the harness runs in a loop, continuously polling your tracker for work to pick up.

With each new task, there needs to be a disposable container to run it in, with a clean checkout and scoped secrets, and each harness needs to be set up with the skills, tools and MCP servers it will use. If you’re running locally, git worktrees are the cheapest way to give several agents their own working copy of the same repo.

There are many projects building this layer for you. Some of these are:

• Sandcastle — Orchestrates coding agents in isolated sandboxes
• Flue — A programmable TypeScript harness for durable agents
• Herdr — A runtime for your coding agents to live on
• Conductor — Runs a team of coding agents in the cloud
• Parallel Code — Dispatches agents in parallel, each in its own worktree

Put context where it can be searched

Harness / LLM session memory and logs are usually stored on your local machine. With disposable containers, that context is lost after every task, so you need a mechanism for storing and building knowledge that outlives the container.

CLAUDE.md or AGENTS.md is the entry point, not the project’s memory: it gets loaded on every run, so keep it to what’s true for every task and keep it short. Everything else — architecture decisions, why an abstraction exists, what features were built last quarter — belongs in structured context where an agent can search for the two paragraphs that matter.

An MCP server or CLI is the standard way to access context external to the active session, and skills and plugins pull everything together.

The simplest version is a documentation folder structure committed to the repo, or connectors to whatever databases or external systems exists. Beyond that, there are many options for this layer:

• Supermemory — A memory and context layer for AI
• Project Brain — Stores reviewed, structured knowledge authoritative enough to guide downstream reasoning
• Context-llemur — Portable, version-controlled context that travels between all your AI tools
• Memory Bank, Basic Memory or Context Portal — MCP servers that turn file-based memory banks into a queryable service

Wire up a small step from the full workflow first

Start with one narrow, recurring class of work — dependency bumps, flaky test triage, small well-specified bug fixes — and let it run for a couple of weeks before widening the scope.

Label an issue → a workflow triggers → the agent runs in a fresh container → a task is performed (commenting on a PR, triaging a ticket, checking in code) → the agent checks its own work → you review it like any other.

That second-to-last arrow is what makes the rest safe to leave alone. For code the check is nearly free — whatever your CI already runs, made runnable inside the sandbox and named in your CLAUDE.md or AGENTS.md. Everywhere else you define it yourself: a review graded against a rubric, with every finding citing a file and line; a specification checked against the use cases it was meant to cover; a triage, by whether its steps actually reproduce. An agent that can’t tell whether it succeeded will tell you it did.

The rest of the work is in the prompts. A clear workflow uses the skills and tools available, draws on the ticket contents, and avoids side effects along the way. Community skill sets are a good place to start, and you can write your own:

• Matt Pocock’s skills
• Compound engineering plugin
• Superpowers

Expand from there — more classes of work first, then more steps of the workflow.

What to add once the first step works

That first pass is deliberately thin. These are what turn it into a system:

Observability, metrics and cost management. Define and measure what’s important to you: per-task numbers on time, rework or spend, so you can tell which work is worth giving more of.

Tighter guardrails. Scope the task as well as the permissions: a precise brief leaves less room to invent work, and per-task credentials, paths and merge rights limit the blast radius when it does.

Using different LLMs and harnesses for different opinions. Different models have different blind spots, so one reviewing another’s work sees things self-review can’t.

More parallelism, inter-agent communication. Several tasks in flight at once, and agents that hand off to each other rather than escalating everything to you.

Common questions

Should we start with an AI coding assistant? +

Only if writing code is genuinely your constraint, which is less common than assumed. Measure your stage timings before committing — if work is sitting in review queues or waiting on environments, a code assistant increases the inflow to a stage that is already backed up.

How is this different from vibe coding with something like Lovable? +

Vibe coding tools are synchronous by design, and that’s the whole difference. Lovable, Bolt and the rest are excellent at getting from nothing to a working prototype, especially if you can’t write the code yourself — but you’re in the loop at every step, and the work stops the moment you stop watching. What’s described here is a system rather than a tool: specified once, run unattended, checked by the agent — which is what lets several run at once. Vibe coding is right for validating an idea; this is right once the thing exists and has to keep working.

How do we stop AI-generated code from degrading quality over time? +

Don’t outsource the thinking. Agents are fast at producing work and indifferent to whether it’s the right work, and you still own the outcome — “the agent wrote it” isn’t a defense anyone accepts. Architecture stays yours in particular: decide the shape of the system, then let agents build inside it rather than the reverse. Underneath that, layer the checks — unit tests for logic, integration tests for the seams, end-to-end for the paths that matter — so the quality bar is enforced mechanically rather than by whoever happens to pick up the review.

What about sending our source code to a third-party model? +

Treat it as the vendor-security question it is, not as a special AI question. Establish what the provider retains, whether your data trains their models, where it is processed, and what your customer contracts and compliance obligations already commit you to. Many providers offer zero-retention or self-hosted options that resolve most concerns. The failure mode is teams adopting tools informally before anyone has asked, so the useful move is deciding the policy early rather than discovering the exposure later.

How do we measure whether the automation is actually working? +

Measure the outcome, not the activity. Suggestion-acceptance rates, tokens consumed, and lines generated all move without delivery improving. The number that matters is time from decision to customer value, broken down by stage so you can see where time is spent. If total elapsed time hasn’t fallen, the work has moved rather than disappeared, and that’s worth knowing before you expand the rollout.

---

If the tools are in place but the roadmap hasn’t moved, working out which parts of your delivery can actually run unattended is the substance of an AI transformation engagement.