That's the short answer. The longer one matters more, because the label gets stuck on everything from a chat window to a fully autonomous bot. If you're deciding whether to bring one onto your team, you need to know what actually happens between "here's the ticket" and "here's the PR", and where it goes wrong.

The one-line definition

A useful test: what is the unit of work?

• An autocomplete tool works on the next few lines.
• A chat assistant works on one question.
• An AI software engineer works on one task, end to end, and is judged on whether the result passes tests and review.

Everything else follows from that. Because it owns a task, it needs its own workspace, a way to run your code, and a way to hand the result back without touching production. That hand-back is almost always a pull request, because the pull request is where software teams already do their quality control.

How an AI software engineer works, step by step

Most serious systems run the same loop. Here's what it looks like when YTS picks up a ticket.

1. Read the ticket and the codebase

It starts by reading the ticket, then the parts of the repository that matter: the files the ticket mentions, the code around them, the tests that cover them, the README and the build config. A human engineer does the same thing on day one of a new task. The difference is speed, not method.

2. Write a plan

Before touching code it writes down what it intends to change and why. This is the cheapest place to catch a misunderstanding. If the plan is wrong, you fix one paragraph, not three hundred lines of diff.

3. Make the change in its own environment

The agent edits files in an isolated copy of your project, not on your machine and never on a shared branch. It can install dependencies, run scripts and open a browser to check a page, the same way a developer would.

4. Run the build and the tests, then fix what fails

This is the step that separates an engineer from a code generator. It runs your test suite and the build, reads the failures and iterates until they pass. If there are no tests for the change, a good agent writes them.

5. Open a pull request

The output is a normal pull request: a branch, a description of what changed and why, and evidence such as test results. Your team reviews it like any other PR. Nothing reaches your main branch until a person merges it.

6. Leave a record

Every step above should be visible. YTS logs each plan, file change, test run and review on a timed record, and the live tracking board shows which agent is on which ticket right now. When a PR looks odd, you can see exactly how it got there.

What it is not

It is not autocomplete, and it isn't a chatbot with a bigger context window. We wrote a full comparison in AI coding agent vs AI coding assistant, but the short version is this: an assistant helps a developer write code faster, while an agent does the task and hands back a result for review.

It's also not a replacement for code review. That isn't a philosophical position. It's what the data says.

What the 2025 and 2026 data actually says

Adoption is nearly universal now. Trust is not.

• 84% of developers use or plan to use AI tools in their development process, up from 76% the year before (Stack Overflow 2025 Developer Survey (opens in a new tab)).
• 46% actively distrust the accuracy of those tools, while 33% trust it. Only 3.1% say they "highly trust" it (same survey).
• The top frustration, named by 66%, is AI output that is "almost right, but not quite". That's exactly the kind of bug that slips through a quick skim.
• 90% of respondents in Google's 2025 DORA research use AI at work. DORA also found AI adoption still has a negative relationship with software delivery stability (Google Cloud, 2025 (opens in a new tab)).

Agents specifically are still early. In the same Stack Overflow survey, 52% of developers either don't use agents or stick to simpler AI tools, and 14.1% use agents at work daily. GitHub reports its Copilot coding agent created more than 1 million pull requests between May and September 2025 (Octoverse 2025 (opens in a new tab)). So the PR-shaped workflow is real and growing fast.

There's one finding every buyer should know. In a July 2025 randomized trial, METR found experienced open-source developers took 19% longer to finish tasks when using AI tools, while still believing AI had sped them up by about 20% (METR, 2025 (opens in a new tab)). METR has since said the tools moved on and its newer data gives an unreliable signal (METR, 2026 (opens in a new tab)). The lesson still holds. Feeling faster is not a measurement. Count merged PRs and post-merge defects instead.

Where an AI software engineer does well

These tickets tend to go well:

• Bugs with a clear reproduction. "Clicking Save with an empty title throws a 500" is a perfect ticket.
• Small features with a clear finish line. A new field, a new endpoint, a new filter.
• Tests. Adding coverage to code that has none is tedious for people and ideal for agents.
• Upgrades and migrations. Bumping a framework version, replacing a deprecated API, moving config formats.
• Refactors with a fixed target. Rename, extract, split a file, without changing behaviour.

The common thread is that each one has a checkable "done". If the tests can say yes or no, the agent can loop until yes.

Where it struggles

• Vague tickets. "Make onboarding better" has no finish line, so the agent invents one.
• Missing context. Business rules that live only in someone's head. Tribal knowledge about why a weird check exists.
• No tests, no build script. If your project can't be built and tested from the command line, the agent can't verify its own work.
• Judgment calls. Product trade-offs, security posture, what to cut. These belong to people.
• Security-sensitive code. In Veracode's 2025 testing (opens in a new tab), 45% of AI-generated code samples introduced an OWASP Top 10 vulnerability. Anything near auth, payments or user data needs a careful human review.

Benchmarks: useful, but read them carefully

