4.2: Common Pitfalls

Mistakes to Avoid When Integrating AI with ASPICE

Pitfall 1: Blind Trust in AI

Problem: Merging AI-generated code without review

Example - Wrong Approach:

/* AI generated this code: */
float CalculateDistance(float speed) {
    return speed * 2;  /* [FAIL] WRONG: Returns km, not meters! */
}

/* Engineer merged without testing, bug found in HIL test (€5k cost) */

Correct Approach:

/* AI generated this code: */
float CalculateDistance(float speed) {
    return speed * 2;
}

/* [PASS] Engineer reviews: "Wait, this should return meters, not km!" */
float CalculateDistance(float speed_kmh) {
    const float KMH_TO_MS = 1.0F / 3.6F;
    const float TIME_GAP_SEC = 2.0F;
    return (speed_kmh * KMH_TO_MS) * TIME_GAP_SEC;  /* [PASS] Correct: meters */
}

Consequence: Defect escapes to testing/field, expensive to fix

Solution:

• Always review AI output (correctness, edge cases, MISRA)
• Run tests before merge (unit tests, static analysis)
• Code review checklist (Ch 35.02)

ASPICE Compliance: SUP.2 (reviews mandatory), human approval required for ASIL-B+

Pitfall 2: Over-Reliance on AI for Safety-Critical Logic

Problem: Using AI to generate safety-critical code without human-led design

Example - Wrong Approach:

/* Prompt: "Generate emergency braking function for ASIL-B" */

/* AI Output: */
void EmergencyBrake(void) {
    Brake_Apply(100);  /* [FAIL] Missing: Sensor validation, redundancy, fail-safe */
}

/* Assessor finding: Function lacks hazard analysis documentation and fail-safe behavior required for ASIL-B compliance */

Correct Approach:

/* Human designs safety architecture first, then AI assists with implementation */

/**
 * @brief Emergency braking function with ASIL-B compliance
 * @implements [SWE-BRAKE-001] Emergency Braking Control
 * @safety_class ASIL-B
 * @hazard_analysis HARA-EB-001 (Emergency braking failure)
 * @fail_safe Defaults to maximum braking if sensor failure detected
 */
void EmergencyBrake(void) {
    BrakeSensorStatus_t sensor1 = BrakeSensor_Primary_Read();
    BrakeSensorStatus_t sensor2 = BrakeSensor_Secondary_Read();

    /* [PASS] Redundancy: Check both sensors */
    if (sensor1 == SENSOR_VALID && sensor2 == SENSOR_VALID) {
        Brake_Apply(100);  /* Full braking */
    }
    else if (sensor1 == SENSOR_VALID || sensor2 == SENSOR_VALID) {
        Brake_Apply(100);  /* Apply braking with one valid sensor */
        DiagnosticLog(ERROR_SENSOR_DEGRADED);
    }
    else {
        /* [PASS] Fail-safe: Both sensors invalid, apply maximum braking */
        Brake_Apply(100);
        DiagnosticLog(ERROR_SENSOR_FAILURE);
        EnterSafeState();
    }
}

Consequence: ASIL-B certification fails, project delayed 3–6 months

Solution:

• Human designs safety logic (FMEA, HARA, fail-safe state)
• AI assists with implementation (boilerplate, testing)
• Safety engineer reviews (mandatory for ASIL-B+)

Rule: AI cannot design safety-critical systems — the process must be human-led with AI assisting.

Pitfall 3: Ignoring MISRA Violations

Problem: Accepting AI code with MISRA violations

Example:

/* AI Output: */
uint16_t x = 10;
int16_t y = -5;
int16_t z = x + y;  /* [FAIL] MISRA 10.4: Implicit unsigned + signed conversion */

/* Engineer: "It works, ship it!" */
/* ASPICE assessor: "MISRA violations not allowed for ASIL-B" → Rejected */

Consequence: ASPICE assessment failure (CL2/CL3 not achieved)

Solution:

• Run cppcheck/PC-lint on all AI code
• Zero tolerance for MISRA violations (ASIL-B requirement)
• CI/CD fails build if violations found

ASPICE Compliance: SWE.3 BP2 (coding standards mandatory)

