What Are AI Coding Tools Actually Good At?
AI coding tools are now good enough to create a dangerous impression. After you watch Codex, Claude Code, Cursor Agent, or a similar tool read a repository, edit files, run tests, and explain failures, it is tempting to ask: should we just hand it the whole feature? Maybe even the architecture?
My answer is no. AI is very useful for bounded execution. It should not take over engineering judgment before it understands the business constraints.
These tools are excellent at reading code, adding tests, moving boilerplate, tracing call chains, and making small changes that can be checked. They are much weaker at owning architecture, permission boundaries, data models, and release strategy. Those are not just coding tasks. They carry product, security, operational, and organizational responsibility.
The best use is extracting context
In real projects, a lot of time is not spent typing code. It is spent finding the right code.
Why does this button have no permission? Where is this field removed from the response? Is this endpoint appending data or replacing it? Which cache layer is stale? Those questions often require moving through routes, components, services, controllers, database queries, migrations, and tests.
This is where an AI coding agent can help a lot. It can search broadly, follow references, compare nearby files, and summarize what it found.
Good tasks look like this:
- Read an unfamiliar module and identify the entry points, core services, and data writes.
- Trace one user action from frontend component to backend handler and database query.
- Find where a field is created, transformed, filtered, and returned.
- Compare similar implementations and explain which local pattern this codebase uses.
- Start from a failing test or log and narrow the likely cause.
The tool is not making a deep product decision here. It is acting as a fast code reader and organizer. Its answer should still point back to files, functions, and command output.
Small verified changes are the sweet spot
AI coding tools work best when the goal is narrow, the boundary is clear, and the acceptance check is concrete.
Examples:
- Add a missing null check in an existing service.
- Add tests for an API using the local test style.
- Migrate a group of components from one UI primitive to another.
- Fix a duplicate-submit issue in a form.
- Adjust a query to remove an obvious N+1 pattern.
- Normalize error handling to match the existing project format.
These tasks have two helpful properties. First, the repository already contains examples for the AI to follow. Second, the result can be checked with tests, builds, linting, or a focused manual review.
The value is not that the AI understands the system better than a senior engineer. The value is that it can do tedious, detail-heavy work quickly. It can read adjacent files, copy naming conventions, update repeated patterns, run checks, and repair the next failure. The human still owns the scope, reviews the diff, and decides whether the behavior is right.
A good instruction sounds like this:
“Only fix permission visibility for the export button on the user list page. First inspect how existing button permissions are checked, then update the page component and add one focused test. Do not change backend APIs or redesign the permission model.”
That is much better than “optimize the permission system.” The first prompt is executable. The second prompt invites unconstrained design.
Tests and migrations are high-return work
Many teams underinvest in tests because writing them can be repetitive. AI is a good fit for that kind of work, especially when the repository already has examples.
It can add coverage for:
- successful paths
- permission denial
- duplicate submissions
- empty values and boundary values
- error responses
- behavior that must not change after a refactor
Boilerplate migrations are similar. Moving old form components to a new design system, routing API calls through a shared service, renaming repeated props, or replacing one date formatter with another can be boring and error-prone for humans. AI can handle a lot of that work if the rule is clear and the validation command is known.
There is still a boundary. AI can migrate boilerplate. It should not casually redefine the abstraction while doing it. If it notices the old structure is messy, it can report the issue. But “bulk migration” and “architecture redesign” should not be hidden inside the same task.
Architecture is not folder decoration
Architecture is not just making folders look cleaner or adding more layers.
Real architecture decisions depend on constraints the model may not know: team size, release cadence, legacy systems, permission rules, database cost, compliance needs, rollback ability, incident history, and the actual roadmap. If the AI only sees code, it may propose something that sounds sophisticated but is expensive or risky to land.
For example, it may suggest:
- splitting a monolith into multiple services
- rewriting the permission system
- normalizing the database model around a cleaner theory
- introducing an event bus or CQRS
- replacing a simple workflow with a state machine framework
Those ideas are not automatically wrong. They are just not automatically actionable. The real question is not “is this architecture elegant?” The real question is “is it worth the migration, can we roll it back, and does it match the cost of failure for this business?”
AI can absolutely participate in architecture work. The safer use is to ask it for current-state analysis, risks, options, and migration steps, not to let it decide the direction by itself.
A better prompt is:
“Based on the current code, where are permission checks implemented today? If we wanted to converge them into one authorization layer, what is the smallest migration path? Which endpoints are highest risk? Do not edit code yet.”
Now the tool is doing analysis. It is not acting as the architecture owner.
Some boundaries must stay human-owned
Several areas should not be handed to AI for direct decision-making.
Permission boundaries decide who can read, change, export, approve, delete, or delegate access. A mistake here may be a security incident, not just a bug. AI can help find whether checks exist. It should not decide the business policy.
Data models last longer than the feature that created them. Tables, unique constraints, soft-delete behavior, status fields, audit columns, and idempotency keys affect future migration, reporting, and concurrency behavior. AI can draft a schema, but a person must own the invariants.
Release strategy is production responsibility. Feature flags, migrations, rollback plans, config order, old-client compatibility, and monitoring need operational judgment. AI can draft a checklist, but it cannot own the production risk.
Business invariants must be explicit before implementation starts. Order totals cannot be changed after payment. Withdrawal approval cannot bypass manual review. An admin cannot silently grant themselves more power. Deletion must preserve audit history. AI can implement rules once they are stated. It should not invent them.
A better collaboration model
Treat AI as a very fast teammate with no durable organizational memory.
Give it:
- a clear goal
- a clear file or module boundary
- local examples to follow
- checks it must run
- things it must not change
- the exact behavior that must remain true
Then let it do the work it is good at: read code, find paths, make small edits, add tests, run checks, and explain the diff.
For bigger design questions, ask for a research pass first. What is the current implementation? Where are the risks? What are the options? What is the smallest reversible first step? After a human chooses the direction, the implementation can be split into smaller AI-friendly tasks.
Bottom line
AI coding tools are most valuable when they remove low-value friction from engineering work: searching, tracing, moving boilerplate, adding tests, and making small verified changes.
They are not a replacement for architecture ownership. Do not let them take over permission boundaries, data models, release strategy, or business invariants before the constraints are clear.
The mature pattern is simple: let AI accelerate execution; keep humans responsible for judgment.