Intent and Context Capture in Hardware Design

Two things that made me smile

Last week I moved into a new place and unpacked some boxes that have been in storage three years. A few things gave me a wry smile:

The first: a custom-built propellor balancing stand, complete with IMU and Arduino. Balanced props mean low vibrations and smooth footage. Not long after I finished building this thing, DJI started shipping perfect props… 2014 equivalent of building scaffolding for LLMs 💀

Second: a pile of handwritten log books from 2011-2018 (my hardware R&D days). Their purpose was to capture thoughts, ideas, calculations, revisions, sketches, etc., as I designed and tested hardware. Today they serve as a handy segue into today’s bit…

Intent and context capture in hardware design

To understand why this is really worth thinking about, I’ll lean on software engineering and 3D geometry (CAD) again. When building software, engineers dutifully leave a structured breadcrumb trail explaining their intent, discussions and other context as they iterate (commit messages, PR descriptions and discussion threads); this has been AI training gold dust.

In mechanical component design, by contrast, we convert hundreds of clicks into ‘part trees’ which define solid models. Maybe some sketches entombed in a Black n’ Red book. Let’s call this incredibly ‘lossy encoding’ of engineering design intent into object. Not great for future human engineers who pick it up later, terrible for AI models in both training and inference.

A CAD model is a frozen answer and the missing artifact is the trail of questions.

Software engineers are taking very seriously the questions of how to capture and prepare context. Context is, after all, everything for AI agents. Companies are spawning to create the next Github for the AI age. This post is not about “but we don’t even have Github for the last age?!” but we can come back to that.

Two approaches

I’ve been having lots of interesting conversations on this recently and there’s a couple of approaches floating about:

Digital comms mining: take the bet that the context lives somewhere—Slack, emails, meeting transcriptions. Go digging and reconstruct the intent and evolution.

This camp is betting that Slack/email is a sufficient substitute for a proper engineering log.

Engineering workflow: take the alternative view that afte-the-fact reconstruction won’t be sufficient, and devise a way to digitally capture the design context in real time.

The hard part: capturing context without turning engineers into scribes.

My gut says we might have to contemplate the second camp seriously. I spent a good chunk of 2025 sifting through chaotic unstructured data in search of signal and humbly conclude that it ain’t easy. That said, I’m not onboard with the maximalist version where engineers wear recording devices all day.

Two non-negotiables

For (2), I hold two things as non-negotiable:

Simply instating a rule that “engineers must document their working” won’t do—it’s always been the rule anyway!
Any new workflows must be strictly value-adding to the engineer’s day, otherwise they are just rules dressed up as a product.

The value nugget

Rapid and helpful design feedback might be that value nugget—like a linter for mechanical design.

Examples: “this fastener is unreachable with standard tools”, “this tolerance stack is implicit but critical”, “your interface hole pattern drifted from the mating part”.

Tell me where I’m wrong!