Every automotive software organization has now run the same experiment. Roll out a coding assistant, watch the velocity metrics on greenfield utility code go up, get excited. Then point it at the real work — an ECU function with safety requirements, an interface defined in the architecture model, coding rules from a standard the agent has never been told about — and watch it produce fluent, plausible, unshippable code.
The agent isn't the problem. The problem is what it can see. In most automotive organizations, everything that defines "correct" lives outside the repository: requirements in Polarion or DOORS, architecture in an MBSE tool or a PDF export, safety constraints in the ISO 26262 work products, hardware behavior in a 400-page datasheet. The agent gets none of it. It sees code and comments, and it fills every gap the way language models fill gaps: confidently.
In consumer software, a wrong guess costs a code review comment. In our world, it costs more — because the code must not only work, it must be traceable to a requirement, conformant to the architecture, and defensible in front of an assessor. Context-starved AI doesn't just write worse code in automotive; it writes code that cannot enter the V-model at all.
So the teams getting real leverage from agents aren't the ones with the best prompts. They're the ones who fixed the plumbing: connected the ALM to the IDE, made architecture and standards machine-readable, and gave agents the same context they'd give a new senior engineer on day one.
What actually fixes this
Three categories on this marketplace close the context gap. All listings are curated; we introduce you to the right one for your setup.
Requirements Engineering
Connect requirements to the IDE
The fastest fix: expose your existing ALM to the agents your engineers already use. MCP servers and AI-native requirements platforms make requirements readable — and traceable — from inside Claude, Cursor, or Copilot.
Listed here: ATOMS (MCP server for Siemens Polarion), trace.space (AI requirements platform, air-gapped deployable).
Browse Requirements tools →
ASPICE & Compliance
Agents that know the standard
Instead of hoping a generic copilot respects ASPICE and ISO 26262, use agents configured for them — auditing requirements, validating architecture conformance, and generating test specs with traceability built in.
Listed here: AI Agents OS — 20 Claude Code recipes for automotive compliance, SWE.1–6 coverage.
Browse ASPICE & Compliance tools →
Hardware-Aware Coding Agents
Firmware without hallucinated registers
For embedded work, the missing context is the hardware itself. Hardware-aware agents index datasheets, schematics, and pin maps so generated driver code refers to peripherals that actually exist — and can be flashed and tested in the loop.
Listed here: Embedder — hardware-aware coding agent for embedded systems (STM32, ESP32, nRF52, NXP, RISC-V).
Browse YC Startups →
On the marketplace, use the filter pills above the grid (Requirements, ASPICE & Compliance, YC Startups) to jump straight to these categories.
Frequently asked
Why do AI coding agents underperform in automotive?
Because the context that defines correct automotive code — requirements, architecture, ASPICE work products, ISO 26262 constraints, hardware datasheets — lives in systems the agent cannot reach. An agent that only sees the repository is guessing at everything that makes the code shippable in a regulated environment.
How can a coding agent access requirements in Polarion or DOORS?
Through integration layers such as MCP (Model Context Protocol) servers that expose ALM data to AI assistants in the IDE — for example ATOMS, listed on this marketplace, which connects Siemens Polarion to Claude, Cursor, and GitHub Copilot. The alternative is moving to an AI-native ALM where the data is agent-accessible by design.
Can AI-generated code be used in ASPICE or ISO 26262 projects at all?
Yes, if the surrounding evidence holds: traceability, architecture conformance, review records, test coverage. Code generated with knowledge of the requirement and architecture can carry traceability from the start, and compliance-focused agents can generate the supporting work products alongside the code.
What about embedded code — can agents handle hardware-specific firmware?
General agents routinely hallucinate hardware registers because they have never seen the datasheet. Hardware-aware agents — such as Embedder, listed here — index datasheets and schematics so generated driver code refers to registers that exist, and can be tested against real hardware.