An Efficient Way to Use AI Coding Assistants to Produce Runnable Code

5 hr ago0 views

A practical methodology for getting reliable, runnable code from AI coding assistants: how to choose and set up the right tool, write requirements the model can act on, work through two complete examples (a Python data-visualization script and a filterable front-end dashboard), and review and secure AI-generated code.

In 2025, AI coding assistants are no longer just editor add-ons that “autocomplete the next line.” They are becoming “pair programmers” that can understand an entire project, read and write files, run commands, and check their own results. Getting real value from them, however, takes more than installing a plug-in and adding an API key. Given the same tool, the quality of what different people produce often depends less on the underlying model than on how clearly they state requirements, how well they break tasks down, and how rigorously they verify the results.

This article does not compare specific products. Instead, it presents a reusable methodology across five areas: choosing and evaluating a tool, connecting a model, asking effective questions, two complete hands-on examples, and engineering quality assurance.

1. Choosing a Tool: Three Form Factors and Six Evaluation Criteria

AI coding assistants on the market today fall into three broad categories, each with a different focus:

In-editor assistants run in an editor sidebar. They can read the files you have open and the workspace structure, and once authorized, write code and run commands. They suit quick questions during everyday coding and small-to-medium changes.
Conversational and cloud assistants run in a web browser or a cloud environment. They excel at long-chain reasoning, solution design, and technical research. Their output is usually code blocks with explanations that developers copy into their projects by hand.
Terminal and command-line assistants run in the shell. They can work directly on a code repository and run tasks in batches. This makes them easy to script and to combine with automated pipelines.

In practice, most teams get better results by combining all three. They use an in-editor assistant as their everyday workhorse, conversational tools for solution design and technical research, and command-line tools for bulk refactors and automated tasks.

Once you know which form factors fit your workflow, evaluate a specific assistant against six criteria:

Model capability: Can the assistant correctly interpret a complex, multi-step instruction in one go? Does it stay consistent across a long context? Is it familiar with the mainstream languages and frameworks you use? Test these questions on a small sample of your team’s real tasks rather than relying only on public leaderboards.
Depth of tool integration: Can it read files in the workspace, edit code across multiple files, and run commands and read their output? Can it bring in external context such as databases, documentation, and APIs through an extension protocol?
Control: Does it show a diff preview before changing code? Can you approve changes one by one? Is it easy to undo or roll back?
Data compliance: Is your input used to train the model? Are there options such as data retention opt-outs or enterprise-grade data isolation? Check the answers against the compliance requirements of your industry.
Cost and latency: How many tokens does a typical task use, and how fast does the assistant respond? Can you assign models of different sizes to different kinds of tasks?
Extensibility and replaceability: Can you switch between model providers easily? Does it support private deployment or local models? These features determine whether you can avoid being locked into a single vendor later on.

2. Setup: Installation, Configuration, and a Connectivity Check

2.1 Install and Authorize the Assistant

Most mainstream editors have a plug-in marketplace. Search for AI coding assistant plug-ins and install one, which is usually all it takes to get started. The first time you use the assistant, the editor typically asks which permissions it may need, such as reading workspace files, writing files, and running terminal commands. Try it first on a non-critical repository. Once you have confirmed that it behaves as expected, roll it out to production projects.

2.2 Create an API Key and Store It Securely

Using a cloud model service as an example, the general process looks like this:

Sign up for the model service in your cloud provider’s console;
Create an API key;
In the console, check which models the service offers, along with context lengths, pricing, and rate or usage limits;
Keep the key safe. Never hard-code it in source files or commit it to version control. Store it in environment variables on your development machine, or manage it centrally with a secrets management service.

2.3 Configure the Model Parameters

In the assistant’s settings, look for an option along the lines of “custom model provider.” You will then need to enter the API endpoint (Base URL), the API key, and the model name. Pay particular attention to the following:

