AI Coding Assistants from Scratch: Usage, Prompting, and Workflow Guide

1. What Problems Can AI Coding Assistants Actually Solve?

In recent years, LLM-based AI coding assistants have gradually entered the software development process. They can understand natural-language requirements, analyze project files, generate code snippets, explain error messages, and assist with testing, refactoring, and documentation.

It is important to be clear that an AI coding assistant is not a universal tool that can “complete all development automatically from a single sentence.” It is better suited to the following types of work:

1. Quickly understanding unfamiliar code
   When developers take over a new project, they can ask the assistant to explain the directory structure, module responsibilities, key call chains, and relationships between configuration files, reducing the cost of reading the codebase.

2. Generating repetitive code
   For interface boilerplate, data structures, parameter validation, basic tests, configuration templates, and other content with clear rules, the assistant can significantly reduce mechanical work.

3. Helping locate problems
   When an exception occurs, developers can provide the error message, relevant code, and reproduction steps, then ask the assistant to analyze possible causes and suggest a troubleshooting order.

4. Optimizing existing implementations
   The assistant can help improve runtime efficiency, code readability, exception handling, logging, and module boundaries, but the final solution still requires developer review and verification.

5. Supplementing technical documentation
   The assistant can generate comments, API descriptions, deployment steps, change logs, and usage examples based on the code, helping teams accumulate knowledge.

2. Environment Preparation Before You Start

High-quality results are usually built on clear project context. Before formal use, it is recommended to complete the following preparation.

1. Define the Project Boundary

Do not hand the entire project to the assistant at the beginning. First determine the scope involved in the current task, for example:

• a business module;
• an API or a page;
• a data processing flow;
• a set of test cases;
• a performance or maintainability improvement.

The clearer the boundary, the easier it is to verify the generated result. If the task scope is too large, the assistant may miss implicit dependencies or modify unrelated files.

2. Check the Project State

Before making changes, confirm that the current code is in a rollback-capable state. It is recommended to:

• save uncommitted local changes;
• record the current branch or version information;
• ensure the project can build or start normally;
• confirm whether existing tests pass;
• avoid providing secrets, tokens, personal information, or other sensitive content to the model.

If the project lacks basic tests, at least prepare a set of manually executable verification steps so you can judge whether the changes are correct.

3. Provide Necessary Context

Rather than saying vaguely, “Help me optimize this code,” provide information such as:

• the business goal of the current feature;
• input and output formats;
• known constraints;
• modules that must not be changed;
• the language and runtime environment;
• the error symptoms that have occurred;
• the expected acceptance criteria.

The more complete the context, the easier it is for the assistant to understand the real requirement instead of guessing from a local piece of code.

3. Correct Task Decomposition

The most common problem in AI-assisted development is not that the model cannot write code at all, but that the task description is too vague. A complex requirement should be split into multiple verifiable small steps.

Step 1: Analyze First, Do Not Rush to Modify

You can first ask the assistant to complete work such as:

• explaining the responsibilities of relevant project directories;
• finding the entry files involved in the requirement;
• listing the data flow process;
• identifying dependencies that may be affected;
• pointing out risk areas in the current implementation;
• proposing two or three possible approaches.

The focus of this stage is to build shared understanding, not to immediately generate final code. Developers can use the analysis results to correct misunderstandings.

Step 2: Define the Implementation Plan

Once the problem scope is clear, ask the assistant to provide an implementation plan. The plan should preferably include:

1. files that need to be modified;
2. the purpose of modifying each file;
3. functions or modules that may be added;
4. impact on existing behavior;
5. testing and rollback plans.

For example, adding parameter validation to an API may involve the route layer, business layer, data model, and test files. If only the entry function is modified, validation logic can easily become duplicated or missed.

Step 3: Execute Changes in Small Steps

It is recommended to handle one relatively independent goal at a time. For example, first add input validation, then add exception handling, and finally write tests. After each step, run the build, static checks, or tests.

This approach has three benefits:

• problems are easier to locate;
• the change scope is easier to review;
• errors are less likely to accumulate.

Step 4: Ask the Assistant to Explain the Changes

After code generation, do not focus only on whether it runs. Also ask the assistant to explain:

• which files were modified;
• why the design was chosen;
• whether existing behavior was changed;
• which edge cases are not yet covered;
• what verification still needs to be performed.

The explanation process helps developers discover unreasonable assumptions and improves team understanding of the code.

4. How to Write High-Quality Instructions

A practical task description usually contains six parts: role, goal, context, constraints, output format, and acceptance criteria.

Recommended Template

You are a developer responsible for maintaining this project.
Goal:
Add input validation to the existing feature and keep the existing success path unchanged.
Context:
The current feature is in a business module, and the input contains several fields.
Two of the fields must be present, and one field must match a specified format.
Constraints:
1. Do not change public interface names;
2. Do not introduce new external dependencies;
3. Keep the existing error response structure;
4. Add clear logs for invalid input;
5. Reuse existing utility functions where possible.
Output requirements:
1. Analyze the current implementation first;
2. Provide a modification plan;
3. Then provide the code changes;
4. Finally list test scenarios and risks.

