Agentic engineering: how to ship SaaS faster with coding agents

Agentic engineering is how we describe senior engineers building software with coding agents such as Claude Code and Codex. The agent reads the codebase, writes code, runs tests and iterates in a loop. The engineer decides what gets built, how it fits the architecture and whether the result is good enough to merge.

This post is for CTOs, founders and engineering leads who want to know how that works on a real SaaS product, where the code has to be maintained for years. Autocomplete suggests the next line. A coding agent can take a well-scoped task, change a dozen files, run the test suite and come back with a pull request. Engineering time moves away from typing and towards specifying, reviewing and deciding.

It also changes what can go wrong. Agents produce plausible code quickly, including plausible code that is subtly wrong. The practices below are how we get the speed while keeping quality where it needs to be.

Agents do their best work on tasks with a clear goal, clear boundaries and a way to check the result. They struggle with vague requests that need product judgement or that span the whole system.

• Right-sized: one feature slice, one migration or one integration endpoint. Something a senior engineer can review in 15 to 30 minutes.
• Bounded: name the files, modules or layers in scope, and what must not change.
• Verifiable: say how success is checked, such as passing tests, a clean type check or a screenshot of the new screen.
• Contextual: keep an AGENTS.md or CLAUDE.md file in the repository with conventions, commands, architecture notes and things to avoid, so every session starts from the same ground rules.

Large pieces of work get broken down by an engineer first. That breakdown is design work, and it stays with people.

The most reliable pattern we use is to write the specification and tests before the agent writes the implementation. Tests turn an ambiguous request into an executable definition of done, and they give the agent a loop it can run by itself: implement, run tests, fix, repeat.

For example, for seat-based billing in a SaaS product, the engineer writes the edge cases as tests:

import { describe, expect, it } from "vitest";
import { prorateSeatChange } from "./billing";

describe("prorateSeatChange", () => {
  const period = { start: new Date("2026-09-01"), end: new Date("2026-10-01") };
  const base = { period, seatPriceCents: 3000 };

  it("charges for the remaining days when seats are added mid-period", () => {
    const result = prorateSeatChange({ ...base, from: 5, to: 7, at: new Date("2026-09-16") });
    expect(result.amountCents).toBe(3000);
  });

  it("issues no refund when seats are removed", () => {
    const result = prorateSeatChange({ ...base, from: 7, to: 5, at: new Date("2026-09-16") });
    expect(result.amountCents).toBe(0);
  });

  it("rejects a change outside the billing period", () => {
    expect(() => prorateSeatChange({ ...base, from: 5, to: 6, at: new Date("2026-10-02") })).toThrow(RangeError);
  });
});

The agent then implements prorateSeatChange until the tests pass. The engineer reviews the tests carefully, because an agent asked to make tests pass will sometimes change the tests. Our rule is simple: agents may add tests, but any change to an existing test needs an explicit reason in the pull request.

Faster writing only helps if review keeps up. Agent output gets the same review as a colleague's code, and in some areas more. What we look for:

• Unrequested changes: reformatted files, renamed variables, new dependencies or refactors outside the task.
• Duplication: a new helper written when an existing one should have been reused.
• Silent error handling: broad try/catch blocks, swallowed errors and fallbacks that hide failures.
• Test quality: tests that assert the implementation instead of the behaviour, or that mock away the thing under test.
• Performance: N+1 queries, missing indexes and API calls inside loops.

Small pull requests keep this manageable. We would rather merge five small, properly reviewed changes a day than one large change nobody has fully read.

The pattern is consistent. Agents are strong where the work is well defined and checkable, and engineers own every decision that is expensive to reverse.

A coding agent runs commands on a machine with access to your code. It deserves the same care as any other automation with write access.

• Run agents in isolated environments, such as containers or separate worktrees, with no production credentials.
• Keep secrets out of the repository and out of agent context, and use scoped, short-lived tokens for anything the agent must call.
• Restrict which commands can run without approval, especially anything that deploys, deletes or touches infrastructure.
• Treat content the agent reads, such as issues, web pages and dependency READMEs, as untrusted input that may contain prompt injection.
• Keep dependency scanning, secret scanning and static analysis in CI, and require human approval for merges to the main branch.

1. 01Add an AGENTS.md with your conventions, commands and architecture notes.
2. 02Make sure tests, type checks and linting run quickly with a single command.
3. 03Pick one class of well-defined tasks, such as admin screens or integration endpoints, and use agents there first.
4. 04Adopt tests-first for new features, with a clear rule on changes to existing tests.
5. 05Keep pull requests small and review agent output line by line.
6. 06Set up sandboxing and command permissions before widening use.

This is how our engineers build client software day to day. Our SaaS scale-up case shows the effect on delivery time, and how we work describes how we run projects with coding agents.