Check the provider’s documentation to see whether the endpoint should end with /v1. Otherwise, requests may fail because of an incorrect path.
The model name must exactly match the identifier in the provider’s official model list.
Keys and endpoints are usually not interchangeable between cloud providers or between different access methods.

Two parameters deserve special attention:

Temperature controls how random the output is. Lower values produce more consistent results, so keep it low when generating code. You can raise it for creative tasks.
Max output length and context length should match the complexity of the task.

2.4 Assign Models by Task

In practice, you can adopt a tiered strategy that matches the model to the task:

Give complex tasks such as requirements analysis and architecture design to models with stronger reasoning ability;
Use models that respond faster and cost less for routine Q&A and small single-file changes;
For tasks that involve internal code, prefer a deployment option that does not use your data for training.

Some teams connect multiple model services through Baidu AI Cloud’s Qianfan model platform. The platform is compatible with mainstream model API specifications, so switching models often requires changing only a few parameters, such as the model name. This makes it easier to choose the right model for each scenario.

2.5 Verify Connectivity

Once the configuration is complete, check that it works. The model name appearing in the interface is not proof of that. Instead, run three checks in order:

Chat check: Send a greeting and confirm that you receive a response.
File read check: Ask the assistant to read and summarize the file that is currently open, and confirm that it picks up the context correctly.
Tool execution check: Ask the assistant to create a test file in the current directory, then read it and delete it. This confirms that the file read/write and command execution paths work.

Only start real development work once all three checks pass.

3. Using AI Coding Assistants Effectively: State Your Requirements Clearly

How well an AI coding assistant generates code depends largely on how clearly you describe what you need. A structured prompt usually has six elements:

Role and context: The professional role you want the assistant to take on, and the project’s tech stack;
Task objective: A one- or two-sentence summary of what you want done;
Input description: Which data or files are involved, along with field meanings, units, and approximate size;
Execution steps: The order in which you want the work done;
Constraints: Code style, dependency limits, error handling, performance requirements, and so on;
Acceptance criteria: What counts as done, and which deliverables are expected.

For complex tasks, four additional strategies help:

Understand before acting: Ask the assistant to read the data or code first and restate its understanding. It should raise questions before proceeding.
Plan before implementing: Have the assistant draft a to-do list or implementation plan. Confirm it before any code is written.
Move step by step: Tackle one verifiable sub-goal at a time. Validate each stage before moving on to the next.
Specify deliverables: State which files are required, how to run them, and how to verify the results.

It also helps to state the project background and coding conventions at the start of each conversation. For example: “This project uses Python 3.10 or later and follows PEP 8. Functions must include type annotations and docstrings.” This significantly reduces rework later.

4. Example 1: A Four-Panel Sales Chart in Python

4.1 Break Down the Requirement

Data visualization is one of the most common tasks in everyday programming. Suppose you have a spreadsheet of electric vehicle sales data with about 500 rows and five columns: rank, model, sales, manufacturer, and guide price. The goal is a single figure with four subplots:

Subplot 1: The top 10 models by sales;
Subplot 2: The top 10 manufacturers by sales;
Subplot 3: The sales distribution across price ranges. These are five bands: under 100k, 100k–200k (including 100k but excluding 200k; the same convention applies to the bands below), 200k–300k, 300k–400k, and 400k and above.
Subplot 4: The 10 manufacturers with the most models launched, together with their model counts.

4.2 Validate the Data Before Analyzing It

In real-world analysis, data quality problems are more often overlooked than problems in the plotting code. Before analyzing, have the assistant run these checks:

Whether field names contain spaces or mix full-width and half-width characters;
Whether the sales and price columns are recognized as numeric types, and whether text values contain units such as “10k” or “yuan”;
Whether there are nulls, duplicate records, or obvious outliers;
Whether field meanings are ambiguous, for example whether “manufacturer” and “brand” mean the same thing.

When the assistant finds an ambiguity, it should ask the developer to clarify rather than guess and keep going.

4.3 Choose the Right Data-Cleaning and Plotting Tools

