Agent-Assisted Automotive Software Development: A Practical Guide

1. Introduction: Three Pressures in Automotive Software Development

Automotive software is moving from small embedded codebases toward software-defined vehicles. A single vehicle may involve more than 100 million lines of code, covering domains such as body control, three-electric management (for example, BMS battery management systems), ADAS advanced driver-assistance systems, in-vehicle networking, diagnostics, and calibration.

Compared with traditional IT software development, automotive software development has three distinctive characteristics:

• High standards density: Functional safety, cybersecurity, coding standards, and process improvement frameworks overlap with one another. Engineers must not only write correct code, but also provide evidence that the code meets requirements.
• Highly specialized toolchains: Static analysis tools, compilation environments, and test systems can be expensive and have steep learning curves. Root-cause analysis often depends heavily on expert experience.
• Strict process constraints: Requirements traceability, review records, and change management require a complete documentation evidence chain. Every change must clearly explain why it was made and what it is based on.

In this context, engineers spend a significant amount of time on two repetitive but experience-intensive activities:

1. Searching standards and reviewing clauses.
2. Fixing code and filling out forms line by line based on inspection reports.

These tasks are exactly where AI agents can provide substantial value.

General-purpose large language models have broad knowledge, but using them directly in automotive engineering scenarios reveals clear limitations:

• Their memory of specific standard clauses can be vague. They may produce outputs that sound plausible but cannot withstand detailed scrutiny.
• They do not understand a team’s internal coding conventions, module architecture, or toolchain configuration.
• They can only provide textual suggestions. They cannot directly read or modify code files, execute scripts, or integrate with inspection tools.

Domain-specific agents aim to fill these gaps.

2. From Generic Conversation to Domain-Specific Agents: Capability Breakdown

A domain-specific agent is not created by simply adding “You are an automotive software expert” to a prompt. Instead, it systematically injects industry knowledge, tool capabilities, and workflow experience into an AI coding assistant. Such an agent typically consists of four layers.

2.1 Knowledge Layer: Structured Accumulation of Standards and Specifications

Standards related to functional safety, automotive C-language safety coding, automotive cybersecurity engineering, and software process capability assessment should be organized into a structured knowledge base. Each knowledge item usually includes:

• Rule ID and standard source.
• Key requirement and applicability conditions.
• Example violations and compliant examples.
• Corresponding inspection methods and remediation suggestions.

Internal coding conventions, interface design specifications, and architecture design documents should also be included, forming a two-layer knowledge system: industry-wide standards plus team-specific specifications.

2.2 Skill Layer: Encapsulating Process Experience into Reusable Capabilities

Expert workflows for specific tasks should be accumulated as standardized “skills,” covering the following areas:

• Functional safety: Safety goal decomposition and traceability from safety requirements to technical requirements.
• Coding standards: Coding-standard compliance review and remediation.
• Basic software architecture: Layered architecture, interface definition, and module design.
• Diagnostics: Fault code definition, diagnostic service implementation, and consistency checks.
• Calibration: Parameter table maintenance, and naming and unit checks for calibration and measurement variables.
• ADAS and BMS: Algorithm interface definition, state machine design, and critical path review.
• Cybersecurity: Threat analysis and risk assessment, and security requirement tracking.

Skills are organized as files. The agent retrieves and invokes them on demand, avoiding the need to load all context into the model window at once.

2.3 Role Layer: Matching Expert Perspectives to Tasks

Expert profiles should be defined around typical engineering roles, such as functional safety engineer, basic software architect, diagnostics engineer, calibration engineer, and cybersecurity engineer. Different roles have different review focuses and output specifications, making the agent’s responses closer to the mindset of the target role.

2.4 Execution Layer: Connecting to the Real Development Environment

The agent can read source code and documents in specified directories, execute inspection scripts, generate or modify code files, and submit changes according to team rules. Only when the agent can genuinely see the code and modify files can its suggestions become verifiable results.

A conceptual organization structure is as follows:

automotive-agents/
├── standards/      # Structured knowledge base of standards and specifications
├── rules/          # Coding standards and architecture constraint rules
├── skills/         # Domain-specific professional skills
│   ├── functional-safety/
│   ├── coding-standard/
│   ├── bas-software/     # Basic software architecture
│   ├── diagnostics/      # Diagnostics
│   ├── calibration/      # Calibration
│   ├── adas/             # Driver assistance
│   ├── bms/              # Battery management
│   └── cybersecurity/    # Cybersecurity
└── roles/          # Expert role definitions

For example, a coding-standard review skill can be abstractly defined as follows:

