This is a sample newsletter. Sign up to get email delivery!

Hello there!

You knew this could happen. One day, summer would come to an end and you can see fall around the corner. If you’re in upside down world, that’s winter and spring. Today is that day. Either way, it’s inevitable, just like Jetson news.

As I’m sure you’ve heard, pricing has radically changed the Jetson landscape. NVIDIA raised prices across essentially the entire Jetson lineup, including all three of the current developer kits.

You can see the pricing for the entire Jetson lineup in the NVIDIA Jetson FAQ. Generally, we view eye-watering increases like this in a negative manner.

The Orin Nano pricing is a little more interesting than the table makes it look. The original Jetson Orin Nano Developer Kit launched in 2023 at $499. When NVIDIA introduced the Orin Nano Super software update in December 2024, they dropped the developer kit price to $249. So its price history is really:

$499 → $249 → $399

That makes the new price a 60% increase from where it was last month, but it is still $100 less than the original launch price.

There is also a curious bit of pricing further up the product line. The Jetson AGX Orin 64GB production module is now $2,999 in 1,000-unit quantities. So is the newer Jetson T4000 module.

Both have 64GB of memory, but the T4000 is the newer Blackwell-generation module, while AGX Orin is based on the previous Ampere architecture. At the new pricing, NVIDIA is asking the same amount for both.

That makes for an unusual overlap in the product line. Unless there is some specific reason that an existing design requires AGX Orin, the newer T4000 looks like the rather obvious choice at the same price.

Jetson Orin Nano 2

NVIDIA announced the Jetson Orin Nano 2 on August 25, 2026. It offers roughly 2× the inference performance of the Orin Nano Super while using 40% less power at the same performance point. The new module has 78 TOPS, 8GB of memory, and an 8-core Arm CPU. NVIDIA says the module and developer kit are expected in the first half of 2027.

The NVIDIA article is here: NVIDIA Announces Jetson Orin Nano 2 Robotics Computer to Redefine Entry-Level Edge AI

Nemotron 3.5 Lightning and NVIDIA Switchyard

NVIDIA recently announced Nemotron 3.5 Lightning, a 30B-A3B model that runs on both Jetson AGX Thor and Jetson AGX Orin. Lightning is optimized for agentic workflows and is another example of NVIDIA’s increasingly strong support for open models and open weights.

Jensen Huang has been making that position explicit. In July, he wrote that open models “strengthen safety and cybersecurity, accelerate innovation and diffusion, and enable sovereignty.” Jensen Huang on open models and open weights

NVIDIA announced Lightning alongside NeMo Switchyard, an open-source programmable model router. The basic idea is that different requests can be sent to different models depending on what the task requires. A relatively simple task might go to a small, fast local model such as Lightning, while a more difficult task can be sent to a more capable model.

Here’s a video I just released examining Lightning and talking about Switchyard: https://youtu.be/_3rB-loUjF4

AI Assistants as a Solo Developer

Over the last couple of months I’ve been working on an application which is an animation editor for a Reachy Mini robot. The Reachy Mini is the minimum viable interesting robot. There are enough actuators (9 servos) that it’s not trivial to understand how they work together.

There’s sound input, sound output, and video in. Which means that it can be interactive, interpreting its surroundings and responding to the environment around it. I decided to control the robot with what most people use as a digital audio workspace control. These are commonly referred to as control surfaces, and in this case there are 9 motorized faders, 16 encoders with buttons, and 39 buttons, all controlled over MIDI, a musical instrument serial protocol over USB.

The overarching idea here is going through the process of using AI as a solo developer to create a professional-level application. You can think of the application as similar to a video or audio editor, but instead of using video, it stores poses of the robot and animates between them over time. In the first incarnation, it is a show control sequencer. You hit the play button and it plays back the robot motions, triggers sounds, and external events. Nothing state of the art, but fun.

We’ve been flooded with people telling us how great AI is at building software. You nearly describe the application, and within a short amount of time a complete application is ready for you. Code, unit tests, documentation, everything you need to impress your friends and confuse your enemies.

That has not been my experience in the least. It doesn’t even rhyme.

Sometimes it’s Straight Magic

To be fair, there have been magical moments. There are tasks which I actually get excited about using AI for. Everyone knows what a pain internationalization is to implement. As it turns out, that’s a great match for AI capabilities. Tasks that used to take forever, hunting down every last string of characters to translate and keep track of, are straightforward for the AI. It’s a task I’ve always dreaded, and now it’s almost fun to watch.

