A solo engineer's SDLC for an army of AI agents

A solo engineer with several coding agents has a coordination problem: many contributors can produce changes, while one person remains responsible for deciding what ships.

That is the point at which I want an explicit software development lifecycle, or SDLC. It defines how a change moves from an idea into a maintained product, what evidence allows it to move, and who can authorize each transition. The design has to include the period after deployment, when dependencies age, vulnerabilities emerge and users still depend on the software.

CTO to Human: making delivery explainable

A useful lifecycle lets me explain why a release deserves confidence. I can connect the original request to the design, the checks, the reviewed source and the deployed artifact. If something fails, I have a record to investigate and a recovery decision to make.

For a solo engineer, the benefit is continuity. A process recorded in the repo gives tomorrow's session the same expectations as today's. Agents can prepare work against that process, and the human can spend review time on the decisions that require judgment.

There is a real limit: one engineer remains one engineer. Several agents can offer additional analysis, but their agreement does not create an independent human reviewer. The lifecycle should make that limitation visible and require outside review when the risk warrants it.

Engineer to Engineer: design the transitions first

I would start by defining a small set of states and the evidence needed to move between them:

Proposed → Designed → Implemented → Verified → Released → Operating
               ↑                         |                 |
               └──── revised assumptions┘                 └→ Retired

This is an illustrative lifecycle, rather than a workflow engine you need to install. A repository issue, pull request, CI run and release record can hold the state and evidence. The important part is that the transitions have conditions.

My SDLC policy is a concrete example. It records planning, design, branching, review, a definition of done, release controls, dependency maintenance and retirement. You can borrow the structure while choosing requirements that fit your product and its risks.

Define the change before assigning the agent

An agent needs more than a feature title. The work item should state the observed behavior, desired behavior, acceptance criteria, constraints and exclusions. Identify changes to authentication, data storage, external interfaces, permissions or deployment before implementation starts.

For an illustrative export endpoint, the acceptance criteria might include:

• An authorized user can export only the records they are allowed to read.
• An unauthorized request returns no exported data and creates no downloadable file.
• Exported fields follow a documented allowlist.
• The operation has a size limit, and temporary files follow a retention rule.

Those criteria give testing something specific to establish. They also expose questions an implementation could otherwise answer accidentally: who decides the field allowlist, how access is checked, and whether the export contains sensitive data.

Record expensive design decisions in an architecture decision record (ADR). Capture assets, external interfaces and trust boundaries in a threat model. A small system can use a short document, provided it names the actual boundaries and risks. My ADR template and threat-model template show the information I expect to preserve.

Make the policy consumable by a project

A shared standards repo owns the common expectations. A product repo owns its build commands, architecture, local decisions and evidence of adoption. Keep that boundary explicit:

shared-standards/
  policies/sdlc.md
  policies/security-program.md
  policies/ai-assisted-development.md
  standards/ci-cd.md
  templates/
  exceptions/

product/
  AGENTS.md
  CONTRIBUTING.md
  SECURITY.md
  docs/adr/
  docs/security/threat-model.md
  docs/releases/

This is an example organization, not a required directory layout. The project instructions should identify the adopted standards revision, applicable rules, exact build and test commands, and where intentional departures are recorded. Verify that the actual agent harness loads the entry point. A file being present does not establish that a session consumed it.

Give requirements stable identifiers so a failed check or review comment can point to a specific expectation. An illustrative control record might look like this:

This YAML documents a control; it does not configure a hosting provider or enforce a release. Each enforcement entry needs an actual implementation and an exercised check.

Separate contribution, verification and release authority

Give an implementation agent a task branch and an isolated checkout or worktree. Define which files it owns when several agents work concurrently. Shared staging areas, generated files and branch changes can otherwise mix unrelated work.

The agent can write code and prepare a pull request. Ordinary implementation credentials should not also administer repository rules or publish production artifacts. Put release authority in a separate, narrowly scoped workflow or operator action. If a maintainer authorizes a particular release, make the authorization identify the artifact and target.

On the repository, protect the default branch, require named status checks, prohibit force pushes and limit bypass permissions. Treat a change to the rules or pipeline as a change to the security boundary. An agent that can rewrite a required check and approve the rewrite can change what “verified” means.

My repository standard includes a one-maintainer arrangement with documented compensating controls. That is an explicit limitation to assess, rather than evidence that automated review is equivalent to an independent maintainer.

Choose checks that challenge the implementation

Use a build and tests as the foundation. Add relevant static analysis, dependency and secret scanning, and checks for the pipeline itself. Record the command, failure threshold, expected output and owner for each required gate.

Agent-written tests need deliberate scrutiny. A test that reproduces the same mistaken assumption as the implementation can pass consistently. In the export example, test the denied request, access to another user's records, unexpected fields and oversized input. Check the resulting response and side effects, rather than just whether the function returned.

An AI review can ask different questions and identify missing cases. Treat its findings as input to a human decision. Tests, analyzers and review have different scopes; none alone demonstrates every property of the deployed service.

NIST's Secure Software Development Framework is useful here because it organizes practices around preparation, protection of the software, secure production and vulnerability response. NIST describes adaptation according to risk and resources. I use that as a planning reference, then identify the concrete controls and evidence a project needs.

My CI standard provides worked requirements for workflow permissions, pinned dependencies and checks. Copying the document is insufficient: verify the live repository's required checks and confirm that a failed check prevents the relevant transition.

Bind a release to what was reviewed

Record a release tuple such as:

reviewed source commit
build definition revision + build run identity
artifact digest + version
release target + authorization
deployment result + recovery reference

Build the artifact from reviewed source and verify its identity before promotion. If you rebuild it, record and verify the new artifact; an earlier approval should not silently become approval of different bytes. Keep release credentials out of jobs executing untrusted contribution code.

An SBOM, or software bill of materials, identifies components in an artifact. A provenance record describes how it was built. A signature supplies identity and integrity evidence. Each answers a different question, and each still needs a trusted verification path. None establishes that the software is free of defects.

For deployments, include schema changes, backups where relevant, readiness checks and post-deployment behavior. “Rollback” needs a specific meaning: restoring an image may be possible while reversing a data migration is unsafe. My release checklist is an example of keeping the release decision and its evidence together.

Keep operating responsibilities in the lifecycle

Choose a dependency-review cadence, a vulnerability-reporting route, remediation targets and a support policy. Decide how findings are triaged, which events trigger urgent action, and how users learn about fixes. Reassess these decisions when the product's exposure changes.

An exception should identify the requirement, reason, affected scope, compensating controls, owner and expiry or review date. A finding with no upstream fix still requires a decision. Record what remains exposed and what event would cause you to stop shipping or operating the affected component.

Before retirement, plan user migration, support communication, credential revocation and data disposition. The last release is still something people may run; retain the information they need to understand its support status.

Exercise the process with one real change

Start with a small change and trace it through every transition. Have an agent prepare the implementation and evidence. Read the diff and review findings yourself. Confirm a failing check blocks merge, and confirm the release action cannot substitute another artifact unnoticed.

Use that exercise to identify missing commands, excessive permissions and evidence that nobody actually reads. Expand the process when the risk or workload requires it. Limit concurrent work to what you can review and integrate; an agent's capacity to open another branch does not expand your capacity to make a sound release decision.

A practical SDLC gives an army of agents a common path through the work. It gives the engineer responsible for them a way to explain what was decided, what was verified and what is running. The broader standards argument is that those decisions belong in the architecture of the system itself.