AI-Assisted Coding and Agent Workflows: From Debugging to Automation
This article explains practical ways to use large language models in software development, covering AI-assisted debugging, project scaffolding, script generation and unit tests, agent workflows, human-AI collaboration, and product management tasks. For each scenario, it describes the input materials to provide, output requirements to specify, and human review points that remain essential. The goal is to show how to make LLM outputs more reliable through clear constraints, verification, permissions, logging, and approval mechanisms.
Large language models can already complete many real tasks, but results depend heavily on how they are used. For the same question, a well-prepared prompt with complete materials and clear requirements can produce very different results from a casual one-line request. The following sections describe practical approaches for four core scenarios—debugging, project setup, scripts and unit tests, and agent workflows—and then cover human-AI collaboration and product management use cases. For each scenario, the article describes input materials, output requirements, and areas that require human review.
1. AI-Assisted Code Debugging
Debugging is often the scenario where AI assistance produces the fastest visible results. When troubleshooting, provide four types of materials at once: the complete error log, the smallest code snippet that reproduces the issue, dependencies and version numbers, and a description of the runtime environment. The more complete the materials, the more the model can narrow down the scope.
You can use the following prompt structure:
Task: Identify the root cause of the following error.
Materials: Error log, minimal reproduction code, dependency versions, runtime environment.
Output requirements: 1. List root-cause hypotheses in order of likelihood; 2. Provide one verification step for each hypothesis; 3. Provide a fix patch; 4. Provide regression test cases.
Constraints: Clearly mark uncertain areas. Do not invent functions or parameters that do not exist in the code.
The model is usually reliable on issues such as null pointers and type mismatches, because these errors leave clear traces in the code. Concurrency and asynchronous issues are different. These depend on execution timing; when logs are missing or timestamps are inaccurate, the model can only make guesses. In such cases, first add logging and try to reproduce the issue consistently before adopting a fix.
2. Project Setup and Scaffolding
When starting a project from scratch, a large amount of time is spent on boilerplate such as directory structure, routing, and database connections. Having the model generate this content can save time, but explicit constraints are needed; otherwise, the generated structure may not match team conventions.
At a minimum, specify the following fields in the prompt: technology stack and versions, directory structure constraints, API conventions (such as URL style and a unified response format), database migration method, and test framework. After describing entity attributes and core business rules, the model can generate code for the data model layer, business logic layer, and controller layer.
After generation, two things must be done: run the code linting tools and existing tests, confirm that the project starts, and pass basic test cases. Model-generated code may reference dependencies that do not exist or use incorrect versions. Such issues can only be found by actually running the code.
3. Script Writing and Unit Tests
One-off scripts for data cleaning, format conversion, and batch renaming are good candidates for direct generation by the model. Describe the input file structure, expected output, and exception cases. The script should first be run on sample data and confirmed before being used on real data. When deleting or overwriting files is involved, test on a copy first.
Unit tests can also be drafted by the model. After providing the function source code, how it is called, and business constraints, the model can list common boundary cases, such as empty input, out-of-range values, and type exceptions. However, the generated assertions need human review, because the model may write incorrect behavior as the expected result. Coverage tools such as coverage.py and Istanbul measure which code was executed; they do not show whether assertions are correct. A high coverage number cannot replace code review.
4. Agent Workflows
4.1 Basic Structure of an Agent
An agent consists of three parts. The model understands instructions and plans steps, memory stores context and intermediate results, and tools perform actual operations such as querying data and executing code. A single-turn Q&A only outputs text, while an agent can call tools step by step and adjust the next action based on returned results.
4.2 Workflow Example: Weekly Sales Analysis
Suppose the instruction is “analyze this week’s sales data and generate a chart.” A controllable process can be broken down as follows:
| Step | Action | Control |
|---|---|---|
| 1 | Parse the instruction and confirm the time range and metrics | Ask the user a follow-up question if the instruction is unclear |
| 2 | Call the sales query API to retrieve data | Read-only permission; 30-second timeout; maximum of 2 retries on failure |
| 3 | Run the aggregation script in a sandbox | No external network access and no production write access |
| 4 | Call the charting tool to generate a chart | Check whether axes and units are correct |
| 5 | Generate a text report | Every number must be traceable to the results from step 2 |
| 6 | Publish after human review | External release only after the reviewer confirms |
When implementing such workflows, the following mechanisms should be set at the same time: configure tool-calling permissions according to the principle of least privilege; set timeouts and retry limits for each tool; define a clear rollback or stop strategy when a step fails; set human approval at key nodes; and write all tool calls and their parameters to an audit log.
4.3 Operations Scenario: Log Analysis and Alerting
An agent can classify logs, extract error fields, correlate with a knowledge base, and provide handling suggestions. This part only produces suggestions and carries lower risk, making it suitable for an initial pilot.
Automatically restarting services or scaling containers is a high-risk operation. The agent should be allowed to execute it directly only when all of the following conditions are met: the action has been approved, a least-privilege account is used, the operation can be rolled back, and the entire process is written to an audit log. If these conditions are not met, the agent should only output suggestions, and the on-call personnel decide whether to execute them.
5. Human-AI Collaborative Development
Human-AI collaborative development means that the developer describes intent in natural language, the model generates code, and the developer runs and verifies it before moving to the next iteration. The industry often refers to this approach as Vibe Coding. The term does not have a single definition; the key lies in the verification step. Fast iteration can improve speed, but every round of output still needs testing and review.
5.1 Expressing Intent
A clear requirement usually includes role setting, input and output formats, and exception-handling rules. For example, instead of “build an export feature,” write: “Add an export feature to the order list page. The input is filtered order data, and the output is a UTF-8 encoded CSV file with fields listed in the attachment. Export at most 10,000 rows at a time; if the limit is exceeded, prompt the user to narrow the filter. If the export fails, log the error and return a readable message to the user.” The more specific the description, the less room the model has to fill in assumptions on its own.
5.2 Context Management
Large projects contain a large amount of code. Pasting the entire repository into the model may exceed the context window and introduce irrelevant content. A more reliable approach is to provide context in layers: first the interface contracts and related files, then the code snippets to be modified. Retrieval-augmented generation (RAG) or the code index built into the IDE can help quickly find relevant files. Generated results must also remain consistent with existing interfaces and naming; otherwise, compatibility issues are easy to introduce.
6. AI Applications for Product Managers
6.1 Requirement Breakdown
For vague business requests, provide the background, user stories, existing pain points, and constraints to the model, and ask it to output functional modules, process nodes, state definitions, and exception flows. The draft produced by the model usually covers a broad range, but business rules still need to be confirmed by the product manager and business stakeholders.
6.2 PRD Drafts and Analytics Event Suggestions
The model can add exception-flow descriptions and analytics event suggestions to help product managers check whether the document misses any cases. Event fields need to be checked with the data team for naming and metric definitions; otherwise, data cannot be aligned after launch.
6.3 Competitive Analysis and A/B Testing Plans
The model can provide comparison dimensions and evaluation metrics.
