I use AI coding agents daily. They are useful tools. They are also tools that can cause significant damage if used carelessly. The difference between "the agent helped me ship a feature in an hour" and "the agent broke three things while fixing one" comes down to how you direct them.

This article describes the workflow I have developed through trial and error. It is not the only way to use AI agents, but it works for me on real projects with existing codebases.

The Problem with "Build This Feature"

The simplest way to use an AI agent is to describe what you want and let it build it. This works well for greenfield projects where there is no existing code to conflict with. It works poorly on existing codebases.

When you tell an agent "add a blog system," it might:

Create a new database schema that conflicts with the existing one
Use a different ORM or a different version of the same ORM
Invent a routing structure that does not match the existing conventions
Import libraries that are not in the project's dependencies
Generate code that passes the type checker but breaks at runtime because it misunderstands the data model

The agent does not know what it does not know. It fills gaps in its understanding with assumptions, and those assumptions are often wrong.

Read Before Write

The most important instruction I give an agent is: read the codebase before modifying anything. Specifically:

Find the framework, ORM, database, and deployment setup
Read the schema or data models for the entities being modified
Check existing services, routes, and components for conventions
Look for existing implementations that might already solve the problem
Identify the testing approach and run existing tests before making changes

This takes more time upfront. It saves much more time later.

AGENTS.md and Project Context

Some projects include an AGENTS.md file (or similar) that describes the project structure, conventions, and constraints. When this file exists, I tell the agent to read it first. When it does not exist, I include key context in my initial prompt.

The context does not need to be exhaustive. A few lines about the stack, the database, and the deployment setup give the agent enough to avoid the worst assumptions.

Minimum Viable Modification

When the agent proposes changing 15 files, I ask why. Often, the same result can be achieved by changing 3 files. Every file modified is a potential point of failure. The agent should change the minimum number of files necessary to achieve the goal.

I ask the agent to list the files it plans to modify before it starts. If the list is longer than expected, I ask it to explain each change. Sometimes the extra files are justified (a new feature that touches frontend, backend, and database). Sometimes they are not (the agent is re-implementing something that already exists).

Preserving Conventions

Every codebase has conventions: naming patterns, file organization, import styles, error handling approaches. An agent that does not respect these conventions produces code that works but feels alien in the project.

I ask the agent to mimic existing code style. If the project uses camelCase for variables, the agent should not introduce snake_case. If the project groups imports by type (external, internal, relative), the agent should follow the same pattern.

This is not about aesthetics. Inconsistent code is harder to maintain because it requires context-switching between conventions.

Plan Before Execution

For anything beyond a trivial change, I ask the agent to present a plan before implementing. The plan should include:

What files will be created or modified
What the changes accomplish
What the verification steps are

I review the plan and either approve it or ask for modifications. This is the "measure twice, cut once" principle applied to AI-assisted development.

Verification After Modification

After the agent makes changes, I verify them:

Typecheck: Does the code compile?
Lint: Does the code follow the project's style rules?
Tests: Do existing tests still pass?
Build: Does the production build succeed?
Manual check: Does the diff look reasonable?

If any of these fail, I ask the agent to fix the specific failure. I do not accept "it should work" as a response. Either it passes or it does not.

The Diff Review

The most revealing step is reading the actual diff. The agent's summary of what it did is useful but incomplete. The diff shows exactly what changed line by line.

I look for:

Unnecessary changes (modifying files that should not have been touched)
Over-engineered solutions (adding abstractions for a simple problem)
Hardcoded values that should be configurable
Missing error handling
Inconsistencies with the rest of the codebase

The agent cannot review its own work effectively. It tends to justify its choices rather than question them. The human review is the quality gate.

A Prompt Template

Here is a prompt structure that works well for me:

You have access to the full codebase. Before making any changes:

1. Read the project structure and identify the framework, ORM, and database.
2. Find the existing models/services related to [FEATURE].
3. Check if any part of [FEATURE] already exists.
4. Identify the conventions used in similar features.

Then:
5. Present a plan with the files you will modify.
6. Implement only those files.
7. Run typecheck, lint, and tests.
8. Report the results.

This prompt is not magic. It is just explicit about the steps that the agent might otherwise skip.

When the Agent Gets Confident and Wrong

The most dangerous moment is when the agent states something with confidence that is factually wrong. "The project uses PostgreSQL" when it uses SQLite. "The ORM is Sequelize" when it is Prisma. These incorrect assumptions cascade through the entire implementation.

I verify the agent's understanding by checking the claims against the actual code. If the agent says "the project uses X," I look for X in the configuration files. If it does not exist, I correct the agent before it builds on a false foundation.

The Limits of AI Agents

AI agents are good at:

Generating boilerplate and scaffolding
Implementing well-defined patterns
Finding and fixing syntax errors
Explaining existing code

They are less good at:

Understanding business logic and domain constraints
Making architectural decisions that consider long-term maintenance
Identifying edge cases in complex workflows
Knowing when not to add complexity

The agent is a tool, not a collaborator. It executes instructions well. It does not exercise judgment. The judgment remains yours.

What This Looks Like in Practice

When I needed to add an automatic seed system to my portfolio, I did not tell the agent "add a seed system." I told it to analyze the existing architecture, find the Prisma schema, check for existing seed scripts, and propose a plan. The agent found the existing restore-content.ts script, understood the data model, and proposed a solution that integrated with the Docker entrypoint without duplicating the existing functionality.

If I had just said "add a seed," it might have created a second seed system, changed the schema, or skipped the Docker integration entirely. The extra context took five minutes to provide. It saved hours of cleanup.

AI agents amplify your ability to write code. They also amplify your ability to write the wrong code. The workflow I describe here is not about distrust. It is about using a powerful tool with the appropriate level of oversight.