This format is more executable than “Help me change the code.” In particular, constraints and acceptance criteria can significantly reduce results that deviate from the actual requirement.

5. Common Development Scenarios and Usage Patterns

1. Reading and Summarizing Code

You can ask the assistant to explain code in the order of “entry point, core logic, data sources, exception handling, external dependencies, and return results.” For complex modules, you can further request a text-based call chain:

Request enters the API
→ Parameter parsing
→ Permission check
→ Business rule validation
→ Data read or write
→ Result transformation
→ Return response

If the explanation does not match the actual code, the code execution path should be treated as authoritative, and the assistant should be asked to re-check.

2. Generating Test Cases

Tests should not cover only normal input. They should also include:

• empty values;
• type errors;
• overly long strings;
• boundary numbers;
• duplicate requests;
• insufficient permissions;
• missing resources;
• downstream service failures;
• concurrency or duplicate submission.

You can ask the assistant to output a test checklist in the format of “scenario, input, expected result, verification method,” then select suitable parts for automated test code.

3. Troubleshooting Runtime Errors

When providing problem information, it is recommended to include:

• the complete error message;
• when it occurred and the operation steps;
• relevant code;
• input samples;
• runtime environment;
• the most recent change;
• whether it can be reproduced consistently.

Do not provide only “the program reported an error.” When information is insufficient, the assistant can only guess and may give suggestions that sound reasonable but are actually irrelevant.

Troubleshooting should follow an order from near to far:

1. Check whether the input matches expectations;
2. Check variable types and null values;
3. Check configuration and environment differences;
4. Check dependency versions and API responses;
5. Check concurrency, timeouts, and resource limits;
6. Only then consider complex architecture issues.

4. Refactoring Legacy Code

Before refactoring, you must first confirm existing behavior, especially hidden rules. You can ask the assistant to first list:

• current features;
• known callers;
• dependencies;
• input and output contracts;
• exception behavior that external dependencies may rely on.

Refactoring should prioritize improving readability and testability. Do not replace stable implementations on a large scale just to make them “look more advanced.” After each refactoring step, run the existing tests and add key regression scenarios.

6. Why AI Assistants Often Get Stuck

1. Incomplete Context

Providing only one function while asking the assistant to solve a problem in the entire module usually leads to incorrect judgments. The solution is to add callers, data structures, and configuration relationships.

2. Unclear Goals

“Optimize it,” “write it better,” and “improve performance” are all vague goals. Specify optimization metrics, such as reducing duplicate queries, reducing unnecessary object creation, improving error readability, or shortening response waiting time.

3. The Task Is Too Large

Asking the assistant to design the architecture, modify more than a dozen files, add tests, and write documentation at the same time can easily cause omissions. Break the task down and confirm it in stages.

4. No Feedback Loop

If generated code is not tested and actual results are not fed back to the assistant, subsequent suggestions will naturally drift away from the problem. The correct approach is: propose a hypothesis, run verification, return the results, and continue correcting.

7. Security and Engineering Governance Requirements

AI coding assistants involve source code, configuration, and business logic, so security boundaries must be followed during use.

1. Do not input sensitive information
   Passwords, access tokens, private keys, customer data, and internal addresses should be redacted first.

2. Apply least privilege
   If the tool supports file access or execution operations, only open the directories and permissions required to complete the task.

3. Review all automated changes
   Focus on deletion operations, dependency changes, permission checks, database writes, network requests, and exception handling.

4. Pay attention to supply chain risks
   Review the source, maintenance status, and license of dependencies generated or suggested by the assistant, and avoid adding them to the project without evaluation.

5. Keep change records
   Important tasks should record requirements, generated content, manual adjustments, test results, and the final version for later traceability.

8. Build a Stable Daily Workflow

A mature AI-assisted development process can be summarized as:

Clarify the goal
→ Check the project state
→ Collect necessary context
→ Ask the assistant to analyze first
→ Confirm the implementation plan
→ Make small-scope changes
→ Run builds and tests
→ Feed back actual results
→ Human review
→ Record final changes

The most critical parts are “verification” and “human review.” AI assistants can increase coding speed, but they cannot replace requirements judgment, architecture decisions, or quality responsibility.

For beginners, it is recommended to start with low-risk tasks such as code explanation, test generation, and documentation organization. After becoming familiar with the interaction style, gradually use the assistant for module development, troubleshooting, and refactoring. For teams, it is useful to establish unified task templates, code review rules, and sensitive information handling policies.

Conclusion

The value of AI coding assistants is not to completely replace developers, but to free them from repetitive work and information organization so they can invest more energy in requirement understanding, solution design, and quality assurance. As long as you insist on clear descriptions, step-by-step execution, timely verification, and strict review, even without extensive experience, you can gradually build an efficient, stable, and controllable AI-assisted development method.