How Sabright Uses AI Coding Agents to Build Software Faster

Software clients want two things that used to pull in opposite directions: faster delivery and code they can trust. At Sabright, AI coding agents are how we deliver both. They take on the repetitive, time-consuming parts of development, while our engineers plan the work, review every change and decide what ships.

This article explains exactly how that works: the tools we use, the step-by-step workflow from a Jira ticket to merged code, a real example, and the guardrails that keep humans in control.

AI coding assistants vs AI coding agents

Most developers have already used an AI coding assistant. It suggests the next line, completes a function or answers a question in a chat window. It is helpful, but the developer still does every step: finding the right files, making the changes, running tests and fixing what breaks.

An AI coding agent works differently. You give it a goal, such as “fix the bug described in this ticket”, and it carries out the steps itself:

  • reads the relevant files across the whole project,
  • plans the change,
  • edits multiple files,
  • runs commands, tests and linters,
  • fixes its own mistakes when tests fail,
  • reports back with a summary and a diff to review.

In short: an assistant helps you type, an agent helps you get tasks done.

What is Agentic Development?

Agentic development is a way of building software where AI agents do much of the hands-on implementation, and engineers direct, review and approve the work.

The developer’s role shifts from writing every line to:

  • writing clear tasks with acceptance criteria,
  • giving the agent the right context and permissions,
  • reviewing plans before any code is written,
  • reviewing diffs and test results,
  • deciding what gets merged and released.

The speed comes from the agent. The quality, architecture and accountability stay with the engineer.

The Sabright Agentic Development Workflow

Our workflow connects six tools. Each one has a clear job.

Jira

Jira is where the work lives: user stories, bugs, acceptance criteria, priorities and status. Every change an agent makes starts from a Jira ticket, so there is always a clear record of why the code changed.

VS Code

VS Code is the developer’s cockpit. The code, the terminal, the diffs and the AI agents all sit side by side, so the engineer can watch what an agent is doing and stop or redirect it at any moment.

Claude

Claude, used through Claude Code in the terminal or its VS Code extension, is our main agent for planning and multi-file implementation. It is strong at understanding large codebases, following project conventions and explaining its reasoning before it acts.

OpenAI Codex

OpenAI Codex, through its CLI or VS Code extension, is our second agent. We use it as an independent reviewer of changes made by Claude, or as a parallel implementer when we want to compare two approaches. Different models make different mistakes, so a second opinion catches a lot.

GitHub

GitHub holds the code and enforces quality: branches, pull requests, GitHub Actions for automated tests and builds, and branch protection so nothing reaches the main branch without passing checks and a human approval.

MCP

The Model Context Protocol (MCP) is the glue between all of the above. It is an open standard that lets AI agents connect to outside tools. Atlassian and GitHub both publish official MCP servers, so our agents can read a Jira ticket or open a pull request directly, without anyone copying and pasting. (We explain MCP in detail in MCP Explained: How AI Agents Connect to Your Business Tools.)

Step 1: Prepare the repository

Agents are only as good as the context they get. Before any agent touches a project, we add a short instructions file at the root of the repository:

  • CLAUDE.md for Claude Code,
  • AGENTS.md for Codex and other agents.

It covers how to install and run the project, how to run tests and linting, the folder structure, naming conventions and hard rules such as “never commit secrets” and “every change needs a test”.

We also make sure the project has a reliable test command. An agent that can run tests can check its own work; an agent that cannot is guessing.

Step 2: Connect Jira and GitHub

Next, we add the Atlassian and GitHub MCP servers to the agent’s configuration and sign in with OAuth or a scoped token. Two rules always apply:

  1. Least privilege: the agent gets access to this project only, not the whole organisation.
  2. Read before write: we start with read-only access to Jira, and allow comments and status changes once the setup is proven.

From then on, a developer can simply say: “Read ticket WEB-142 and propose a plan”, and the agent fetches the description, acceptance criteria and comments by itself.

Step 3: Turn a Jira ticket into a plan

For anything beyond a trivial change, the agent writes a plan before writing code:

  • which files it will change and why,
  • edge cases and risks,
  • how the change will be tested.

The engineer reviews the plan like a senior developer reviewing a junior’s approach, and corrects it while changes are still cheap. Claude Code’s plan mode is built for exactly this: the agent explores and proposes, but changes nothing until the plan is approved.

Step 4: Let the agent implement

Once the plan is approved, the agent:

  1. creates a branch named after the ticket, for example fix/WEB-142-checkout-field,
  2. makes the changes across all the files involved,
  3. runs tests and linters, and fixes what fails,
  4. commits with a message that references the ticket.

The engineer watches the diff in VS Code and can pause or redirect the agent at any point. Large tickets are split into smaller steps, with a review after each one.

Step 5: Use a second agent for review

