Cognition SWE-2: 6 Coding-Agent Workflows Engineering Teams Can Use Now

Cognition launched SWE-2, a new coding-agent model positioned for serious software engineering work: repository understanding, multi-file debugging, issue reproduction, patch planning, test generation, and code review. The market signal is bigger than “another coding model shipped.” Coding agents are moving from impressive demos into daily engineering operations, where every run has to produce a useful artifact, hand off cleanly to humans, and stay inside a predictable budget.

The immediate comparison point is premium agentic coding models such as Fable 5.1 and GPT-Astra-style systems: models that are not just autocomplete engines, but task executors that can inspect a repo, reason through dependency chains, call tools, write patches, and explain risks. For engineering leaders, the question is no longer “can an AI write code?” The question is: which parts of our software delivery workflow should now be agent-assisted, and which model should handle each step?

This guide turns the SWE-2 launch into a practical operating plan. You’ll get six copyable workflows for repo triage, issue reproduction, patch planning, test generation, code review, and escalation routing. You’ll also get model-routing guidance using current AI Cost Check pricing data, including where premium software-engineering models are worth it, where cheaper fallbacks are enough, and how to estimate cost per run before agent usage scales across the engineering org.

---

What changed with Cognition SWE-2

SWE-2 matters because it is being positioned as a dedicated software engineering agent model, not a general assistant with coding skills bolted on. That distinction changes how teams should evaluate it. A general model can answer programming questions. A coding-agent model needs to maintain context across a repo, inspect files, reason through failing behavior, propose changes, run or simulate tests, and return artifacts that fit an engineering workflow.

For teams already experimenting with coding agents, the bottleneck is usually not raw code generation. The bottleneck is trust. Engineers need agents that can explain what they inspected, distinguish confidence from uncertainty, avoid risky broad rewrites, and know when to escalate. A stronger software-engineering model gives teams a better chance of making the agent useful before the pull request stage, where most engineering time is actually lost.

The timing also matters. Engineering organizations are under pressure to ship more with the same headcount, but fully autonomous coding remains risky for production systems. SWE-2-style workflows are a middle path: use agents for investigation, reproduction, planning, and review scaffolding, while humans retain merge authority. That is where coding agents become daily infrastructure instead of novelty tooling.

Where SWE-2 fits in the coding-agent stack

Most engineering teams should think in layers:

Layer	Job	Recommended model class	Human involvement
Intake	Classify issue, identify component, find owner	Cheap fast model	Low
Repo scan	Map relevant files, APIs, dependencies	Mid-tier long-context model	Medium
Reproduction	Create repro steps, scripts, failing tests	Strong coding-agent model	Medium
Patch planning	Propose minimal safe fix	Premium coding-agent model	High
Test generation	Add unit/integration/regression tests	Mid-tier or premium model	Medium
Code review	Find bugs, regressions, security issues	Premium for risky PRs, cheap for routine PRs	High
Routing	Decide merge-ready, needs human, or escalate	Cheap + rule engine, premium for ambiguous cases	Medium

SWE-2 belongs in the repo scan, reproduction, patch planning, test generation, and review layers. It should not handle every ticket. Routine labeling, duplicate detection, formatting cleanup, dependency bump summaries, and simple doc edits should route to cheaper models.

---

Six practical workflows SWE-2 unlocks

A stronger software engineering model becomes valuable when you give it bounded jobs with clear outputs. The following six workflows are designed for real engineering queues, not one-off demos.

1. Repository triage for incoming issues

Repository triage is the first workflow most teams should automate because it produces value without allowing the agent to modify production code. The agent reads a GitHub, Linear, Jira, or Sentry issue, maps it to likely code areas, identifies missing information, and assigns a confidence score.

A good triage artifact includes:

• suspected subsystem
• likely owner or team
• relevant files and tests
• duplicate or related issues
• severity estimate
• reproduction confidence
• recommended next step

