It took me some time to jump aboard the AI train. When chatGPT came out, I found it useful for certain “padding” tasks; like turning a set of dot-points into a position description but it just wasn’t mature enough to be part of my daily workflow.

It took me a couple of months to notice the Claude Code hype-train, and to overcome my initial skepticism to try it out. The fact that it was a command line application removed one of the biggest barriers for me; the web interface.

These days, i generally rely on OpenAI models with oh-my-pi as the harness. Here are some of my reflections on what’s worked and what hasn’t.

The Good

AI Agents as an shopping assistant for components.

When one builds a complicated machine like a robotic system, you usually have a bunch of constraints on your components; size, weight, power, cost, etc. I usually find this process incredibly time consuming; lots of searching, filtering and reading.
When building our current robotic system, i talked through requirements and sizing with my agent, then got it to search the web for options and rank the options based on our conversation history. This then either refined my thinking about the system design, eventually coming out with candidate parts. Having the agent dump the results to a spreadsheet, with technical specs and URLs to the data sheet, drawings and store is really, really helpful when building a bill of materials.

Hardware Abstraction Layer for Embedded peripherals.

A bit of background for those not familiar with embedded software engineering. It’s pretty common for embedded devices to consist of a microcontroller (uc) that talks to peripherals like stepper motor drivers, current sensors and other chips, connected by some standard (usually serial) interface. Microcontrollers are generally too small to host a traditional operating system (and having an OS like Linux often defeats the purpose; the goal here is to be small, fast, and close to the metal), but do tend to come with manufacturer support (or via 3rd party libraries) for configuring the microcontroller itself. For the peripherals, your often only have a datasheet and, if you’re lucky, a few hobbyist open-source partial implementations.

For our toolchain (rust). Using an agent to go from datasheet to binary interface bindings has saved me a ton of time an effort. The design often needs a few guided revisions, since agents are currently bad at architecture, but the basic functionality seems to be pretty good first go.

Doing the software implementation/refactor grunt work.

Sometimes I just need a quick python script to do X, that I’ll throw away afterwards; an agent is great for that. Sometimes I have a refactoring goal in mind, and I can easily express the intended outcome (even better if i can write the example as code); agentic coding is pretty good at moving the interface across, though it sometimes likes to take shortcuts. Sometimes I’m working on a new feature and I’ve got it to the point where the skeleton is there. AI can be pretty good at putting the meat on those bones.

“Rubber duck” debugging (for mech, elec and software)

I’ve worked with some pretty great teams in my time, and one thing they have had in common is a culture of sharing the gnarly problems, seeking an outside perspective, or even just someone to talk through the issue (which helps clarify the problem and solution).

Currently, we have a engineering team of 1, so agents have been a useful (but not always reliable) stand-in. It’s helped with walking through gnarly mech, elec and software problems, even if it’s not always a reliable substitute for a human colleague on the other end.

The Bad

Poor agent usage (eg. vibe coding) undermines the intuition -> expertise pipeline.

It’s very rarely the case that you know enough about the problem before you start building, or that the understanding is implicit-unconscious, so a big part of the first draft is learning the shape of the problem, a shape of the solution, and how to articulate what that looks like (in code, or design) using the tools of the domain. As you do this, you’re constructing a map of the problem-solution space for you to come back to later, and accumulating learnable experiences. Hand that first draft to an agent instead of doing it yourself, and you skip the very process that builds the map in the first place.

This is especially the case when you’re building something actually new – even if new is cobbled out of existing parts.

Agents currently suck at software architecture.

Software engineering is full of cargo-cults, fads, and baseless extrapolation. This is especially the case when it comes to architectural decision. For me, a software architecture is an organisation of information processing that needs to fit the constraints over the expected (bounded) time horizon of the a) business/intended use case, b) compute platform and/or operational environment, c) current (and expected future) developers background.

Architecture is as much cultural and organisational as it is technical; and a problem (i would argue) is not in the purview of current AI systems.

This part of this falls into a broader mistake that we make about cognition, and how we fail to recognise just how big the gap is between what we can clearly articulate, and what we intuitively understand. How when you work with people, our intuitions ‘rub-off’ on our colleagues (and vice-versa), which goes a long way to building an strong engineering culture. Obviously, you want to document this if possible, but a culture is a living-breathing thing, and current agents can only be a peripheral tool in that respect.

Tokenenomics

Not a surprise, but the opacity of token pricing, and how quickly the price can change. Everyone knows the pricing model isn’t a sustainable business, and I’m expecting some kind of rug-pull later this year (Anthropic already did around April, which is why I’m on GPT at the moment).
Regardless of whether the model does what you want, ties itself in circles, or deletes your file system, you’re still paying for the tokens. I’ve seen some decent results come of directing a team of agents, but then the cost skyrockets pretty quickly, and I’m just not sure the payoff is there.

Conclusion

AI agents as a genuinely good research assistant, datasheet-reader, and grunt-work machine, but a pretty mediocre architect that can easily flush money down the drain. I’m very hesitant about it’s ability to work on anything truly novel or niche, but am pretty happy for it to slap together a webpage and a quick-and-dirty script.

I worry mostly about finding the balance between the questionable/circumstantial short-term gains from heavy AI use, and the long term costs of opacity (both internally and externally) and technical/organisational/personal debt – which I think should not be underestimated.