Before a human reviews the change, a second agent does. If Claude implemented it, Codex reviews the branch for bugs, missed edge cases, security issues and inconsistencies with the rest of the codebase.

The reviewing agent only reports findings. The engineer decides which ones are real and which to fix. This step regularly catches issues that are easy for anyone, human or AI, to miss on a first pass.

Step 6: Pull request + GitHub Actions

The agent pushes the branch and opens a pull request that links the Jira ticket and explains what changed and how it was tested. Then GitHub takes over:

  • GitHub Actions run the full test suite, linting and build on every push.
  • Branch protection requires all checks to pass and at least one human approval.
  • Reviewers can ask the agent for small fixes in PR comments, and it updates the same branch.

Code reaches production because tests passed and an engineer approved it, never simply because an AI produced it.

Step 7: Close the Jira loop

After the merge, the agent posts a summary and the pull request link on the Jira ticket and moves it to the correct status. The project board stays accurate without anyone updating it by hand, and clients can see exactly what was done.

Real Example: Fixing a WooCommerce Checkout Bug

Here is how a typical bug fix runs through this workflow:

  1. The report: a client’s WooCommerce store stops saving a custom “GST number” field at checkout. A ticket is created in Jira with steps to reproduce.
  2. Investigation: the agent reads the ticket, searches the theme and plugins, and finds the hook that saves the field. It discovers that a recent plugin update renamed a checkout hook.
  3. Plan: it proposes moving the save logic to the new hook, adding validation for the GST format, and writing a test that submits an order with the field. The engineer approves.
  4. Implementation: the agent makes the change on a branch, runs the tests and confirms the field saves correctly.
  5. Second review: Codex reviews the diff and points out that the field is not sanitised before saving. The fix is added.
  6. Pull request: CI passes, the engineer tests checkout on staging, approves and merges.
  7. Close the loop: Jira is updated with a summary, and the fix is deployed.

Work that used to take half a day of context switching was done in about an hour, and the engineer spent that hour on judgement, not on typing.

Why Human Developers Still Matter

AI agents are fast, but they do not understand your business, your customers or the trade-offs behind your product. Human developers remain essential because they:

  • understand the business problem behind each ticket,
  • make architecture decisions that shape the system for years,
  • spot what is missing, not only what is wrong,
  • judge risk, such as what is safe to release on a Friday,
  • own the outcome: every merged line has an engineer who understands it and answers for it.

At Sabright, AI multiplies what an experienced developer can do. It does not replace the developer.

Guardrails for AI Development

We run agents inside clear limits:

  • Permissions: safe commands such as tests and linting can run automatically; anything that deletes data, deploys or touches production needs explicit human approval.
  • Secrets stay secret: .env files, API keys and client credentials are kept out of the agent’s reach and out of the repository.
  • Isolated environments: agents work on branches and staging, never directly on live systems.
  • Small pull requests: easier to review, easier to roll back.
  • Tests first: the better the test coverage, the more work can be safely delegated.
  • Full audit trail: every change is linked to a Jira ticket, a pull request and a human approval.

Where Agentic Development Works Best

Agentic development delivers the biggest gains on:

  • well-defined features with clear acceptance criteria,
  • bug fixes with known reproduction steps,
  • refactoring and code clean-up,
  • writing and extending automated tests,
  • API integrations and repetitive CRUD work,
  • framework and dependency upgrades,
  • documentation and code explanations.

Where AI Agents Should Not Make Decisions

Some decisions always stay with people:

  • architecture and technology choices for a product,
  • security-critical design, such as authentication and payment flows,
  • anything involving production data, deployments or deletions,
  • unclear or conflicting requirements, which need a conversation with the client,
  • business and product trade-offs, such as what to build first,
  • final approval of every change that goes live.

Agents can research, propose and draft in all of these areas. They do not make the call.

How Sabright Uses AI in Software Development

We use this workflow across all our services:

  • WordPress development and maintenance: faster theme and plugin work, safer updates tested on staging, and quick bug fixes.
  • Custom software development: SaaS products, marketplaces and business software delivered in shorter cycles with clean architecture.
  • Automation and integration: n8n workflows, MCP servers and AI agents connected to your existing systems.
  • Maintenance and support: faster response to issues, with every change documented and reviewed.

For clients, this means shorter timelines, lower cost for the same scope, and full transparency about what changed and why.

Conclusion

AI coding agents have changed how software is built. Used well, with clear tasks, good context, a second reviewer and strict guardrails, they let a small team deliver like a much larger one, without lowering quality.

The key is balance: agents do the heavy lifting, engineers stay in control.

Want to build your next project faster without losing control? Talk to Sabright about your WordPress site, custom software or automation project. We will show you how our AI-accelerated workflow can shorten your timeline, and we will keep an experienced engineer responsible for every release.

← Back to Blog