The Prototype Is the Easy Part

Where AI shines and where it doesn’t.

Asked point blank whether the software team should simply be handed over to AI, the answer was immediate: absolutely not. Used well, the tools make an experienced team faster, and the output beats what someone brand new to firmware could produce. Where AI shines is helping people get from zero to one, standing up a prototype good enough to prove what works and find early traction. It is even handy for putting a rough vision on screen, generating several versions of an idea in minutes so the right one becomes obvious. Turning any of that into something dependable is still the engineer's job.

A working prototype is not a reliable product.

The hardest part of the shift is expectation. It is easier than ever to show something on a screen, so it is easier than ever to assume the rest will be quick. It will not be. A lot of the work is helping clients see, with real examples, where things go wrong and what it actually takes to make a product reliable and ready to scale. That is usually the point where a project moves from a promising demo toward design for manufacturing.

AI is great at finding edge cases. Owning them is human work.

On the testing side, the tools are strikingly good at surfacing edge cases, including plenty that were never in scope for the job at hand. That is genuinely useful, but it changes the work rather than removing it. The open source world is feeling the same thing, with maintainers sorting through a flood of machine-generated contributions. Finding the edge case is cheap now. Deciding which ones matter, and standing behind that call, is still on people.

Build with AI, but ship something deterministic.

One habit worth copying: use AI to build a tool, then let the tool itself be deterministic and run it as part of the workflow, rather than handing everything to a model and asking it to figure the whole thing out. That instinct to contain the flexible part and make the rest predictable carries straight into how you plan a program and decide what to do next. Flexible where you need it, dependable everywhere else.

The hard problems are the fun ones.

The projects the team lights up over are the genuinely difficult ones. A flame cannon built for stage effects was tested on a bench in a version that did not actually produce fire. Cameras and measurement systems built to work underwater. A custom chip they designed to measure neural activity in mice, which is a masterclass in squeezing real work into almost no power and almost no space. The common thread is difficulty on purpose, whether that means a mission-critical system, a tight power and size budget, or pulling a clean signal out of a genuinely noisy environment.

Empower people, or make them miserable.

The favorite engagements for Product Insight do not arrive with the solution already chosen. They start with a real problem and a real workforce, often at a large scale, where the goal is not to swap everyone out for a full robotic system but to put people and machines together so the people are better at their jobs. The line between empowering someone with automation and making them resent it is subtle, and walking it well is most of the work. Keeping a human in the loop is not a limitation here. It is the point.

A small team where everyone owns the culture.

Inside a small company, there is no room to sit back and wait for someone else. Any one person can shape the culture, which is why the team is built to notice a problem and go solve it rather than just flag it and move on. Leadership models the behavior it wants instead of mandating it, and that same confidence is what lets even newer people sit directly across from a client. It is a culture of ownership, and it shows up in the work.

Being in a niche is the whole advantage.

Focus is a feature. Working deep in a narrow domain makes it fast and obvious whether a given problem is the right one to take on, instead of stretching to fit anything that comes along. Pair that with a willingness to question the brief and ask why a thing is being built before building it, and you get a partner that is honest about fit from the very first conversation. The clearest engagements are the ones where both sides can tell, quickly, that it is a match.

If you have a problem but no solution yet, that is the best time to talk. The work these teams do best starts before the answer is obvious, when there is still room to figure out the right mix of people, automation, and hardware, and to pull the pieces together into something reliable enough to build on. Test what is worth building before you commit to it.