For example, a payment bug report might be routed to billing-api, linked to recent changes in webhook parsing, and marked “needs reproduction” because the issue lacks request payloads. A frontend layout bug might route to the design systems team with likely component names and a screenshot request.

This is a strong fit for SWE-2 when the issue requires repository understanding. For short issues with obvious labels, use a cheaper model such as GPT-5 mini, Gemini 2.5 Flash, or DeepSeek V3.2.

Output template

## Triage result

Severity: P2
Area: payments/webhooks
Likely files:
- services/billing/webhooks/stripe.ts
- services/billing/events/normalize.ts
- tests/billing/stripe-webhook.test.ts

Why:
- Error message matches webhook signature verification path.
- Similar failure appeared after commit touching event normalization.

Missing info:
- Raw webhook payload
- Stripe event type
- Environment and timestamp

Recommended next step:
Create reproduction test using captured payload shape and verify signature middleware behavior.

---

2. Issue reproduction and failing-test creation

Issue reproduction is where coding agents begin to save senior engineering time. Many bugs spend hours in “cannot reproduce” status. SWE-2-class models can inspect issue text, logs, stack traces, repo structure, and existing tests to create a minimal reproduction path.

The goal is not to let the agent fix the bug immediately. The goal is to produce a failing test, script, or command that a human can run.

Useful outputs include:

• exact setup commands
• required seed data
• minimal API request or UI sequence
• failing unit or integration test
• expected vs actual behavior
• reproduction confidence

This workflow is valuable because it converts ambiguous tickets into engineering-ready work. Even if the agent’s first attempt is imperfect, it can narrow the search space.

Step-by-step workflow: issue reproduction agent

Use this process for bug reports with logs, stack traces, user reports, or flaky tests.

Step 1: Gather context

Send the model:

• issue title and description
• stack trace or logs
• impacted environment
• recent commits
• package manifest
• test directory tree
• relevant file snippets from search

Step 2: Ask for a reproduction plan before code

Prompt:

You are a software engineering agent. Your task is to reproduce the reported bug, not fix it yet.

Return:
1. Most likely code path
2. Minimal reproduction strategy
3. Files to inspect
4. Existing tests to extend
5. Missing information
6. Confidence score from 0-100

Do not propose a patch until a failing test or script is specified.

Step 3: Let the agent inspect targeted files

Give the agent access to repository search, file read, test read, and dependency metadata. Avoid giving write access during this stage unless your tool supports isolated branches.

Step 4: Generate a failing test or script

Require the output to include a command:

Create the smallest failing test that demonstrates the bug. Prefer extending an existing test file. Include the exact command to run the test.

Step 5: Run in CI or a sandbox

The agent should not claim reproduction success without a test result. If the environment cannot run tests, the output must say “not executed” and provide the expected failure.

Step 6: Store the artifact

Attach the repro script, failing test diff, and confidence score to the ticket. This allows a human engineer to start from a concrete failure instead of a vague report.

---

3. Patch planning for multi-file changes

Patch planning is one of the best uses of a premium coding-agent model. The agent should produce a plan before writing code, especially for multi-file changes. The plan should define the minimal diff, tests required, migration risks, rollback path, and review checklist.

SWE-2-class models are useful here because patch planning requires more than syntax. The agent needs to understand architecture boundaries, hidden coupling, naming conventions, and expected side effects.

A strong patch plan includes:

Plan component	What the agent should produce
Problem statement	One-paragraph explanation of the failure
Root cause hypothesis	Specific function, module, or data flow
Minimal change set	Files to modify and why
Tests	Unit, integration, regression, and fixtures
Risk analysis	API compatibility, data migration, performance, security
Rollback	How to revert safely
Review guide	What human reviewers should inspect first

Patch planning should be mandatory for customer-impacting bugs, auth changes, billing logic, data deletion, migrations, and distributed systems behavior. It is overkill for typo fixes, simple docs, import cleanup, or obvious dependency bumps.

---

4. Test generation and regression coverage