Python has a mature ecosystem for tabular data and plotting:

Use a data analysis library such as pandas to read and aggregate tabular data;
To read .xlsx spreadsheets, install an engine such as openpyxl;
For visualization, use a plotting library such as matplotlib or seaborn;
A better workflow is to let the assistant first explore the data quickly with pandas’ plotting interface, then refine the styling in matplotlib. If the charts need to render directly in an interactive environment such as a Jupyter Notebook, an interactive plotting library such as Plotly also works.

Choose the chart type based on what the data represents, not on which option makes the code shorter:

Rankings: For model names and their rankings, horizontal bar charts work best, because long names are easier to display in full.
Aggregated categories: Manufacturer sales totals suit vertical bar charts.
Distributions across ranges: Price-range data suits bar charts or histograms, which make it easy to see where sales concentrate.
Counts: Manufacturer model counts suit bar charts or horizontal bar charts.
Highlighting a single metric: To highlight a key number, a metric card can be more effective than a chart.

A few general visualization principles also apply: remove unnecessary borders and grid lines, use a colorblind-friendly palette, keep axes and units clear, and make sure legends and titles are complete and easy to read.

4.4 Prompt Template

You are a professional data analysis engineer skilled in Python data visualization.
The attached spreadsheet contains electric vehicle sales data with about 500 rows and five columns:
rank, model, sales, manufacturer, and guide price. Please do the following:
1. Read and understand the data first. Explain what each column means and what your data quality
   checks found. Ask me to clarify anything that is unclear before continuing.
2. Using Python's tabular data and plotting libraries, draw four subplots (a 2x2 layout) on a single figure:
   - Subplot 1: Top 10 models by sales. Use a horizontal bar chart sorted by sales in ascending order,
     with value labels.
   - Subplot 2: Top 10 manufacturers by sales. Aggregate sales by manufacturer and take the top 10.
     Use a vertical bar chart with value labels.
   - Subplot 3: Sales distribution by price range: under 100k, 100k-200k, 200k-300k, 300k-400k, and 400k+
     (values in 10k yuan). Use a bar chart.
   - Subplot 4: Number of models launched by each manufacturer. Take the top 10 manufacturers.
     Use a vertical or horizontal bar chart.
3. Chart requirements:
   - Choose the chart type that best suits the data in each case.
   - Make titles, axis labels, and units clear and complete. Use a consistent, attractive, and easy-to-read color scheme.
   - Handle missing fonts gracefully so that labels do not render as empty boxes when the font is unavailable.
   - Choose sensible figure dimensions, spacing between subplots, and font sizes for the value labels.
4. Code requirements:
   - Organize the code into functions, with comments and type annotations where appropriate.
   - Add error handling when reading the file, with clear messages if the file is missing or columns are absent.
   - Make sure the code runs as-is. Save the output as a PNG file and provide the command to run it.

4.5 Example Code

from pathlib import Path
import pandas as pd
import matplotlib.pyplot as plt
from matplotlib import font_manager
DATA_FILE = Path("sales_data.xlsx")
OUTPUT_FILE = Path("sales_dashboard.png")
# Price bins in 10k yuan: 10 means 100,000 yuan.
PRICE_BINS = [0, 10, 20, 30, 40, float("inf")]
PRICE_LABELS = ["<100k", "100k-200k", "200k-300k", "300k-400k", "400k+"]
def setup_font() -> str:
    """Select the first installed font from a candidate list and return its name."""
    candidates = [
        "Microsoft YaHei", "SimHei", "PingFang SC",
        "Noto Sans CJK SC", "WenQuanYi Micro Hei",
    ]
    installed = {f.name for f in font_manager.fontManager.ttflist}
    for name in candidates:
        if name in installed:
            plt.rcParams["font.sans-serif"] = [name]
            break
    else:
        print("Warning: no suitable font found; some characters may render as empty boxes.")
    plt.rcParams["axes.unicode_minus"] = False  # Render minus signs correctly
