Claude Code Can Generate Full Source Code, But Who Reviews the Logic?

Introduction

Claude Code, ChatGPT, Cursor, Copilot, and other coding agents have changed how many engineers write software. A developer can now ask an agent to read a repository, create a new module, fix a bug, write tests, update documentation, and prepare a pull request across multiple files.

That is powerful.

But the more useful question is not, "Can an agent generate code?"

The better question is:

If a coding agent can generate full source code, who is reviewing the logic?

Syntax can be correct. The build can pass. Tests can be green. The code can look clean. But the business logic can still be wrong.

In backend systems, logic mistakes are often harder to notice than broken UI. A logic error can quietly affect transaction status, approval rules, user access, retry behavior, pricing, refund flows, message processing, or a query that looks harmless but changes the meaning of data.

This article is a practical guide for using Claude Code and similar coding agents without giving up engineering judgment. The goal is not to reject AI-assisted development. The goal is to build a review workflow where engineers stay responsible for intent, domain correctness, and production behavior.

TL;DR

• Coding agents can write code, but engineers must still review intent, logic, domain rules, and production impact.
• Do not review generated code only by checking whether the build is green.
• Ask the agent to explain assumptions, changed behavior, edge cases, and risks before implementation.
• Review in layers: requirements, domain logic, data integrity, security, tests, observability, and rollout.
• Treat a coding agent like a fast pair programmer, not the owner of production behavior.
• For backend systems, logic review matters more than generated code volume.

The Real Problem Is Not Code Generation

Coding agents are very useful for work that has a clear pattern:

• Creating boilerplate.
• Adding DTOs.
• Writing basic CRUD flows.
• Drafting unit tests.
• Renaming methods.
• Explaining unfamiliar modules.
• Summarizing logs.
• Updating documentation.
• Preparing a migration draft.

The risk appears when a task looks technically clear but is actually full of business rules.

For example:

Implement an endpoint to cancel an order.
Update the order status, return the correct response, and add tests.

That sounds simple. But the real logic may include many hidden questions:

• Which order statuses can be cancelled?
• What if the order has already been paid?
• What if shipment has already started?
• Should a refund be triggered?
• Should inventory be returned?
• Who can cancel the order: customer, admin, or system job?
• Should cancellation be idempotent?
• Is an audit log required?
• Should an event be published to another service?

A coding agent can infer some common patterns, but it does not automatically know your domain history, production incidents, compliance boundaries, internal agreements, or the reasoning behind older code.

That is why logic review must start with intent, not with the diff.

Review Generated Code with Better Questions

When reviewing code written by Claude Code or another agent, the first question should not be:

Does this code look clean?

A better question is:

Is this change correct for the business and safe for production?

Useful review questions include:

• What problem is this change actually solving?
• What assumptions did the agent make?
• Which business rules changed?
• Which data is being read or written?
• What state transitions are now possible?
• What happens when the input is invalid?
• What happens when a dependency times out?
• What happens if the same request is sent twice?
• Are authorization rules still correct?
• Do the tests prove behavior, or do they only increase coverage?

If these questions cannot be answered, the code is not ready to merge.

Mental Model: The Agent Drafts, the Engineer Decides

I like this mental model:

The agent accelerates drafting. The engineer owns judgment.

If that ownership flips, the risk increases. Generated code can look convincing while still being wrong for the domain.

A Practical Logic Review Checklist

Use this checklist before merging AI-generated code.

1. Requirement Check

Make sure the code solves the right problem.

• Is the problem statement clear?
• Did the agent add behavior outside the requested scope?
• Did unrelated files change?
• Was a new dependency added?
• Do method names and class names match the language of the domain?

Red flags:

• The agent creates a new abstraction for a small change.
• The agent edits many files without explaining why.
• The agent mixes lint cleanup with logic changes.
• The agent creates a generic helper with no clear use case.

2. Domain Logic Check

This is the most important layer.

• Are status transitions valid?
• Are approval rules correct?
• Are calculations correct?
• Are roles and permissions applied correctly?
• Does the behavior match the existing business process?
• Are edge cases covered?

Backend logic can compile successfully while being wrong. Review the flow like a user story, not only like source code.

3. Data Integrity Check

Ask:

• Which tables are changed?
• Which fields are updated?
• Is the update atomic?
• Is there a race condition?
• Is the transaction boundary correct?
• Can the query update data it should not touch?
• Is the migration backward-compatible?

