From Hoarding Resources to Engineering Implementation

Lately, “complete practical collections” of AI coding tools and agents have been circulating widely in developer communities. Some are lists of coding tricks; others promise that you’ll “master everything once you have it.” But turning a list of tools into real engineering productivity requires a whole methodology: how to organize context, how to verify output, how to orchestrate workflows, and how to control boundaries.

This article is not about any single product. Instead, it takes a general perspective and systematically lays out how to put AI coding agents into practice, covering five areas: individual developer and product manager practices, enterprise-grade engineering governance, and quantifiable productivity evaluation.

A helpful way to understand the landscape is a three-tier progression: completion → conversation → autonomy:

• Completion tier: The model suggests the next snippet of code based on the current code context. The core concerns are latency and accuracy.
• Conversation tier: By describing requirements in natural language and pasting error messages, you have the model explain code, locate defects, and suggest fixes.
• Autonomy tier: The model, in agent form, connects to tools and an execution environment and autonomously completes multi-step tasks—reading code, editing code, running tests, and fixing errors. This is what people commonly call AI coding.

Compared with “generation,” the hard part of “implementation” is repeatability, verifiability, and controllability. Setting clear goals matters more than collecting resources.

Capability Tiering: First Decide What to Trust an Agent With

In practice, most inefficiency comes from a mismatch between task and capability: handing an entire task that should have human oversight to an agent, or repeatedly doing manual work at a step that could be automated. Borrowing from the tiering used in autonomous driving, we can classify how agents work into four levels based on task autonomy. The judging criterion is not “who wrote more code,” but rather how many steps the agent can be trusted and reviewed on:

Level	Working mode	How humans participate	Typical scenario
L0 assisted completion	Generates code snippets from context	Adopts segment by segment	Boilerplate code, common patterns
L1 human-AI collaboration	Understands, modifies, and debugs in conversation	Confirms throughout	Defect localization, unit test writing, script development
L2 supervised execution	Autonomously completes multi-step tasks under constraints	Reviews results	Modular features, batch migration, documentation completion
L3 autonomous orchestration	Drives a complete workflow toward a defined goal	Oversees key checkpoints	Requirement-to-delivery pipelines, regression testing and fixing

Tiering serves three purposes:

• Clarify permission boundaries: The higher the task level, the higher the requirements for test coverage, sandboxed execution, and human review.
• Match task types: First-time exploratory design work suits L1, clearly bounded batch refactors suit L2, and only processes with fixed steps and clear acceptance criteria suit L3.
• Support a measurement system: Different levels use different evaluation metrics, avoiding a single metric for all scenarios.

Context Engineering: The First Variable That Determines the Ceiling

The performance differences of the same model across teams often come down first to “what it can see.” The goal of context engineering is to give the model the most relevant information for the current task within a limited information budget. Too little information leads the model to guess; too much irrelevant information dilutes the effective signal.

1. Establish structured project conventions

In projects where the tech stack, directory structure, naming style, testing requirements, and commit conventions are not yet written down, the model’s output often diverges from team habits. Codifying these conventions into a file that the whole team shares and that loads automatically as background for each session is the lowest-cost, highest-return step. Example:

# Project development conventions (illustrative)
- Stack: Python 3.11 + FastAPI + SQLAlchemy
- Layering: api → service → repository → model; no cross-layer calls
- Testing: new logic must include unit tests using pytest, coverage no less than 80%
- Commits: follow the Conventional Commits specification
- Prohibited: hardcoding secrets in code, directly concatenating SQL statements

2. Load code on demand via retrieval

A code repository is usually beyond an agent’s context budget. It needs code indexing and semantic retrieval to dynamically load relevant files and symbols per task. Two more mature approaches are:

• A lightweight resident map: Keep the directory structure, module responsibilities, and key interfaces in context as a summary, so the model can build a global understanding.
• On-demand tool reads: Let the model read specific files or definitions through tools as needed, rather than pasting all source code at once.

For large repositories, this “map plus on-demand retrieval” approach is usually more economical and more controllable than stuffing the entire repository into context.

3. Give every interaction a clear goal

Compared with open-ended instructions like “take a look at this project,” a task description that includes the following elements is more reliable: goal, constraints, acceptance criteria, and relevant code locations.

Task: Add a "cancel order" endpoint to the order service
Constraints:
  1. Follow the existing layered structure; business logic goes in the service layer
  2. Only allow cancellation of orders in "pending payment" or "paid" status
  3. Log status changes as operation logs
Acceptance criteria:
  1. Return 409 for invalid status, with a clear error message
  2. Unit tests covering three cases: successful cancellation, invalid status, and non-existent order

Building an Executable Feedback Loop: The Agent’s “Verification Circuit”

Generation is only the starting point. Code generation without verification quickly accumulates technical debt and hidden defects. What deserves the most investment is the “generate → execute → feedback → fix” loop, whose core is environment constraints, fast verification, and structured feedback.

1. Replace subjective judgment with executable verification