def load_data(path: Path) -> pd.DataFrame:
    """Load and clean the data; raise an exception if the file or columns are missing."""
    if not path.exists():
        raise FileNotFoundError(f"Data file not found: {path}")
    df = pd.read_excel(path)
    df.columns = [str(c).strip() for c in df.columns]
    required = {"rank", "model", "sales", "manufacturer", "price"}
    missing = required - set(df.columns)
    if missing:
        raise ValueError(f"Missing required columns: {', '.join(missing)}")
    df = df.dropna(subset=["model", "sales", "manufacturer", "price"])
    df = df.drop_duplicates(subset=["rank", "model", "manufacturer"])
    df["sales"] = pd.to_numeric(df["sales"], errors="coerce")
    df["price"] = pd.to_numeric(df["price"], errors="coerce")
    return df.dropna(subset=["sales", "price"])
def build_chart(df: pd.DataFrame) -> None:
    """Draw the four-panel chart and save it as a PNG file."""
    setup_font()
    top_models = df.nlargest(10, "sales").sort_values("sales")
    brand_sales = df.groupby("manufacturer", as_index=False)["sales"].sum().nlargest(10, "sales")
    price_dist = (
        df.groupby(pd.cut(df["price"], bins=PRICE_BINS, labels=PRICE_LABELS),
                   observed=True)["sales"]
        .sum().reindex(PRICE_LABELS)
    )
    brand_count = (
        df.groupby("manufacturer")["model"].nunique().nlargest(10).sort_values()
    )
    fig, axes = plt.subplots(2, 2, figsize=(14, 9))
    fig.suptitle("Electric Vehicle Sales Analysis", fontsize=16, fontweight="bold")
    (ax1, ax2), (ax3, ax4) = axes
    bars = ax1.barh(top_models["model"], top_models["sales"], color="#4C78A8")
    ax1.bar_label(bars, padding=3, fontsize=8)
    ax1.set_title("Top 10 Models by Sales")
    ax1.set_xlabel("Sales (units)")
    ax1.margins(x=0.15)  # Leave room for value labels
    bars = ax2.bar(brand_sales["manufacturer"], brand_sales["sales"], color="#F58518")
    ax2.bar_label(bars, padding=3, fontsize=8)
    ax2.set_title("Top 10 Manufacturers by Sales")
    ax2.set_ylabel("Sales (units)")
    ax2.tick_params(axis="x", rotation=45)
    bars = ax3.bar(PRICE_LABELS, price_dist.values, color="#54A24B")
    ax3.bar_label(bars, padding=3, fontsize=8)
    ax3.set_title("Sales Distribution by Price Range")
    ax3.set_xlabel("Guide Price Range (10k yuan)")
    ax3.set_ylabel("Sales (units)")
    bars = ax4.barh(brand_count.index, brand_count.values, color="#E45756")
    ax4.bar_label(bars, padding=3, fontsize=8)
    ax4.set_title("Top 10 Manufacturers by Number of Models")
    ax4.set_xlabel("Number of Models")
    for ax in axes.flat:
        ax.spines[["top", "right"]].set_visible(False)
        ax.grid(axis="x" if ax in (ax1, ax4) else "y",
                linestyle="--", alpha=0.3)
        ax.set_axisbelow(True)
    fig.tight_layout()
    fig.savefig(OUTPUT_FILE, dpi=200, bbox_inches="tight")
    plt.close(fig)
if __name__ == "__main__":
    build_chart(load_data(DATA_FILE))
    print(f"Chart saved to {OUTPUT_FILE.resolve()}")

Run the script with the following commands:

pip install pandas matplotlib openpyxl
python plot_sales.py

A few details in the code are worth noting:

