DeepSeek Harness Gives LLMs a Pair of Hands — and a Path to Automating AI Hardware Prototyping

1. First, Let's Talk About the Difficulties in Our Industry

Anyone working in AI hardware has probably seen this scenario.

A small team of five or six people has developed a decent algorithm, and their demo video has received good feedback, attracting several investors. But when someone asks, "Did you bring the prototype?", the team falls silent. They have the algorithm, they have the demo, but they don't have a single machine that can actually run.

This is not an isolated case. Most early-stage AI hardware teams globally get stuck here. Is it because they lack ideas? No. Is it because they lack technology? No. The problem is—doing hardware is completely different from writing software.

With software, you change the code, click run, and get results in seconds. With hardware, you change a pin configuration, recompile, flash, power on, check the logs, find that the I2C isn't communicating, then check if the reset pin wasn't pulled correctly, and half a day is gone.

So many teams' choices are: either recruit people to build a hardware team—expensive, slow, and not guaranteed to find the right people; or find an external solution provider—high minimum order quantities, cycles measured in quarters, and an agonizingly long communication chain. In the end, product validation gets stuck on that "last piece of hardware," and the entire funding rhythm is disrupted.

Our company, Kickers.ai, is in the business of helping people solve this problem. A client says one sentence, like "I want a camera that can recognize pet emotions," and within a few weeks, we give them a working prototype. From optics, hardware, drivers to algorithms, we handle it all.

Sounds pretty fast, right? But honestly, behind these "few weeks" is a lot of manual labor. Selecting chips requires people, designing boards requires people, writing drivers requires people, tuning algorithms requires people, and even finding customer needs requires our operations staff to scroll through comments on various social media platforms every day.

I've been thinking recently, can we automate this a bit more? Coincidentally, DeepSeek open-sourced something called Harness, or dsh for short, earlier this month. I've been studying it for a few days and find it quite interesting. Let's talk about it.

2. What Exactly Is dsh?

Don't be intimidated by the name first. To put it bluntly, this thing is giving a large model a pair of hands.

When you usually chat with DeepSeek or GPT, it's like a particularly smart consultant—quick-witted, knowledgeable, and able to give you advice on anything you ask. But it can only talk; it can't really help you do the work. It can't open files on your computer, can't type commands, can't help you modify code, and certainly can't flash firmware for you.

What dsh does is attach arms and hands to this consultant. Once connected, it can open files to read on its own, type terminal commands on its own, search for information online on its own, break down a large task into several steps and complete them one by one, and even check if it did it correctly afterward.

The official formula is quite vivid: Agent = Model + Harness. The model is the brain, Harness is the body.

It also has a concept called "Everything is a Plugin." I appreciate this—it's the same principle as the modular design we use in hardware. Reading a file is a module, typing a command is a module, and even how it thinks can be swapped. If you want to add a new capability, just plug in a plugin; no need to tear everything down and start over.

Currently, there are several modes: the standard mode is a complete coding assistant, the code mode is more flexible, allowing the model to write code to call tools, and there's a minimal mode for testing model capabilities. For specifics, you can check the documentation yourselves; I won't just copy it here.

But one thing must be said upfront: this thing is currently v0.1 Developer Preview, just released a few days ago, and the API can change at any time. The official team themselves wrote that it's suitable for early adopters, not for running directly in production. Anyone who's been in this industry long enough knows that first-generation stuff is just for looking; don't get too carried away.

3. So, What Can This Thing Actually Do?

I've been pondering for a few days and think it can be used, and in quite a few places. I'll explain in order from easiest to hardest; see if it makes sense.

First: Mining Requirements from Social Media, This Is the Most Practical

Let's start with the easiest to implement. We do overseas markets and have a presence on many social media platforms—TikTok, Instagram, YouTube, LinkedIn, Facebook. Koreans use KakaoTalk, Japanese use LINE, plus WhatsApp and email.

