When a coding agent starts participating in development, it enters a process that already has identity, repositories, dependencies, execution environments, tests, branch policies, CI/CD, and rules for promoting changes.
Giving it repository access solves only part of that integration. The agent still needs to know what change is being requested, what constraints it must respect, where it can execute code, which tools are available, and what results must be produced before a change can move forward in the flow.
That need led me to look at Agentic SDLC as a platform problem. The model and coding agent remain important, but the architectural unit also comes to include the path between an intention to change something and a merge decision.
In this text, I will limit the scope to that interval. Release, production operations, rollback, and incident response deserve their own discussion.
The sequence I use as a reference is:
Intent → Contract → Agent → Sandbox → Verification → Evidence → Merge
Enlarge ↗It does not necessarily represent a linear pipeline. Some stages can repeat and others can happen in parallel. The goal is to identify which responsibilities need to exist and where they should reside.
The agent enters an SDLC that already exists#
Imagine a developer asking:
add support for a new type of transfer to the API.
A coding agent can locate files, change code, create tests, and execute commands. Depending on the tools available, it may go as far as creating a pull request.
But the initial request does not necessarily contain the rules that determine whether the implementation is correct:
Which API contract must remain compatible?
How does the application handle idempotency?
Which libraries may be used?
What behavior is expected when the external service is unavailable?
Are there specific requirements for logs or sensitive data?
In an exclusively human workflow, some of this knowledge is often scattered across documentation, code, team experience, and the review process. An agent can also retrieve some of that information, but the quality of retrieval directly influences the change it produces.
For a platform, this creates an interface problem. The task needs to reach the agent with sufficient execution context and criteria that can later be used to verify the result.
The contract needs to travel through the flow#
I have previously covered spec-driven development and the role of specifications, acceptance criteria, and constraints in code generation. Here, the focus is on what happens to that contract after the agent starts working.
It should not exist only as text used in the first prompt. If the task specifies that an operation must be idempotent, that requirement can guide generation, appear in tests, and be verified later. If a dependency is prohibited, the same criterion can be consumed by a scanner or quality gate.
This lets different components work from the same reference.
The builder uses the contract to build a proposal. The executor runs the commands defined for that project type. Verifiers produce results. An evaluator can compare properties that are not easily checked deterministically. The pipeline uses these results before allowing promotion.
Implementation can vary considerably between companies. The important point is to avoid each stage reconstructing the original intent from the previous stage's output, because a rule that began explicitly may disappear along the way.
Execution needs known boundaries#
A coding agent capable of modifying files and executing commands has a considerably larger action surface than an assistant that only suggests code.
The platform needs to decide where that execution takes place. For some workloads, a controlled local workspace may be enough; others may justify ephemeral sandboxes or isolated remote environments.
Regardless of implementation, I would try to make some limits explicit: accessible filesystem, available network, computational resources, execution duration, credentials, and tools.
Permanent credentials in the agent's environment unnecessarily increase the authority available during execution. When an operation genuinely requires access to another system, short-lived credentials or workload identity provide a better boundary than reusing the developer's long-lived secrets.
The same reasoning applies to tools: MCPs and other integrations can be offered through a corporate catalog with known permissions. A documentation tool may have read-only access. A service capable of changing infrastructure may require a different authorization policy, because the platform does not need to treat every task as if it carried the same risk.
Verification needs to happen outside the agent#
An agent can write code, create tests, and review its own diff. These capabilities are useful, but I would not put the entire quality decision inside the same loop that produced the change.
Some checks already have much better deterministic mechanisms. Compilation, tests, lint, static analysis, dependency scanning, and policy checks naturally belong to a trusted executor whose execution does not depend on whether the model decides to call them.
This creates a useful separation: the agent produces a change proposal, and the executor produces evidence about that proposal.
Enlarge ↗Some properties remain difficult to reduce to an exit code. Adherence to an architectural convention, for example, may require semantic evaluation. In these cases, a separate evaluator can be useful, provided its verdict is not treated as absolute truth.
The evaluation needs a clear scope and, when possible, calibration against known examples.
This separation also makes evolution easier. Changing the coding agent should not require rebuilding every quality gate. Changing an evaluator should not change how the application compiles or runs its tests.
Evidence needs to originate during execution#
When the flow starts involving an agent, tools, a sandbox, and different verifiers, keeping only the final diff removes much of the context needed to understand how that change was produced.
I would create an execution identifier that travels through the flow.
It would allow correlation of information such as the contract version, model used, instruction or harness version, tools invoked, commands executed, diff produced, executor results, and evaluator verdicts.
That does not mean indiscriminately recording every prompt, file, and output.
The level of evidence depends on the organization's risk and privacy rules. Often, metadata, hashes, versions, results, and artifact references already allow the relevant path to be reconstructed without turning observability into a permanent copy of the developer's entire context.
What interests me in this layer is the ability to answer operational questions afterward.
Which contract was in force when this code was produced? Which agent version executed the task? Did the mandatory tests pass? Was any gate skipped? Was the evaluator that approved the change the same one used today?
These answers depend on correlation between evidence; otherwise, each system preserves only part of the story.
Merge remains a decision of authority#
At the end of the flow, there is an important difference between producing a change and having authority to promote it.
The coding agent can prepare the diff and open the PR. The executor can confirm that checks passed. An evaluator can provide an additional verdict.
None of this requires the agent itself to have authority to decide the merge.
Enlarge ↗That decision can remain distributed among branch policies, CODEOWNERS, quality gates, and human approval, according to the change's criticality.
A small documentation change may follow an almost automatic path. A financial-rule modification may require review by specific people. An infrastructure change may follow another set of policies.
HITL makes more sense when review is tied to a concrete decision of authority. Adding human approval to every agent action creates a sequence of confirmations that tends to be ignored over time.
The platform needs to know which decision requires approval and why.
When these pieces become a platform#
It is possible to implement every component above within a single repository. The problem appears when dozens or hundreds of teams start rebuilding the same integrations.
One creates its own sandbox. Another writes different hooks. A third maintains a local list of MCPs. Each pipeline records evidence in its own format.
At that point, part of Agentic SDLC starts to approach Platform Engineering.
The platform can offer a reusable set of capabilities:
Enlarge ↗I would not expect every team to use all these capabilities.
A simple Python library probably needs much less infrastructure than an agent with access to internal services. The platform's advantage is offering known components so a team does not have to start from scratch when a particular capability becomes necessary.
I would also avoid turning the golden path into a mandatory route that works only for the most common case.
It needs to be the easiest route when applicable, while allowing extensions when the workload genuinely needs something different.
The platform needs to compete with the shortcut#
There is a practical consequence that is sometimes left out of architectural design.
If setting up the corporate environment requires opening tickets, copying files manually, waiting for credentials, and figuring out which tools are permitted alone, developers will find a shorter path.
This behavior is already familiar in internal platforms and did not originate with AI.
Scaffolding, documentation, configuration distribution, onboarding, and support are as much part of the capability as technical controls.
A perfect hook that never reaches the developer's machine correctly does not protect the flow. A corporate MCP that is hard to discover competes with easier local integrations. A technically correct policy that is incompatible with everyday workflow creates pressure for exceptions.
That is why I would treat Developer Experience as part of platform design, not just a later satisfaction metric.
How I would start#
I would not try to build this entire platform before getting the first team to work.
I would choose an application class and a sufficiently representative set of tasks to discover which interfaces really need to be shared.
For example, a backend service with established CI provides a good environment for testing scaffolding, context, sandbox, test execution, evidence, and promotion without introducing every possible problem at once.
The pilot should also have a baseline:
How long do these tasks take today?
Where does the developer wait?
Which errors reach review?
How many return after the gates?
Which parts of the flow require manual intervention?
The intent would not be to prove in advance that Agentic SDLC increases productivity. The pilot would serve to observe where the agent changes the flow and which components are worth turning into platform capabilities.
I would begin by investing in points that reduce repetitive work across teams: context structure, known execution environments, a tool catalog, reusable verification, evidence contracts, and integration with the promotion process.
Other layers would probably emerge as workloads gain more authority or require more isolation.
From agent to merge#
When I look at this design, the coding agent occupies an important but relatively small part of the flow.
Before it come intent and contract. Around it are context, identity, tools, and execution boundaries. After it come verifications, evidence, and promotion decisions.
Within this scope, Agentic SDLC as a platform is the set of these responsibilities and the interfaces that let them work consistently across projects.
To evolve this design, I would prioritize clear interfaces between components, defined ownership, and a golden path that teams can adopt without rebuilding the architecture for each project.