Amp is a programming agent and development environment described by its own team as focused on coding tasks. The documentation presents interfaces for web, apps and terminal, plus sessions that can run in local environments or remote machines called orbs. Current features are detailed in the official Amp documentation.
How it works
A person starts a work conversation, states the objective and provides access to the project code. The agent can inspect files, run commands and tests and propose changes. The flow is organized in threads, which keep the task context and allow the interaction to continue.
The documentation describes different execution modes. A session can run on the local machine or in an orb, a remote environment created for a thread, with the project and necessary tools. The terminal interface can also be used in interactive flows or scripts. Integrations and available models can change, so consult the current documentation before adopting a specific way of working.
Like any agent with tool access, Amp can change files or execute commands. The documentation advises considering policies and isolated environments when the repository or connected servers are not trustworthy. The team should review permissions, check changes and run tests before incorporating the result.
Practical example
A developer wants to fix an error reproduced by a test. She describes the expected behavior, points to the project and asks the agent to investigate the failure, propose a fix and run the related test. At the end, she reviews the diff, checks if other files were changed and runs the appropriate suite.
If the team prefers not to run commands locally, it can evaluate remote execution in an orb, according to the current documentation options. If it needs to automate a bounded task, it can explore the command line interface, first in a test repository and with controlled permissions.
A good request defines the outcome and validation criteria. Instead of saying just "improve the project", describe the error, the relevant files and which tests should keep passing. The agent can still misinterpret the task, so human review remains part of the process.
What it's for
Amp serves to support software development, such as investigating bugs, changing code, searching a repository and running tests. The possibility to work in different interfaces and environments helps integrate the agent into a person or team's flow, as long as access controls are adequate.
Before using it on an important project, check how the tool accesses the repository, which commands it can execute and how sessions are stored. Test a small job, evaluate quality and observe if it is easy to recover or discard changes. Avoid exposing secrets or granting broad access without need.
Amp does not replace code review, tests or architecture decisions. Treat the result as an automated contribution: inspect the diff, run validations and confirm that behavior meets requirements. Record project instructions and maintain a recovery strategy in case an execution modifies something unexpected.
Difference between code agent and autocomplete
Autocomplete suggests snippets while a person writes. A code agent can receive a broader task, explore multiple files and execute tools to propose changes. The level of autonomy depends on execution mode, permissions and controls defined by the team.