Unit tests, type checking, static scanning, and build scripts should be unified into a single command that the agent can run itself after each step. The risk with natural-language descriptions is that code “looking reasonable” does not mean it is “actually correct,” whereas automated verification provides objective signals. Example:

# ci-verify.yaml (illustrative)
name: agent-verify
steps:
  - run: pip install -r requirements.txt
  - run: pytest -q --cov=src --cov-fail-under=80
  - run: mypy src
  - run: ruff check src

2. Isolate the execution environment with a sandbox

When an agent executes generated code, it should run in an isolated environment, which typically includes:

• A container or dedicated virtual machine, limiting CPU, memory, and execution time
• Network access disabled by default, allowed only on an allowlist when truly necessary
• Dedicated database and cache instances, avoiding pollution of development or production data
• Complete execution logs, for traceability

3. Make failure information usable

When an agent faces a test failure, the useful information is not “how many failed” but “which assertions failed, how the expected and actual output differ, and where the error stack points.” Returning failure information in a structured format and driving fixes with a minimal reproduction case is usually more effective than dumping an entire log.

# Simplified structured validation output (illustrative)
import json, subprocess
def run_checks(cmd: list[str], timeout: int = 300) -> dict:
    try:
        proc = subprocess.run(
            cmd, capture_output=True, text=True, timeout=timeout
        )
        return {
            "passed": proc.returncode == 0,
            "exit_code": proc.returncode,
            "stdout_tail": proc.stdout[-4000:],  # truncate output to avoid context overload
            "stderr_tail": proc.stderr[-4000:],
        }
    except subprocess.TimeoutExpired:
        return {"passed": False, "reason": "timeout"}
result = run_checks(["pytest", "-q"])
print(json.dumps(result, ensure_ascii=False))

Custom Workflows: From “a Single Conversation” to a “Reusable Pipeline”

A single conversation solves point problems. Embedding agents into the development process to form reusable flows with fixed roles and fixed inputs and outputs is the key to enterprise-grade productivity gains. A common approach is to split the agent into several roles, each with a single responsibility and structured output, then chain them together with an orchestration layer:

• Planner: Converts requirement documents into a task list with acceptance criteria.
• Implementer: Completes code changes on a specified branch according to the task list.
• Test generator: Writes unit tests and edge cases based on the acceptance criteria.
• Code reviewer: Checks naming, layering, exception handling, and security risks against team conventions.
• Regression verifier: Runs the full test suite and static checks in CI.

The orchestration layer’s job is to decide the order, pass artifacts along, and handle failures. The benefits of dividing roles are:

• Each role has smaller context and clearer goals;
• When one step fails, it can be retried individually without starting over.

Example workflow:

# Illustrative: feature-development agent pipeline
pipeline: feature-delivery
trigger:
  - type: issue
    labels: ["ready-for-dev"]
roles:
  - name: planner
    input: issue.body
    output: tasks.json          # task list + acceptance criteria
  - name: implementer
    input: tasks.json
    constraints:
      branch_pattern: "feat/issue-{issue_id}"
      max_changed_files: 20
    output: pull_request
  - name: reviewer
    input: pull_request.diff
    rules_file: ./docs/review-checklist.md
    require_human_approval: true
  - name: verifier
    input: pull_request
    checks: [unit-test, type-check, lint, security-scan]

Two points deserve emphasis:

• Keep orchestration deterministic: Define the workflow skeleton with deterministic code or configuration; use the model’s autonomous judgment only where understanding is required.
• Standardize tool integration: The way an agent accesses the code repository, build pipeline, logs, and monitoring should be unified through standard tool interfaces (such as the interfaces of code hosting and CI/CD platforms, and log query interfaces), rather than custom-tailored for each model. This lowers the cost of migration and replacement.

Vibe Coding: From “Code-Oriented” to “Intent-Oriented”

The term “Vibe Coding” originated in early 2025 as a developer’s playful name in the tech community, referring to a way of coding based entirely on natural-language descriptions and barely looking at the code itself. It vividly captures a shift in mindset: the developer moves from writing code line by line to defining goals in natural language, letting the agent do the implementation, and then verifying results through tests and review.

Note that the industry generally does not treat it as a complete method ready for direct production use; it is better suited to risk-controllable scenarios such as prototype validation, scripting tools, and personal projects. The truly reusable core of this mindset comes down to three points:

• Clear intent: Describe clearly “what you want, what you don’t want, and how to judge completion”—which is essentially writing acceptance criteria.
• Small iterative steps: Propose only one verifiable small change at a time, and run tests immediately to confirm it, avoiding piling up large blocks of code until problems can no longer be localized.
• Continuous review: The faster the generation, the more review and testing investment must increase in step. Review is not optional; it is part of the process.

In individual practice, you can divide the work like this:

• Parts you can hand off: Unit tests, API documentation, data migration scripts, logging and monitoring configuration, and repetitive refactoring.
• Parts that need caution: Core transaction paths, authorization and authentication logic, database schema changes, and external protocol definitions.

The Product Manager’s Perspective: Requirement Decomposition and Solution Output