Test generation is safer than autonomous patching and often more valuable. Teams with poor coverage can use SWE-2-style models to identify missing tests around recently changed code, known incidents, and high-churn modules.

A useful test-generation agent should:

• inspect existing test patterns
• reuse project test utilities
• avoid inventing unavailable helpers
• add regression tests for known failures
• separate unit tests from integration tests
• explain what each test protects

The key is to make tests reviewable. Avoid asking the model to “increase coverage.” Instead, ask it to generate tests for a specific behavior or incident.

Example prompt:

Inspect the existing tests for the billing webhook normalization path.
Generate regression tests for the following incident:
- Duplicate event IDs can be processed twice when retry headers differ.
Follow existing test style.
Do not change production code.
Return a patch plus explanation of what each test proves.

Use a cheaper coding-capable model for straightforward test expansion. For example, Codex Mini costs $1.50 input / $6 output per 1M tokens and has a 200,000-token context, making it a practical fallback for small to medium test generation tasks. For broader repository reasoning, use SWE-2 or a premium alternative.

---

5. Code review for high-risk pull requests

Code review agents should not replace human reviewers. They should prepare reviewers by finding likely defects, missing tests, risky assumptions, and unclear migrations. This is especially useful when a PR touches unfamiliar code or spans multiple teams.

Use SWE-2-class review for:

• authentication and authorization changes
• payment flows
• data migrations
• concurrency and distributed systems
• public API changes
• security-sensitive dependencies
• large refactors
• PRs from external contributors

Use cheaper models for:

• formatting
• naming
• documentation clarity
• simple TypeScript or Python mistakes
• changelog summaries
• test output summarization

A strong review output should be structured by severity:

## AI review

### Blockers
- Potential authorization bypass in `canEditProject()`: new branch skips org membership check when role is cached.

### Should fix
- Migration lacks rollback for index creation failure.
- Tests cover successful webhook flow but not duplicate delivery.

### Questions
- Is this API response shape considered public?

### Looks good
- Error handling in retry path follows existing queue convention.

The premium model is worth it when a missed issue would cause production damage. It is not worth it for every PR comment.

---

6. Escalation routing and human handoff

Escalation routing is the workflow that keeps coding agents safe. The agent decides whether a ticket can proceed, needs more information, should route to a specialist, or must be escalated.

Good routing labels include:

• agent-ready
• needs-repro
• needs-product-decision
• security-review
• data-migration-risk
• human-only
• premium-model-required
• cheap-model-ok

The routing workflow can start with a cheap model and escalate only uncertain cases. For example, use GPT-5 nano or Gemini 2.0 Flash to classify obvious tickets, then route complex tickets to SWE-2 or another premium coding model.

This routing layer is critical because coding-agent costs scale with loops. A single agent run that reads the repo, plans, writes tests, revises a patch, and responds to CI failures can consume many times more tokens than a simple chat response.

[stat] 1,000,000-token context Premium long-context models such as GPT-5.2, Claude Fable 5, and Claude Sonnet 5 can ingest large engineering context, but routing determines whether that context window becomes leverage or waste.

---

Step-by-step workflow: daily engineering queue agent

This is the copyable workflow most teams should deploy first. It does not require fully autonomous merging, and it creates immediate value across issue intake, triage, reproduction, and routing.

Step 1: Define ticket classes

Create five ticket categories:

Category	Examples	Model route
Routine	Docs, labels, small UI copy, dependency notes	Cheap model
Simple code	Small test additions, obvious config changes	Mid-tier coding model
Complex bug	Repro unclear, stack trace, multi-file path	SWE-2-class model
Risky change	Auth, billing, data, migrations, security	SWE-2-class model + human
Human-only	Product ambiguity, legal, incident command	Human owner

Step 2: Run cheap intake classification

Use a low-cost model to classify every incoming ticket. The prompt should force a route:

Classify this engineering ticket into exactly one category:
Routine, Simple code, Complex bug, Risky change, Human-only.