Font fallback: setup_font checks the candidate fonts one by one, so the chart does not render empty boxes in environments without the target font.
Bin boundaries: pd.cut uses left-open, right-closed intervals by default. The “100k-200k” band therefore includes 100k and excludes 200k, which matches the requirement. The upper bound of the last band is set to positive infinity so that it covers models priced at 400k and above.
Tied ranks: When sales values are equal, nlargest returns rows in their original order, which may not match a manual sort. For reports where ranking matters, agree in advance on a rule for breaking ties.
Aggregation logic: Subplot 2 sums sales by manufacturer, while Subplot 4 counts distinct models per manufacturer. The two subplots use different definitions, so document this in the delivery notes.

4.6 Verify the Results

Once the chart is generated, verify it at three levels:

Data: Spot-check the sales figures of several models against the original spreadsheet. Confirm that nulls and duplicate records have been handled appropriately.
Chart: Check that all four subplots have complete titles, axes, and value labels, and that any non-Latin characters display correctly.
Code: Delete the output image and run the script again. Confirm that the results can be reproduced from scratch.

5. Example 2: From a Static Chart to a Filterable Front-End Dashboard

To turn the analysis into a dashboard that users can browse online and filter by criteria, you can build a single-page application with HTML, CSS, and plain JavaScript. The whole page consists of one HTML file plus separate CSS and JS files. It needs no backend, which makes it well suited to internal sharing or quick prototypes.

5.1 Define the Features

Key metrics: Show total sales, number of models, number of manufacturers, and the best-selling model at the top of the page.
Rankings: Display the top 20 models and the top 10 manufacturers by sales as bar charts.
Multi-dimensional filters: Combine price range, manufacturer, and minimum sales. The rankings should update in real time as filters change.
Detail table: List the models that match the current filters, along with the number of results.

5.2 Suggested Architecture

For a complex page, separate the data layer from the view layer:

Data layer: Convert the cleaned data to a JSON file that the front end loads asynchronously. Define the name, type, and unit of every field explicitly, so the front end does not depend on the original spreadsheet format.
View layer: Keep all filter conditions in a single state object. When a filter changes, recompute only the results and update the affected sections.
Charting: You can use a lightweight charting library for the bar charts, or draw them yourself with plain SVG or Canvas.

// state.js: keep filter state in one place (illustrative)
export const state = {
  priceRange: "all",
  brand: "all",
  minSales: 0,
};
// filter.js: filter logic as a pure function, which makes unit testing easy (illustrative)
export function filterRows(rows, { priceRange, brand, minSales }) {
  const matchPrice = (price) => {
    if (price === null) return false;
    if (price < 10) return priceRange === "all" || priceRange === "<100k";
    if (price < 20) return priceRange === "all" || priceRange === "100k-200k";
    if (price < 30) return priceRange === "all" || priceRange === "200k-300k";
    if (price < 40) return priceRange === "all" || priceRange === "300k-400k";
    return priceRange === "all" || priceRange === "400k+";
  };
  return rows.filter(
    (row) =>
      (brand === "all" || row.brand === brand) &&
      matchPrice(row.price) &&
      row.sales >= minSales
  );
}

In the JS snippet, price is expressed in 10k yuan, the same unit as the chart’s price bands.

A dataset of 500 rows can be embedded directly in the page. Once the data grows to tens of thousands of rows, switch to paginated loading or server-side aggregation queries to avoid slow rendering in the browser.

5.3 Prompt Template

You are a senior front-end engineer. Build a single-page data dashboard with HTML, CSS, and plain
JavaScript. The data comes from data.json, with the following fields: model, brand, sales, and guide
price (price, in 10k yuan).
Features:
1. Metrics section at the top: total sales, number of models, number of brands, and the best-selling model.
2. Rankings section: the top 20 models and the top 10 brands by sales, each shown as a horizontal bar chart.
3. Filters: combine price range (under 100k, 100k-200k, 200k-300k, 300k-400k, 400k+), brand, and minimum
   sales. The rankings and detail table should refresh in real time as filters change.
4. Detail table: list the models that match the filters, with rank, model, brand, sales, and price, and show
   how many results match.
