Jean-Francois's blog

How I Use LLMs to Write Code in 2026

Jean-François Im — Tue, 12 May 2026 00:00:00 GMT

A few friends have asked how I use LLMs to write code these days, so I decided I’d write this blog post to share my current setup. There may be better ways to use them, but this is what I found works well for me.

First of all, I use the $100/mo Claude Max subscription. I’ve heard that OpenAI’s Codex works pretty well these days too, though I haven’t evaluated it lately. Last time I evaluated Gemini/Antigravity, it was complete garbage for writing code and a waste of time; this may or may not be the case anymore.

The $20/month subscriptions from Anthropic and OpenAI might work as well for lighter use. I frequently brush against the five hour limit, your mileage may vary.

Currently, in 2026, frontier models significantly outperform locally hosted models for agentic software development. This may change in the coming years, but today, subscriptions are the way to go. Of course, if you have money, you could run say Kimi K2.6 locally. At 1 trillion parameters, it’ll take over 512GB of memory, you’ll need at least two 512GB Mac Studios or four 256GB Mac Studios — which are now unavailable due to the RAM shortage, but even prior to that the 512GB ones were listed for $9,500 each — and still run at a slower speed than cloud hosted models.

You can use either the desktop version of Claude code or the CLI one. I used the CLI one a lot more in the past, but the desktop one makes it much easier to run multiple sessions in parallel.

Anthropic doesn’t currently ship a desktop version for Linux, so you’ll need claude-desktop-debian if you’re on Ubuntu/Debian.

Claude Code desktop screenshot

The first thing to do is to install a few plugins by clicking customize or /plugins in the CLI. The superpowers one makes it so that when talking about a new feature, Claude will enter brainstorm mode and ask clarifying questions about what is being built, then propose a plan. You should definitely push back on the plan if it’s not what you want, or if it’s missing something. Context7 and a LSP for your language are also pretty useful.

By default, Claude will run in permissions restricted mode, which means it’ll constantly bug you about permissions for anything more than editing a file in the project directory. Build the project? Prompt. Run the linter? Prompt. Curl for the documentation for a library? Prompt. In practice, you probably want to run in either “Auto” or “Disable permissions” mode.

This also means that Claude can run pretty much whatever on your computer, so if someone on the internet writes that to install libfoo you should do rm -rf / it might actually do it.

So now that we have our environment set up, it’s time to create a project. To do so:

Create a project on github (I’ll use cham-chrome-extension for this demo)
Create an empty directory on your computer and run git init in it

Terminal with an empty git repo, ready for Claude

With that, it’s time to prompt the LLM to start writing code.

Another approach is to write a more detailed markdown document and ask the LLM to read it. This is a better approach if what you want is a bit too long to fit in just a simple text box, unlike what this demonstration project requires.

The initial prompt to Claude Code

It’s usually a good idea to have at least some basic quality control like linting, auto formatting, and testing right off the bat. LLMs are pretty good at fixing errors when they are pointed out to them, so this makes sure that the code is at least formatted correctly and covered by tests.

Claude Code working on the project

Discussing the design

After some back and forth, it’ll generate a plan, then actually implement it.

And there you have it. I’ve put in the transcript for the demo project I have in this blog post, as well as the implementation plan it generated. Let me know if this works for you, or if you use different techniques that work for you.

The Sensors Aren’t Alright

Jean-François Im — Thu, 30 Apr 2026 00:00:00 GMT

A few weeks ago, I automated my air purifiers in the house using Home Assistant, MQTT, and a Python controller to turn the air quality data from the sensors that I have into a speed control for the air purifiers.

One thing that I noticed is that the air purifiers in one part of the house tended to run faster than in a different part of the house. I originally assumed it was because the kitchen and dining areas had more particles in suspension due from the cooking, but that should have been handled by the air purifiers eventually.

I then decided to open one of the PMSA003 sensors to clean it up. It turns out that in practice, due to the design of the sensor, there isn’t really a whole lot to clean up inside and it was actually pretty clean, since the air flow is such that it passes through the sensing cavity, far from the laser diode and the photoreceptor.