Example:

order.setStatus(OrderStatus.CANCELLED);
orderRepository.save(order);

This code is simple, but it does not answer:

• What was the previous status?
• Was the order already paid?
• Is a refund needed?
• Is audit logging required?
• Should repeated cancellation be safe?

Generated code is often correct in shape but incomplete in state handling.

4. Security Check

Minimum review:

• Is input validated?
• Is authorization checked at the right boundary?
• Are sensitive values kept out of logs?
• Are queries parameterized?
• Are external URLs guarded before fetch?
• Is file upload safe?
• Do error responses avoid leaking internal details?

Security is not only "does this endpoint require authentication?" Security means the user can only perform actions they are allowed to perform, using data they are allowed to see and modify.

5. Test Quality Check

Do not be satisfied with tests that only make coverage higher.

Good tests prove behavior.

For every meaningful logic change, check:

• Happy path.
• Invalid input.
• Forbidden action.
• State that must not change.
• Idempotency when the endpoint can be retried.
• Dependency failure.

Weak assertion:

assertNotNull(response);

Stronger assertion:

assertEquals(OrderStatus.CANCELLED, order.getStatus());
assertEquals("ORDER_CANCELLED", auditLog.getAction());
assertEquals(previousAmount, refundRequest.getAmount());

The agent can create a test skeleton. The engineer must make sure the assertions prove the right behavior.

6. Observability Check

For production backend systems, correct code that cannot be observed is still hard to operate.

Check:

• Are important failures logged with useful context?
• Are key metrics available?
• Is the correlation ID preserved?
• Can retry and failure paths be traced?
• Are important events auditable?

If the agent adds async processing, queue consumers, schedulers, or integration calls, observability deserves extra attention.

Safer Prompts for Claude Code

Avoid starting with:

Build the cancel order feature.

Start with:

Read the current order module first.
Before editing files, explain:
1. Existing status flow
2. Files that need to change
3. Assumptions you are making
4. Edge cases to test
5. Risks in data consistency and authorization
 
Do not implement yet.

After the plan makes sense:

Implement the smallest change based on the approved plan.
Do not introduce new dependencies.
Do not refactor unrelated files.
Add tests for happy path, invalid status, unauthorized user, and idempotent retry.
After editing, summarize the diff and list remaining risks.

This workflow forces the agent to reason before editing.

Add Project Rules Before You Ask for Code

One practical improvement is to keep project rules close to the repository. Claude Code supports persistent project instructions through files such as CLAUDE.md, and the official docs recommend using project-level instructions for coding standards, architecture decisions, preferred libraries, and repeatable workflows.

That matters because many review problems are not caused by the agent being unable to write code. They happen because the agent does not know the team contract.

A useful project instruction file can include:

• Build and test commands.
• Naming conventions.
• Package/module boundaries.
• Approved libraries.
• Forbidden patterns.
• Security rules.
• Logging standards.
• Database migration rules.
• Review checklist.
• Rollback expectations.

Example:

# Project Rules
 
## Engineering boundaries
 
- Do not introduce new dependencies without explaining why.
- Do not refactor unrelated files during feature work.
- Keep controller logic thin; put business rules in the service layer.
- Use existing exception and response patterns.
- Preserve backward compatibility for public API responses.
 
## Database rules
 
- Do not create destructive migrations without a rollback plan.
- Keep migrations backward-compatible during rolling deploys.
- Explain any change that affects indexes, constraints, or high-traffic queries.
 
## Review expectations
 
- List assumptions before implementation.
- Add tests for happy path, invalid state, unauthorized access, and dependency failure.
- Summarize production risks after editing.

This does not remove the need for human review, but it improves the starting point. The agent is less likely to invent patterns when the repository already tells it how the team works.

Do Not Trust the Summary Alone

Coding agents often provide a summary like:

Implemented cancel order feature with validation and tests.

That summary is useful, but it is not a review.

The engineer still needs to inspect the diff:

• Which files changed?
• Are there unrelated changes?
• Did existing behavior change?
• Do tests assert real behavior?
• Did config, environment, or permissions change?
• Are the abstractions necessary?

My usual review order:

1. Read the requirement.
2. Read the tests first.
3. Read the domain service.
4. Read the controller or API boundary.
5. Read repository, query, and migration changes.
6. Read configuration changes.
7. Read the agent summary last.