Return:
- category
- confidence 0-100
- reason in one sentence
- recommended model tier: cheap, mid, premium, human
- missing info

For this intake layer, use a cheap model such as GPT-5 nano at $0.05 input / $0.40 output per 1M tokens, Gemini 2.0 Flash at $0.10 / $0.40, or DeepSeek V4 Flash at $0.14 / $0.28.

Step 3: Route only complex tickets to SWE-2

Send tickets to SWE-2 when they meet one or more of these conditions:

• stack trace references internal code
• repro is unclear
• likely change spans more than three files
• test failures are flaky
• customer severity is P0 or P1
• security, billing, data, or permissions are involved
• the cheap classifier confidence is below 80

Step 4: Require a structured artifact

Do not let the model return a conversational answer. Require a ticket artifact:

## Agent artifact
Category:
Confidence:
Files inspected:
Likely root cause:
Reproduction status:
Proposed next step:
Risk flags:
Human owner recommendation:

Step 5: Push results into the engineering system

Post the artifact back to GitHub, Linear, Jira, or Slack. Include links to files and test commands. Do not bury the output in an agent UI that engineers have to check separately.

Step 6: Track outcomes

Measure:

• triage accuracy
• reproduction success rate
• percent of tickets correctly routed
• human time saved
• agent cost per useful artifact
• reopened tickets
• reviewer override rate

The right metric is not “number of agent runs.” The right metric is “useful engineering artifacts per dollar.”

---

Model choice and cost

Cognition’s SWE-2 pricing was not included in the provided AI Cost Check model dataset, so the safest way to budget today is to compare it against available public model prices and set internal routing thresholds. The core decision is simple: use premium coding-agent capacity when the task needs repo-wide reasoning or high-stakes judgment; use cheaper models when the task is classification, summarization, or localized code generation.

Current reference pricing

Model	Provider	Input / 1M tokens	Output / 1M tokens	Context	Best use
Claude Fable 5	Anthropic	$10	$50	1,000,000	Premium agentic planning and complex code review
GPT-5.2 pro	OpenAI	$21	$168	1,000,000	Highest-stakes reasoning, architecture review
GPT-5.2	OpenAI	$1.75	$14	1,000,000	Strong general coding and repo analysis
Claude Sonnet 5	Anthropic	$2	$10	1,000,000	Balanced coding, review, long-context tasks
GPT-5 mini	OpenAI	$0.25	$2	500,000	Routine issue triage and small code changes
Codex Mini	OpenAI	$1.50	$6	200,000	Focused coding patches and tests
DeepSeek V3.2	DeepSeek	$0.28	$0.42	128,000	Low-cost classification, summaries, routine tasks
Gemini 2.5 Flash	Google	$0.30	$2.50	1,000,000	Cheap long-context triage and test assistance

The comparison above uses public pricing from the model list: DeepSeek V3.2 at $0.28 input / $0.42 output per 1M tokens versus Claude Fable 5 at $10 input / $50 output per 1M tokens. The exact SWE-2 price may differ, but the budget lesson holds: premium coding agents should be routed, not sprayed across every ticket.

Cost per run examples

Use these scenarios as planning baselines. A coding-agent run is heavier than a chat turn because it includes issue text, file snippets, repository maps, tool results, plans, diffs, and test output.

Workflow	Estimated tokens	Premium reference: Claude Fable 5	Balanced reference: Claude Sonnet 5	Cheap fallback: DeepSeek V3.2
Issue triage	20k input / 3k output	$0.350	$0.070	$0.0069
Repo scan	120k input / 10k output	$1.700	$0.340	$0.0378
Repro plan + failing test	180k input / 35k output	$3.550	$0.710	$0.0651
Patch plan	250k input / 30k output	$4.000	$0.800	$0.0826
High-risk PR review	300k input / 60k output	$6.000	$1.200	$0.1092
CI failure analysis	80k input / 15k output	$1.550	$0.310	$0.0287