Another jaw-dropping task is a typical embedded engineering one. In this example, I have a control surface which comes with the standard multi-language quick-start guide. I’ve always assumed that these don’t make sense in any one of the given languages. This is an attempt to get the owner to throw away the little book with type too small to read. In many of these support-type documents, hidden in messy drawings or a small table, is the technical information needed for a developer to interface with the device. In my case, a table with all the MIDI codes. In addition, the illustrations contained mode and mapping information for each of the buttons.

For an experienced developer, this is a good few hours of work trying to transcribe everything into an appropriate format. There’s the idea of creating the 75 entries and organizing them in accordance with the mapping. There’s translating the control mappings to their MIDI values, and so on. And best be careful because if you get it wrong, it no worky.

But if you give it to a frontier model, it figures it out and gives you a nice YAML table in just a few minutes. As an added bonus, it tries to piece together a theory of operations and a nice little plan on how to test the values to make sure everything works. Every software guy hates this task; to see it done in just a few minutes auto-magically stirs the soul.

Other times, not so much

On the other hand, using actual software practices and creating real applications? Not so much.

Much of what we hear about and see when people talk about using AI to build applications is what I call “The rabbits guarding the lettuce.” Here the implication is not only that the AI will define and implement the application, it will also judge its own implementation. We’ve talked about managing expectations in the newsletters before. It’s hard not to be disappointed when you ask for a fully working application and the results that come back are lackluster.

That leads us back to coding. In our case, embedded programming. Each type of programming has challenges: web development, servers, front end, back end, and so on. For embedded programming, you are most likely working with external hardware. Sensors, actuators, cameras, basically the things that live in the real world. There’s this really big idea in the embedded space: it has to work.

That means the code has to be well executed and work in a closely defined space. Usually you don’t have unlimited memory or a particularly fast machine. More importantly, you usually have timing constraints when interacting with external devices.

I’ve been working over the last several months to develop a process to build for that environment. My usual process in the past was to write sketches to experiment with certain parts of the system. That might mean a sketch to use the camera, emit sound, or record sound. Experiment with the motors and determine their capabilities. If I felt I knew enough about the parts, then I could start building the application. For the most part, applications are integrations of the different subsystems and getting them all to work together.

Many times one would write a specification, and then produce a unit implementation from that. The unit implementation would then be coded, and if people felt tests were needed, they would build unit tests from the code. Once everything was built, people would test it to make sure it did what it said it did and start a feedback loop to make it better.

The specification and unit implementation, to a large degree, are pretty straightforward for an AI system. You build an interview process, answer the questions, and the AI writes the specification, then an implementation unit. Write the subsystems in that way, produce the evidence, and then have the AI write an integration plan to integrate all the parts. That works pretty well with sketches and with the more final application.

The part that I haven’t figured out yet, even after quite some time and asking the LLMs for help, is how to convince the AI to code what you ask for and then write sensible tests for coverage. The code kinda-sorta works, but the tests tend to be abysmal. I’ve done the trick of having another LLM run a red team against it. The result seems consistent.

The model seems to be trying to get to “done” quickly, rather than making sure it actually finished the job. Then the unit tests get designed around that, which usually only cover a portion of the desired task.

As an example, writing a GUI timeline for the animation data. Naturally you want to cut, copy, and paste different parts of the animation, shorten sequences, and so on. On its face, it’s familiar and seems simple. In practice, it tends to be a bit of a UI nightmare.

Even if you carefully craft the spec and implementation notes, the AI builds something that kinda/sorta works. You recognize it as part of a solution, but it takes many turns with intent to make it work as you expect.

The challenge is turning this into a development process you can work with and control.

I remember once hearing a little green puppet say, “You must unlearn what you have learned.” And so it is with LLMs.

They’ve seen a lot of software built for large teams. GitHub workflows, layers of abstraction, process around process. That makes sense when you have dozens or hundreds of people working on the same codebase. As a solo developer, not so much.

That’s a layer that’s the antithesis of being a solo developer. In essence, what the LLM tries to do is put the overhead of large-group development on you, because that’s the pattern it knows.

The hard problem isn’t getting the LLM to write code. It loves doing that. The hard part is getting it to refine that code, integrate it, and stop when it’s built something that you actually asked for.

How do you make the AI work inside your development process, instead of making you work inside its process?