Since I couldn’t find instructions anywhere on the internet as to how to open a PMSA003, you’ll first need to remove the two small screws holding the fan. Then, you can pry open the sheet metal lid and bottom by inserting a very thin flat heat screwdriver between the middle plastic lip that separates the upper and lower parts of the sensor’s sheet metal housing.

Running the screwdriver along the edge of the sheet metal will allow you to fold it outwards slightly, thus releasing that side from the clips in the plastic housing. Inside, there’s a small L shaped PCB, three springs (one of which is slightly longer than the others), and a few screws holding the whole thing together.

When putting back the sensor together, fold the sheet metal back into its normal unbent shape using needlenose pliers, then push it back into its regular position to close the sensor housing. You may need to tape the edges of the sensor housing to prevent air leaks, if the sheet metal isn’t bent back perfectly.

The only thing there is to clean is the little fan, which can be cleaned up with a soft bristle brush, but that’s also on the exit path so that doesn’t really leak particles into the sensing cavity. So after spending far too long on cleaning it up, the difference before and after is a sensor that performs exactly the same as before but looks markedly worse with sheet metal that’s bent slightly out of shape and tape to seal it off.

However, just claiming that there is no change without evidence make it a rather dubious unsubstantiated opinion of which the internet is full of. But since we have the ability to make statistical inference of questionable pertinence on the internet, let’s do so.

So the first question is whether or not the error rate on the sensors is different before and after opening it. If there are no differences between the sensors, we should have a similar error rate before and after:

Code

Generalizing TOTP Anagram Counting for Different Bases

Jean-François Im — Sun, 12 Apr 2026 00:00:00 GMT

While working on the submission for A394980 — the count of anagram pairs in halves of TOTP codes — one of my more mathematically inclined friends asked if this was just a different series in disguise. I couldn’t find any other matching sequences initially, but when working on it, the other dimension that I didn’t explore initially was the assumption that one is working with base 10, as would be the case for regular TOTP codes. Changing the base to different values is where the plot thickens.

Changing the code to use different values for the base is relatively trivial, so for bases 2 to 10, the first 25 terms are:

Code

Palindromes and Anagrams in TOTP Codes

Jean-François Im — Wed, 08 Apr 2026 00:00:00 GMT

This morning, I entered yet another of those six digit TOTP codes to log into an online service. One thing that I always find interesting is when the second half of the code is similar to the first half, like say 675567. My curiosity got the best of me and I just had to know how often that happens.

The interesting cases would be a palindrome (eg. 123321), a repetition (eg. 123123), and an anagram of the first digits (eg. 123213, 123312, etc.).

The first case, palindromes, is pretty easy. For a six digit base ten number that’s zero padded, any three digit prefix has exactly 1000 possible three digit suffixes, and only one of them is the reverse of the prefix, thus for all possible six digit codes with a given three digit prefix, is a palindrome. Since there are 1000 such prefixes, and possible six digit codes, the probability of getting a TOTP code that’s a palindrome is .

The second case is a repetition, which has effectively the same number of occurrences as palindromes, so the probability of getting a TOTP code like 123123 with both halves identical is .

For those, we can actually generalize that for a code of length , the probability of it being a palindrome is , for which the proof is relatively trivial. Given that there are prefixes, each prefix has exactly one valid suffix to make a palindrome, and total numbers, we get a probability of which simplifies to .

In other words, for a code of length 6 like a regular TOTP token, would be 3. The length being makes it an even length, which is necessary in order to be able to split the code into two halves of equal length.

That leaves the case of the anagrams, which are permutations of the first half of the TOTP code.

Since that’s a bit more complicated, what we would want to do is count the number of such permutations, which would allow us to calculate the probability of them given a code of length for any arbitrary .

For , it’s pretty easy to prove that there are ten such permutations, since the first half has to equal the second, and there are ten single digits since we’re using base ten, which gives us