You'll see agents ranked on SWE-bench Verified, a set of 500 real GitHub issues that humans checked for fair grading (SWE-bench (opens in a new tab)). It's a fair signal of raw ability on open-source Python repos. It is not a measure of how an agent does in your codebase, with your conventions and your missing docs. Run a two-week pilot on your own backlog before trusting any leaderboard.

How teams actually use one

The teams that get the most out of an AI software engineer treat it like a very fast new hire:

1. Write tickets a newcomer could finish. Goal, acceptance criteria, the files involved, how to test it.
2. Keep tests green and runnable. Your test suite is the agent's eyes.
3. Start with the boring backlog. Bugs, tests, upgrades. Earn trust before handing over features.
4. Review every PR like a teammate's. We wrote a checklist for reviewing AI-generated pull requests you can use from day one.
5. Measure outcomes. Time from ticket to merge, review rounds, bugs after merge.

If your team doesn't have review capacity, that's the real bottleneck, not the agent. It's why YTS offers YTS Review, where a senior engineer from our team reviews every PR before it reaches you.

The bottom line

An AI software engineer is worth having when three things are true. The work is well scoped. Your code can be built and tested automatically. And a person still owns the merge. Get those right and it clears the tickets that sit in "next sprint" for months.

YTS is built that way. It plans, codes and tests in its own environment, and it never merges on its own. You can see how it works or watch it pick up a ticket on the live board.

Here's the checklist, and why each item is on it.

Why AI pull requests need a different eye

The standard doesn't change. The failure patterns do.

• In CodeRabbit's December 2025 analysis of 470 open-source pull requests, AI co-authored PRs had about 1.7x more issues than human-only PRs (10.83 vs 6.45 per PR). Logic and correctness issues were 75% more common (CodeRabbit, 2025 (opens in a new tab)). CodeRabbit sells code review and notes it can't be certain every "human" PR was human-written, so treat the exact ratio with care. The direction is consistent with other research.
• In Veracode's 2025 testing, 45% of AI-generated code samples failed security tests and introduced an OWASP Top 10 (opens in a new tab) vulnerability. Java was worst at a 72% failure rate (Veracode, 2025 (opens in a new tab)).
• 66% of developers say their top frustration with AI is output that is "almost right, but not quite" (Stack Overflow, 2025 (opens in a new tab)).
• GitClear's 2025 research found that in 2024, copy-pasted lines outnumbered moved (refactored) lines for the first time (DevClass coverage (opens in a new tab)). Duplication is quiet debt that a quick review misses.

Put simply, AI code fails confidently. It compiles, it's well named, the tests are green, and it's still wrong. Your review has to be built for that.

The 12-point checklist

Before you read the diff

1. Does the PR solve the ticket that was asked? Re-read the ticket, then the PR description. Agents sometimes solve a nearby problem very well. Check the acceptance criteria one by one.

2. Is the plan sound? If the agent wrote a plan (good ones do), read it first. A wrong approach is cheaper to reject here than after reading 400 lines. YTS attaches its plan to every ticket's timed record for exactly this reason.

3. Is the PR small enough to review properly? If it touches unrelated files or runs to thousands of lines, send it back and split the ticket. Nobody can verify a giant diff, human or machine.

Read the tests before the code

4. Do the tests actually test the change? Look for tests that assert something trivially true, mock the very thing they claim to test, or only cover the happy path. Green tests that prove nothing are the most common way a bad AI PR gets merged.

5. Were existing tests changed or deleted? Any edit to an existing assertion needs a reason in the PR description. "Updated the test to match the new output" can mean "hid the bug".

6. Are edge cases covered? Empty input, nulls, large values, time zones, concurrency, permissions. Ask: what would break this in production on a bad day?

Then read the code

7. Does every API, package and function actually exist? Check imports and calls against your real dependencies and their versions. Invented methods and outdated signatures look completely plausible in a diff.

8. Does it follow your codebase's patterns, or invent new ones? A second HTTP client, a new date library, a fresh helper that duplicates one you already have. Each is small. Together they're the duplication GitClear measured.

9. Is error handling real? Look for swallowed exceptions, catch-all blocks that log and continue, and retries without limits. AI code often handles errors in a way that hides them.

Security and data

