"AI-native engineering" is easy to claim and hard to make concrete. Here's specifically where large language models change the work in a hardware/firmware/cloud product engagement — and where they don't.
The site already states publicly that "AI accelerates the engineering process at every layer under senior human review" (see The AI/Human Split). This article makes that claim concrete: specifically where large language models change our day-to-day work, and where they don't.
We lean on LLM-based coding assistants for scaffolding — generating boilerplate automation scripts, cloud/API code, and structured state-machine implementations for device and application logic. It's the kind of structural, well-specified typing that an LLM handles reliably, and it saves hours that would otherwise go into writing repetitive scaffolding by hand.
LLMs are actively unreliable for timing-critical RTOS tasks, register-level hardware manipulation, and safety-critical logic. Our senior human review step is specifically looking for the failure modes an LLM won't natively reason about in a bare-metal context — hallucinated memory allocation, and race conditions in concurrent or interrupt-driven code. This is exactly the kind of work covered in RTOS vs. bare-metal and firmware security, where correctness can't be delegated.
This is in active use, not aspirational: we run a local LLM-based retrieval-augmented generation (RAG) pipeline to ingest and query component datasheets and reference manuals, rather than relying on manual keyword search across hundreds of pages of vendor documentation.
During the architectural planning phase of a recent embedded project, we used this internal RAG setup to query hardware vendor datasheets directly, cutting down the time spent on hardware selection and pin-muxing research by a significant margin. See our AI & intelligence work and the AI/human split page for how this fits into the broader engagement.