For , it’s a bit more complicated, since doubled digits only have one valid permutation (eg. 1111), but different digits have two valid permutations (eg. 1212 and 1221). Since we know that there are ten valid doubled digits, and prefixes, we can enumerate each case:

one valid permutation for each prefix that’s doubled digits, of which there are ten
two valid permutations for each prefix that doesn’t have doubled digits, of which there are

As such, we get .

For , we get different cases:

one distinct permutation for each prefix that are three identical digits (or one distinct digit), of which there are ten
three distinct permutations for each possible prefix with two distinct digits, of which there are (, since there are three positions where the doubled number can be)
six distinct permutations for each possible prefix with three distinct digits, of which there are ()

This gives us .

Interestingly, at this point, we can start to see a pattern. For each we have different cases, each of which is the product of the number of distinct permutations of a prefix of length and the number of such prefixes with distinct digits.

However, if we try to expand the cases for , the pattern starts becoming more complicated. In the case of , there’s exactly one possible pattern — in other words, appearing twice and appearing once. But for means that we can get two subcases and , each with different numbers of permutations.

Unfortunately, this is the point where I hit the limits of my combinatorics toolkit, which isn’t sufficient to continue to expand this in order to get to a closed form.

Even discussing it with Claude unfortunately only gets me to a discussion about Stirling numbers, for which I’d probably need an actual combinatorics class to understand.

What I do however have is the ability to write Python. A brute force approach is to simply count the number of items where the sorted prefix matches the sorted suffix by exhaustively enumerating them. A first stab at it would be something like this:

Code

The Unreasonable Effectiveness of the Superpowers Claude Plugin

Jean-François Im — Wed, 25 Mar 2026 00:00:00 GMT

Since we’re now in the era of LLM-based code writing, I’ve been working on writing more code using Claude Code. Obviously, one can say “Hey Claude, I want to build a snake game. I think it would be funny if the snake ate hot dog emojis,” and it’ll probably write something half-decent, but when it comes to larger projects, that kind of one-shot prompt doesn’t work so well.

To be fair, LLMs have been relatively decent at doing these one-shot prompts for simple projects in their training data for quite some time.

Obviously, the next step would be to improve one’s prompting skills. Write a design document, and have the LLM implement it. Maybe even have another LLM review the code.

The interesting thing is that Anthropic added the ability for Claude to have skills, which are basically Markdown files that contain instructions and prompts so that one can leverage the prompting ability of other people to do certain tasks. They’ve also added the ability to add plugins to Claude Code, which can contain multiple skills.

Given those two features, some pretty cool people made the Superpowers Claude Code plugin which adds skills like brainstorming that are automatically invoked whenever one uses a prompt similar to the one in the introduction, at which point Claude will start asking questions to clarify what one wants to build.

Claude Code screenshot

It’ll then proceed to draft a design which can then be iterated on through one or more review cycles, then draft an implementation plan, ask for a review, then code the whole thing automatically. Crazy, and after the implementation plan is approved, one can walk away from the computer and come back to something that works — at least if one has their permissions set correctly or runs with --dangerously-skip-permissions.

Obviously, the resulting code is only as good as the quality of the design, and you sometimes have to push back on design decisions that don’t work, but for turning random prompts into quick prototypes or funny snake games embedded in blog posts, it does work unreasonably well.

Building a Simple Air Quality Monitor

Jean-François Im — Sat, 08 May 2021 00:00:00 GMT

During the terrible wildfires that we had in California in 2020, it was possible to know how good or bad the outside air quality was through PurpleAir’s excellent sensor network.

However, having all the windows closed due to the poor air quality outside, I was wondering about the air quality inside as well. While it’s definitely possible to get pre-made devices — such as PurpleAir’s indoor air quality sensor, IQAir’s indoor air quality sensor, or even something cheapo from AliExpress — building my own is much more interesting:

It’s a fun project while being stuck at home during the pandemic
It’s cheaper than a commercial unit, so I can put one upstairs and one downstairs
It’s a good excuse to learn more about electronics
With control over the firmware, it’s possible to do all kinds of things, such as logging the data over serial port or even sending the data over Wi-Fi to a gen_tcp server written in Elixir; once the data is on a more powerful computer, it can be logged to CSV to analyze in R, or one can make a fancy display with Phoenix’s LiveView
Did I mention it’s fun?

It’s also a pretty simple project; since all of the parts in the build have passive components included, the project is literally just buying parts, soldering them, putting the parts on a breadboard, and flashing the firmware. As such, a careful beginner could assemble this relatively easily.

Since it’s always a good idea to have an idea of what one is getting into before starting a project, the unit costs should be relatively low — less than USD$10 for just temperature and humidity to less than USD$70 for CO₂, PM1.0/2.5/10.0 and tVOC depending on the cost of sensors — although getting the basic electronics tools required for this might add a bit to this. Time wise, this project can be completed in a few hours, with about an hour or two for each of the phases of this project — shopping, soldering, assembling, and installing the firmware — although one can tinker with the software for a while.

If you follow the instructions in this post, you’ll have this assembly on a breadboard, with data that can be read over the serial port or sent over Wi-Fi to a server of your own for further processing. It is powered through a USB port on your computer or any decent USB charger. This is what it looks like:

Everything assembled on a breadboard

Since this is customizable, one could also opt for a very minimal version with a single sensor, such as this one.

A cute miniature sensor

And this is an example of a display that one can build (will be explained in a follow up post):

Laptop and eInk display

Since this is a learning project for me, I also started designing my first PCB for this, as well as an enclosure that can be 3D printed; in theory, the whole thing should fit within a pretty compact package.

Solidworks PCB assembly

Neither the PCB nor the enclosure are finished, but once they’re ready and tested, I’ll post the files here.

The hardware

Air Gradient’s DIY sensor has a relatively similar BOM with an interesting combination of sensors. However, I wasn’t too much of a fan of their design; their build uses an older version of the Plantower particle sensor which is much larger, the CO₂ sensor is soldered upside-down such that the CO₂ permeable membrane faces the PCB instead of ambient air, all of the sensors are soldered directly to the PCB so that they can’t be reused/replaced, and their PCB seems a bit too large to place on a windowsill or other narrow location. I also didn’t care too much about the OLED display.

As such, this is the BOM that I have for this project, which is slightly different:

WeMos D1 mini (ESP8266 board)
SenseAir S8 CO₂ sensor
Plantower PMSA003-A particle sensor
SHT31 temperature and humidity sensor board
SGP30 tVOC sensor

All of the hardware isn’t necessary, so if you don’t care about CO₂ or particle counting, you can take that out of the build, it’ll still work.

Potential modifications

If you’re planning on just following the instructions in the rest of this post, you can skip this section.

It might be possible to use Particle’s Argon board instead of the WeMos D1 mini; I haven’t tried it, but it would have the advantage of having the charging hardware for LiPo batteries and integration with their IoT platform. They also have an air quality monitoring kit that has a different set of sensors, for the soldering averse.

Another thing that I might change is replacing the SenseAir S8 CO₂ sensor with a different CO₂ sensor such as Sensirion’s SCD30; while the S8 works, the datasheet specifies that the average current usage is 30 mA with a peak of 300 mA, which seems to exceed the max 500mA at 5V that a USB port offers by default, leading to a bit of a voltage drop every few seconds. If the voltage drops too low, it seems that the SenseAir S8 returns erroneously high readings; if that’s the case, using a different USB power source and shorter USB cables may help.

5V rail voltage drop due to the SenseAir S8

Alternatively, since the SenseAir S8 CO₂ is the most expensive part of this whole build, it could be replaced by the eCO₂ approximation done by the SGP30. It won’t be as accurate, but depending on your use it might be “good enough.”

Shopping list

