Embedded system development before and after AI

Yes, it's in use, mostly Claude, via CLI or a VS Code plugin, with Codex and others also tested. Product development runs through 70–80 skill sets and the steps don't disappear; AI shortens the time between iterations. Biggest impact is on the coding side, which is becoming scary good.

Layouting, component placement, component selection and reading datasheets. Most models read datasheets badly and make a lot of mistakes. Telling AI to "build me something" end-to-end is nowhere close.

Rule inside the chip company: neither AI-written code nor founder-written code goes into production, one hallucinates, the other gets distracted. The first chip was designed from 2023, when GPT-4 was still toy-level for hardware code, and Verilog has too little public data for models to learn from. From the second chip onward AI is used for exploring designs, writing Python models that mimic Verilog for fast parameter sweeps, building tooling that crawls compiler logs, and generating developer documentation. A lot of chip design is manual work, write a tool that iterates over it and run it overnight so people can sleep.

Board bring-up is the most painful part of product development, hardware blames firmware, firmware blames hardware, and sometimes it just won't work. Even being pointed in the right direction can save days of hunting for a small thing in some corner of the board.

Start small, with problems you would have done yourself.

Fundamentals haven't moved; Google interviews still ask time and space complexity. Think in systems: when you declare an array in C, know what happens through L1/L2/L3 to DRAM, down to the capacitor level. Then pick a project that optimises a model for specific hardware, physical AI and robotics are the next stage, with 15+ companies having raised $500M+. Do an internship on a real hardware product, even if the work is validation, verification, test-case generation or log analysis.

Same answer: build system-level thinking, then bridge it with AI. The rare and valuable person understands both how models and inferencing work and how firmware and embedded systems work. Very few people can do both today.

Hands-on hardware work, solid fundamentals, lab access, and the ability to take a problem statement and figure it out. Companies aren't short of people who'll do grunt work; they're short of people who ask questions.

Mongol analogy: it's easier to teach a horseman to shoot than to teach an archer to ride. So learn the hardware first, the physics of how electronics works, build boards, burn a few, smell the smoke of cooking chips. Then write low-level code against different hardware. FPGA is its own skill (it's hardware design). Don't chase a specific technology; the core muscle is losing the fear of hardware. One panelist learned GPU programming only because he needed to write a ray tracer, the skill came from the problem, not the other way round.

Learn to use a solder gun. If you've never soldered anything or burned something, you can't call yourself an engineer. Know differential ground, eddy currents, T-states. There is no replacement for fundamentals.

Motors, especially BLDC. Feedback control systems. Electromagnetics and how antennas work. Microcontroller basics. Mathematics, Fourier transforms and filters for signal processing, some on the hardware side and some on firmware. Go back specifically to the subjects you found hardest. A four-year degree's worth can be brushed up in a couple of months.

Engineers aren't writing less code, they're writing less meaningless code. Removing boilerplate has been the goal of every development framework ever; that was Arduino's whole promise. Debugging sessions that ran for sleepless days now run for hours. That's productivity, not replacement. The engineer's real job is architecture and stitching a system together, it was never about the code.

More. There's a set of engineers who do grunt work and are happy doing it, and a set who want to do the innovative work AI can't, and that starts with the ability to ask good-quality questions, or just being curious enough.

The premise doesn't hold anymore. More companies are building hardware products across defence, space and medical. All the panelists' companies have open positions. The one question worth asking of any internship: will I get to use a lab? If yes, run to it and experiment as much as possible. Books and tools for fundamentals are freely available; lab access isn't.

It has to. We've gone from encountering an electronic device every few days to being unable to take ten steps without one. Even a document-signing dongle is a chip, a layout, security requirements and a full product lifecycle. And there are products nobody has thought of yet, India's shortage of manual labour will pull robots in, and curiosity will pull new categories out.

Hardware will be there, humans will be there, AI will be there. This decade belongs to deep tech and hardware. The engineer who shines is the one who can hold the architecture in their head and think at the meta level. If you're scared of AI, treat it as a partner, humans are still needed to think, to be creative, and to ask pertinent questions.

Automotive is growing, not lagging. A car is a moving data centre with ~100M lines of code, multiple HPC zones, ADAS, OTA and infotainment. Every automotive chip released in the last few years has an NPU, even brake controllers now run a model for ABS. Automotive has a reputation for being slow but moves fast when it wants to. Wherever intelligence moves into software, software-defined vehicle, software-defined defence, and earlier software-defined networking, that's where the pull is.

Physical AI is real. 700+ startups in India are working on drones or robotics. Defence has heavy tailwind, with new hardware being made AI-ready. Avionics companies are adopting AI too, not at code level but on compliance process, like getting to DO-178C faster.

The demand shows up as system-side work: porting code between architectures, refactoring legacy monoliths to service-oriented designs, modernising software so it can actually exploit new hardware. As hardware fragments, the software work multiplies.

Yes, the speed at which Chinese companies are rolling out cars and software is putting pressure on everyone to respond.

A tabletop version, yes, something on a bench that works. Something you'd wear, no. Taking a product to market is a different problem.

A medical product used to take 2–4 years from ideation to market depending on complexity. Hardware is iterative, you rarely get the board or the EMI/EMC compliance right first go, and there are usually one or two iterations. AI compresses individual steps: tuning a BLDC motor took about a month, now half that or less. Code review is better too. But the steps themselves don't disappear.

Out of your control. US FDA, EU MDR, and CDSCO in India (getting stricter), with more countries adding their own regimes. Regulatory bodies take the time they take. Your engineers just get more done inside that window.

If you were a pianist in an orchestra, AI will play the piano a little better. You get better at orchestration, the harmony, the symphony, and doing more with it.

Three things. It's purpose-built for embedded and firmware rather than general purpose, powered by an in-house model called SPARC whose training recipes and data approach are open-sourced on the website. It has a context engine that ingests datasheets, schematics, BSPs, HDKs and C code, with 5,000+ peripherals and SoCs from ST, NXP, Qualcomm and Broadcom pre-indexed offline, so retrieval is fast and doesn't burn tokens on repeated grep-and-search. And it ships domain plugins, like UAV log analysis and binary file analysis. It also generates MISRA-compliant code for automotive and DO-178C for UAV.

Making the model aware of physics, timing, latency, power, energy, voltage, thermal, memory, so generated code is deterministic and verifiable on the target hardware, including its compilation and execution environment. The name stands for Hardware and Human in the Loop; the point is code that actually runs on the board.

No model training required. Feed it the SoC/MCU datasheet, reference board documentation, any existing HDK or BSP, and constraints like power management requirements. It derives context from there and helps with board bring-up, I2C/SPI drivers and sensor data handling. It runs as an agentic framework, effectively 10–15 orchestrated co-workers across tasks. The more information you give it, the better the output.

Not answered on the call. Noted only that embedded interfaces are generally CLI or a VS Code plugin.

Chips are in hand; last-minute board issues and supply chain are the holdup. No order link will go up without stock, a reasonable price point and a reasonable lead time. Shortest possible time. A medical product built on a Mindgrove chip is also on the way to hospitals.

Not answered on the call.