# Illustrative skill definition. Field names are examples only;
# implementation details vary by tool.
name: coding-standard-check
description: Review C code against the specified coding standards and output findings with remediation suggestions
inputs:
  - target_dir     # Directory containing the code to review
  - rule_profile   # Rule configuration: enabled rule categories and severity levels that must be fixed
outputs:
  - findings.json  # Structured list of findings
  - fix_plan.md    # Fix plan and change description
workflow:
  1. Traverse source files and use headers and call relationships to understand context
  2. Match findings against the rule library and record location, rule basis, and risk
  3. Sort by severity, generate a fix plan, and wait for human confirmation before applying changes
  4. Re-run the review after changes to confirm closure

3. Scenario 1: Coding-Standard Review and Code-Fix Closure

3.1 Review: From a Single Prompt to Evidence-Based Findings

Traditional static analysis tools can efficiently discover problems, but their outputs often contain only a rule ID, file location, and short description. Engineers must combine the manual with their own understanding to determine whether a finding is valid and how it should be fixed.

A review performed by a domain-specific agent can directly provide the rule basis and risk explanation for each finding. The output can be structured as follows:

[File] src/door_lock.c
[Rule] Pointer parameters must be validated before use
[Location] Line 42, function door_lock_get_state()
[Issue] The parameter state is dereferenced without validation. If the caller passes a null pointer,
       invalid memory access may occur, potentially causing abnormal behavior in the door control module.
[Recommendation] Add a null-pointer check at function entry and return an error code if the check fails.
[Severity] High (must fix)

This “finding + basis + risk + recommendation” format significantly reduces judgment cost, especially for less experienced engineers.

3.2 Fix: Achieving Closure Under Human Confirmation

After confirming a finding, the agent can be instructed to fix the code according to the recommendation. The following is an illustrative fix process:

/* Fix before: dereferences parameter without validation */
#include <stdint.h>
typedef enum {
    DOOR_STATE_LOCKED = 0,
    DOOR_STATE_UNLOCKED = 1
} door_state_t;
/* Assume this variable is maintained by the lock control execution logic */
extern door_state_t g_door_lock_state;
uint8_t door_lock_get_state(door_state_t *state)
{
    *state = g_door_lock_state;   /* state may be a null pointer */
    return 0;                      /* no error code is returned */
}

/* Fix after: validate parameters at entry, return a clear error code, and add comments */
#include <stdint.h>
typedef enum {
    DOOR_STATE_LOCKED = 0,
    DOOR_STATE_UNLOCKED = 1
} door_state_t;
/* Assume this variable is maintained by the lock control execution logic */
extern door_state_t g_door_lock_state;
/**
 * @brief   Read the current door lock state
 * @param   state  Output parameter for the door lock state
 * @return  0 indicates success; -1 indicates an invalid parameter
 */
int8_t door_lock_get_state(door_state_t *state)
{
    if (state == NULL) {
        return -1;
    }
    *state = g_door_lock_state;
    return 0;
}

In this illustrative case, the agent identified and fixed more than ten issues in one pass, with the interaction completed in a few minutes. In traditional workflows, an engineer would need to check the manual, locate the code, apply fixes, and verify them item by item, which usually takes several times longer. Actual efficiency depends on issue complexity, module size, and team review requirements.

3.3 Knowledge Accumulation: Making Fix Patterns Reusable

A common traditional practice is to maintain a manual mapping issues to remediation suggestions. Engineers consult this manual whenever a new issue is found. This approach has three limitations:

• High maintenance cost: the manual easily becomes outdated after rules are updated.
• It explains only “how to fix,” not “why,” which is less helpful for onboarding new engineers.
• It cannot be directly linked to code, making it difficult to accumulate experience as engineering assets.

When remediation suggestions are structured into a rule library, each rule can continuously accumulate typical cases, easily confused points, and boundary conditions. After each fix, a re-check can verify closure. Team experience thus moves from personal notes to version-controlled, reviewable, and continuously evolving engineering assets.

3.4 Boundary Reminder: Not a Replacement for the Formal Toolchain

It is important to clarify that agent-based review cannot replace certified static analysis tools that are integrated into the formal development process:

• Toolchain outputs are often used directly as review and delivery evidence in process workflows, providing clear traceability.
• Agents are better suited to explaining issues, proposing fixes, and handling design-level problems that tools may not easily cover.

A practical approach is to run both tracks in parallel: use the formal toolchain to maintain a complete compliance evidence chain, and use the agent to improve understanding and fix efficiency. The results of both should corroborate each other.

4. Scenario 2: Standardized Architecture Development and Specialized Modules

4.1 Architecture Skeleton and Interface Design