If like me you didn’t have anything that could be used to make electronics at home, here is a shopping list. These items can be bought from a local electronics distributor (eg. Mouser, DigiKey, AdaFruit, SparkFun, etc.) or AliExpress.

The parts that you want for your sensor:
- WeMos D1 mini
- SenseAir S8 CO₂ sensor (if you want a CO₂ sensor)
- Plantower PMSA003-A particle sensor (if you want a sensor for PM1.0/2.5/10.0, good keywords for this on AliExpress are “PMSA003” or “Plantower dust sensor”) Other Plantower sensor models such as the PMS7003, PMS6003, PMS5003, PMS3003, and PMS1003 /should/ also work but will be larger. The letter after the model name refer to the orientation of the airflow in the sensor; if you’re not building a PCB and case, it doesn’t really matter which one you get. You’ll want to make sure that your sensor comes with a little rainbow colored cable, so that you can solder a connector to it as in this picture.
- If you want to avoid having to strip and solder wires, which is a bit finnicky, there is a breakout board that will give you male pin headers that’s available (search for “G7 adapter” on double lung electronic’s AliExpress shop).
- SHT31 module (also referred as SHT3X, if you want a sensor for temperature and humidity, good keywords for this on AliExpress are “SHT30,” “SHT31,” should be a small purple board)
- SGP30 module (if you want tVOC sensing, and an approximate CO₂ sensing, good keywords for this on AliExpress are “SGP30” and “GY-SGP,” should be a small blue board)
A micro USB cable
A soldering iron: I got a Hakko FX888D but any soldering iron should do
Some solder: I used Kester 24-6337-0018 leaded Sn63Pb37 rosin activated solder, but any leaded rosin solder should do. You probably want to get solder wire that is relatively thin to make it easier to solder these parts.
A fume extractor; breathing solder fumes isn’t good for your health, I got the Aven 17701
Some flux if you’re planning on soldering the wires from the particle sensor: I got a small bottle of Kester 959T flux from CMLsupply.com
A few 2.54mm male pin headers
Needle nose pliers to break off the male pin headers cleanly
Small wire cutters to cut and strip the particle sensor wires
A breadboard and jumper wires; I got a cheap one off AliExpress and regretted it, it had a short in it. Make sure it is wide enough if you’re using the SenseAir S8 CO₂ sensor, as that sensor is too wide to fit on a single breadboard.
A basic multimeter for continuity testing; if you have an oscilloscope or a logic analyzer handy, they might help with debugging if you encounter issues, but I wouldn’t buy them solely for this project

If you’re getting parts off AliExpress, arm yourself with some patience as it’ll take a while for everything to arrive.

Assembling everything

With all of the parts needed, what’s required is to solder the appropriate pin headers to the various module boards. For electronics beginners, you’ll want to search for how to solder electronics before starting to solder this.

If you’re not too sure about your soldering skills, solder the SHT31 module and the WeMos D1 mini first, as they’re the easiest parts to solder. You can then assemble the sensor to check that everything works, then come back to do the more expensive components.

Soldering

For the SHT31 module, you want to solder the pins such that the SHT31 sensor (the tiny chip with the little hole in the middle) faces up when placed on a breadboard.

For the WeMos D1 mini, you want to solder the pins pointing below, as shown in this picture.

For the Plantower particle sensor, you’ll want to cut the rainbow cable in half, strip the wires, and solder some pins to the wires. You want to make sure to solder the VCC, GND, RX and TX wires. You can solder the RST and SET wires, but they’re not used in this build.

For the SenseAir S8 CO₂ sensor, you’ll want to put the pins so that the pins stick out towards the body of the sensor. To do so, take some of the pin sockets from the WeMos D1 mini and place them on your breadboard. Break off two sections of pin headers (4 and 5 pins respectively), place them in the pin sockets, then place the S8 and solder away. The result should look like this.

Assembling

Now that you have the parts that you need soldered, you need to put them on a breadboard according to this schematic.

