---

AI is changing software development quickly. Embedded systems are harder: generated code still has to run on real processors, interact with real hardware and behave correctly under timing, resource and physical constraints that no model can simply assume.

At Accemic, we build the infrastructure that connects AI-driven development with what actually happens on the target. The work spans processor trace, FPGA systems, high-throughput data processing, runtime analysis, coverage, requirements and verification - often as parts of the same engineering problem.

CEDARtools.Forge is one expression of that direction. The goal is to make embedded development loops increasingly autonomous without making the generator responsible for judging its own work. Code and tests can be created and refined at machine speed; independent evidence from real target execution provides the ground truth; an external convergence layer decides whether the required criteria have actually been met.

Building that requires much more than an AI application. It means getting data reliably out of processors, moving and processing multi-gigabit streams, reconstructing execution from trace, relating machine behavior back to source code and requirements, defining measurable acceptance criteria, and integrating all of it into development systems that can iterate automatically.

We are a focused engineering team working with highly capable AI agents across these areas. The agents are already part of how we develop software, analyze problems, research, document and review. That changes what individual engineers can take on - and makes broad technical judgment more important, not less.

Broad technical challenges, no narrow slots

Our work crosses traditional role boundaries. The same person may work on FPGA logic, an agentic development workflow, a trace decoder, a coverage problem and a customer’s board bring-up in the same week.

What the work actually is

• Building the evidence and convergence infrastructure that allows AI-driven embedded development to iterate against measurable behavior on real target hardware.

• Designing agentic engineering workflows in which requirements, generated code, independently generated tests, target execution and acceptance decisions can feed the next development iteration.

• Decoding and encoding trace protocols such as Arm^® CoreSight^™, Infineon^® MCDS, Intel^® PT and RISC-V^® E/N-Trace.

• Designing FPGA architectures and software pipelines for sustained multi-gigabit stream processing, where latency, bandwidth and resource budgets are part of the system architecture.

• Reconstructing program execution from processor trace and mapping machine-level evidence back to source code, requirements and verification objectives.

• Developing runtime-analysis, coverage and verification methods with functional-safety, certification and tool-qualification constraints such as ISO 26262 and DO-330/ED-215 in view.

• Working across hardware and software boundaries: processors, debug and trace infrastructure, FPGA logic, host-side processing, analysis algorithms and the interfaces between them.

• Bringing up trace and debug infrastructure on customers’ boards, where the schematic and reality sometimes differ - and finding out which one is wrong is part of the job.

• Exploring what engineering responsibility, independent verification and measurable acceptance need to look like when increasingly large parts of development are performed by AI.

What it is not

This is not a large organization with predefined roles and narrowly separated responsibilities.

We do not divide problems neatly into “AI”, “software”, “FPGA”, “verification” and “systems” and hand each part to a different department. Many of the problems we care about exist precisely at the boundaries between those disciplines.

If you prefer a clearly bounded position with a fixed technical scope, this environment is unlikely to be a good fit.

Interested?

We are not currently recruiting through unsolicited applications.

We also do not currently offer internships, working-student positions or thesis supervision. That is a capacity decision, not a judgment about the applicant: doing any of them well takes engineering time we do not have right now.

Exceptional technical work can still get our attention. Show us something you have built, published, analyzed or explained: a public project, a technical article, a difficult hardware or software problem you solved, or a strong contribution to a relevant open-source project. Send links rather than summaries: a repository, a paper, a write-up, a measurement we can look at ourselves. Work we cannot open tells us very little, however well it is described.

It does not have to be work for Accemic or a contribution to one of our repositories. Please do not build something for us just to apply - existing work is enough.

Contributions to Accemic repositories are governed by the respective repository’s contribution terms and are considered independently of any employment discussion.

What interests us is evidence of how you think, build and solve difficult problems - particularly when the problem does not fit neatly inside one engineering discipline.

We hire rarely and are not currently running a formal process. If building the foundations for AI-driven embedded engineering sounds like the kind of problem you want to work on, write anyway - a short mail with links is enough.