Tests first matter because tests reveal what the change claims to make true. If the tests are weak, clean implementation is not enough.

A Review Rubric for Pull Requests Written with Claude Code

For AI-assisted pull requests, I like using a simple scoring rubric. It prevents review from becoming subjective and makes expectations clear.

If a pull request is weak in two or more dimensions, I would not merge it yet. Either tighten the scope, improve the tests, or ask the agent to produce a risk-focused revision.

The Three Review Modes I Use

Not every AI-assisted change deserves the same review depth. I usually separate work into three review modes.

Mode 1: Mechanical Change

Examples:

• Rename a method.
• Update formatting.
• Replace a deprecated API with an equivalent API.
• Add missing tests for existing behavior.

Review focus:

• Did behavior stay the same?
• Did the agent touch unrelated files?
• Do tests still pass?

Mode 2: Product Logic Change

Examples:

• Add a new endpoint.
• Change a state transition.
• Add a new validation rule.
• Modify a checkout, approval, or cancellation flow.

Review focus:

• Are business rules correct?
• Are edge cases tested?
• Is authorization correct?
• Is the data state safe?

This is where most teams should slow down.

Mode 3: Production Risk Change

Examples:

• Database migration.
• Queue consumer change.
• Retry mechanism.
• Cache invalidation.
• Payment or billing flow.
• Authentication or authorization change.
• Infrastructure or deployment config.

Review focus:

• Is there a rollback plan?
• Can the change be deployed gradually?
• What metrics confirm success?
• What alerts might fire?
• What is the blast radius if the logic is wrong?

Claude Code can help draft all three modes, but the review depth should increase as production risk increases.

Example: Reviewing Cancellation Logic

Suppose an agent generates:

public Order cancelOrder(String orderId) {
    Order order = orderRepository.findById(orderId)
        .orElseThrow(() -> new OrderNotFoundException(orderId));
 
    order.setStatus(OrderStatus.CANCELLED);
    return orderRepository.save(order);
}

The code compiles. It may even pass a basic test. But the domain review is incomplete.

Questions:

• Can a SHIPPED order be cancelled?
• Does a PAID order require refund?
• Is cancellation idempotent?
• Is the current user allowed to cancel this order?
• Is an audit log required?
• Should an ORDER_CANCELLED event be published?

A more domain-aware version might look like:

public Order cancelOrder(String orderId, UserContext user) {
    Order order = orderRepository.findByIdForUpdate(orderId)
        .orElseThrow(() -> new OrderNotFoundException(orderId));
 
    authorizationService.ensureCanCancel(user, order);
 
    if (order.isAlreadyCancelled()) {
        return order;
    }
 
    if (!order.canBeCancelled()) {
        throw new InvalidOrderStateException(order.getStatus());
    }
 
    order.cancelledBy(user.id());
    orderRepository.save(order);
 
    auditService.recordOrderCancelled(order, user);
    eventPublisher.publish(new OrderCancelledEvent(order.getId()));
 
    return order;
}

Not every system needs this exact shape. The point is that logic review checks business invariants, not only Java syntax.

Common Mistakes When Using Coding Agents

1. Treating a Green Build as Proof of Safety

A green build proves the code compiles and the existing tests pass. It does not prove the logic is correct.

2. Letting the Agent Refactor Too Much

Large refactors make logic review harder. For production work, ask for small and focused changes.

3. Ignoring Agent-Written Tests

Generated tests can look impressive while asserting very little.

4. Not Asking for Assumptions

Agents make assumptions silently. Ask for assumptions before implementation.

5. Mixing Feature Work, Refactoring, and Cleanup

Separate them. Feature review should focus on behavior. Refactor review should focus on equivalence. Cleanup review should focus on maintainability.

6. Forgetting Rollback

If the change touches database state, queues, integrations, or configuration, think about rollback before merge.

A Workflow I Recommend

For small tasks:

1. Describe the problem.
2. Ask the agent to read context.
3. Ask for a plan before editing.
4. Approve the plan.
5. Request the smallest implementation.
6. Review the diff.
7. Run tests.
8. Ask the agent to list remaining risks.
9. Merge only when the engineer is convinced.

For larger tasks:

1. Start with a design note.
2. Review the design note.
3. Split the work into small pull requests.
4. Use the agent for each small pull request.
5. Require human review for logic and rollout.

