Agentic SDLC

Traditional SDLC vs. agentic SDLC

Core components of the agentic SDLC

• Coding agents: write code and tests, then open pull requests.
• Maintained test suite: tests people own, which agents read and run.
• Test execution service: runs tests next to the systems under test, the same way for every caller.
• Access control: sets who or what may run which tests, where, under which role.
• Execution record: one history of who ran what, where, with logs and artifacts.

How a change moves through a well-run agentic SDLC

1. Agent writes the change: code plus tests for the area it touched.
2. Agent checks existing tests: it finds the tests that already cover that area.
3. Shared service runs the tests: inside your clusters, against real dependencies.
4. Result returns as data: the agent can act on it but cannot alter it.
5. Pipeline runs the same set: at the pull request gate, with the same runtime.
6. Run is recorded: trigger, environment, logs, and artifacts land in one history.
7. Nightly backstop runs: the full suite catches anything the scoped set missed.

Why the agentic SDLC matters to engineering leaders

Agents raise output faster than teams can verify it. The numbers show where the pressure lands.

• More code: GitHub's Octoverse 2025 counted commits up 25.1% and merged pull requests up 29%.
• More pipeline runs: CircleCI's 2026 data showed daily workflow runs up 59%.
• Less stability: CircleCI put main-branch success at 70.8%, its lowest in over five years.
• A new bottleneck: In GitLab's 2026 survey, 85% said AI moved the bottleneck to reviewing and validating code.

DORA's 2025 research found AI adoption improves throughput but still increases delivery instability. Its explanation is about process, not code quality. Bigger batches stretch the practices that keep delivery stable, including robust testing.

Why a passing test proves less in the agentic SDLC

A pass tells you two things. The code did what the test asked. The test asked the right question. Agent-written tests often get the first right and miss the second.

• Wrong expected answers: A January 2026 University of Auckland and King's College London study found model-written test oracles correct only 40.74% to 53.64% of the time.
• Tests that lock in bugs: An ISSTA 2026 study found models often wrote tests that pass on a bug and fail on the fix.
• Gaming the test: METR reported that OpenAI's o3 took test shortcuts in 30.4% of runs on one benchmark.
• Instructions don't fix it: Anthropic's Claude Opus 4.5 system card reports hard-coded tests 35% of the time, even when told not to.

These figures come from benchmark conditions, not production. The mechanism still applies. A test that encodes a guess passes whenever the code agrees with the guess.

Common challenges

• Self-grading: the agent writes, runs, and reports on its own tests.
• Mocked dependencies: sandbox runs often skip services that matter in production.
• Lost results: sandbox results stay in the agent's session and disappear.
• Disconnected CI: the pipeline runs its configured suite and doesn't know what the agent already tested.
• Drifting test selection: an agent picks a different subset each run, so runs don't compare.
• Credential sprawl: agents get direct cluster access just to run tests.

Three common setups

Teams handle agent-written tests in one of three ways. These aren't maturity stages, and company size doesn't predict which one you're in.

• No shared record: agents, pipelines, and engineers each test somewhere different. Results live in chat transcripts, expiring CI logs, or nowhere.
• Homegrown tooling: someone builds wrappers, a results store, and a dashboard. It works until its one maintainer leaves.
• One shared service: every team runs tests through one service in its own infrastructure. It costs compute per change, and a platform team owns it.

Example: 300 to 500 untracked tests a week

This illustrative team is fictional but representative. A product team of 25 engineers runs about 30 services on Kubernetes. Three coding agents are in daily use.

Each engineer opens about four pull requests a week. Each one carries three to five agent-written tests. That adds up to 300 to 500 new tests a week.

Then the VP asked what the agents tested last week. Nobody could answer. The team kept the agents at full speed and changed where tests ran:

1. A CI rule first: every agent-written test had to run in CI, with results on the pull request.
2. One place for every run: agent, pipeline, and human runs moved into one service in their clusters.
3. Agents read before they write: agents run existing tests for an area before adding new ones.
4. Sampling over skimming: the head of QA reads a handful of agent-written tests closely each week.

Now the VP's question has an answer: what ran, who or what triggered it, where, and with what result.

Five decisions every leader has to make

Most teams make these by default. Making them on purpose matters more than any tool choice.

• Who checks the agent's work: the agent itself, or a service it does not control.
• Where tests run and what agents can access: the agent sandbox, or your clusters behind role-based access.
• What counts as the record: chat transcripts and rotating logs, or one execution history.
• What runs for each change: whatever the agent picks, or sets people define and the run records.
• What an auditor can see: which agent ran which test, under what permission, with what result.

Best practices

• Separate author from reviewer: run tests outside the agent's control.
• Keep a human-owned suite: agents read and run it before writing new tests.
• Let people define test sets: map tests to service areas and let agents choose among them.
• Record every run: keep trigger, environment, logs, and artifacts in one history.
• Gate access by role: agents call a service that holds the credentials.
• Keep a nightly backstop: run the full suite nightly and review scoped sets quarterly.

The Testkube view: separation beats suspicion

Models will keep getting better at writing tests. That won't fix the core issue. A program checking its own work, with a tool it can edit, is weak evidence.

Engineering already separates authors from reviewers for code. The agentic SDLC needs the same separation for tests. That's a structural choice, not a judgment about agents.

Testkube is that independent service. Agents trigger runs, but the results and records live outside their control.

How Testkube fits into the agentic SDLC

Coding agents generate code and tests. They have nowhere reliable to run them. Agent sandboxes and CI/CD pipelines weren't built as test runtimes.

Testkube is the test execution layer agents call:

• Any test, at scale: runs any framework inside your own Kubernetes clusters.
• Context for agents: past executions show agents what "normal" looks like.
• Troubleshooting help: agents get logs and artifacts to diagnose and fix failures.
• One standard for every caller: agent-written tests get the same visibility and governance as CI tests.

Testkube doesn't orchestrate coding agents. It sits inside your existing agent loop, the same way it sits beside CI.

Frequently Asked Questions (FAQs)

‍