What AI Coding Agents Can and Cannot Do: A Plain Guide

If you are wondering what an AI coding agent can and cannot do, the short answer is this. It can do much of the hands-on building work: reading a project, writing code, running tests and fixing what breaks. It cannot decide what your business needs, and it cannot reliably prove its own work is right without a check you set up.

This guide is for people who do not write code: founders, product owners, analysts, testers and managers. It explains where agents are strong, where they are weak, and what that means for how you work with them. The examples come mostly from Anthropic's public documentation for Claude Code, one widely used agent.

What is an AI coding agent, exactly?

A chatbot answers questions and waits. An agent does things. Anthropic describes Claude Code as "an agentic coding tool that reads your codebase, edits files, runs commands, and integrates with your development tools". The codebase is simply the folder of files that makes up your software.

So you can say "add a password reset page" and the agent plans the approach, writes the code across several files and checks that it works. You do not have to dictate each step. That is the real change from older tools that only suggested a line of code at a time.

What can an AI coding agent do well?

These are the jobs where agents earn their keep.

Build features and fix bugs from plain words

Anthropic's documentation says you can describe what you want in plain language. For bugs, you can paste an error message or describe the symptom, and the agent traces the problem through the project, finds the cause and makes a fix. "Customers say login fails after they have been away for an hour" is a usable starting point.

Do the chores people keep putting off

The same documentation lists writing tests for code that has none, fixing style errors across a whole project, resolving merge conflicts (two people having changed the same thing), updating the outside building blocks a product depends on, and writing release notes. These jobs are tedious, rarely urgent and easy to check. That makes them a good fit.

Answer questions about your own software

You can ask how something works, or what happens in an unusual case, much as you would ask another engineer. Anthropic suggests this for getting up to speed on a new codebase. For a new manager or analyst taking over a product, it can be the most useful thing an agent does on day one.

Work in parallel

Anthropic's documentation describes starting several agents that work on different parts of a task at the same time, with a lead agent coordinating the work and merging results. For a founder this means a longer list of work can move at once.

What can't it do?

This is the part that surprises people, so it is worth being blunt.

It cannot read your mind

Anthropic's own advice says it directly: the agent "can infer intent, but it can't read your mind." If you say "make the dashboard look better", it will make some choice, and that choice may not be yours. The documentation's advice is that the more precise your instructions, the fewer corrections you will need. Name the screen, the problem and what "fixed" looks like.

It cannot tell whether it is right without a check

This is the biggest limit. Anthropic's guidance says the agent "stops when the work looks done". Without a check it can run, "looks done" is the only signal it has, and you become the person who must notice every mistake.

The guidance names a typical failure: the agent produces "a plausible-looking implementation that doesn't handle edge cases". An edge case is an unusual situation, like a customer with no address, or two people clicking Buy at the same moment. The fix is to give the agent something that returns pass or fail: tests (small programs that check the software behaves correctly), a build that must succeed, or a screenshot compared against a design. Anthropic's blunt rule: "If you can't verify it, don't ship it."

For you, this means asking one question about any finished task: what evidence shows it works? Anthropic suggests having the agent show evidence, such as the test output or a screenshot, rather than simply saying it succeeded.

It does not remember everything, and it gets worse as it fills up

An agent works inside a "context window", which holds the whole conversation, every file it has read and every result it has seen. Anthropic notes that performance degrades as this fills, and the agent may start "forgetting" earlier instructions or making more mistakes.

In practice, one giant session covering ten unrelated requests is a bad idea. Anthropic recommends resetting between unrelated tasks. If you have corrected the agent more than twice on the same point and it is still wrong, the advice is to start fresh with a better brief rather than keep arguing.

It does not grade its own homework well

Anthropic notes that a fresh session reviews code better, because the agent "won't be biased toward code it just wrote". A reviewer that sees only the finished change and the criteria you give it, not the reasoning behind it, judges the result on its own terms.

There is a catch. A reviewer asked to find gaps will usually report some, even when the work is sound, and chasing every finding leads to over-engineering. Anthropic suggests telling the reviewer to flag only gaps that affect correctness or the stated requirements.

It should not make your business decisions

Going live, spending money, deleting data and cutting scope are choices with real consequences. An agent can prepare them and explain the trade-offs. A person should decide. This is our advice rather than a rule from any one vendor, and it follows from the points above: the agent has no way to know your priorities, and some of these actions cannot be undone.

So what does that mean for my role?

Your job moves from describing and chasing to deciding and checking. In practice:

• Founders and product owners spend less time waiting on build work and more time deciding what is worth building and what "good" looks like.
• Business analysts become the source of precise requirements: who the user is, what the rules are, what is out of scope.
• Testers matter more, not less. Someone has to define the checks that the agent works against and to look at the evidence.
• Managers and agency owners need to watch approvals and who signs off, rather than hours worked.

A simple way to decide what to hand over

Hand over work that is clearly described, easy to check and cheap to undo. Be careful with work that is vague, hard to check or hard to reverse.

• Good to hand over: a new report page with clear fields, tests for old code, renaming things consistently, a bug with steps to reproduce.
• Hand over with care: anything touching sign-in, payments or customer data. Have a person review it as well.
• Keep with a person: pricing choices, launch dates, legal wording, what to leave out.

Anthropic also points out that for larger features you can let the agent interview you before it starts. It asks about edge cases, trade-offs and things you may not have considered, then writes a spec, which is a written description of what to build. That is a cheap way to find gaps before they become code.

How teams add structure around agents

A single agent leaves you holding a lot of the checking. Some tools wrap agents in a team structure so the checking is part of the process. Atlas, for example, is a team of AI engineers built on Claude Code. It refuses to call work done until the work is on the main version of the code or queued to join it, a screen has its test cases and screenshots, and the product's rules pass. Every finished build is also reviewed, and decisions such as production go-lives, spending and deleting data are never made for you. You can read more on the Atlas home page.

Conclusion

AI coding agents are strong at doing described, checkable work quickly, and weak at knowing what you meant, knowing whether they are right, and carrying a very long conversation. Treat them as fast builders who need clear briefs, a way to prove their work, and a person making the final calls. Get those three things right and you remove much of the risk while keeping the speed.