Pitfall 4: No Traceability

Problem: AI-generated code without @implements tags

Example:

/* AI Output: */
float CalculateSafeDistance(float speed) {
    return (speed / 3.6) * 2.0;
}
/* [FAIL] Missing: @implements tag → Can't trace to requirement */

/* ASPICE assessor: "How do you prove this implements [SWE-089-1]?" */
/* Engineer: "Uh... trust me?" */
/* Assessor: "Not acceptable." → Non-compliance */

Consequence: Traceability gaps → ASPICE CL2 not achieved

Solution:

• Add @implements tags to all functions (manual or AI-assisted)
• Auto-generate traceability matrix (scripts parse tags)
• Quality gate: Fail PR if traceability missing

ASPICE Compliance: SUP.8 (configuration management), traceability mandatory

Pitfall 5: Insufficient Testing

Problem: Using AI-generated tests only (missing edge cases)

Example:

/* AI generates 3 tests: */
TEST(Calc, NominalCase) { /* 50 km/h */ }
TEST(Calc, ZeroSpeed) { /* 0 km/h */ }
TEST(Calc, MaxSpeed) { /* 200 km/h */ }

/* Missing: Negative speed, just below max, just above max, null pointers */
/* Bug found in field: Crash when negative speed passed → €50k recall */

Consequence: Low test coverage (60–70%), defects escape to field

Solution:

• Human adds edge cases (boundary, error, equivalence)
• Aim for 90–100% coverage (ASIL-B requirement)
• Review test cases, not just coverage %

ASPICE Compliance: SWE.4 (unit verification), coverage mandatory

Pitfall 6: Skipping Human Review

Problem: Automated merge without code review

Example - Wrong Approach:

# Bad CI/CD: Auto-merge if tests pass
deploy:
  stage: deploy
  script:
    - git checkout main
    - git merge ${CI_COMMIT_BRANCH}  # [FAIL] Auto-merges without review
    - git push
  only:
    - branches
  when: on_success  # [FAIL] Automatically runs when tests pass

Correct Approach:

# Good CI/CD: Human approval required
code_review:
  stage: review
  script:
    - echo "Waiting for code review approval"
  when: manual  # [PASS] Requires human to click "Run"

deploy:
  stage: deploy
  script:
    - git checkout main
    - git merge ${CI_COMMIT_BRANCH}
    - git push
  only:
    - branches
  needs:
    - code_review  # [PASS] Requires review stage to complete
  when: on_success

Consequence: AI errors (logic bugs, security vulnerabilities) merged automatically

Solution:

• Human review mandatory (SUP.2 requirement)
• Quality gate: Manual approval before merge
• CI/CD fails if no reviewer approval

ASPICE Compliance: SUP.2 (reviews mandatory for CL2+)

Pitfall 7: Context Loss (Hallucinations)

Problem: AI invents APIs that don't exist

Example:

/* AI Output: */
CAN_ReadMessageWithRetry(0x200, buffer, 3);  /* [FAIL] Function doesn't exist! */

/* Code doesn't compile, engineer wastes 2 hours debugging */

Consequence: Compilation errors, wasted time

Solution:

• Verify API exists before using (check header files, documentation)
• Compile early, compile often (catch errors fast)
• If AI suggests unfamiliar API, validate (search codebase, ask senior)

Detection: Code doesn't compile → AI hallucinated

Pitfall 8: Gold Plating (AI Suggests Unnecessary Features)

Problem: AI suggests features not in requirements

Example:

/* Requirement: Calculate distance (v × 2s) */

/* AI Output: */
float CalculateSafeDistance(float speed, float weather_factor, bool night_mode) {
    /* [FAIL] Unnecessary complexity: Weather and night mode not in requirements */
}

/* Engineer: "Cool features, let's add them!" */
/* Manager: "That's scope creep. Stick to requirements." */

Consequence: Scope creep, schedule delays, unnecessary testing burden

Solution:

• Implement requirements only (no gold plating)
• If AI suggests extra features, ask stakeholder (may be future requirement)
• Defer to next release if not in current scope

ASPICE Principle: Requirements-driven development (Ch 33.01)

Pitfall 9: Not Measuring AI Effectiveness

