Like a lot of teams, we've been figuring out where AI coding agents actually help and where they just get in the way. The honest answer is that it depends on the task. Some work is too open-ended or too novel for an agent to do well. But we've found one job that fits unusually well: porting open-source software to QNX.

This post is part "why porting suits AI agents" and part "here's a real port we ran." We're still early with this, so treat it as a field report rather than a finished playbook. But the early results have been encouraging enough that it's worth sharing.

Why porting is a good fit for AI

Porting has a particular shape that plays to an agent's strengths.

The problems recur. Across hundreds of packages, the same classes of issue come up again and again: a library that needs an explicit link flag, a build that assumes a Linux-only header, a compiler standard that doesn't match the target's system headers. A human learns these the slow way. An agent that's been told about them can apply them immediately.

The feedback is concrete. Unlike a lot of software work, a port has an unambiguous oracle: it builds or it doesn't, the tests pass or they don't, the package installs or it fails. There's no vague "is this good enough?", there's a compiler and a test suite giving a yes or no. That tight, objective loop is exactly what an agent needs to make real progress without a human refereeing every step.

It's native now, and you can watch it happen. With the QNX Self-Hosted Developer Desktop, the QNX target builds its own software using Alpine's abuild and apk tooling, running natively on QNX. No cross-compilation, no SDP, no toolchain files. The agent runs on our workstation, reaches the target over SSH, and edits and builds right there on the machine that will run the result. We watch the build output stream by, the same as if we were doing it by hand.

Teaching the agent what we know

The piece we're experimenting with most is how to give the agent the QNX-specific knowledge that usually lives in an experienced porter's head.

Our approach is a set of skill files: plain Markdown documents, kept in a Git repo, that the agent reads before it starts. They cover the things that bite QNX ports, sockets live in libsocket rather than libc, the default thread stack is small, uname -m returns x86pc, and so on, plus the workflow itself: how to adapt an Alpine recipe, how to make a patch the right way, how to validate before declaring victory.

A few rules sit on top, and they're the ones that make the output trustworthy rather than just plausible:

Prove claims with command output. The agent doesn't get to assert a build passed; it has to show the command that proves it.
Never write a patch from an untested change. Test in the source tree first, then capture the patch.
A human runs Git. The agent edits, builds, and reports. A person reviews and pushes.
Write down what you learn. When the agent works out something new about QNX, it records it back into the skills, so the next port already knows.

That last rule is the one we're most curious about. In principle it means the system gets better every time it's used. We'll see how well that holds up at scale, but the early signs are good.

A real port: cJSON

To make this concrete, here's a port we ran end to end. We pointed the agent at cJSON, a small, widely used JSON parser. It's a good test case precisely because it's small but not trivial: it needs a genuine source patch, not just a flag change, so it exercises the full loop without burying us in a giant dependency graph.

The instruction was simply to port cJSON to QNX. The agent pulled the Alpine recipe, adapted it (including a small dependency swap, Alpine's samurai becomes ninja on QNX, and dropping the cross-compile block that native builds don't need), and started building.

It hit one real failure. cJSON's build forces the -std=c89 C standard. On QNX 8.0, the system headers use static inline definitions that require C99 or newer, so compiling against them under C89 fails inside the QNX headers themselves. The agent diagnosed that, and the fix is about as clean as a patch gets:

cJSON's own code is C89-clean and compiles fine under C99, so bumping the standard to meet the target's headers is the correct, minimal change. One observed failure, one targeted line.

Then it validated, and this is the part that matters:

Three packages came out with a sensible split: the runtime shared library, a -dev package with headers and CMake/pkg-config files, and a -static archive.

Proving it actually works

A passing build and test suite is good, but cJSON is a library, not a program you can just run. So the agent did one more thing we really like: it wrote a small C program that links against the installed package and exercises it for real, creating a JSON object, printing it, parsing JSON text back, checking field types, iterating an array, and freeing everything.

That's the difference between "it compiled" and "the package you'd actually install works against a real downstream program." The agent reached for that step on its own, and it's the moment the port goes from plausible to proven: a clean build, a full passing test suite, and a real program using the installed library on QNX.

Where the human still comes in

We don't run any of this unattended, and we don't want to.

The agent stops at the edge of Git. It does the porting, the building, the testing, and writes up a structured report of exactly what it changed and why, but it never commits and never pushes. A person reviews the diff, the report, and the test results, and makes the call. For cJSON that review is quick, because the change is one line with a clear reason and a passing suite behind it. For a thornier package it's where a human weighs whether a workaround is sound or whether a disabled test is hiding something. Either way, the judgment to ship stays with a person.

That boundary is deliberate. The agent is fast and tireless and, given the right knowledge, genuinely good at the mechanical heart of a port. But "should this go into the tree?" is a human decision, and keeping it that way is part of what makes the speed safe to lean on.

Early days, promising signs

We want to be clear-eyed: encoding our porting know-how as agent-readable skills is new, and we're still learning what it's good at and where it falls short. But the shape of the results so far is hard to ignore. The recurring, concrete, testable nature of porting is genuinely well-matched to what these agents do well, and the native QNX Developer Desktop makes the whole loop something you can watch and trust.

The most exciting part isn't any single port. It's that the knowledge stops evaporating. Every package that surfaces something new about how QNX differs from Linux leaves the system a little smarter for the next one, and the next engineer.

The skills are on GitHub, ready to drop into a project: clone them in, point them at your QNX Developer Desktop (a QEMU image or a Raspberry Pi), and give an agent a package to port. We'd love to hear what you build with it, and what you teach it along the way.