Building an Intelligent Coding Assistant and an Automated Closed-Loop Workflow from Scratch

When an intelligent coding assistant moves beyond “autocompleting a few lines of code” toward “understanding a task, calling tools, executing verification, and continuously fixing issues,” the developer’s focus shifts as well. It is no longer only about whether the model can write a snippet, but whether it can read the project structure, follow team conventions, invoke external capabilities, handle unexpected results, and form a closed loop in a real environment.

This article starts from scratch and lays out a practical coding-assistant workflow: how to prepare the runtime environment, how to connect to large language models (LLMs), how to design three model-access patterns (direct, routing, and aggregation), how to turn the assistant into a development workbench through context rules and skill extensions, and how to combine search, web, and device operations to form an automated closed loop. For developers who want to genuinely embed AI into their development process, the key is not chasing a single tool but building a stable, controllable, and extensible engineering system.

1. The Three Layers of Automation: Search, Web, and Device

Before getting into the concrete build, one judgment needs to be clear: how far an intelligent coding assistant can automate depends on what it can “see” and “touch.”

Many models only produce “seemingly reasonable” answers because they lack awareness of real-time information, real interfaces, and the running environment. When engineering a solution, capabilities are usually split into three layers: the information layer, the interface layer, and the device layer.

Layer	Core Capability	Typical Scenarios	Impact When Missing
Information layer	Search, web content reading	Querying the latest docs, version changes, error solutions	Can only rely on training data; struggles to answer “latest” and “current” questions
Interface layer	Opening pages, clicking, filling forms, taking screenshots	Operating systems without APIs, end-to-end verification	Cannot verify real interactions; stuck at the code level
Device layer	Installing, launching, clicking, reading logs	Mobile verification, terminal command execution, troubleshooting	Cannot verify real runtime results; the automation chain breaks

Together, these three layers form a complete closed loop:

1. Use search to find the latest documentation, root causes of errors, and fix approaches;
2. Use web or device operations to perform clicks, form fills, installations, launches, and similar actions;
3. Verify the real results through screenshots, logs, network requests, and command output;
4. If a problem is found, return to search and code changes and keep fixing.

This is also the shared foundation for all later automation capabilities. Whether the assistant is used to write code, investigate issues, generate tests, or inspect systems, it ultimately comes back to this loop: gather context, perform an action, verify the result.

2. Pre-Installation Preparation: Runtime Environment, Directory Structure, and Configuration Layers

An intelligent coding assistant usually runs from the command line, and its core components can be abstracted into four parts:

1. Entry program: receives user instructions, parses the task, and dispatches to the model;
2. Model service: provides inference capability, which can be a direct model, an internal gateway, or an aggregation service;
3. Tool capabilities: file read/write, command execution, search, web operations, device operations, and more;
4. Project context: rule files, tech-stack descriptions, directory conventions, test commands, permission policies, and so on.

Before the formal installation, it is recommended to complete three types of preparation.

1. Prepare the Runtime Environment

At a minimum, you need a stable command-line runtime that satisfies the following conditions:

• A usable script runtime and dependency management tool are available locally;
• The network can reach the model service or an internal gateway;
• Basic file read/write permissions are available;
• If you need to run commands or operate devices, confirm the permission boundaries in advance;
• Do not hardcode sensitive information; inject it uniformly through environment variables or secure configuration.

For enterprise environments, it is also worth considering proxies, intranet access, audit logging, and permission approval mechanisms.

2. Design the Directory Structure

It is recommended to create a dedicated working directory under the project root to store assistant configuration, rules, skill scripts, and runtime logs. For example:

project/
  agent/
    rules/
    skills/
    logs/
    temp/
  src/
  tests/
  docs/

Where:

• rules: stores project rules, team conventions, and context descriptions;
• skills: stores extension capabilities such as search wrappers, web operation wrappers, and device operation wrappers;
• logs: records execution logs for troubleshooting;
• temp: holds temporary files to avoid polluting the source directory.

The benefit of this approach is that all configuration and capability extensions of the coding assistant can be brought under version control, and it is easy for the team to share and audit.

3. Layer the Configuration Files

Configuration files should be split along four dimensions—environment, model, permissions, and tools—so that sensitive information and business logic are not mixed together.

A general configuration example:

model:
  mode: direct        # Options: direct, route, aggregate
  endpoint: ""
  timeout: 30
  max_output: 4096
auth:
  token_from_env: "MODEL_TOKEN"
tools:
  file_read: true
  file_write: "ask"
  command_exec: "ask"
  web_search: true
  browser_automation: false
  device_debug: false

