Agentic SDLC vs coding assistants: what changes when the agent owns the issue, not the keystroke
AI help for software teams comes in several shapes. They differ in one thing above all: how much of the work one request covers. A tool that finishes your line covers a line. A tool that takes an approved issue covers the path from issue to pull request.
This page describes four categories by what they do by design, where each fits, and where an agentic software development lifecycle (SDLC) differs. The categories are not rivals. Most teams will use more than one.
The four categories
Autocomplete
Suggests the next token, line or block inside your editor while you type. You drive every step. It fits fast, local edits where you already know what you want to write. It keeps no plan and does not open pull requests.
Chat assistants
Answer questions and draft code in a conversation. You paste context in, read the answer, and carry the result back to your repository yourself. They fit explaining unfamiliar code, sketching an approach and one-off scripts. What you get depends on the context you supply each time.
Coding agents
Read files, run commands and edit across a project to complete a task. Many run in a session a developer starts and steers. Some also run hosted, take an assigned issue and open a pull request. What they do not usually include is separate roles checking the work against acceptance criteria before a human reads it.
Agentic SDLC
Teammates with defined roles (product, engineer, QA) run on an agent server and work from an issue instead of a prompt. The unit of work is the issue, and the output is a pull request a human reviews. An approved issue becomes a review-ready PR with evidence against the acceptance criteria and a plain account of what remains uncertain.
What changes when the agent owns the issue
With the first three categories, you hold the plan. You decide what to ask next, you check the result, and you carry it to the next step. The tool is fast at its slice, and the rest of the work stays yours.
When the agent owns the issue, the plan lives in the issue. Acceptance criteria say what done means. Teammates with different roles pick up different parts, and each can be checked against the same criteria. Your attention moves from watching keystrokes to reading a pull request and its evidence.
That trade only pays off when issues are written clearly. If your issues are one-line notes, you will spend the saved time clarifying them. The product Teammate exists to close that gap before implementation starts.
Side by side
| Autocomplete | Chat assistants | Coding agents | Agentic SDLC | |
|---|---|---|---|---|
| Unit of work | A line or block | A question or snippet | A task, sometimes an assigned issue | An approved issue |
| Who drives each step | You | You | You start it; how much you steer varies | Teammates by role, a human approves |
| Where it runs | Your editor | A chat window | Your machine or a hosted session | An always-on agent server |
| What it remembers between tasks | Little | What is in the conversation | Depends on the tool | Memory tiers and a failure-pattern file in your repo |
| Evidence you get | The suggestion | The answer | A diff and a summary | Evidence against the acceptance criteria, plus what is still uncertain |
| Who merges | You | You | You | A human approves; nothing merges without that |
Where each fits
Autocomplete and chat assistants are the right tool for many tasks. A rename, a regular expression, a quick question about an unfamiliar library: opening an issue for these would be slower. Coding agents fit work where a developer wants to stay in the loop.
An agentic SDLC fits work that is already written down as an issue with acceptance criteria, and that you would rather review than supervise. It can sit beside the others. Developers keep their editor tools, and the lane handles the issues you hand it.
How the engineering lane works
An engineering lane is a product, an engineer and a QA Teammate on one agent server: an always-on workstation with its own files and its own tools, always running. The role templates are described in Teammates.
- The product Teammate helps turn a request into an issue with acceptance criteria. A human approves it.
- The engineer Teammate implements the issue and opens a pull request, with evidence against the acceptance criteria and a plain account of what remains uncertain.
- The QA Teammate runs your scenario suite in its own context, separate from the engineer's.
- The QA Teammate reviews the pull request with inline findings checked against the issue and your repo's conventions, and notes whether the PR changes its own tests.
- A human approves. Nothing merges without that approval.
A failure-pattern file in the repo records the classes of bug your team has seen. The reviewer reads it each time it reviews, so a pattern you have written down gets caught at review next time. The engineer Teammate can mine past review comments into that file.
The engineer gets write access to code, pull requests and issues. The reviewer gets a narrower profile: it can read code and review, approve and comment, but cannot push or edit CI and workflow configuration. Once GitHub is connected, PR, review and comment events arrive without per-repo webhook setup. See Integrations.
Teammates have memory in three tiers, and private conversations are never rolled into shared summaries. Workspace files are read-only at runtime, so a Teammate cannot rewrite its own instructions.
Start smaller than the full lane
The smaller first step is a second review of the PRs you already have, before anything writes code. It waits on the readiness gate described under Honest limits below. For how that compares with per-seat review tools, read a second reviewer that remembers your repo.
Honest limits
- The reviewer and the engineering lane run on our own repositories today. Before either runs on yours, a readiness gate must pass, including an option to keep review findings private and a visible verdict on the final commit of most PRs.
- Linear is the only issue tracker supported today.
- We do not have a SOC 2 report yet.
- The reviewer does not run your tests or read CI today. It reads the diff, the issue and the failure-pattern file.