Problem: Using AI tools without measuring ROI

Example:

Team uses GitHub Copilot for 6 months, but:
- No metrics collected (time saved? defects reduced?)
- No retrospectives (what works? what doesn't?)
- Can't justify renewal cost (€10/month × 10 engineers)

Consequence: Can't prove value, management cuts AI budget

Solution:

• Track metrics (Ch 36.00):
  • Time saved (before vs after AI)
  • Defect density (AI code vs manual)
  • Test coverage (AI tests + manual)
• Retrospectives (monthly): What AI tasks work well?
• Justify cost with data (ROI calculation)

Example Report:

## AI Effectiveness Report (Q4 2025)

Productivity:
- Code generation: 50% faster (10h → 5h)
- Test generation: 62% faster (8h → 3h)
- Total time saved: 35% (€112k value)

Quality:
- Defect density: 1.5 defects/KLOC (down from 2.8)
- Test coverage: 95% (up from 70%)
- MISRA violations: 0 (maintained)

ROI: €112k benefit / €2.4k cost = 47x return

Recommendation: Renew all AI tools [PASS]

Pitfall 10: Forgetting Human Expertise

Problem: Over-automating, losing human engineering skills

Example:

Junior engineer: "AI generates everything. Why learn algorithms?"
Senior engineer: "When AI makes a mistake, can you fix it?"
Junior: "Uh... no."

Result: Team dependent on AI, can't debug complex issues

Consequence: Skills atrophy, team can't work without AI

Solution:

• Use AI as assistant, not replacement (human-in-the-loop)
• Junior engineers learn fundamentals (algorithms, data structures, MISRA)
• Senior engineers mentor (explain AI output, teach debugging)
• Pair programming (human + AI collaboration)

Balance: AI accelerates execution, humans provide expertise and oversight

Summary of Pitfalls

Key Lesson: AI is a tool, not a replacement for engineering expertise and ASPICE rigor.

Next: Continuous Learning (36.03) — How to stay current with AI and ASPICE evolution

Self-Assessment Quiz

Test your understanding of common AI pitfalls. Answers are at the bottom.

Question 1: AI generates code for your ASIL-B emergency braking system. What should you do?

• A) Deploy it directly—AI is trained on safety-critical code
• B) Human must design the safety logic; AI can only assist with implementation
• C) Run static analysis, then deploy
• D) Add more test cases, then deploy

Question 2: AI generates a function but the generated code references an API that doesn't exist in your codebase. What happened?

• A) Your codebase is outdated
• B) AI "hallucinated" a non-existent API
• C) The AI used a different library
• D) You need to upgrade your compiler

Question 3: AI-generated code has 3 MISRA violations. What's the correct response?

• A) Ignore them—they're minor style issues
• B) File a ticket to fix later
• C) Zero tolerance: fix immediately before merging
• D) Ask AI to justify the violations

Question 4: Your team uses AI tools but has no metrics on effectiveness. What's the risk?

• A) No risk—AI obviously helps
• B) Can't justify ROI, management may cut AI budget
• C) AI will become less effective over time
• D) Compliance issues with ASPICE

Question 5: A junior engineer says "AI generates everything, why learn algorithms?" What's wrong with this mindset?

• A) Nothing—AI has made traditional skills obsolete
• B) Skills atrophy means the team can't debug when AI makes mistakes
• C) It's disrespectful to senior engineers
• D) Management prefers traditional development

Quiz Answers

1. B - Safety-critical logic requires human design expertise. AI can assist with non-safety implementation, but humans must lead safety design per ISO 26262.

2. B - AI models can "hallucinate" APIs that don't exist. Always verify generated code compiles and references valid APIs.

3. C - Zero tolerance for MISRA violations. Fix immediately in the current change; don't accumulate technical debt.

4. B - Without metrics (time saved, defects reduced), you can't prove ROI. Management decisions require data justification.

5. B - Over-reliance on AI leads to skill atrophy. When AI makes errors, humans must have the expertise to detect and fix them.

Score Interpretation:

• 5/5: Excellent awareness of AI pitfalls
• 3-4/5: Good understanding, review the pitfalls you missed
• 1-2/5: Critical knowledge gap—re-read this chapter carefully