The point here is not the specific field names but the design principles:

• Keys are not written into the configuration file;
• High-privilege actions require manual confirmation by default;
• Different environments use different configurations;
• Tool switches are controlled at the project level;
• All actions are, as far as possible, traceable.

3. Connecting to LLMs: Direct, Routing, and Aggregation Patterns

When connecting to LLMs, you should not only care about “whether it connects” but also about stability, cost, permissions, auditing, and the cost of future replacement. There are usually three integration patterns: direct, routing, and aggregation.

1. Direct Pattern

The direct pattern means the coding assistant sends requests directly to a specific model service.

Advantages:

• Simple configuration;
• Short path with relatively controllable latency;
• Suitable for quick validation and single-model scenarios;
• Easy to troubleshoot.

Drawbacks:

• Tends to lock in a single model service;
• Once the model becomes unavailable, there is no fallback capability;
• Parameters and response structures may differ between models;
• Migration costs are relatively high later on.

Applicable scenarios: individual developers, prototype validation, fixed model services, and small internal projects.

2. Routing Pattern

The routing pattern adds a layer of task classification and model-selection logic on the assistant side. For example:

• Use lightweight models for code explanation and log summarization;
• Use more capable models for complex refactoring and architecture analysis;
• Use lower-cost models for bulk document generation;
• Prefer low-latency models for tasks with high real-time requirements;
• Prefer intranet or private models for sensitive tasks.

The core value of the routing pattern is balancing effectiveness, cost, and latency.

You can use simple rules:

routing:
  - task: code_review
    model_tier: high
  - task: doc_summary
    model_tier: light
  - task: test_generation
    model_tier: medium
  - task: sensitive_analysis
    model_tier: internal

You can also select dynamically based on conditions such as input length, task type, retry count on failure, and user role.

3. Aggregation Pattern

The aggregation pattern abstracts a unified gateway on top of the model service. No matter how many model services are integrated underneath, they appear as a single unified interface to the upper-level assistant.

An aggregation gateway usually takes on the following responsibilities:

• Unified authentication;
• Unified request format;
• Unified response parsing;
• Unified log recording;
• Unified rate limiting;
• Unified billing statistics;
• Unified failure fallback;
• Unified model switching.

For enterprise teams, the aggregation pattern is better suited as a long-term solution. It minimizes the impact of model-vendor changes and makes it easier to do canary releases, cost allocation, and permission governance.

4. Key Parameters When Connecting

Regardless of the pattern, it is recommended to focus on the following parameters:

• Request timeout;
• Maximum output length;
• Concurrency limits;
• Retry count;
• Failure fallback strategy;
• Streaming output switch;
• Context length limit;
• Sensitive-word and content safety policies;
• Log masking rules.

These parameters may look basic, but they determine the stability of the system in real business.

4. Turning the Coding Assistant into a Workbench: Context, Rules, and Skills

The real challenge of an intelligent coding assistant is not “generating a piece of code” but making it work according to project conventions over time. To solve this, you need to establish three layers of context: global rules, project rules, and task context.

1. Global Rules

Global rules describe the assistant’s basic behavioral boundaries, for example:

• Read the relevant files before modifying code;
• Do not arbitrarily delete user data;
• Do not run unconfirmed high-risk commands;
• Provide a change description after making modifications;
• When tests are involved, run the smallest set of relevant tests first;
• For uncertain information, clearly flag that confirmation is needed.

Global rules are similar to “working guidelines” and are well suited to reuse across projects.

2. Project Rules

Project rules describe the current project’s tech stack, directory structure, and development conventions, for example:

• What language and framework are used;
• How the code style is defined;
• What the test command is;
• What the build command is;
• Where logs are stored;
• How configuration is managed;
• Which directories must not be modified;
• Which interfaces need to be backward compatible.

The clearer the project rules, the more controllable the assistant’s output.

3. Task Context

Task context is the information relevant to the current request, for example:

• The current error log;
• Relevant code snippets;
• Recent commit records;
• Test cases;
• API documentation;
• Page screenshots;
• Device logs;
• The user’s specific intent.

Task context should not be expanded indefinitely. It is recommended to keep only information strongly related to the current task, avoiding overly long context that leads to distracted attention, rising costs, and slower responses.

4. Skill Extensions

If context solves the “understands the project” problem, then skill extensions solve the “gets work done” problem. Common skills include:

• File reading and patch modification;
• Command execution and result parsing;
• Search and information gathering;
• Web operations and screenshots;
• Device debugging and log collection;
• Test execution and result analysis;
• Build artifact inspection;
• Dependency change checking.

Each skill should have a clear permission boundary. For example:

