I’m a perception engineer learning mechanical design in my free time. It started small. I wanted custom parts to organize things at home. Somewhere along the way it changed how I see the world. Now I look at every object and ask: how was this designed? How would it be made?
And it feeds straight back into my actual work. If you’re a perception engineer and you can design a camera mount that survives vibration and speed on a drone or a mobile robot, your whole stack gets better. Vibration means motion blur, rolling shutter artifacts, and calibration drift. A mount that holds the sensor rigid under load is not a mechanical detail. It is perception infrastructure. And now it’s another area that can be optimised.
The same applies to using LLMs for design. Yes, they can generate CAD. But you still need to understand the design process yourself: tolerances, fits, materials, manufacturing constraints. Otherwise you cannot prompt the model correctly, and you cannot judge whether the output can actually be made. LLMs amplifies your knowledge. It does not replace it.
This matters beyond robotics too. Non-tech industries like design and manufacturing are about to need engineers who can build AI tools that make them faster. The people who understand both domains will be the ones building those tools.
Software, perception, mechanics, manufacturing. The walls between them were always artificial. @IlirAliu_ is right that building things requires a working knowledge of the physical world. I’d add this: it also makes you better at the software side. Knowing how things are made makes you better at making machines that think.
if you’re in software, learn manufacturing.
software coding is not going away.
but the next decade will increasingly be constrained by what we can actually build.
materials. tolerances. machining. tooling. assembly. quality. supply chains. automation. production systems.
building things required a working knowledge of the physical world.
that knowledge matters again.
learn how things are made.
learn materials.
learn tolerances.
learn processes.
learn production.
you can’t patch a bad tolerance stack in production.
you can’t scale a product if nobody knows how to make it repeatedly, cheaply, and well.
manufacturing is what turns that intelligence into robots, machines, vehicles, energy systems and infrastructure.
technology cannot be just coded.
it needs to be manufactured.
@lukas_m_ziegler This reminds of one of my old projects where we trained a model to take a sequence of BEV occupancy grid maps as input and output controls which acted as the mean for an MPPI.
@MiaAI_lab Can you also do the same comparison with DSv4-Flash? Curious how the native precision weights will perform compared to the newer quantized models.
@MiaAI_lab Yep. It’s especially helpful to debug how AGENTS.md instructions impact your output.
P.S> The best AGENTS.md is no AGENTS.md or as minimal as possible.
Every time my agent makes a mistake this is the prompt I use to identify the point of failure:
Review the immediate context you had available while working on the last task.
Specifically:
1. Reconstruct what information, files, instructions, and constraints were visible or active in your context at that point.
2. Describe what the “L1 files” looked like from your perspective, including their structure, contents, and relevance to the task.
3. Identify any instructions, file organization, naming, or context that may have been ambiguous, contradictory, incomplete, or potentially confusing.
4. Explain how those confusing elements could have affected your reasoning or execution.
5. Suggest concrete ways to make the context, files, or instructions clearer for future runs.
Be specific and grounded in the actual context you observed. Do not speculate beyond what was visible to you.
Hot tip: you can ask your agent to verify its own work and catch issues. The trick is to do the verification in a separate, clean session.
You can also specify which model and reasoning effort to use for the review, and who should fix what it finds.