Internally, we call this step the "Requirement Radar," meaning fishing out potential customer needs from these channels.

How was it done before? The operations staff would open five or six apps every morning, scrolling through comments and private messages one by one. Anything that looked like a requirement was copied into a spreadsheet. If it was in Spanish, Japanese, or Korean, they had to copy it into translation software to translate it. By the end of the day, not only were their eyes strained, but they often missed things.

How to do it with dsh? Write a collection plugin for each platform, letting it periodically pull data itself—TikTok comments, Instagram DMs, YouTube comments, email inquiries—all aggregated together. Then it translates by itself and judges by itself: Is this just a complaint? A price inquiry? Or a genuine requirement? If it's a requirement, it can even extract it for you: What product is wanted? For what scenario? Any specific requirements?

Let me give you an example. Someone comments on TikTok: "I wish there was a small camera that could tell me when my cat is vomiting while I'm at work."

Before, the operations staff would see it, translate it, and note it down. With dsh, it directly outputs structured data:

Requirement Type: Pet monitoring camera Scenario: Remote monitoring while owner is at work Feature Point: Identify cat vomiting behavior Form Factor Requirement: Small Popularity: 200+ likes, high priority

See how much effort is saved. When the operations staff arrives in the morning, the spreadsheet is already filled with translated, categorized, and prioritized requirements; they can just focus on the key ones.

Taking it a step further, it can also help with auto-replies. For common questions like "How long is your cycle?" or "What's the approximate price?", it answers directly based on company materials. When encountering a genuine requirement, it can even automatically ask a few follow-up questions to clarify the need—"Is this for indoor or outdoor use? Any requirements on device size?"—collecting all the information before forwarding it to an engineer.

We say we give a "feasibility assessment within 48 hours." With this thing helping, maybe it can be done in 4 hours.

And most crucially, once these requirements are collected, they don't need to be manually entered into the system; they can directly enter the subsequent development process. A single comment could be the starting point of a project.

Second: Serving as an Assistant for Engineers, This Is the Most Direct

This doesn't need much explanation; it's the same principle as Claude Code or Cursor.

Anyone who writes drivers knows that the time actually spent "thinking" in a day isn't much. Most of the time is spent checking manuals, looking up registers, modifying device trees, compiling, reading error messages, and modifying again. These tasks, frankly, become skilled with practice, but they just consume time.

With dsh's help, you say, "Help me write the driver for the OV5640 on the RV1106, 1080p@30fps, MIPI interface." It goes to the SDK to find reference drivers by itself, checks register configurations by itself, writes the code by itself, and compiles by itself. If a compilation error occurs, it reads the error message by itself, modifies by itself, until it compiles successfully.

You just sit beside it and review the code. Isn't this like giving every engineer a junior engineer who never sleeps?

Of course, it might not get hardware-related code right the first time, as many register configurations are vaguely written in chip manuals. But it can help build the framework and handle repetitive tasks, allowing you to focus on key issues, which definitely boosts efficiency.

Third: The Commander-in-Chief of the POC Process, This Has the Most Imaginative Potential

This is the usage I find most valuable.

What is our ultimate goal? "Generate hardware with one sentence." A client says what they want, and the system automatically produces a prototype. This sounds mystical, but breaking it down, it's actually a series of steps:

Step one, understand the requirement. To detect an elderly person falling, that's human pose estimation. Step two, select the chip. Pose estimation doesn't require high computing power; RV1103B is sufficient and cheap. Step three, select the sensor. For indoor use, choose a CMOS with good low-light performance. Step four, configure the BSP. Sensor driver, inference framework, all configured. Step five, deploy the algorithm. Convert the model to a format the chip can run, quantize, adapt to the NPU. Step six, joint debugging and testing. Run it to see the effect, whether the frame rate is sufficient, whether the accuracy meets the standard.

This series of steps currently relies entirely on people to connect. Project managers track progress, engineers communicate verbally, and when problems arise, groups are pulled together for discussions.