• Read files: available by default;
• Modify files: recommended to show the change first;
• Run commands: high-risk commands require confirmation;
• Web operations: restrict accessible domains;
• Device operations: restrict the device scope and command allowlist.

5. High-Frequency Daily Workflows: From Requirements to Verification

The most valuable use case for an intelligent coding assistant is not replacing developers, but automating repetitive, mechanical, cross-tool work. Here are several high-frequency workflows.

1. Requirement Clarification and Task Decomposition

After the user enters a vague requirement, the assistant should not go straight to coding but first decompose the task:

1. Clarify the goal;
2. List the files involved;
3. Assess the scope of impact;
4. Produce a modification plan;
5. Execute only after confirmation.

This significantly reduces cases of “right code, wrong direction.”

2. Code Generation and Refactoring

When making changes in an existing project, follow the “minimal change” principle:

• Read the relevant files first;
• Then present a modification plan;
• Generate a patch rather than overwriting the entire file;
• Explain the impact after the change;
• Automatically run the relevant checks.

For refactoring tasks, prioritize keeping behavior unchanged, then optimize structure.

3. Defect Investigation

A typical flow is as follows:

1. Read the error log;
2. Search for similar issues;
3. Locate the relevant code;
4. Build a minimal reproduction;
5. Propose a fix;
6. Modify the code;
7. Run tests;
8. Verify the real result.

In this process, search, web, device, and log capabilities all come into play.

4. Filling Test Gaps

Based on function signatures, business descriptions, and existing test cases, the assistant can generate basic tests. However, test quality needs human review, especially for:

• Boundary conditions;
• Exception paths;
• Permission scenarios;
• Concurrency scenarios;
• Data consistency;
• Idempotency.

5. Documentation Generation and Code Review

The assistant can generate:

• API descriptions;
• Module descriptions;
• Change logs;
• Configuration descriptions;
• Code review comments;
• Risk notes.

But documentation and review results should serve as supporting material, not as final conclusions.

6. Scheduled and Persistent Tasks: Keeping the Assistant Working Continuously

Beyond on-demand Q&A, an intelligent coding assistant can also take on scheduled and persistent tasks.

1. Scheduled Tasks

Common scenarios include:

• Daily build checks;
• Dependency change scanning;
• Log summary generation;
• Test case regression;
• Project documentation updates;
• Weekly or daily report generation.

When designing scheduled tasks, note the following:

• The task must be idempotent;
• Avoid duplicate execution at the same time;
• Failures must trigger alerts;
• Output must be traceable;
• High-risk operations require approval.

2. Persistent Tasks

Persistent tasks are usually triggered by events, for example:

• Automatically check after a file changes;
• Automatically generate a description after a commit;
• Automatically analyze logs after a build failure;
• Automatically screenshot and compare after a page update;
• Automatically collect logs after an abnormal device state.

The key to persistent tasks is stability. It is recommended to set for each task:

• Trigger conditions;
• Execution timeout;
• Retry count;
• Circuit-breaker threshold;
• Log retention period;
• Failure notification method.

7. Web and Device Automation: Closing the Real Loop

If an intelligent coding assistant can only read/write files and run commands, it still stays in the “code world.” To enter the “real system world,” you need to introduce web automation and device automation.

1. Web Automation

Web automation can be used for:

• Opening business pages;
• Logging into the admin backend;
• Filling out forms;
• Uploading files;
• Downloading results;
• Capturing screenshots as evidence;
• Checking page status;
• Verifying end-to-end flows.

In implementation, focus especially on:

• Session/login state management;
• Element-waiting strategies;
• Exception screenshots;
• Network request recording;
• Accessible domain restrictions;
• Approval for accessing sensitive pages;
• Version management of automation scripts.

The value of web automation is that it turns “does the code pass” into “is the page really usable.”

2. Device Automation

Device automation is usually used for mobile devices, terminal environments, or embedded devices. Common capabilities include:

• Installing applications;
• Launching applications;
• Clicking controls;
• Entering text;
• Reading logs;
• Capturing network requests;
• Taking screenshots;
• Restoring device state.

The difficulty of device automation lies in environment differences. Results may vary across different devices, system versions, and network conditions. Therefore, you need to:

• Define a clear device inventory;
• Fix the test environment;
• Record device state;
• Clean up residual data;
• Automatically retry failed results;
• Archive key screenshots and logs.

3. A Closed Loop Across Both Ends

The ideal state is: the user states only the intent, and the assistant autonomously plans the path.

For example, the user says: “Help me verify whether the login page works correctly on mobile.”

The assistant can run the following flow:

