Software used to be something many hardware teams requested and then waited for.
That arrangement is starting to change.
AI coding tools have moved from novelty to everyday workflow for many developers. According to JetBrains, 85% of developers now use them as a regular part of writing code. But the more interesting shift may be happening outside traditional software teams, where engineers in adjacent disciplines are using AI tools to build small utilities on their own.
For hardware engineers, that can matter because physical product development often moves through tight dependencies. A sensor test, material decision or measurement problem can stall while a team waits for a custom tool that may only be needed once.
Clayton Haight is director of robotics hardware at Sunday Robotics, where he leads mechanical, electrical and manufacturing engineering for wearable data devices and a home robot. His background includes hardware work across electric vehicles, delivery drones and neural interfaces.
Haight has argued in print that most jobs sit further from automation than the headlines suggest. His own workflow points to a related idea: AI coding tools may not replace technical workers so much as give them new ways to remove bottlenecks in their own work.
The wait that slows hardware down
Hardware decisions often have to happen in sequence. A team may need to test a sensor, compare a material, validate a measurement or inspect a data stream before moving to the next design step.
Traditionally, that kind of work could require help from software engineers. Even a small internal utility might need to be described, prioritized, built and revised before the hardware team could use it.
AI coding tools change that calculation. A hardware engineer can describe the tool they need in plain language and get working code quickly enough to test an idea, inspect a signal or answer a narrow design question.
That does not mean software teams become unnecessary. Production systems, core infrastructure and customer-facing software still require engineering review and long-term maintainability. But for small, temporary tools, the barrier is lower than it used to be.
At Sunday Robotics, Haight has used AI coding tools to build utilities that support hardware decisions without turning every request into a formal software project. The value is not that every tool becomes permanent. It is that some tools can be useful precisely because they are disposable.
Disposable tools built for one decision
Speed is what makes one-off tooling more practical.
In controlled testing, developers using an AI assistant finished a standard programming task 55% faster than those working without one, according to GitHub research. For engineers outside software roles, the benefit can be less about writing production code faster and more about creating tools that would not have been worth requesting before.
One example is sensor testing. If a hardware team needs to evaluate a sensor that is not yet supported by a company’s main data pipeline, waiting for a full integration may slow the work down.
A lightweight visualizer can be enough to read output, plot the signal and help determine whether the component is suitable. Once that decision is made, the tool may no longer be needed.
That kind of temporary software can change the rhythm of hardware development. Instead of waiting for a formal pipeline to support every question, engineers can build small instruments around the specific thing they need to understand.
Using data to settle hardware debates
Hardware teams often make material decisions based on a mix of experience, testing and judgment. But when a product is worn, handled or used repeatedly, those choices can affect comfort, durability and long-term usability.
Haight has written that the cost of producing working code is collapsing toward nothing. In a hardware lab, that can show up as a willingness to build custom analysis tools for questions that once might have been settled more informally.
For example, comparing material options can become more data-driven when engineers can quickly generate a tool to organize measurements, visualize trade-offs or compare results side by side.
The point is not that AI-written software replaces physical testing. It is that it can make it easier to turn test results into usable decisions.
That matters because hardware mistakes can be expensive. Once tooling, manufacturing choices or supplier decisions are made, changing direction can cost time and money. If a simple analysis tool helps a team make a better decision earlier, the value is not in the software itself. It is in the avoided mistake.
Designing for real-world variation
Wearable hardware creates another challenge: human variation.
A wearable device has to fit the person using it, not just the person who designed it. Hand size, finger length, width and proportion can vary widely, especially when a device is intended for use by a large and distributed group of people.
In that context, measurement tools become part of the design process. Haight has used AI-assisted software development to create utilities that estimate hand dimensions from a photo using a credit card in the frame as a reference for scale.
That kind of tool can help hardware teams compare design assumptions against a broader set of real-world measurements. It is not a replacement for formal validation, but it can make early design work more informed.
The larger lesson is that AI coding tools can help hardware teams create the measurement systems they need at the moment they need them. Instead of relying only on the small group of people physically present in a lab or office, teams can collect and evaluate more varied inputs earlier in the design cycle.
When the tooling barrier drops
The spread of AI coding tools suggests this shift is still early.
The market for AI code tools is projected to grow from roughly $7 billion in 2025 to nearly $30 billion by 2031, according to Mordor Intelligence. Much of that market will serve software developers, but the effects are likely to reach other technical fields as well.
For hardware engineers, the change is not simply that they can write more code. It is that they can ask more questions.
If a custom utility takes days or weeks to obtain, only the most important requests make it into the queue. If a rough tool can be created in an afternoon, smaller questions become worth testing.
That can soften the boundary between hardware and software work. The core disciplines remain distinct, but more engineering decisions can happen in one workflow instead of waiting for a handoff.
The most valuable skill may become knowing what to measure, what tool is needed and where a quick utility is good enough versus where a production-grade system is required.
AI coding tools will not remove the need for software engineering judgment. But they may give hardware teams a faster way to explore, test and validate the physical systems they are already responsible for building.
As those tools become more common, the biggest change may not be that hardware engineers become full-time programmers. It may be that they stop waiting for software to answer every small question.
©2026 Cox Media Group
