Menu

The Merapar Agentic SDLC

Agents in the lifecycle, not beside the developer

Most organisations have bought their developers an assistant. That makes a developer faster at typing. It does not change how long a change takes to reach production, what it costs to build, or how good it is when it lands.

How a transition works

An assistant speeds up a person. An agentic lifecycle changes the system

The distinction matters more than it sounds. An assistant is a tool a developer reaches for inside one step of the process — writing the code. Everything either side of that step is untouched: the refinement, the branch, the build, the test run, the staging deploy, the failing pipeline nobody has looked at yet, the incident at two in the morning. That is where the time actually goes.

Put agents in the lifecycle instead and the shape changes. Work is picked up as soon as it is prioritised. Several changes progress at once, each on its own branch and its own environment. A change is built, tested and deployed before a person sees it, so review starts from something that already runs. Production is watched continuously, and what is found there comes back as a ticket rather than as a phone call. Agents work while nobody is at a desk.

What does not change is who decides. People define and prioritise the work, people approve and merge every pull request, and a person triggers every production release. Agents execute; people decide.

How it fits together

Three phases, one flow. The blue boxes are the points where a person is required, and there is no path to production that avoids them.

The Merapar agentic software development lifecycleA flow in three phases. Plan: a product owner defines and prioritises the work, a product definition agent turns it into stories and bugs on the ticket board. Develop: a development agent picks up a ticket, refines it and implements it, with several dev agents working on their own feature branches; a developer spars with the agent and keeps control. Work is pushed to version control, which triggers a CI/CD pipeline that deploys to a staging environment, looping through test, fix and redeploy until it is stable. A pull request is then opened and a person reviews, approves and merges it to main. Operate: a release manager triggers the production deploy, and a monitoring agent observes production logs and metrics continuously, raising what it finds back onto the ticket board.PlanDevelopOperatePersonAgentMonitoring agentInfrastructureProduct ownerdefines and prioritises the workProduct definition agentturns intent into stories and bugsTicket boardstories and bugspicks up a ticketDevelopment agenttechnical refinement, design and approachImplement — writes the code autonomouslyDev agent 1branch ADev agent 2branch BDev agent 3branch Cpushes to a feature branchVersion controlthe feature branch, not maintriggersCI/CD pipelinebuilds and tests every changedeploysStaging environmentone per feature branch, disposablestable, so it opens a pull requestPull request reviewa person approves and merges to mainRelease managera person triggers the production deployCI/CD to productionProductionlogs, metrics and monitoringDeveloperguides and reviews,and keeps controlsparringreviews, approvesFeedback looptest, fix, redeployuntil it is stableMonitoring agentwatches productioncontinuouslyraises what it finds
The Merapar agentic software development lifecycle. Agents plan, implement on parallel branches and observe production; people prioritise, review, approve and release.

What happens in each phase

  • Plan

    A product owner defines and prioritises the work. A product definition agent turns that intent into stories and bugs on the board, so refinement is waiting rather than scheduled.

  • Develop

    A development agent picks up a ticket, works out the approach and implements it, with several agents on their own feature branches. Each change builds through CI/CD into its own disposable staging environment and loops — test, fix, redeploy — until it is stable. Only then is a pull request opened, and a person reviews, approves and merges it.

  • Operate

    A person triggers the production deploy. A monitoring agent then watches logs and metrics continuously, investigates what it sees and raises deduplicated tickets back onto the board, which is where the loop closes.

Where the win actually comes from

Three of these are the reasons a board cares, and the fourth is the reason a CTO sleeps. None of them come from typing faster.

  • Time to market

    Work starts when it is prioritised, not when someone is free, and several changes move in parallel rather than queueing behind one developer. The waiting between steps is where a lifecycle loses its weeks, and most of that waiting stops being necessary.

  • Development cost

    The repetitive half of building software — scaffolding, test coverage, chasing a red build, tracing an incident back to its cause — stops consuming senior engineering time. Your expensive people spend their day on the decisions that need judgement.

  • Quality

    Nothing reaches a reviewer until it has been built, tested and run in its own environment, so review starts from something that works and can be about design rather than mechanics. Every change is tested, validated and monitored on the way through, automatically and every time.

  • Control, not autopilot

    A person approves every merge to main and triggers every release. The lifecycle is auditable at each gate, which is what makes this defensible in a regulated setting rather than merely fast.

We run this on client work, not on a lab project

Hartley is a household management app that Merapar built end to end, from proof of concept to a live app on the App Store and Google Play in under eight months. Claude Code is embedded directly in the day-to-day engineering of it, and the surrounding lifecycle is the one drawn above:

  • Every feature branch gets a complete, disposable environment, deployed by the pipeline, so a change is exercised for real before anyone reviews it.
  • An automated evaluation harness replays test scenarios against every change, which is how agent quality stays a build gate rather than a hope.
  • An autonomous triage agent works production, classifying live incidents, investigating root causes and raising deduplicated tickets without a human in the loop.
  • People still hold the gates: product direction, security review, quality control and the release itself.

Read the Hartley case

The Hartley app, built and operated through the agentic lifecycle

Moving your lifecycle onto this

We bring the expertise, we build it with your engineers rather than around them, and you own what comes out — including the parts our agents wrote. It is stage three of becoming AI-native, and it is the stage that sticks.

Related work and writing

Bring us the part of your lifecycle that hurts

Usually it is the wait between a change being written and it being live, or a backlog that grows faster than the team can clear it. Tell us which one it is and we will be straight with you about what an agentic lifecycle would and would not fix.

Contact us