1. Search for login-related code;
2. Find the page URL and the login API;
3. Start the local service;
4. Open the web version for initial verification;
5. Connect the device debugging channel;
6. Install or launch the corresponding app;
7. Enter a test account;
8. Click login;
9. Take a screenshot and read the logs;
10. If it fails, search for the cause of the error;
11. Modify the code or configuration;
12. Verify again;
13. Output the conclusion and evidence.

This is the key leap of an intelligent coding assistant from “writing code” to “completing an engineering task.”

8. Engineering Governance: Security, Cost, Monitoring, and Evaluation

Once an intelligent coding assistant enters a real team, governance issues surface immediately. Without governance, the more automation grows, the greater the risk.

1. Permission Governance

Follow the principle of least privilege:

• Read-only capabilities are available by default;
• Write operations require confirmation by default;
• Command execution uses an allowlist;
• Web access is restricted by domain;
• Device operations are limited in scope;
• Production environments are read-only by default;
• High-risk actions must go through manual approval.

2. Data Security

Pay special attention to:

• Do not expose keys in prompts;
• Mask account, token, and phone number information in logs;
• Perform compliance checks before uploading to the web or the cloud;
• Do not send internal code to untrusted external services;
• Apply content safety filtering to model inputs and outputs.

3. Cost Management

Common optimization methods include:

• Cache repeated requests;
• Summarize long text first, then analyze it;
• Use lightweight models for lightweight tasks;
• Merge requests for batch tasks;
• Limit the maximum output length;
• Build fixed templates for high-frequency flows;
• Track invocation costs on a regular basis.

4. Monitoring and Evaluation

It is recommended to establish the following metrics:

• Task success rate;
• Average response time;
• Model invocation failure rate;
• Tool invocation failure rate;
• Context length distribution;
• Number of manual corrections;
• Number of high-risk action triggers;
• Cost per task.

You should also build an evaluation set, for example:

• Common code modification tasks;
• Error-fixing tasks;
• Test generation tasks;
• Documentation generation tasks;
• Page verification tasks;
• Device verification tasks.

After each change to a model, rule, or skill, run the evaluation set as a regression to avoid “locally better, globally worse.”

5. Cloud Hosting

If the team chooses cloud deployment, it can be supported by combining general capabilities such as object storage, log services, monitoring and alerting, container platforms, and message queues. If using Baidu AI Cloud, you can also build a model gateway, log auditing, monitoring and alerting, and a task scheduling system based on its general cloud services. The key point is to upgrade the assistant from a “personal script” into an “operable engineering system.”

9. Common Pitfalls

1. Blindly Chasing an All-in-One Tool

An intelligent coding assistant is not a universal tool. At the current stage, it is better suited for:

• Tasks with clear boundaries;
• Flows with verifiable results;
• Highly repetitive engineering actions;
• Scenarios that require cross-tool collaboration.

For high-risk, irreversible operations or those requiring strong business judgment, manual confirmation must be preserved.

2. Excessive Permissions

If the assistant can freely run any command, access any page, and modify any file, risk escalates quickly. Permission control is not about limiting capability, but about making capability manageable.

3. Lack of a Verification Mechanism

Without screenshots, logs, test results, and network requests as evidence, automation easily becomes “looks finished.” Engineering must emphasize a closed verification loop.

4. Too Much Context

Stuffing all code, logs, and documents into the model at once does not necessarily improve results and may actually add noise and cost. A better approach is on-demand retrieval, layered loading, and dynamic trimming.

5. Ignoring Version Management

Rules, skills, prompts, and model configurations should all be brought under version control. Otherwise, when results fluctuate, it becomes hard to determine whether the cause is a model change, a rule change, or a context change.

10. Final Thoughts: Get In and Work Along the Capability Boundary

The value of an intelligent coding assistant lies not in whether it can complete every task in one shot, but in whether it can automate the “last mile” of the development process: looking up information, reading code, editing files, running tests, viewing pages, verifying devices, reading logs, locating issues, and building an evidence chain.

A truly efficient workflow usually does not start by piling on every capability at once, but begins with a small closed loop:

1. First, let the assistant understand the project;
2. Then let it safely modify code;
3. Then connect search capability;
4. Then open up web operations;
5. Finally, add device and terminal verification;
6. Continuously supplement rules, skills, monitoring, and evaluation.

As the three layers of search, web, and device gradually fill in, the intelligent coding assistant upgrades from a “code assistant” into an “R&D workbench.” And what the developer needs to do is not wait for a perfect tool to appear, but get in, work along the current capability boundary, and build out the real workflow step by step.