These numbers show why model routing matters. A team running 5,000 monthly high-risk PR reviews at the Claude Fable 5 reference price would spend about $30,000/month for that workflow shape. The same workload on Claude Sonnet 5 would cost about $6,000/month. DeepSeek V3.2 would cost about $546/month, but it may not provide the same code-review depth on complex PRs.

Use the AI Cost Check calculator to plug in your own token counts and task volume before rolling coding agents into every repository.

Recommended routing policy

Task	Default model tier	Upgrade trigger	Downgrade trigger
Labeling and dedupe	Cheap	Confidence below 80	Obvious duplicate
Issue summary	Cheap	Customer escalation	Short ticket
Repo triage	Mid-tier	Multi-service impact	Single known component
Reproduction	Premium	Ambiguous bug or flaky tests	Existing failing test
Patch planning	Premium	Data, auth, billing, migration	One-file change
Test generation	Mid-tier	Complex mocks or integration tests	Simple unit test
Code review	Mid-tier	Security, payments, concurrency	Docs or formatting PR
Escalation routing	Cheap + rules	Risk flags or uncertainty	Clear owner and severity

When the premium model is overkill

Do not use SWE-2-class capacity for:

• issue title rewriting
• changelog summaries
• dependency update descriptions
• obvious lint fixes
• small docs edits
• routine unit test naming
• PR comment summarization
• ticket deduplication when exact matches exist
• file search where embeddings or grep are enough

Use cheaper fallbacks for those tasks. GPT-5 mini, Gemini 2.5 Flash, DeepSeek V3.2, and Codex Mini cover most routine engineering operations at a fraction of premium-model cost. For broader model selection, compare GPT-5 vs DeepSeek V3.2 or GPT-5 vs GPT-5 mini.

---

Architecture for a production coding-agent workflow

A production workflow should look less like a chat window and more like a controlled CI system. The model is one component inside a pipeline with permissions, logs, budgets, and human approval.

Recommended stack

Component	Recommendation
Issue source	GitHub Issues, Linear, Jira, Sentry
Repo access	Read-only by default; branch-limited write access
Retrieval	Repository search, dependency graph, test index
Cheap classifier	GPT-5 nano, Gemini Flash, DeepSeek V3.2
Premium agent	SWE-2-class model for complex work
Sandbox	Ephemeral container with test runner
Output store	PR comment, issue comment, artifact attachment
Policy layer	Risk labels, budget caps, escalation rules
Metrics	Cost per artifact, acceptance rate, review override rate

Controls that prevent runaway spend

Set hard controls before expanding access:

1. Per-ticket budget cap: Stop after a fixed token or dollar threshold.
2. Tool-call limit: Limit file reads, test runs, and patch attempts.
3. Retry cap: One automatic retry for failed formatting; human escalation after that.
4. Context pruning: Send relevant files, not the entire repo.
5. Cheap-first routing: Every ticket starts with a low-cost classifier.
6. Risk escalation: Auth, billing, data deletion, and migrations require premium review plus human approval.
7. Artifact scoring: Track whether humans used the output.

A coding agent that generates long explanations but no accepted artifacts is expensive noise. A coding agent that reliably produces reproducible failures, focused patch plans, and useful review comments becomes engineering leverage.

---

Risks, limits, and failure modes

SWE-2-class models are stronger, but they are not substitutes for engineering judgment. The most common failure mode is confident local reasoning that misses production constraints. A model can inspect code and tests, but it may not know operational history, hidden customer contracts, or why an ugly workaround exists.

Key risks include:

Risk	What happens	Mitigation
Over-broad patches	Agent rewrites more than necessary	Require patch plan and max changed-files limit
False confidence	Agent claims reproduction without running tests	Require command output or “not executed” label
Test theater	Agent writes tests that assert implementation details	Require behavior-focused test review
Context omission	Important file excluded from prompt	Use retrieval logs and file-inspection checklist
Cost loops	Agent retries repeatedly after CI failures	Set retry and dollar caps
Security leakage	Secrets or customer data enter prompts	Redact logs and use scoped access
Ownership confusion	Agent assigns wrong team	Keep CODEOWNERS and service map in context