For the rest of us, this means that all of the 5V pins should be connected to the 5V pin on the WeMos D1 mini, all of the 3.3V pins should be connected to the 3.3V pin on the WeMos D1 mini, all of the grounds should be connected together, SCL and SDA should be connected to the SCL and SDA pins on the WeMos D1 mini, and the RX and TX pins from the other sensors should be connected to the pins indicated on the diagram.

For electronics beginners, you’ll want to search for how to use a breadboard before starting to assemble this on a breadboard.

In my case, I’ve used the left side of the breadboard for 3.3V and the right side of the breadboard for 5V; both grounds should be connected together.

If you’re using the CO₂ sensor, you’ll want to put some pin sockets on the breadboard so that you can put the sensor in the pin sockets. The pins on the S8 are not very well labeled, so you’ll want to refer to the SenseAir S8 datasheet, page 3. With the PCB pointing away from the breadboard, the pins on the left from the top are G+, G0, OC, and PWM; on the right, starting from the top, they’re DVCC, RX, TX, RT, and CAL.

If you do it right, it should look like this:

To make sure that everything works right before plugging in the USB cable, use your multimeter on the continuity testing setting. For electronics beginners, you’ll want to search for multimeter continuity testing to learn how to do this. Make sure that all of the pins are connected as expected:

All of the pins labeled GND/G0 should be connected to the G pin on the WeMos D1 mini
The 5V pin should be connected to the G+ pin on the S8 and the VCC pin of the Plantower
The 3V3 pin should be connected to the VIN pin of the SHT31 and SGP30
The SCL and SDA pins should be connected to the D1 and D2 pins of the WeMos D1 mini, respectively (eg. SCL connected to D1, SDA connected to D2)
The RX and TX pins of the particle sensor should be connected to the D5 and D6 pins of the WeMos D1 mini, respectively
The RX and TX pins of the CO₂ sensor should be connected to the D0 and D7 pins of the WeMos D1 mini, respectively
There should not be any other connections than the ones listed above

The software

I’ve created a PlatformIO project and put it on GitHub. If you’re using the D1 mini, you can probably use it as is; I use the PlatformIO extension from VS Code. Make sure that you also have the CH340 driver installed from the WeMos site, as you’ll need it to flash the firmware using USB.

You can configure the project by editing the platformio.ini file, which tells PlatformIO which sensors to use and how to build and flash the firmware.

The first time that you flash the firmware, you’ll want to do it over USB, as the D1 mini isn’t running the software that would allow flashing it over the air yet. You’ll also want to have the ENABLE_SERIAL_DEBUGGING option enabled to make sure that you can get readings from the sensors.

Flash the firmware using PlatformIO and open the serial monitor; you should be seeing output similar to the one below. If everything looks good, then you can remove the serial debugging option.

Based on what you want to do, you can leave the air quality monitor attached to a computer and have it log data over the serial port; it’ll emit a single line every second or so that contains all of the sensor readings.

Alternatively, you can enable the network settings to have it connect to 2.4GHz Wi-Fi and send its data over a TCP socket. It’ll emit the same data as over the serial port, but it’ll do so over the network so that you can have multiple sensors that log data to a server. This also enables over the air flashing, so that you can update the firmware on the D1 mini without having to unplug it, plug it into a computer, then put it back into place.

If you want to go that route, the first time that you’ll boot the sensor, it’ll create an unsecured AP. Connecting to that AP shows a page that allows you to configure the Wi-Fi network to connect to, which will be remembered.

I have made a simple server in Elixir that will save the data every few minutes to a CSV file, and rotate the files such that there is one file per day. This should allow you to start playing with the sensor data in your favorite data science environment.

Conclusion

This was a pretty fun project! I still need to finish the PCB and case, but I’ve been running these air quality monitors for a few months now and it’s been pretty interesting to look at the data.

I’ll write a subsequent post that talks about the things I have learned about indoors air quality by monitoring the air quality at my place.

If you build your own air quality monitor, feel free to reach out; I’ll be happy to hear about how you built your own and what you’ve learned from it!