AI Coding Agents: From First Prompt to Pull Request

An AI coding agent turns a request into proposed code changes by inspecting a repository, planning and carrying out edits, and running available checks. From the first prompt to a pull request, it works inside a cycle of tool use and feedback; a person still needs to review the result, decide whether it is correct, and approve or revise it.

What makes an agent different from code completion?

Code completion typically suggests what to type next in a file. An agent can pursue a larger task across multiple steps: it may search files, read project instructions, edit several files, run tests, inspect errors, and make further changes. The exact abilities depend on the product, its permissions, and the tools connected to it.

An agent is not an independent developer with reliable understanding of every project. It generates and evaluates actions using the information it can access. It may misread requirements, overlook an important file, or produce code that appears plausible but is wrong. “Agent” describes a more iterative way of using a model, not a guarantee of autonomy or correctness.

1. The first prompt establishes the task

The process starts when someone describes a desired change, such as: “Add a CSV export button to the reports page, preserve the current filters, and add a test for the export.” A useful request states the outcome and relevant constraints. If the repository has conventions, naming rules, or a preferred test command, mentioning them can help—but an agent may also find written guidance in the project.

The system turns the request and available context into instructions for the model. Depending on the setup, context can include selected files, repository content, prior conversation, and tool descriptions. There are practical limits to how much information the model can consider at once, so it may need to search for relevant code rather than receiving the entire project in one go.

Ambiguity matters. “Make reports better” leaves choices about behavior and design; “add a CSV export for the currently filtered rows” is more testable. For consequential or unclear changes, a person may need to answer follow-up questions before implementation begins.

2. It explores the repository and plans

Before editing, a capable coding agent often uses tools to understand the project. It might list files, search for the reports page, inspect nearby components, read package or build configuration, and look for instructions such as contribution notes. The goal is to discover how the existing code is organized and which conventions apply.

It may then form a short plan: locate the page and data source, add an export action, preserve active filters, write or update a test, and run relevant checks. Some systems show this plan; others proceed with less visible intermediate reasoning. A plan is a working aid, not proof the agent has understood every dependency.

Good repository exploration reduces the risk of implementing a feature in the wrong layer. For example, an application may centralize report filtering in a shared function. Building a separate filter in the export button could make the downloaded file disagree with the rows on screen.

3. It edits code through tools

Once it has enough context, the agent proposes and applies changes using the tools it is allowed to use. These may include reading and writing files, applying patches, running shell commands, or interacting with an editor. It can alter one file or many; a change might include application code, tests, documentation, or configuration.

Each action is bounded by the environment’s permissions. A tool may allow edits only in a workspace, require approval before running a command, or prevent access to the network. Other setups grant broader access. These controls shape what the agent can actually do and are separate from the model’s ability to suggest an action.

For the CSV example, an implementation might reuse the table’s filtered data, convert it into rows and columns, and trigger a file download. It should also account for details such as quoting commas and line breaks in values. Whether it does so correctly depends on the request, codebase, and verification that follows.

4. Tests and feedback drive another cycle

After editing, an agent may run targeted tests, a type checker, a linter, or a build command. These checks produce concrete feedback: a test failure, a missing import, or a type mismatch. The agent can inspect that output, revise its changes, and run checks again. This loop—act, observe, adjust—is central to agent-style coding.

Passing checks is useful evidence, but it does not establish that the feature meets the user’s intent. A test suite may not cover a new edge case; a build cannot tell whether a button is confusing; and a test can pass while the implementation changes behavior incorrectly. Conversely, a failing check may be unrelated to the agent’s edits, particularly in a project with existing failures or environment-specific requirements.

Review the actual diff, not just the agent’s summary. Check what files changed, whether unrelated edits slipped in, whether tests cover the requested behavior, and whether the code handles expected inputs. If the agent cannot run a check, its report should make that limitation clear rather than implying the work is verified.

5. From local changes to a pull request

When the work is ready, the agent or the person using it can prepare a pull request. In a typical workflow, changes are committed on a separate branch and submitted for review against a target branch. A pull request describes the proposed change and gives collaborators a place to inspect the diff, discuss it, and see automated checks.

Some tools can create a branch, commit changes, and open a pull request; others stop after modifying files or provide a patch for a person to apply. Creating the pull request is a handoff, not final approval. Reviewers may request changes, and automated repository checks may still run after submission.

A clear pull request description should explain the behavior changed, relevant design choices, tests run, and any checks that were not run. The human author remains responsible for ensuring the description matches the diff and for responding to review feedback.

Common failure points and practical safeguards

Agents can fail at different stages: they can misunderstand the prompt, miss project guidance, edit the wrong code path, make assumptions about dependencies, or misinterpret test output. They may also produce a broad rewrite when a small change would be safer. Long tasks are especially prone to losing important constraints unless those constraints remain explicit and verifiable.

• Make the request observable: describe expected behavior and, where useful, an example of input and output.
• Set boundaries: identify files or behaviors that should not change and ask for a focused diff.
• Use checks that match the change: run relevant tests and inspect failures rather than relying on a generic “done” message.
• Review sensitive operations: carefully inspect changes involving permissions, data handling, authentication, or external commands.
• Limit permissions appropriately: avoid granting tools access they do not need, and approve consequential actions deliberately.

Generated code should be treated like any other proposed code. It may contain bugs, insecure patterns, licensing concerns, or dependencies that a project would not otherwise accept. A human review and the project’s normal engineering process remain important, especially when changes affect users or production systems.

Frequently Asked Questions

Does an AI coding agent write and submit code without a person?
It can do so in some configurations, but its permissions and workflow determine what actions it can take. Even when it opens a pull request automatically, people still need to assess the changes and decide whether to merge them.

Can an agent understand an entire codebase?
It can search and inspect repository files, but it may not consider every file or dependency. Its effective understanding is limited by the context it receives, the tools available, and the quality of its exploration.

Why can tests pass while an AI-generated change is still wrong?
Tests only check the cases they cover. They may not reflect the requested behavior, include important edge cases, or catch a poor user experience. Reviewing requirements and the diff is still necessary.

Is a pull request from an agent ready to merge?
Not automatically. A pull request is a proposed change. Reviewers should verify the behavior, examine the code and test results, and follow the repository’s usual approval and release process.

What should I include in the first prompt?
State the desired outcome, relevant constraints, and how success can be checked. Include examples or project-specific requirements when they affect the implementation, and clarify ambiguous choices before asking the agent to make them.

Related

• Convolutional Neural Networks: How They Work
• Why Won’t Videos Play on Your Phone?
• How to Reload Old Log Files Into ELK