What role can dsh play here? Commander-in-Chief.

Turn each step into a plugin—chip selection plugin, sensor selection plugin, BSP configuration plugin, algorithm deployment plugin, testing plugin. Then dsh acts like a project manager, calling these plugins in sequence, step by step. If a step goes wrong, it judges by itself whether to retry or change the plan.

Previously, one project manager plus several engineers delivered in three weeks. In the future, with dsh automatically scheduling and engineers only checking at key nodes, it might be done in one week.

And have you noticed, the output from the first scenario (finding requirements on social media) is directly the input for this process. Discover a requirement on social media → automatically clarify → automatically assess feasibility → automatically create a project → automatically develop. The entire chain is connected.

This is the real "AI-assisted R&D pipeline."

Fourth: A Reference for the BSP Agent, This Is Most Relevant to Our Team

The BSP Agent built by our Agent platform team is, to put it simply, about automating hardware configuration. If a client changes a sensor, the engineer doesn't need to manually modify it; the Agent adjusts the device tree, drivers, and configurations all by itself.

dsh offers us inspiration on two levels.

One level is architectural reference. Its "Everything is a Plugin" design is something we can completely borrow. Make an adaptation plugin for different chips, a driver plugin for different sensors, a deployment plugin for different algorithms. In the future, when changing combinations, just plug and unplug plugins; no need to rewrite code. Anyone in hardware understands how important modular design is—today the client wants RK3588, tomorrow RV1106, the day after CV1812. If you hardcode it, you'll want to die when modifying it.

The other level is directly using it as a runtime. If the BSP Agent needs the model to make dynamic decisions—like "What's the cause of this error? Which configuration should be changed?"—dsh's code mode is quite suitable. It allows the model to write code by itself, execute by itself, see the results by itself, and iterate by itself until the problem is solved.

Let me give you a real scenario. Connecting the IMX415 to the RK3588. How was it done before? Check pin definitions, modify the device tree, write the driver, compile, flash, power on, check the boot log—oh, I2C communication failed, then check if the reset pin wasn't paired correctly, modify again, compile again, flash again... most of the day is gone.

If dsh does it? You say, "Connect the IMX415 to CSI0." It modifies by itself, compiles by itself, flashes by itself, checks the logs by itself, discovers the I2C failure and investigates the cause by itself, modifies and retries by itself, until an image appears.

Of course, this is the ideal state. In reality, hardware has far more pitfalls than software, and many problems can't be located just by looking at logs. But at least those cycles of "change config, compile, flash, check logs" can be saved.

Fifth: Automated Testing, This Is Also Quite Practical

For prototyping, testing takes up a huge chunk of effort. Image quality needs testing—resolution, frame rate, noise, color; algorithm accuracy needs testing—detection accuracy, latency; stability needs testing—running continuously for 24 hours without crashing; power consumption also needs testing.

Previously, all this relied on test engineers manually writing scripts, manually running them, manually recording data, and manually producing reports.

With dsh, it can automatically generate test scripts based on hardware configuration and algorithm type, execute them by itself, analyze the data by itself—whether the frame rate is sufficient, whether accuracy meets the standard, whether there are any abnormal restarts—and finally generate a report by itself.

And it has a benefit: all operations have complete logs. Anyone in hardware knows how painful it is to reproduce a problem. With complete logs, when a problem occurs, you can replay it and check step by step where exactly things went wrong.

Sixth: An Operation Assistant for Clients, This Is Long-Term

When clients receive a prototype, they often don't know how to use it. How to configure vision tasks? How to adjust parameters? How to troubleshoot problems? They all need to come to us for support.

In the future, we can package a customized version of dsh for clients. Clients can operate using plain language—"Turn up the sensitivity a bit for me," and it changes the config and restarts by itself; "How many false alarms today?" and it checks the logs and calculates by itself. Clients find it hassle-free, and we save a lot of after-sales effort.

But this is for later; the previous steps need to be running smoothly first.

