Industrial Robotics
By Clark Jeria, Co-Founder Andes Path
Of course we use AI tools, but “use” is a very vague term. I want to be very specific about what we mean by it, because the gap between using it well and using it badly is not always obvious from the outside. In the environments we build for, including robotics, physical automation, and manufacturing floors, that gap creates very real consequences.
I coach our teams here at Andes Path to think about AI through two lenses. The first is mechanical: understanding how LLMs actually work, not as a black box, but as probabilistic, stochastic machines that take tokens, calculate embeddings, and predict the most likely next characters based on a training set and learned weights. As with any regression, extrapolations beyond the data are risky if done blindly. It remains unclear whether AI tools can be said to reason, but it is clear that they’re imperfect.
The second lens is practical: LLMs are genuinely excellent tools for synthesis, research, prototyping, and implementation. Every engineer on our team uses them constantly. We have gone from using them in a chat window, to integrating with the terminal, to working directly in the IDE. The velocity gain is real. On a recent client project, we identified a compression protocol for LIDAR that could improve their data processing speed and memory usage by over 50%. We implemented the full refactor across the product in a week. Without LLMs, the client’s timeline would have been impossible.
But the compression protocol decision was ours. The judgment about whether the change was worth it, whether the timing was right, whether the tradeoffs made sense: that was human. The LLM made the implementation fast. It did not make the decision.
This is the line I think about constantly. I have watched clients let the LLM become the manager: driving design decisions, writing requirements, setting direction, with nobody questioning whether the output was correct. In one case, a client engineer had added a system requirement regarding data logging. When we dug to understand where that came from, the answer was essentially: Claude suggested it. Nobody had validated it with a user or operator of the interface we were designing. Nobody had evidence for it. Neither their engineer nor Claude were in the loop with the real use case. They were downstream from it.
I’m a fan of Yann LeCun. He has been making a related argument in his work on next-generation AI architectures: that the key challenge for AI systems is not generating better outputs, but developing genuine representations of how the world actually works, rather than patterns of how it has been described. His point is that understanding the architecture of these systems matters more than knowing how to use their outputs. I would extend that directly into engineering. An engineer who understands why LLMs produce confident wrong answers in low-training-data domains will either catch the failure before it ships, or never abdicate the task to the LLM in the first place. In contrast, an engineer who treats the model as a black box will ship what they’re given, and the LLM will probabilistically applaud them for it.
This is where our robotics background at Andes Path becomes relevant in ways that were not obvious even a few years ago. When you run a fleet of robots over intermittent cellular connections, you cannot let an unvalidated assumption about hardware behavior make it into production. You develop habits: skepticism about model outputs, insistence on testing against reality, and discipline around what you trust automatically versus what you verify. Those habits transfer directly to working with LLMs on complex systems.
Most of our clients are building at the frontier of their industries. That's the nature of Frontiers Engineering. The frontier, by definition, is where the training data runs out. If your team is inventing something genuinely new, a probabilistic machine that learned from the past is not going to have all the answers, and treating its “what you should do” outputs as ground truth is the fastest way to build confidently in the wrong direction. The judgment gap that creates has to be filled by people who understand both the domain and the technology.
We are strong advocates for AI tools. We use these tools seriously, throughout the project lifecycle, for research, design, prototyping, coding, testing, and documentation. What we insist on is that every engineer on our team understands the mechanism well enough to know when the decision belongs to them, not the AI. In the systems we build, that has become an essential engineering requirement.