Implementation requirements:
1. Use a modern UI with a card-based layout and a harmonious color scheme. Make it work on both desktop and
   mobile.
2. Make interactions friendly. Show the current value next to each dropdown and slider, support a one-click
   reset, and display an empty-state message when nothing matches.
3. Handle asynchronous loading and errors properly. For example, show an error message if the data file is missing.
4. Encapsulate the filter logic in a separate pure function with a clear structure that is easy to maintain.
5. Make sure the code runs as-is, and explain how to start a local server to view the page.

5.4 Verify the Results

For the front-end result, focus on four areas:

Styling and responsiveness: Check that the layout holds up at different screen resolutions and that the page is easy to use on mobile.
Interaction correctness: Check that combined filters produce the expected results. For example, when “200k-300k” and a specific manufacturer are selected together, the page should show only rows that match both.
Error handling: When the data file is missing or a field has the wrong format, the page should show a friendly message instead of a blank screen.
Security: If users can upload a spreadsheet and parse it in the browser, escape content that comes from the file, or insert it only as text nodes. This prevents malicious content from being executed as code.

6. From “It Runs” to “Trustworthy”: Quality Assurance and Safety Boundaries

Code generated by AI often looks like it runs, but adopting it as-is is risky. Control that risk at four levels:

Code review: Treat AI-generated code like a colleague’s pull request. Check edge cases, error handling, resource cleanup, and potential security vulnerabilities, not just the main code path.
Automated checks: Add unit tests for critical logic, and integrate static analysis and formatting tools. Run the tests before committing. Pure functions such as front-end filter logic are especially well suited to tests. For example, a test can verify that a model priced at 100k falls into the “100k-200k” band.
Version control: Commit the current version before asking the assistant to change any code. Make small changes, verify them step by step, and roll back quickly if something goes wrong. Also ask the assistant to show a diff preview first and apply the changes only after you approve them.
Safety boundaries:
- Never give the assistant real API keys, production data, or data containing personal information. Mask such data first if necessary.
- Be cautious about the commands the assistant runs, especially irreversible operations such as deleting files, force-pushing, or changing system configuration. In principle, a human should confirm these.
- Watch out for indirect prompt injection. When the assistant reads web pages, third-party documentation, or external data, those sources may contain hidden malicious instructions. Limit the assistant’s tool permissions, and require human review for important operations.

Teams should also set up a simple way to measure how well a tool performs. Choose a set of representative tasks from real development work, such as generating code from requirements, fixing defects, explaining legacy code, and writing unit tests. Compare different models on these tasks regularly, using metrics such as the first-pass success rate and the time developers spend on manual fixes. Over time, this produces a selection conclusion that fits your own tech stack.

7. FAQ and Key Takeaways

Can AI fully replace developers? No. AI is good at turning well-defined requirements into code. However, clarifying requirements, weighing architectural trade-offs, judging edge cases, and taking responsibility still require people. The developer’s role is shifting from writing code line by line to defining problems, designing solutions, and reviewing results.

What should you do when the generated code is not good enough? First, check whether the requirements are complete and free of ambiguity. Then break the task into smaller pieces, and provide examples or reference files. Finally, ask the assistant to explain its approach before it writes any code.

How should you handle tasks that involve internal code? Prefer enterprise-grade options or private deployments that do not use your data for training. Agree within the team on which code may be shared with AI tools and which may not.

How do you control costs? Assign models according to task difficulty, and avoid sending every request to the most powerful model. Build a team knowledge base for recurring questions. Set up usage monitoring and alerts to catch unexpected consumption.

Overall, the value of AI coding assistants lies not in writing all of your code for you. It lies in freeing developers from repetitive work so they can focus on defining problems, designing solutions, and ensuring quality. The tools will keep evolving, but the engineering skills of stating requirements clearly, breaking tasks down sensibly, and verifying results rigorously will always be the key to using AI coding assistants well.