General-Purpose Agentic Coding Agents: From Writing Code to Automated Execution

    This article examines how general-purpose agentic coding agents move beyond local code completion to goal-driven execution. It covers suitable and unsuitable task types, the layered agent architecture, reusable project convention files, permission and safety controls, cloud deployment patterns, practical scenarios, evaluation metrics, common anti-patterns, and an adoption roadmap.

    I. Reframing the Problem: From Code Completion to Goal Completion

    Over the past few years, the dominant form of coding assistance has been local prediction: the cursor is placed somewhere, and the model guesses the next line. These tools reduce keystrokes, but they do not understand the goal and do not verify the result.

    More recently, general-purpose agentic coding agents have introduced a different paradigm. The user describes a goal, and the agent reads the context, breaks the task into steps, calls tools to act, and uses execution results to determine whether the goal has been achieved.

    The shift can be summarized in three ways:

    • From syntax-level assistance to intent-level assistance: the input is no longer just a function signature, but “what business outcome do I need?”
    • From suggestions to execution: the output is not merely text; changes are written to the file system, executed, and tested.
    • From one-shot output to a closed loop: the agent can iterate through execution, observation, and correction rather than producing a single final answer.

    Because of this, the applicability of these tools goes far beyond programming. Any computer task that has a clear goal, a verifiable result, and requires moving between files and commands can be handled: organizing batch spreadsheets, generating static pages, cleaning logs, batch-renaming and archiving files, combining audio and image assets into video, or extracting conclusions from raw data into documentation.

    The key judgment is simple: can the result be automatically verified? For verifiable tasks, the agent can converge autonomously. For unverifiable tasks, such as “help me decide whether this business decision is right,” the agent can only provide a draft, and responsibility remains with the human.

    II. Capability Boundaries: What to Delegate and What Not to Delegate

    Tasks Suitable for an Agent

    Task Type Typical Form Source of Verifiability
    Code changes Fix defects, add tests, refactor Compilation passes, unit tests pass
    Data processing Splitting payroll statements, reconciliation, normalization Row counts remain consistent, totals match
    Documentation and content Generate API documentation, write pages, revise copy Structural validation, manual spot checks
    Operations and troubleshooting Locate errors, clean up residual files Command exit codes, service health checks
    Multimedia composition Combine images and audio into video, batch transcoding Output is playable, duration and specifications match

    Tasks Not Suitable for Direct Delegation

    • High-risk irreversible operations: deleting production data, changing permission systems, or making external releases.
    • Tasks without verification mechanisms: large-scale refactoring in a legacy system that has no tests.
    • Compliance and privacy judgments: data transfer or masking policies that require human confirmation.
    • Unclear requirements: if the goal is ambiguous, the agent fills the gap with seemingly reasonable guesses, amplifying errors.

    III. Architectural View: How an Agent Solves a Problem

    Using an agent as a black box often produces unstable results. To apply it effectively, it helps to understand its layered structure.

    1. Perception Layer: Context

    The ceiling of an agent’s capability is largely determined by the context it can see. Typical sources include the current working directory and file tree, explicitly referenced files, standard output and error streams from commands, and version-control diffs.

    What it cannot see effectively does not exist. This explains why clearly specifying important file paths usually improves success more than writing an elaborate requirement description.

    2. Planning Layer: Plan

    Mature implementations usually use a plan-then-execute approach: first produce a reviewable task list, then execute step by step. The value of this step is not that the model is smarter, but that it gives humans a low-cost intervention point. Correcting a plan is much cheaper than reworking a final result.

    3. Execution Layer: Tool Use

    Agents act on the environment through a controlled toolset: reading and writing files, executing shell commands, searching code, and accessing the network. The design of the toolset directly determines security and safety.

    4. Verification Layer: Verification

    This is the dividing line between a toy and a productivity tool. A reliable agent actively constructs verification: running tests, running lint, compiling code, or replaying input and output with minimal examples. Without verification, an agent is essentially an advanced random-output generator.

    5. Context Governance: Memory and Compaction

    In long-running tasks, context overflow is inevitable. Common engineering strategies include:

    • Summarization and compaction: folding completed steps into conclusions.
    • External memory: writing intermediate artifacts to files and reading them back when needed.
    • Retrieval-based recall: loading relevant code snippets on demand.

    A practical recommendation is to write intermediate results to files instead of leaving them in the conversation. This saves context and makes the process auditable.

    IV. Turning One-Time Success into Repeatable Success with Convention Files

    Ad hoc conversations are difficult to reuse. A common practice is to place a project-level agent convention file in the repository root and turn project knowledge into a version-controlled asset.

    The file can include the technology stack and versions, directory structure and meaning, build and test commands, forbidden paths, and code style and commit conventions.

    Example structure:

    1. project/
    2. ├── AGENTS.md # Agent convention file: build, test, and forbidden actions
    3. ├── scripts/
    4. │ ├── verify.sh # One-command verification entry
    5. │ └── dev-up.sh # One-command development environment startup
    6. ├── src/
    7. └── tests/

    Example contents of AGENTS.md:

    1. # Project Conventions
    2. ## Technology Stack
    3. - Runtime: Node.js 20 LTS
    4. - Test framework: built-in test runner
    5. ## Required Commands
    6. - Install dependencies: `npm ci`
    7. - Full verification: `bash scripts/verify.sh` (lint + unit tests + build; all must pass)
    8. ## Hard Constraints
    9. - Do not modify any files under `src/legacy/`
    10. - Database changes must be written as migration scripts; direct changes to the production database are not allowed
    11. - Do not hardcode any secrets in code or configuration; read all secrets from environment variables
    12. ## Delivery Requirements
    13. - Every change must include or update the corresponding test cases
    14. - Run `scripts/verify.sh` locally before committing

    A companion verify.sh turns “is it done?” into an executable command:

    1. #!/usr/bin/env bash
    2. set -euo pipefail
    3. npm ci --silent
    4. npm run lint
    5. npm test
    6. npm run build
    7. echo "verify: OK"

    These two files create a structural change: goals, constraints, and acceptance criteria move from verbal descriptions in a conversation into machine-readable contracts in the repository. Onboarding costs drop significantly for both new human contributors and agents.

    V. Permissions and Security: Non-Negotiable Engineering Constraints

    An agent that can execute shell commands is effectively granted partial control of a machine. Security design must be built in from the beginning, not patched afterward.

    1. Least Privilege and Default Deny

    • Tool whitelist: explicitly allow read-only commands such as ls, cat, grep, git status, and git diff; separately authorize write operations and network operations.
    • Path boundaries: restrict writable directories and prevent access outside the project root.
    • Dangerous command blacklist: recursive deletion, disk writes, permission changes, and global package-manager installations.

    Example whitelist configuration:

    1. {
    2. "permissions": {
    3. "allow": ["Read", "Grep", "Bash(git status:*)", "Bash(git diff:*)", "Bash(npm test:*)"],
    4. "deny": ["Bash(rm -rf:*)", "Bash(sudo:*)", "Write(./.env)", "Write(./.git/*)"],
    5. "confirm": ["Bash(git push:*)", "Write(./src/legacy/*)"]
    6. }
    7. }

    2. Isolation and Sandboxing

    High-risk tasks should run in containers or ephemeral virtual machines, with only the necessary code directory mounted, no production network access, and automatic destruction after the task completes. Containerization also helps ensure dependency consistency.

    3. Credential Management

    Agents often need access to model services, code hosting, and cloud resources. The correct approach is to use short-lived tokens, environment-variable injection, and least-privilege roles, while preventing tokens from appearing in logs, command-line arguments, or commit history. Any credential printed to the terminal should be treated as leaked and rotated immediately.

    4. Auditability and Rollback

    • All changes must go through version control, and direct execution on the main branch should be prohibited; use branches and review before merging.
    • Keep complete operation logs and diffs for later tracing.
    • Create snapshots or backups before destructive operations.

    5. Human Confirmation Points

    Mandatory confirmation should be required before three types of actions: deleting or overwriting existing files, making outbound network requests such as commits, releases, or sending email, and modifying permissions or configuration. These three checkpoints cover most incident scenarios.

    VI. Cloud Deployment: A Reusable Reference Chain

    When an agent moves from an individual tool to team and business systems, it needs supporting engineering infrastructure. The following describes generic capability categories rather than a specific product choice.

    • Container platform: host stateless agent runtimes, scale on demand, and reclaim resources after tasks finish; this naturally supports isolation requirements.
    • Object storage: store uploaded assets, generated artifacts such as reports, videos, and build outputs, and intermediate results instead of stuffing everything into context.
    • Message queue: decouple long-running tasks, turn synchronous requests into asynchronous jobs, and support batching and retries.
    • Logging service: centrally collect session logs, command output, and diffs for auditing and troubleshooting.
    • Monitoring and alerting: track task success rates, average latency, and resource consumption per task, and alert when failure rates spike.
    • Secret management and access control: issue short-lived credentials centrally and assign roles by least privilege to prevent credential sprawl.
    • Model service gateway: provide unified access, quota management, and cost allocation to avoid duplicated builds and uncontrolled usage.

    On Baidu AI Cloud, for example, this chain can be mapped to generic capability categories such as object storage, message queuing, container platforms, logging services, and monitoring/alerting. The architecture principles are vendor-independent: isolated execution environments, artifact storage outside the agent context, asynchronous long-running tasks, and end-to-end observability.

    VII. Practical Guidelines for Five Typical Scenarios

    1. Code Questioning and Troubleshooting

    The most effective way to ask is not to paste an error message, but to let the agent inspect the system itself: provide the repository path, reproduction command, and expected result. After reading logs, configuration, and code, the agent’s diagnosis is usually better than guesses based on snippets.

    1. # Ask the agent to reproduce and locate the failure on its own
    2. Please run `npm test -- tests/user.spec.ts` to reproduce the failure,
    3. identify the root cause, and propose a fix without changing the code yet.

    2. Structured Writing and Documentation Generation

    First produce an outline, confirm it manually, and then expand it. Asking an agent to extract information from code and generate API documentation is much more accurate than asking it to write documentation from scratch.

    3. Web and Frontend Implementation

    Provide design drafts, reference site structure, and acceptance criteria such as responsive breakpoints and accessibility requirements. Ask the agent to start a local service, self-check, and then deliver.

    4. Data Analysis and Report Splitting

    For batch tasks such as splitting payroll statements, the key is to specify invariants: the number of output rows should match the original table, the total amounts should equal the original total, and tax and net pay should satisfy the existing formulas. Ask the agent to write a script rather than perform manual operations, and output a verification report:

    1. Input records: 1,024
    2. Output files: 1,024
    3. Gross total: 8,192,300.00 Total after split: 8,192,300.00 Difference: 0.00
    4. Validation result: PASS

    5. Multimedia Asset Composition

    Combining image sequences and audio tracks into video is a typical command-assembly and parameter-checking task. Specify constraints such as resolution, frame rate, encoding format, and duration alignment, and ask the agent to probe the output parameters after generation to confirm they match expectations. These tasks are computationally heavy and are best executed asynchronously through a message queue, with outputs written to object storage.

    VIII. Measuring Effectiveness: Use Metrics Instead of Feelings

    After introducing an agent, use data to determine whether it actually improves efficiency. At minimum, track the following four metrics:

    • First-pass rate: the proportion of changes that pass verification without manual modification.
    • Average number of interventions: the number of corrections a human must make per task.
    • Cost per task: time and resources consumed, including model usage.
    • Rework rate: the proportion of deliverables rejected in review or causing regression defects after delivery.

    A practical goal curve is that the first-pass rate rises as convention files and test coverage improve, while the average number of interventions declines. If metrics remain flat for a long time, the problem is usually not the model but the absence of executable acceptance criteria in the project.

    IX. Common Anti-Patterns

    1. Letting an agent make large changes in a repository without tests: without verification signals, errors are silently amplified. Add a minimal test set before attempting automation.
    2. Giving a large task in one sentence: excessive scope causes context drift. Break it into independently verifiable small steps and merge them incrementally.
    3. Putting secrets in configuration files or environment examples: the agent can read them, and logs may also capture them. Use a secret management service and short-lived credentials.
    4. Allowing direct commits to the main branch: this destroys rollback capability. Branching plus review is the baseline.
    5. Changing tools without changing process: the value of an agent comes from shortening the closed loop of requirement, implementation, and verification. If acceptance still relies on repeated manual back-and-forth, the benefit is offset.
    6. Launching without observability: without logs and metrics, it is impossible to determine whether failures are caused by prompts, context, or the environment.

    X. Adoption Roadmap

    Phase 1: Read-Only Observation

    Grant only read and search permissions. Let the agent perform code understanding, log analysis, and draft documentation to build trust.

    Phase 2: Controlled Writing

    Allow branch-level writes and local verification, integrate verification scripts such as verify.sh, and route all changes through review.

    Phase 3: Process Integration

    Include convention files, permission whitelists, logging, and monitoring in standard engineering templates, and promote them across teams.

    Phase 4: Platformization and Asynchronization

    Containerize execution, move long-running tasks into queues, and store artifacts in object storage to form an internal capability that is reusable, measurable, and auditable.

    Conclusion

    The value of general-purpose agentic coding agents is not to replace programmers by writing code for them, but to free people from mechanical back-and-forth so they can focus on judgment and decision-making.

    Their capability ceiling is determined by three things: the completeness of context, the clarity of acceptance criteria, and the strictness of permission boundaries.

    Do these three things well, and agents become one of the most efficient links in a team. Ignore any one of them, and they become one of the highest-risk entry points.