AI across the SDLC

These are the places I would look when introducing AI to an engineering team. They combine the workflows I used at Teladoc Health in 2025-2026 with what I am building for my private, pre-launch product. I have not run every stage below as a team-wide system.

The shift I am interested in is from improving individual prompts to engineering the context and the harness around the model: the tools, permissions, checks and feedback it works with. That makes the workflow repeatable and gives the agent a way to find and correct mistakes before a person reviews the result.

Where I would use it

AI through the delivery process

AI through the delivery process

01DiscoveryFind what is missing from the request.02PlanningTurn the agreed request into manageable work.03ArchitectureUnderstand the system before changing it.04DevelopmentImplement a bounded task.05TestingCheck the intended behaviour.06ReviewLook for mistakes before I read the change.07Continuous integrationInvestigate failed builds.08SecurityAdd code reasoning to automated scanning.09DocumentationUpdate the explanation with the change.10OperationsHelp investigate incidents.11MaintenanceKeep cleanup small enough to review.

01 / 11

Discovery

I ask the model to examine assumptions and edge cases before we commit to a solution.

• Identify unanswered questions.
• Draft acceptance criteria for review.

Hands overA clearer request and a list of unknowns.

02 / 11

Planning

I set the scope and constraints, then use the model to help break the work into tasks.

• Write the constraints and acceptance criteria.
• Split the work into reviewable tasks.

Hands overA specification and task plan.

03 / 11

Architecture

I use an agent to help trace dependencies and compare options. I check them against the code and choose the design.

• Inspect affected components and callers.
• Draft design options, migration steps and risks.

Hands overA design proposal with the affected systems named.

04 / 11

Development

The agent investigates the repository, changes the code and checks its own work.

• Implement or refactor within the agreed scope.
• Run project checks and fix failures.

Hands overA change ready for review.

05 / 11

Testing

I want tests based on the requirements, including failure cases, rather than tests that repeat the implementation.

• Add relevant unit, integration or end-to-end tests.
• Investigate failures and missing coverage.

Hands overTest results and any remaining gaps.

06 / 11Human review

Review

I can split review by concern when that adds useful findings. I still decide which findings are valid.

• Review correctness, security and architecture where relevant.
• Keep human approval for production changes.

Hands overFindings and a reviewable change.

07 / 11

Continuous integration

A failed check gives an agent a concrete starting point and often a way to reproduce the problem.

• Read the failure and reproduce it.
• Propose a fix within limited write access.

Hands overA diagnosis and, where possible, a tested fix.

08 / 11Human review

Security

I keep dependency, secret and static checks. Model review is an additional source of findings.

• Run the existing scanners.
• Review the affected trust boundaries and validate findings.

Hands overFindings with evidence for triage.

09 / 11

Documentation

The diff gives an agent a starting point for documentation, but I still need to check whether the explanation is accurate.

• Draft documentation and release-note updates.
• Send the changes through the agreed review process.

Hands overDocumentation that matches the implementation.

10 / 11Human decision

Operations

I would start with read-only analysis of logs and traces. A plausible explanation is still a hypothesis.

• Build a timeline and compare possible causes.
• Propose checks and remediation for the incident owner.

Hands overEvidence, hypotheses and proposed next steps.

11 / 11

Maintenance

I would use scheduled checks to find dependency drift, duplication and broken architecture rules.

• Find and explain a specific maintenance problem.
• Propose a small change with checks.

Hands overA focused maintenance change.

Keep the knowledge close to the code

I use a short AGENTS.md to point to the relevant documents. Product rules, architecture decisions, specifications and tests need their own places. Putting everything into one growing instruction file makes it harder for both me and the agent to find what matters.

repo
  AGENTS.md
  docs/
    product/
    architecture/
    security/
    decisions/
  specs/
  source code
  tests

For a team, I would also make issue history, deployment information and operational evidence reachable through controlled access. I want the agent to use the same sources the engineers trust.

Give the agent useful feedback

Types, lint and tests catch some errors. Model review can question the design or find a missing case. Neither proves the whole change correct. I use them together so I can spend my review time on the decisions and behaviour that still need judgement.

An architecture rule is easier to enforce when a check names the violation and shows what to fix. For example:

payments/domain must not depend on payments/infrastructure.
Move the adapter behind PaymentsRepository.
See docs/architecture/payments.md.

I would use that check for human-written code too.

Build up the capability

This is the maturity path I would use for a team. Each step depends on the checks and boundaries beneath it; buying another tool does not create those conditions.

Start with a workflow we can evaluate

How I would introduce it to a team

1. 01

   Find repeated work and measure it

   Choose a painful workflow with the team. Record time, waiting, rework and the quality problems that matter there.

2. 02

   Set the boundaries

   Agree on tools, permitted data, access and review. Give the agent only what that workflow needs.

3. 03

   Prepare the context and checks

   Make the relevant knowledge easy to find and test the feedback the agent gets when it makes a mistake.

4. 04

   Try it with people and review the result

   Start with a small pilot. Compare the outcome with the baseline, including review time and tool costs. Expand only where it helps.

   Human review

A failed pipeline, a dependency update or a documentation change can trigger an agent without someone writing a prompt each time. I would still begin with limited access and a reviewable proposal. For example, a pipeline failure can trigger reproduction and a tested fix proposal; a dependency vulnerability can trigger impact analysis and an upgrade; a merged change can trigger a documentation update. Scheduled maintenance can produce one bounded cleanup.

I would keep these workflows read-only by default and sandbox their execution. Any write operation needs narrow permissions and sanitised inputs. Production remediation needs a stricter boundary and explicit human approval.

Check whether it helped

I measure the team workflow before and after the change. Usage shows adoption, not whether the workflow helped. Tokens, prompts, accepted suggestions and pull-request counts stay out of individual performance reviews.

Where I would draw the boundary

For adoption planning, I would separate established uses from work that needs a stronger trial. This is my assessment, not a claim that every team has reached the same level.

My Teladoc workflow reduced a repeated investigation meeting. My current product lets me test a broader development process. That is experience with one team workflow and one person's product. I still need evidence before claiming the same approach will work across a larger organisation.