---

See, these six scenarios strung together are actually our entire business line:

Social media requirement discovery → Engineer development → Automated process orchestration → BSP automatic configuration → Automated testing → Client self-service usage

It's not just changing a tool, but intelligently upgrading the entire chain.

4. But Don't Get Carried Away, There Are Several Pitfalls

In our line of work, we must maintain enthusiasm for new technology, but even more so, maintain calm. Let me mention a few problems I see.

First, this thing is still young. v0.1, just released, definitely has many bugs, and the API can change at any time. Plugins you write for it now might need rewriting in two months. So my suggestion is to use it for internal tools first, for technical validation, and don't shove it directly into a client's production environment.

Second, the cost needs to be calculated clearly. The framework itself is MIT open-source, free. But the large model it calls in the background charges by token. If you let it scrape social media, write code, and run tests for you every day, this token consumption won't be a small amount. Before large-scale use, do the math first; don't be shocked when you see the bill at the end of the month.

Third, security is a big issue. This thing can read files on your computer, type commands, and call social media APIs. It's like giving AI a set of keys. For internal company use, permissions must be managed well, and sandboxes must be isolated. Otherwise, one day it might accidentally leak a client's confidential proposal or delete an important directory, and it'll be too late for tears.

Fourth, does the tech stack match? dsh is written in TypeScript. We in the embedded field mainly write C/C++, and algorithm folks write Python. For deep integration, someone needs to understand TypeScript, or adapt through interfaces. This labor cost needs to be considered.

Fifth, data compliance and confidentiality. User data on social media must comply with regulations like GDPR. For client project proposals, red lines must be drawn in advance on what can be passed to the large model and what cannot. Also, be very cautious about auto-replies. Sensitive information like pricing and delivery cycles must be manually reviewed before sending; don't let AI blurt things out, or it'll be troublesome if you can't deliver.

5. So How to Implement Specifically? I Suggest Three Steps

After all this talk, how to actually land this? Here's what I think.

First step, build the social media requirement radar first. This is the easiest and yields the quickest results. Don't be greedy at first; just connect TikTok and email channels, just do "collection + translation + requirement extraction + classification," and hold off on auto-replies for now. Produce a daily requirement summary every morning, and let the operations staff try it for two weeks to see the effect. Simultaneously, find one or two engineers to install dsh as a coding assistant to test the waters and get a feel for this thing.

Second step, pick a specific process for end-to-end validation. For example, do "sensor automatic adaptation"—input a sensor model, and it automatically generates the driver, modifies the device tree, compiles, flashes, and verifies the image output. If this runs through, it proves the direction is right. Meanwhile, on the social media side, you can gradually add platforms, add requirement scoring and sorting, and try auto-replies for common questions, but always with manual review.

Third step, then decide whether to deeply integrate. After running the first two steps for two or three months, you'll have data and have stepped on many pitfalls. Then decide whether to deeply integrate dsh into the POC Studio platform, or just borrow its architecture to build your own, or just keep it as an internal tool without putting it into the product.

Don't go all-in from the start. Anyone in hardware knows that taking too big a step can easily tear things apart.

6. Finally, a Few Words

Regarding hardware, my biggest feeling is—this industry is too slow. The software industry iterates weekly; a single board fabrication for us takes two weeks. AI is developing so fast, and hardware is always holding it back.

I think the emergence of something like dsh is a signal. Before, AI could only help you write code or look up information; now it's starting to truly get its hands dirty—operating files, calling tools, orchestrating processes. Although it's still very rudimentary now, the direction is right.

For us in AI hardware, its greatest value isn't having an extra programming assistant, but having a possibility—connecting the entire chain of "finding requirements, making prototypes, delivering to clients" with Agents, truly automating it.

Of course, it's still too early to say this now. But with technology, if you research early and trial-and-error early, you'll be ahead when it matures. If you wait until everyone sees it clearly before entering, the opportunity will be long gone.

---