He Turned a DJI Drone Into a Home Security System That Follows People

Late at night, someone runs out of your yard. A notification pops up on your phone with a single button: Launch.

Press it. The DJI Mavic on its pad takes off, finds that person, and follows at a distance of 8 meters. When it reaches your property boundary, the drone climbs to 30 meters and keeps the camera on him until he leaves its field of view. Then it returns to the pad and lands. A video with timestamps, distance, and tracking ID is already on your phone.

X user @0xCodez used Opus 5.5 and an open-source project called REA to turn a DJI Mavic into a home security drone. The method: paste a detailed prompt into Claude Code (Anthropic's terminal coding tool, running the Opus 5.5 model), and it handles the rest—code generation, app building, and alarm configuration.

The video shows the full tracking interface: camera feed on the left, with a target on the grass labeled person 0.86; a lidar map on the right; and real-time curves for speed, altitude, and distance at the bottom.

Video source: @0xCodez tweet

The system has several key design choices.

All processing happens on the phone. No cloud involvement, and no GPS tag on the target. Recognition uses a quantized YOLO model that only detects the person class. It runs Core ML on iPhone and LiteRT on Android.

Tracking uses a Kalman filter. When the target runs behind an obstruction, the system predicts his position and locks onto the same ID when he reappears. There are four states: SEARCHING, LOCKED, COASTING, LOST.

Control uses DJI's Virtual Stick protocol at 10 Hz, with three PID loops: the horizontal offset of the target box controls yaw, the target box height controls forward/backward speed, and follow altitude is fixed at 6 meters.

Safety rules are enforced directly in code: GPS geofencing so the drone does not fly outside the user's property; a minimum distance of 8 meters from the target; automatic return-to-home if battery drops below 30%, signal is lost, or the target is lost for more than 5 seconds; and a large STOP button to switch back to manual at any time.

Alarm chain: Home Assistant (an open-source home automation platform) detects the alarm state, pushes it to the phone, and the user taps Launch. The app is built with the official DJI Mobile SDK—Swift on iPhone, Kotlin on Android. The phone is mounted on the remote controller, plugged into a charger, and kept running in the foreground.

@0xCodez posted the full prompt in a reply to the tweet. That is the part really worth examining.

The prompt requires Opus to first check whether the drone model is on the official DJI Mobile SDK v5 supported list. If it is not, stop. It explicitly states: do not modify firmware, do not unlock flight restrictions, and do not disable geofencing or obstacle-avoidance sensors.

It requires reading the official MSDK v5 documentation and sample code before writing code.

It requires all hard safety rules to be implemented in code, not placed in settings.

It requires running the entire tracking flow in the DJI simulator first, logging state, distance, and every stick command. The conditions for the first real flight are also strict: daytime, the user triggers the alarm and walks out themselves, and no one else is around.

The prompt even asks Opus to answer several questions honestly: how long the drone, remote controller, and phone can stay on standby; what is needed for 24/7 standby; and what the drone laws in your country say about this configuration.

Once this flow worked, a real system with physical, safety, and legal constraints landed from a natural-language prompt.

A commenter asked a fair question: if you're developing with the official SDK on officially supported hardware, why do you need REA?

That question gets to the point.

Looking at the whole flow: check the supported list, read the official docs, write the app with the official SDK, test in the simulator. None of these steps require reverse engineering. REA is a recently popular open-source project. According to Movez's tutorial, it gained more than 110,000 GitHub stars in a few days, and its core purpose is to let AI drive decompilation tools such as Ghidra and Hopper. But in this project, @0xCodez did not explain in detail what REA actually did.

Movez's tutorial "How to Reverse Engineer Anything with Opus 5.5" is about real reverse engineering: decompiling binaries, reading assembly, and identifying obfuscated code. The drone project, by contrast, is essentially forward development based on the official SDK.

"Reverse engineering" here is more like a communications angle.

But the story itself is still worth paying attention to. A developer described a complex set of requirements in natural language, and AI turned it into a flying device. Amjad Masad (CEO of Replit) wrote on X: "AI-driven reverse engineering and decompilation are getting insane; soon all software will be de facto open source." He was talking about software. The drone project shows another direction: AI is becoming an interface to the physical world.

Commenters also raised practical issues: flying too low and too close to the target makes the drone easy to attack; why does speed decrease when approaching the target; what happens if the battery runs out mid-flight. These concerns are all valid. The system is currently more of a technical demo than a mature security product.

But the barrier to entry is already low: a drone that supports MSDK v5, an old phone, and a computer with Claude Code installed.

The next form of home security may not be more cameras, but a sensor that can fly, follow, and record.

Cameras record what happened. A drone can tell you where that person went.

References: