Build, Audit, and Ship on Jetson with NVIDIA Skills + JetPack 7.2: Why Your Coding Agent Hallucinates on Jetson (and How NVIDIA Skills Fixes It)

Ask an AI coding agent to build a vehicle-speed detector on Jetson and it will often reply with something harmless-looking:

pip install torch torchvision
python detect.py

On an x86 workstation, that might work. On Jetson, it can trigger a classic “hallucination triple”:

1. The default PyPI torch may be CPU-only, so torch.cuda.is_available() returns False.
2. Even with an aarch64 wheel, a mismatch between JetPack/L4T, CUDA, TensorRT, and driver libraries can break imports or cause runtime symbol errors.
3. The agent may not know whether the target is Orin Nano 8GB, Orin NX 16GB, or AGX Orin 32/64GB — or that the carrier board reserves DRAM for display, camera, firmware, or other hardware engines, leaving less memory than the module name suggests.

“Code that runs” and “code that deploys” are different worlds on embedded AI. NVIDIA’s Jetson agent skills, together with JetPack 7.2, try to close that gap by turning expert Jetson knowledge into loadable, auditable skill packages.

Why agents get Jetson wrong

Training-data staleness is only the shallowest reason. In embedded projects, the bigger issues are:

Implicit hardware state. A general LLM assumes standard Linux servers: x86_64, discrete GPU, separate VRAM, pip/conda-first. Jetson is unified memory — CPU, GPU, codecs, camera buffers, model weights, KV cache, and system services compete for the same DRAM. Orin Nano 8GB, Orin NX variants, and AGX Orin 32/64GB differ in power modes, PCIe lanes, encoder/decoder instances, and usable memory headroom.

Fragmented knowledge. The correct answer may live across NVIDIA Jetson Linux docs, JetPack release notes, carrier-specific wiki pages, GitHub issues, and forum threads. An agent tends to synthesize the most generic answer, not the answer valid for this JetPack version, this SoM, and this carrier board.

Compile-success bias. Agents optimize for “import works / script exits 0.” Embedded failure appears later: CUDA OOM at runtime, 1/10 expected FPS, boot failure on the second device because of a different device tree, or BSP brick after a wrong flash parameter.

Cross-domain coupling. One “why does DeepStream drop frames” question can involve BSP/camera device tree, NV power mode, container-host JetPack matching, TensorRT batch size, NVDEC concurrency, and GStreamer buffer strategy. Agents that treat it as one domain produce-optimal but system-broken answers.

Ambiguous intent. Users say “make a production-grade demo” but mean “give me something today.” An agent eager to please may skip risky-but-necessary warnings such as “this requires reflashing BSP” or “this memory optimization was only validated headless.”

What NVIDIA Skills actually change

Instead of pasting manual commands, the agent loads structured skills. For Jetson, NVIDIA ships device-side and BSP-side workflows: diagnostic, package selection, memory audit, headless conversion, LLM serving/benchmark, video/DeepStream helpers, and BSP customization for pinmux/PCIe/USB/memory-carveout/flash.

Example contrast for a Jetson vision prototype:

• Without skills: agent runs generic pip install torch, picks a random YOLO repo, suggests deepstream-app --version even when DeepStream is installed in a non-standard path.
• With skills: agent first runs a diagnostic skill to read module/SKU/JetPack/L4T/memory; uses a package skill to choose Jetson-compatible wheels or containers; runs a memory-audit skill before model loading; switches to headless only when evidence supports it; and uses a vision-model skill that knows OpenCV/MOG2 for minimum prototypes, ONNX→TensorRT for production, and DeepStream/NVDEC for accelerated pipelines.

In our vehicle-speed tests on AGX Orin, a naive environment check showed no torch and no standard DeepStream path, while a DeepStream test app was actually running from a non-default service directory. A JetPack-aware skill would not conclude “DeepStream missing”; it would inspect the actual installation layout before recommending fixes.

Why this matters for Seeed Jetson users

Seeed reComputer and Jetson carrier platforms are used for prototyping and fleet deployment. The painful part is rarely “write the model” — it is “make the model run reliably on this specific device, JetPack version, and carrier I/O.”

NVIDIA Skills reduce that pain by giving agents:

• hardware identity and JetPack/L4T awareness
• carrier-independent baseline checks plus carrier-specific caveats
• conservative, reversible steps instead of destructive one-liners
• a path from minimal prototype to TensorRT/DeepStream production

In next article, we go deeper into BSP vs device skills and the signing/SkillSpector/Skill Card trust pipeline. Then, we walk the full vehicle-speed demo: diagnostic → package → memory audit → headless → DeepStream/TensorRT benchmark.

Useful links

• NVIDIA Skills: https://github.com/nvidia/skills
• Jetson device skills: https://github.com/NVIDIA-AI-IOT/jetson-device-skills
• Jetson BSP skills: https://github.com/NVIDIA-AI-IOT/jetson-bsp-skills
• Seeed Jetson rapid-prototyping wiki: https://wiki.seeedstudio.com/rapid_prototyping_on_jetson_with_nvidia_skills/
• Seeed Jetson Develop Tool: https://github.com/Seeed-Projects/Seeed-Jetson-DevelopTool

About Author