AI-powered SDLC

An AI-powered software lifecycle is not a chat sidebar next to the repo. It is assistants and agents sitting on the work you already do: tickets, implementation, review, tests, and promote. If the only change is that developers paste code into a public model, you have shadow AI, not an SDLC.

This is a product shape we build as custom AI when the workflow is yours, and as agents when the step is a write (open a ticket, merge a field, file a rollback). One CTA at the end. This post is the pipeline cut. It is not the same article as governing models in the SDLC. That is change control for prompts. This is using AI as the pipeline.

Do not start with a platform that promises to replace your tracker. Start with one step that already has a system of record.

Put the assistant on a step you can measure

The SDLC already has queues. Pick one.

Useful first steps:

• Draft a ticket from a customer note, with a human edit before it is filed.
• Propose a test from a failing case, still reviewed.
• Summarize a diff for a reviewer who owns the merge.
• Assemble a release note from merged tickets, not from a model's imagination.

Useless first steps:

• "AI writes the whole feature."
• A generic coding copilot with no eval and no data-class rule.
• Replacing code review with a model that cannot be paged.

Count hours on that step. Twelve releases a year will not pay for a custom pipeline. Daily tickets might.

The pipeline is still the system of record

Tickets live in the tracker. Code lives in git. Artifacts live in the build. The model proposes. It does not become a second tracker.

Rules that hold:

• Prompts and model pins are versioned with the service that uses them.
• A suggestion that becomes a ticket or a comment is attributed and reversible.
• Secrets and customer data do not leave on a personal account, even "to get the function written faster."
• CI still runs. A green model opinion is not a green build.

If developers can only use the assistant by copying a stack trace into a consumer chatbot, you have not powered the SDLC. You have added a leak.

Eval the step, not the model's personality

You cannot unit-test "was the ticket good." You can hold a set of real, redacted tickets and score whether the draft had the fields your board requires, whether it invented a severity, whether it pasted PII.

For each SDLC step you automate:

• A small eval set from last month's work.
• A pass bar that blocks auto-file or auto-merge.
• A human on the write. Drafts can be cheaper. Merges and deploys cannot be unsupervised on day one.
• A re-run when you change the prompt or the model alias.

This is the same discipline as productionizing. A coding demo that "looked fine" is how you ship a confident wrong test.

Agents belong on writes, copilots on drafts

A copilot that comments on a PR is a writer. An agent that labels a ticket, assigns it, or opens a rollback is an actor. Use the four-step test: look up, decide, act, confirm. If there is no act, do not call it an agent.

Writes in the SDLC that deserve a gate:

• Creating or closing tickets.
• Changing owners or severity.
• Anything that touches production config.
• Customer-facing release text.

Shadow the agent on real traffic before it acts alone. Log every action. Keep a one-click path to a person. That is the agent product, applied to engineering operations, not a new religion.

Do not buy a second lifecycle

Integration is the whole game. The assistant should read the tracker and the repo you already pay for. A new "AI SDLC suite" that wants you to move tickets is a rip-and-replace dressed as innovation.

Build in your environment:

• API-first, in your cloud, in your repos.
• Identity you already use.
• Cost limits so a repo-wide agent cannot run all night.
• Handover docs so the platform team can own it.

Fixed scope after discovery. You own the IP. First slice in staging when the discovery says it is worth building. We do not publish a package price.

If the step is real and the hours are real, put an assistant on that step inside the tools you already have. See custom AI development.