The capabilities of AI coding agents apply equally to a product manager’s daily work, where the key is likewise structure and verifiability.

1. Requirement decomposition

Turning vague ideas into user stories with acceptance criteria is the prerequisite for keeping downstream implementation on track:

User story: As an operations staff member, I want to bulk-export order data so that I can use it during quarterly reviews.
Acceptance criteria:
  1. Support filtering by time range and order status; the per-export limit is set by configuration
  2. Export runs asynchronously and notifies the user to download when complete
  3. When a single request exceeds the configured record limit, return a clear message instead of silently truncating

2. Solution documents and review checklists

Product managers can use agents to quickly produce first drafts of solutions, competitive feature-mapping frameworks, structured meeting notes, and consistency checks on requirement documents. Keep three things in mind:

• The agent does not have access to unpublished online data or business context; any data-related conclusion must be verified manually;
• The draft output should be treated as a “review starting point,” not a “final version”;
• Inputs involving user privacy and commercial data must comply with the organization’s data security rules.

Security and Governance: The Red Lines for Enterprise Adoption

When an enterprise adopts AI coding agents, the first question is not “how much productivity gain can we get,” but “what content must not leave the controlled environment.” Defenses are usually needed at four levels:

• Data boundary: Whether code, documentation, and data leave the enterprise network depends on the deployment model. Data-sensitive organizations can adopt a private network or an on-premises deployment, combined with the enterprise’s existing permission system for unified identity authentication. Baidu AI Cloud’s general-purpose capabilities—such as large-model services, container platforms, logging and monitoring, and object storage—can serve as underlying components for building such an agent-development platform.
• Least privilege: The agent’s code repository permissions, branch-write permissions, and production-access permissions should be granted on a least-necessary basis, and production changes must go through human approval.
• Sensitive-information protection: Scan for and redact secrets, tokens, and personal information before code commits and before agent inputs.
• Auditability: Fully record the agent’s operation logs (which files it read, which commands it ran, what it changed) so that every change can be traced back to a person.

In addition, code generated by agents may introduce dependencies of unknown origin or snippets similar to open-source code. Before adoption, run license-compliance checks and vulnerability scans to avoid legal and supply-chain risks.

Effectiveness Measurement: Using Data to Decide Whether It “Really Improves Productivity”

Without measurement, “productivity gains” easily stay at the level of subjective feeling. You can build three layers of metrics:

• Process metrics: Agent suggestion adoption rate, test pass rate of generated code, number of review rounds, defect escape rate, and average time per task.
• Delivery metrics: The delivery cycle from requirement confirmation to release, deployment frequency, change failure rate, and mean time to recovery. These are the four core metrics the industry commonly uses to measure software delivery performance.
• Quality metrics: Unit test coverage, number of static-scan issues, and the number and severity of production incidents.

Three misreadings to avoid:

• Volume of generation ≠ volume of output: Generating large amounts of code followed by extensive rework actually lowers overall efficiency.
• High adoption rate ≠ high value: Boilerplate code that is easy to complete has a high adoption rate, but its low difficulty does not reflect the ability to solve complex problems.
• Short-term speedup ≠ long-term benefit: Speedups lacking testing and review may be paid back later in the form of defect fixes and technical debt.

It is recommended to select an observation window before and after adoption for comparison, and to gather statistics separately by task type, to reach a relatively objective conclusion.

Implementation Roadmap: From Pilot to Scale

A pragmatic path can be divided into four phases:

1. Individual pilot (weeks 1–2): Choose low-risk tasks such as unit test generation, script writing, and code explanation to validate basic effectiveness, while organizing the project conventions file.
2. Team pilot (weeks 3–6): Establish unified convention files, verification commands, and review checklists within the project; standardize agent usage rules and input/output formats.
3. Process embedding (weeks 7–12): Connect agents into code review, continuous integration, and defect assignment, forming a supervised execution process, and begin collecting effectiveness metrics.
4. Scaled governance (from month 3 onward): Build a platform-based mechanism for tool integration, permission management, auditing, and security scanning; accumulate team-specific best practices and a library of failure cases.

Common Pitfalls

• Treating “complete resources” as “adequate capability”: Tool documentation and collections of tips can only provide input; the real gap comes from project conventions, the verification system, and collaboration processes.
• Asking an agent to complete a major overhaul in one shot: The larger the task, the more uncontrollable factors; splitting it into small-step changes makes it easier to verify and easier to roll back.
• Ignoring review and testing: After generation speed increases, insufficient verification capability directly amplifies defects.
• Missing context preparation: Without convention files, without an index, and without acceptance criteria, stable output is hard to obtain with any model.

Conclusion

The value of AI coding agents lies not in replacing developers writing code, but in handing the repetitive, well-patterned parts of the development process to machines, so engineers can focus their energy on system design, requirement clarification, and quality oversight. For individual developers, this means mastering context organization, task decomposition, and verification methods. For teams, it means distilling tool capabilities into engineering standards. For enterprises, it means applying this at scale within controllable boundaries. Tools will keep iterating; an engineering mindset is the sustainable competitive advantage.