When should teams avoid SWE-2-style automation? Avoid it for incident command, legal/compliance interpretation, ambiguous product decisions, and production data changes. Use agents to gather facts and propose options, but keep accountability with humans.

---

A 30-day rollout plan for engineering teams

A controlled rollout is the difference between useful automation and an expensive experiment. Start narrow, measure outcomes, and expand only after the workflow produces artifacts engineers actually use.

Week 1: Read-only triage

Connect the agent to issues and repository metadata. Allow it to classify tickets, suggest owners, identify files, and list missing information. No code writes. Measure routing accuracy against human triage.

Target outcome: 70%+ useful triage comments on routine and medium-complexity tickets.

Week 2: Reproduction artifacts

Enable sandboxed test generation for bug tickets. The agent can propose failing tests or scripts on a branch, but humans must run or approve them. Focus on one repo or service.

Target outcome: 30%+ of ambiguous bugs receive a useful reproduction artifact.

Week 3: Patch plans and test suggestions

Allow the agent to produce patch plans for complex bugs and test-generation diffs for existing issues. Still avoid autonomous production patches. Require structured review.

Target outcome: engineers accept or adapt 25%+ of patch plans.

Week 4: PR review and escalation routing

Add AI review for high-risk PRs and cheap-model review for routine PRs. Introduce escalation labels and model routing based on risk.

Target outcome: fewer missed test gaps, faster reviewer preparation, and clear data on cost per useful comment.

At the end of 30 days, expand only the workflows with measurable acceptance. If triage comments are ignored, fix prompts and routing. If reproduction artifacts work, expand that first. If code-review comments are noisy, restrict review to high-risk file paths.

---

Frequently asked questions

What is Cognition SWE-2?

Cognition SWE-2 is a new coding-agent model positioned for software engineering workflows such as repository triage, issue reproduction, patch planning, test generation, and code review. Teams should use it for complex, repo-aware tasks rather than routine ticket summaries or simple formatting fixes.

How should engineering teams use SWE-2 first?

Start with read-only repository triage and issue reproduction. Those workflows produce useful artifacts without granting merge authority, and they help teams measure value through triage accuracy, reproduction success rate, and cost per accepted artifact.

How much does a coding-agent run cost?

A coding-agent run can range from under $0.01 for cheap classification with models like DeepSeek V3.2 to several dollars for premium long-context review using a model like Claude Fable 5. Use the AI Cost Check calculator with your own input tokens, output tokens, and monthly run volume.

When is a premium coding model overkill?

A premium model is overkill for labels, duplicate detection, changelog summaries, docs edits, simple lint fixes, and short PR summaries. Use cheaper models such as GPT-5 mini, Gemini 2.5 Flash, or DeepSeek V3.2 for those routine tasks.

Should coding agents be allowed to merge code automatically?

No. Coding agents should create triage artifacts, reproduction tests, patch plans, test diffs, and review comments, but humans should retain merge authority for production code. Use isolated branches, scoped credentials, CI validation, and human approval for every production-impacting change.

---

Next steps

SWE-2 is a signal that coding agents are becoming engineering operations infrastructure. The winning teams will not be the ones that send every ticket to the strongest model. They will be the teams that route work intelligently: cheap models for intake, mid-tier models for routine code tasks, and SWE-2-class models for ambiguous, risky, multi-file engineering work.

To plan your rollout:

• Estimate your per-run and monthly spend with AI Cost Check
• Compare fallback options such as GPT-5 vs GPT-5 mini
• Review premium alternatives like Claude Fable 5, Claude Sonnet 5, and GPT-5.2
• Build your first workflow around triage and reproduction before allowing patch generation

The practical move this week: add a cheap classifier in front of your issue queue, route only complex bugs and risky PRs to a premium coding-agent model, and measure cost per useful engineering artifact.