10. Is every input validated and every query safe? Check for injection, missing output encoding (cross-site scripting was one of Veracode's worst categories), unsafe deserialization and path handling. Treat anything near auth, payments or personal data as high risk by default.

11. Did it touch secrets, permissions or config? New environment variables, widened permissions, logging that could print tokens or personal data, disabled checks "to make the tests pass". All of these need an explicit yes from a person.

Before you approve

12. Did you run it? Pull the branch and use the feature, or at least read the agent's test output and screenshots. Approving based on the diff alone is how "almost right" ships.

How to make AI pull requests easier to review

The best review is the one you barely need. Most of that work happens before the PR exists.

• Write tickets with acceptance criteria. The clearer the finish line, the less the agent guesses.
• Keep tests fast and runnable from the command line. The agent uses them to check itself.
• Require a plan and a summary on every PR. What changed, why, how it was tested.
• Keep the agent PR-only. It should never be able to merge. YTS never merges on its own.
• Use AI review as a first pass, not the last. Automated review catches patterns. A person who knows the product catches wrong intent.

Google's code review guidance (opens in a new tab) still applies in full: the reviewer's job is to keep the codebase healthier over time, whoever wrote the change.

When you don't have time to review

This is the honest bottleneck. An agent can open PRs faster than a small team can review them, and DORA's 2025 research (opens in a new tab) found AI adoption still has a negative relationship with delivery stability. More output without more review is how that happens.

If review capacity is your constraint, you have three options. Slow the agent down to your review speed. Keep its work to low-risk tickets. Or add reviewers. YTS offers the third as YTS Review, where a senior engineer from our team reviews every PR YTS opens before it reaches you.

Copy this checklist

1. Solves the ticket as asked
2. Plan is sound
3. Small enough to review
4. Tests test the change
5. No unexplained test edits
6. Edge cases covered
7. Every API and package is real
8. Follows existing patterns, no duplication
9. Errors are handled, not hidden
10. Inputs validated, queries safe
11. No secret, permission or config surprises
12. You ran it

New to agents? Start with what an AI software engineer actually is and how agents differ from assistants.

Same underlying models, very different jobs. Mixing them up leads to the wrong expectations, the wrong guardrails and a lot of disappointed teams.

The quick comparison

What a coding assistant does

Assistants live where you already work. Inline completion predicts the next few lines. Chat explains an error, drafts a function or writes a regex. Some assistants can edit several files when you ask.

The key point is that you stay in the loop the whole time. You decide what to accept, you run the tests, you commit. That keeps risk low and makes assistants easy to adopt, which is why they're everywhere. In the Stack Overflow 2025 Developer Survey (opens in a new tab), 84% of developers said they use or plan to use AI tools, and 50.6% of professional developers use them daily.

The catch is that your attention is the bottleneck. An assistant makes you type faster. It doesn't give you more hours.

What a coding agent does

An agent works like a teammate you hand a ticket to. A typical loop:

1. Read the ticket and the relevant code.
2. Write a plan.
3. Edit files in its own workspace.
4. Run the build and tests, read the failures, fix them.
5. Open a pull request with a summary and test evidence.

You're involved at two points: writing the ticket and reviewing the result. In between, the agent works without you, which is the whole point. Three tickets can move while you're in a meeting.

This is a younger category. In the same survey, 52% of developers either don't use agents or stick to simpler AI tools, and 14.1% use agents at work daily. But the pull-request workflow is growing fast. GitHub says its Copilot coding agent created more than 1 million pull requests between May and September 2025 (Octoverse 2025 (opens in a new tab)).

We cover the full loop in what is an AI software engineer.

The difference that matters most: where the risk moves

With an assistant, mistakes get caught (or missed) one suggestion at a time, by the person typing. With an agent, mistakes arrive bundled in a pull request that looks finished.

That's why the top frustration in the 2025 survey matters so much here. 66% of developers named AI output that is "almost right, but not quite". An almost-right suggestion in your editor is easy to spot. An almost-right PR with green tests is not, unless your review process is built for it.

Google's 2025 DORA research (opens in a new tab) points the same way at team level. AI adoption now tracks with higher delivery throughput, but it still has a negative relationship with delivery stability, and 30% of respondents report little or no trust in AI-generated code. More output only helps if quality control keeps up.

When to use an assistant

• You're in the middle of the work and want to move faster.
• The task needs constant judgment calls, like UI polish or a tricky design decision.
• You're exploring: reading unfamiliar code, trying approaches, writing a spike.
• There are no tests yet and you're the one who'll verify it.

When to use an agent

• The ticket has a clear finish line and acceptance criteria.
• The project builds and tests from the command line.
• It's work that keeps slipping: bug backlog, test coverage, upgrades, small features, migrations.
• You'd rather review a PR than write it.

A simple rule: if you'd hand it to a capable new hire with a clear ticket, hand it to an agent. If you'd want to sit next to them while they do it, use an assistant and do it yourself.

The guardrails agents need (that assistants don't)

Because an agent acts on its own, the safety model has to be different:

• Isolated environment. It works in its own copy of the project, never on your laptop or a shared branch.
• Pull-request-only access. It can propose changes. It can't merge them. YTS is built so it never merges on its own.
• Runnable tests. Tests are how the agent checks its own work and how you check it too.
• A visible trail. You should be able to see every plan, edit and test run. YTS shows this on a live tracking board with a timed record per ticket.
• A human reviewer who owns the merge. Use a review checklist built for AI code, like our guide to reviewing AI-generated pull requests.

A word on measuring it

Don't judge either tool by feel. In METR's July 2025 randomized trial, experienced open-source developers were 19% slower with AI tools while believing they were about 20% faster (METR, 2025 (opens in a new tab)). The tools have improved since and METR itself says that result is now dated, but the perception gap is the lesson. Track time from ticket to merged PR, review rounds and bugs found after merge.

The bottom line

Assistants make the developer faster. Agents take the task. Most strong teams use both: an assistant in the editor for the work they're doing, and an agent for the tickets that never get picked up.

YTS is the agent half. Give it the ticket and get back a tested pull request your team reviews. See how YTS works.