Do we still need formal requirements — or at least a human-readable system twin?
Original answer on this site:
Yes. Even when an AI can read millions of lines of ADAS code quickly, you still need formal requirements or a clear human-readable system twin.
Code alone shows what currently exists. It does not reliably show what the system is supposed to do, what is safe, or what the original intent was. In a system of this size and complexity, no one — human or AI — can fully understand all interactions, assumptions, and edge cases just by reading the implementation.
When requirements or a system twin are missing, you lose the ability to assess the impact of changes, maintain traceability for safety and compliance, verify that the code fulfills its intended purpose, and enable AI agents to reason about correctness rather than just describe current behavior.
Bottom line: For safety-critical systems like ADAS, “just read the code” is not sufficient. You need an explicit, human-readable layer above the code that captures intent, goals, and constraints.
Ready-to-Use Discussion Prompt
Copy the prompt below and paste it into any modern LLM (Grok, Claude, GPT, Gemini, etc.). It is specifically written for Automotive contexts and produces structured, team-ready discussion output.
You are a senior Automotive Systems Engineer and Requirements Architect with 15+ years of experience on ADAS and Software-Defined Vehicle programs. You have deep knowledge of ASPICE, ISO 26262, homologation, product liability, and multi-tier supplier collaboration. You also understand modern AI-assisted engineering practices and the tension between speed/innovation and required rigor.
**Core Question:**
Do we still need formal requirements — or at least a human-readable system twin — in the Age of AI for Automotive systems?
Write a clear, balanced, and practical discussion that helps real engineering teams (systems engineers, software architects, safety managers, and project leads) understand the topic. Structure your answer exactly like this:
**1. Short Direct Answer**
(One concise paragraph with a nuanced position — not a simple yes/no.)
**2. Why “Just Read the Code” (or AI-Generated Code) Is Not Sufficient**
Explain the gaps in intent, safety goals, assumptions, edge cases, traceability, change impact analysis, compliance evidence, and cross-organizational understanding.
**3. What a Human-Readable Requirements Layer or System Twin Actually Delivers**
Describe the concrete value of an explicit intent layer (formal, semi-formal, or structured) and/or a living system twin / digital thread — especially how it makes AI agents more useful rather than replacing human responsibility.
**4. AI’s Real Capabilities and Hard Limitations in This Domain**
Cover where AI helps today (drafting, analysis, consistency checks, impact prediction) and where it still falls short (hallucinations, accountability, long-term drift, regulatory defensibility, and liability).
**5. Automotive-Specific Examples**
Provide 2–3 realistic scenarios from ADAS or SDV development (e.g., introducing a new sensor, changing a communication matrix, creating architectural variants across vehicle lines, or updating a safety-critical function). Show what typically breaks or becomes expensive/risky without a clear requirements or system-twin layer.
**6. Pragmatic Recommendations for Modern Automotive Development**
Give actionable advice on how organizations can reduce requirements effort while remaining safe and compliant. Include thoughts on traceability strength, model-based elements, AI-augmented workflows, and different formality levels depending on criticality (ASIL).
**7. Key Takeaways + Workshop Discussion Questions**
Summarize the non-negotiables and list 5–6 sharp questions teams can use in architecture reviews or process workshops.
Use precise, engineering language. Avoid hype or marketing language. Ground the reasoning in the practical realities of the V-model (or equivalent), homologation, supplier ecosystems, and product liability. Reference general principles from ASPICE and ISO 26262 without inventing specific clause numbers.
At the very end, provide **three ready-to-copy follow-up prompts** that allow deeper exploration of specific angles (for example: tool & process recommendations, designing a pilot, or creating a lightweight system-twin approach).
The prompt is deliberately structured to produce consistent, high-quality output that teams can actually use in workshops and architecture reviews.
How to Get the Most Out of This Prompt
Copy the full prompt above.
Paste it into your preferred LLM.
Optionally add context at the end: “Focus on ADAS Level 2+ Highway Assistant” or “Consider our current ASPICE Level 2 situation and supplier landscape.”
Use the generated 7-section output as a basis for team workshops, architecture reviews, or internal alignment sessions.
Run the three follow-up prompts the model provides to go deeper on tools, process changes, or pilot design.
What Kind of Output Should You Expect?
The prompt forces the model to deliver a balanced, engineering-grade discussion instead of generic advice. Typical output includes:
Clear positioning on when formal requirements remain non-negotiable
Concrete Automotive examples (sensor changes, communication matrix updates, variant management)
Honest assessment of AI strengths vs. limitations in safety-critical work
Practical recommendations that respect ASPICE, ISO 26262, and homologation realities
Ready-to-use discussion questions for your next architecture review
Ready to bring clarity to your requirements strategy?
Vibe System Engineering helps Automotive teams keep strong traceability and compliance while dramatically reducing documentation effort — even when using AI tools.