In AUTOSAR-style layered designs, engineers often need to write large amounts of similar basic software module code, interface definitions, and configuration files. With a skill library, an agent can:

• Generate module skeletons and interface declarations according to established layering specifications.
• Check whether dependencies between modules comply with architecture constraints.
• Generate supporting documentation and traceability tables based on interface definitions.

This type of work has clear rules and high repetition. It is well suited for the agent to produce the first draft, followed by architect review and finalization.

4.2 Differentiated Support for Specialized Domains

Different technical domains have different focuses:

• Diagnostics: Checks focus on fault code definition, diagnostic service implementation, and diagnostic database consistency.
• Calibration: Focuses on parameter table structure, variable naming conventions, units, and value ranges.
• BMS: Focuses on voltage, current, and temperature acquisition accuracy; SOC estimation boundaries; and completeness of protection logic such as overvoltage, undervoltage, and overtemperature.
• ADAS: Focuses on sensor interface timing, state machine transition conditions, and function degradation strategies.
• Cybersecurity: Covers asset identification, threat analysis, security requirement definition, and security mechanism verification.

These domains share a common pattern: clear rules, document-intensive workflows, and strong reliance on experience. They are ideal scenarios for AI agents.

5. Engineering Implementation Recommendations

5.1 Build Knowledge Assets in Layers

It is recommended to organize the knowledge base into four layers:

1. Standard clauses.
2. Inspection rules.
3. Remediation patterns.
4. Typical cases.

Each rule should specify its source, version, and applicable scope. It should also remain aligned with the toolchain configuration actually used by the team, avoiding the situation where a specification exists but the corresponding tool check is not enabled.

5.2 Clarify the Division of Labor Between Humans and Agents

A human-in-the-loop collaboration model is recommended:

• The agent retrieves specifications, locates issues, generates solution drafts, and produces initial code.
• Engineers confirm whether findings are valid, whether proposed solutions are reasonable, and whether changes introduce new risks.
• Critical decisions, such as changes to safety-related logic, must be reviewed by humans.

For high-risk operations such as file writes or command execution initiated by the agent, tools usually require human confirmation. Engineers should maintain a review habit and avoid simply clicking “confirm” on every step, which would make the review process superficial.

5.3 Establish Four Quality Guardrails

1. Regression testing: Run unit tests and integration tests after fixes to confirm that functionality is not affected.
2. Re-scan verification: Re-run the inspection to confirm that issues are resolved and no new issues are introduced.
3. Change review: All changes must pass code review before merge. The agent does not participate in final approval.
4. Traceable records: Retain issue lists, remediation descriptions, and review records to meet process audit requirements.

5.4 Build a Quantifiable Effectiveness Evaluation

The actual value of agent-assisted development can be measured from the following dimensions:

Metric	Definition	Purpose
Issue remediation cycle	Average time from issue discovery to closure	Measures efficiency improvement
First-pass fix rate	Percentage of fixes that do not require rework after re-scan	Measures fix quality
Issue density change	Trend in the number of issues per unit of code across iterations	Reflects the effectiveness of specification enforcement
Rule coverage	Percentage of applicable standards that have been structured into rules	Measures progress in building knowledge assets
Manual intervention rate	Percentage of suggestions that must be overridden or substantially modified by humans	Evaluates agent reliability

A controlled experiment is also recommended: process the same module using both the traditional approach and the agent-assisted approach, and record time and defect data. This avoids judging effectiveness based only on subjective impressions.

6. Risk Awareness and Realistic Expectations

AI agents are not omnipotent. The following risks should be acknowledged in practice:

• False positives and false negatives: Agents may misinterpret code with complex context. They cannot guarantee full coverage of all issues.
• Over-modification: Changing unrelated code while fixing one issue may introduce regression defects. Review and testing are required as safeguards.
• Knowledge freshness: Standards are revised over time. The rule library must be updated regularly. Otherwise, agents may make recommendations based on outdated clauses.
• Data security: Source code may involve core intellectual property. Usage should follow the organization’s data management policies. Private deployment options should be considered when necessary.
• Responsibility ownership: Regardless of the tools used, the development team always retains final responsibility for code quality and safety.

7. Conclusion

The core value of AI agents in automotive software development is not to replace engineers. It is to free engineers from repetitive work such as searching standards, filling out forms, and fixing issues one by one, allowing them to focus on architecture design, safety analysis, and critical technical problems.

What ultimately determines success is systematic accumulation of standards knowledge, deep integration with processes and toolchains, and strict human-in-the-loop quality assurance.

Teams are advised to start with a small pilot: one module and one type of specification issue. They should validate the effectiveness, accumulate experience, and then gradually expand to more technical domains.