If a task cannot be explained clearly, do not ask the agent to implement it yet. Ask it to help create a technical design, flow, ERD, or checklist first. I wrote more about that workflow in How I Use ChatGPT for TSDs, ERDs, and Database Documentation.

A Reusable Prompt Template for Logic Review

Use this when Claude Code has already produced a diff and you want a second pass focused on correctness:

Review the current diff as a senior software engineer.
 
Focus only on:
1. Business logic correctness
2. Data integrity
3. Authorization and validation
4. Test quality
5. Production risk
 
For each issue, explain:
- Why it matters
- The affected file/function
- The specific edge case
- A safer alternative
 
Do not rewrite the code yet.
Do not comment on formatting unless it affects correctness.

Then ask for a fix only after you agree with the findings:

Apply only the approved fixes.
Keep the diff small.
Do not introduce new abstractions.
After editing, list exactly what changed and which tests prove the behavior.

This separates diagnosis from implementation. It prevents the agent from solving problems you did not approve.

Pre-Merge Checklist for AI-Generated Code

If any area is unclear, do not merge yet.

Where Claude Code Helps the Most

Claude Code and similar agents are very useful for:

• Reading unfamiliar codebases.
• Drafting test cases.
• Finding relevant files.
• Explaining module dependencies.
• Performing small refactors.
• Drafting technical documentation.
• Converting data formats.
• Preparing migration plans.
• Writing repetitive boilerplate.

These tools save energy on mechanical work. The saved energy should move into logic review, not into merging faster without reading.

Where to Be More Careful

Be extra careful when the task touches:

• Payment.
• Authorization.
• Authentication.
• Database migration.
• Data deletion.
• Background jobs.
• Queue consumers.
• Retry mechanisms.
• Cache invalidation.
• Feature flags.
• External integrations.
• Production configuration.

These areas often carry risks that are not obvious from a small diff.

FAQ

Can AI-generated code be merged if tests pass?

Not automatically. Passing tests are useful, but engineers still need to review logic, domain rules, security, and production impact.

Is Claude Code suitable for backend projects?

Yes. It is useful for reading code, drafting implementations, writing tests, and explaining flows. But backend work needs stricter review because it touches data, state, and integrations.

How do I stop an agent from changing too many files?

Set a narrow scope. Ask the agent to explain which files it plans to change before editing. Reject unrelated changes.

What is the most dangerous part of AI-generated code?

The most dangerous code is code that looks correct, passes the build, and is still wrong for the business logic.

Can coding agents replace code reviewers?

Not yet. They can help explain diffs, spot issues, and draft checklists, but review ownership still belongs to engineers.

Conclusion

Claude Code can generate source code quickly. That is not the problem. It is a powerful advantage when used with discipline.

The problem starts when teams forget that source code is only the visible form of a logic decision. The agent can write the form. The engineer must decide whether the logic is correct.

So the important question is no longer:

Can Claude Code generate full source code?

The better question is:

Do we have a review workflow strong enough to validate the logic before that code reaches production?

If the answer is yes, coding agents can become excellent engineering partners. If the answer is no, they may only help teams ship cleaner-looking bugs faster.

FAQ Schema

{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [
    {
      "@type": "Question",
      "name": "Can AI-generated code be merged if tests pass?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "Not automatically. Passing tests are useful, but engineers still need to review logic, domain rules, security, data integrity, and production impact before merging."
      }
    },
    {
      "@type": "Question",
      "name": "Is Claude Code suitable for backend projects?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "Yes. Claude Code is useful for reading code, drafting implementations, writing tests, and explaining flows. Backend work still needs stricter review because it touches data, state, permissions, and integrations."
      }
    },
    {
      "@type": "Question",
      "name": "How do I stop a coding agent from changing too many files?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "Set a narrow scope, ask for a plan before editing, require the agent to list files it intends to change, and reject unrelated refactors in feature pull requests."
      }
    },
    {
      "@type": "Question",
      "name": "What is the most dangerous part of AI-generated code?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "The most dangerous code is code that looks correct, passes the build, and is still wrong for the business logic or production constraints."
      }
    },
    {
      "@type": "Question",
      "name": "Can coding agents replace code reviewers?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "Not yet. Coding agents can help explain diffs, spot issues, and draft review checklists, but final review ownership should remain with engineers."
      }
    }
  ]
}