You send a file, but how do you know it arrived intact? In other words, how do you know that it didn’t get cut off, garbled, or changed somehow? Simplistically, you could just add up all the bytes in the file — a checksum — and send that along with the file. You compute the checksum when you know the file is good, and the receiver can compare the checksum to see if they match.

However, a simple addition doesn’t catch certain classes of errors, which is why there are better checksum algorithms that, for example, wrap the carry bit around or otherwise modify files with common errors so they produce different checksums. There are two problems with checksums. First, no matter how much you modify the algorithm, the chances that two files produce the same checksum are pretty high. Especially with common error patterns.

For example, assume a very simple algorithm that simply adds the bytes and discards any carry. If a file contains 0x80, 0x80, those numbers essentially cancel each other out. If you replace them with 0, 0, you’ll get the same checksum. To some degree, using anything other than a second copy of the entire file will have this problem — some corruption goes undetected — but you want to minimize the number of times that happens.

The other problem is that a checksum by itself doesn’t let you correct anything. You know the data is bad, but you don’t know why. If you think about it, the simplest checksum is a parity bit on a byte: odd parity is simply summing all the bits together. If the parity bit doesn’t match, you know the byte is bad, but you don’t know why. Any even number of errors goes undetected, but I am sure one-, three-, five-, or seven-bit errors will get caught.

People invent better error-checking codes by devising schemes that can promise they can detect a certain number of bit flips and, at least in some cases, correct them. One of these is the cyclic redundancy check (CRC). It is easy to think of the CRC as a “strong checksum,” but it actually works differently. What’s more, there isn’t just a single CRC algorithm. You have to select or design a particular algorithm based on your needs. Most people pick a “named” implementation like CCITT or Ethernet and assume it must be the best. It probably isn’t.

A CRC is a checksum in the broad sense: you feed it a message, and it gives you a small value that you append, store, or compare later. But unlike a simple additive checksum, a CRC is based on polynomial division over GF(2), which is a fancy way of saying “divide using XOR instead of carries.” That detail matters. It gives CRCs very strong guarantees against common classes of errors, provided you choose the right polynomial for the job. That’s the key. You must choose the right polynomial.

The Polynomial Machine

A CRC treats your message as a long binary polynomial. For example, the byte stream is interpreted as a sequence of coefficients: each bit is either present or absent. The CRC algorithm divides the message polynomial, after shifting it by the CRC width, by a generator polynomial. The remainder is the CRC.

In normal arithmetic, division involves subtraction and carries. In CRC arithmetic, subtraction is XOR. That is why CRC code often looks like this:

if (crc & topbit)
crc = (crc << 1) ^ poly;
else
crc <<= 1;

That loop is implementing polynomial long division, one bit at a time. The generator polynomial is the magic number. For a 16-bit CRC, the polynomial has degree 16. For a 32-bit CRC, degree 32. You will usually see it written as a hex constant, such as 0x1021 for CRC-16/CCITT or 0x04C11DB7 for the classic Ethernet/ZIP/PNG CRC-32. But the polynomial is not just an arbitrary constant. It determines what error patterns the CRC is guaranteed to detect.

What CRCs Catch

A well-chosen CRC can guarantee detection of all single-bit errors, many multi-bit errors, all burst errors up to a certain length, and a very high percentage of longer random errors. The key metric is Hamming distance, often abbreviated HD. If a CRC has HD=4 for messages up to a certain length, it detects all 1-, 2-, and 3-bit errors in messages of that length.

That last qualifier is important. CRC strength is not just “16-bit CRC good, 32-bit CRC better.” It depends on the maximum message length. A polynomial that is excellent for 32-byte embedded packets may be mediocre for kilobyte-size messages. A polynomial standardized decades ago may be familiar but not optimal.

[Philip Koopman’s] work at Carnegie Mellon is the go-to reference here. [Koopman] and [Chakravarty’s] paper on CRC polynomial selection for embedded networks specifically looked for good CRC polynomials for short embedded messages, and [Koopman’s] “Best CRC Polynomials” tables list polynomials by width and Hamming-distance performance. The important takeaway is that many standard polynomials were chosen for historical reasons, not because they are mathematically best for your packet size.

There are plenty of videos that explain CRC, but if you are going to watch a video, you might as well pick one of the many from [Phil Koopman] himself, like the one below.

Famous Does Not Mean Optimal

Take CRC-16/CCITT, polynomial 0x1021. It is found everywhere: telecom, embedded examples, and bootloaders. It is not a terrible polynomial, but it is not automatically the best 16-bit choice. [Koopman’s] tables include other 16-bit polynomials with better Hamming-distance behavior over useful embedded-message lengths.

Likewise, classic CRC-32 using polynomial 0x04C11DB7 is deeply entrenched because of Ethernet, ZIP, gzip, and PNG. But CRC-32C, the Castagnoli polynomial, is often a better general-purpose choice. It has excellent error detection properties over common message lengths and is also supported by hardware instructions on many CPUs. Intel added CRC32 instructions with SSE4.2, and ARM AArch64 also includes CRC acceleration for CRC-32 and CRC-32C.

Of course, standards matter if you have to meet the standard. But if you are designing a new private protocol between your sensor board and your controller, blindly copying the first CRC-16 example from the Internet is not engineering. Pick a polynomial based on your packet length and your risk model.

The Practical Embedded View

For very small messages, even an 8-bit CRC may be adequate. For moderate packets, a good 16-bit CRC is often enough. For firmware images or large records, 32 bits is more reasonable. The point is not to use the biggest CRC you can tolerate. The point is to choose a CRC width and polynomial that give the desired detection strength for your longest protected message.

Also, remember what a CRC does not do. It is not cryptographic. It does not stop malicious tampering. The point of a CRC is to detect accidental corruption, not protect against sophisticated hacking attempts.

Real-world CRC definitions also include bit reflection, initial value, final XOR value, and sometimes byte order conventions. Two CRCs can use the same polynomial and still produce different answers because those parameters differ. That is a common embedded debugging trap. Someone says “CRC-16,” and both sides implement different CRC-16s. CRC-16/IBM, CRC-16/CCITT-FALSE, CRC-16/XMODEM, CRC-16/KERMIT, and CRC-16/MODBUS are not interchangeable.

If you specify a CRC in a protocol document, include at least the width, the polynomial (which can be represented in different formats, by the way), the initial value, if you use reflection on the input or output, and any value to XOR the output with. It is also a great idea to include the computed checksum for ASCII “123456789” so anyone can compare their algorithm to yours.

If you are working with Linux systems, be sure to look at the cksum program which can use several CRC algorithms or other methods like sha1 and other digest-style methods.

Efficiency

Computing CRCs a bit at a time is compact, but it costs eight loop iterations per byte. In some cases, that’s ok, but for performance, you want a table if you can afford the memory. For a 16-bit CRC, the table is only 512 bytes and can be generated at compile time, if desired.

Many CPUs have CRC peripherals. Use them, but read the fine print to make sure they can handle your desired CRC. It is often a good idea to check a hardware implementation against a known-good software implementation before you send it out into the wild. You can do many CRC tests using an online tool. Of course, there are several out there.

Choosing a CRC Today

For a new embedded protocol, define the maximum length of data you need to check. Then decide how many bits of overhead you can afford. Then head to Koopman’s tables to pick a polynomial with good Hamming-distance performance for that length.

The CRC has been around for a long time. But it isn’t just something you grab off the shelf. You need to plan and understand the ramifications of picking different polynomials.

CRCs aren’t the only game in town. Credit card numbers, for example, use check digits. There are other ways you can identify and, in some cases, zap bit errors, too.

The world of software has seen many paradigms come and go, all of which were supposed to revolutionize its development. Still, one of the basic tenets in engineering of there being no shortcuts to just doing the work properly also rings true in the field of software engineering: trying to skip ‘nice to haves’ like proper documentation, code formatting, and proper testing inevitably results in developers nervously trying to ignore the looming avalanche of technical and other project debts as they keep piling up.

While Test-Driven Development (TDD) once got praised as the silver bullet, the principle of writing tests before writing code merely postpones the inevitable project collapse. The elephant in the room is that you cannot pass on the basics in engineering and expect to come out fine on the other end. There’s a reason why phrases like “all tests green, successfully failed in production” have become common.

This is where the concept of Comment-Driven Development (CDD) comes into play. What started as a bit of a joke many years ago stuck in my mind and led me to my current approach in software development that tries to effectively mirror solid engineering principles.

Defining Comments

In the field of software engineering, code comments are often regarded as a bit of an unloved stepchild. No developer regards them in the same way, few appreciate them, most neglect them and some outright banish them from their lives. The most extreme response here is probably that of the Clean Code movement, who together with the Self-Documenting Code crowd insist that inline comments in particular are unnecessary, an eyesore and that beautiful, well-written code documents itself.

Then there are those who use comments as a (temporary) crutch, as in what is referred to as ‘comment programming‘.  This puts comments in the place where code is supposed to go, for either later replacement or to elucidate a specific aspect. None of this uses comments consistently to provide a parallel flow with the code that explains the what, why and how of said code.

Why this matters is that despite claims to the contrary, reading and understanding code is hard. Grasping architectural decisions and intuitively separating them from quick hacks is hard even if you’re reading back your own code after a few development cycles. This is also basically why writing documentation based on just code with at most spotty inline commentary is a nightmare at best.

After working with a variety of (commercial) codebases over the years that were practically dripping technical debt and regrets – as well as writing comprehensive documentation for some of them – I have become convinced that comments are ultimately the Alpha and Omega of a healthy codebase and up to date documentation.

Software Engineering

Although most people see the finished product of engineering and believe that that’s all there’s to it, the truth is that before that bridge, high-rise building or even some fancy electronic widget sees the light of day, most of the work has already happened. Building it is then theoretically as easy as following the provided instructions.

An essential point here is the assumption that said instructions are half-way correct and you don’t end up building your very own Millennium Tower.

Thus the process of engineering begins with the list of requirements. These have to be chiseled into the hardest of stone, as any change here will have potentially massive repercussions. From these requirements you can then begin to work on a design document that details the overall design of the product, from which the desired architecture follows.

While the specific details will differ for each specific field of engineering, it is this condensing from an abstract idea into increasingly more concrete steps that enables for all angles to be considered before committing to a specific decision that can be hard to revert or change later. In the case of the aforementioned Millennium Tower project, those in charge omitted steps like peer review, where an external set of eyes is asked to give their two cents, because this would have ‘taken too long’.

From Design To Code

Even if in general software is easier to change than e.g. the blueprints for a civil engineering project, you still want to avoid having to go back repeatedly to change or modify parts of a codebase. To this end you do not want to write code until you are very confident that said code is proper and correct.

Fortunately, with the detailed design document and architectural planning already in the bag you can then start the feedback loop of laying out the foundations, with any obvious issues discovered during this phase being used to improve the design and architectural documentation.

Laying out these foundations involves creating the codebase’s basic layout, including details like creating header and source files with appropriate naming. Next, within these files the architectural structure is laid out, such as creating the skeletons of types, classes, functions and methods that establish the APIs.

For each file a heading comment block is added that briefly summarizes the file’s purpose, the features contained therein, as well as a truncated change list with date and name, for accountability.

At this point we are ready to pour in the details of each compile unit’s implementation, starting by taking the design and related documents and turning the details contained therein into comments that describe the overarching design decisions, special considerations, the flow within a section and any interactions with other modules.

An example of this can be found in my Sarge command line argument parsing library, which both in its C++ and Ada form would be a very hairy mess of logic to keep track of without having the continuous flow of thought describing what is happening, why it’s happening and relevant implications.

Although it may seem simple and obvious, doing this consistently and in a way that doesn’t leave future you staring dumbfounded at a section of code, or chasing red herrings during a debugging session due to a flawed assumption is somewhat of an art. Here it’s crucial that whenever you find yourself in such a state that the relevant inline comments are updated or new ones added as necessary to prevent future confusion.

It shouldn’t even have to be said that keeping these comments – and related documentation – updated whenever code changes are made is absolutely paramount as well. While it’s ‘boring’ work, you don’t do it for your present self, but your future self and/or fellow developers who’ll otherwise use extremely colorful language related to your person.

Documentation And Tests

Writing the documentation with CDD starts from the first list of requirements, with the design document being the next major part, both providing the higher-level overview of the project before diving into the nitty-gritty of the architecture and implementation.

What the best approach here is largely depends on the project and who might be interested in documentation and to which extent. For a typical commercial project where there never is budget for ‘writing documentation’, simply having the design document and the detailed inline comments in the source might be what one has to settle for.

Here it might also be possible to use said inline comments to generate e.g. API listings from with tools such as Doxygen. My own experiences with such tools are mixed, but in a CDD context such auto-generated documentation could be significantly more useful, not to mention accurate.

Finally, any tests required to test specific functionality would be defined along with the code’s architecture, letting it define the testing scope rather than vice versa. With APIs for modules already settled early on, writing unit- and integration tests tends to be a lot easier and without the nagging and nebulous goal of that mystical ‘100% test coverage’.

Mitigating Circumstances

Of course, not every software project is the same, especially for hobbyist projects where you’re often the sole maintainer. It is here your prerogative to take all the shortcuts you want, as long as it is in the knowledge that you’ll only have yourself to blame.

This is why some of my projects are definitely a bit more loose in their adherence to CDD, while others are a complete stickler. for example, when I created my NyanSD network service discovery protocol, I started by writing out a complete requirements and design document, including the protocol itself. By following the top-down CDD approach here I was able to design and implement the entire protocol in the course of about two days, and have it mostly work first try.

Ultimately, CDD in my eyes is the correct approach to software engineering, as it saves a lot of time while being the only approach that actually follows basic engineering principles. You can change the field, but ultimately both physics and underlying hardware remain just as unimpressed by your personal views on how things ought to work.

When the Artemis lunar program was first conceived, the third mission would have seen astronauts step foot on the Moon for the first time since Apollo 17 in 1972. But as hard as getting into space is, a sojourn to our nearest celestial neighbor is even more mindbogglingly complex, and so earlier this year it was announced that actually landing on the Moon would be pushed out to the fourth mission.

In turn Artemis III would take a page out of the Apollo 9 playbook and test out rendezvous and docking procedures with commercial landers while operating in the relative safety of low Earth orbit. Moving the target date for the landing a few years down the road gave all involved parties a little more breathing room, but it also provided a valuable opportunity to gain insight into the performance of the vehicles and systems ahead of the critical moment. In the original timeline, the first time Orion would attempt to dock with the lander would have been just before descending to the lunar surface — leaving precious little time to troubleshoot should anything go wrong.

Yesterday NASA held a press conference to update the public on their progress towards the planned 2027 launch of Artemis III, which included the long-awaited announcement of the crew that will kick the tires on the next-generation lunar landers being developed by SpaceX and Blue Origin

Meet the Artemis III Crew

One Mission, Three Launches

Although astronauts are by their nature the best of the best, the collected experience and knowledge of the Artemis III crew is truly incredible — and for good reason. This flight will be one of the most challenging and technically complex operations ever conducted in space, perhaps second only to the Apollo Moon landings themselves. In the most ambitious version of the plan, three spacecraft launched by three different booster rockets will conduct a carefully choreographed operation over the course of two weeks.

To start the first phase of Artemis III, Blue Origin will use one of their New Glenn rockets to carry the Blue Moon MK2 lander into low Earth orbit. The lander is designed to spend up to 90 days in space, which will give NASA a comfortable window of opportunity to get their Space Launch System rocket and Orion spacecraft ready for liftoff. After launch Orion will rendezvous and dock with the lander, and the crew will spend the next two days performing various tests and demonstrations. If everything goes well, they will ultimately enter the lander itself and don prototypes of the spacesuits that Axiom Space is developing for the Artemis IV crew to wear on the lunar surface.

Meanwhile, SpaceX will be preparing a modified version of their Starship V3 spacecraft for liftoff atop the Super Heavy booster. Once the Orion spacecraft is undocked and clear of the Blue Moon MK2, the prototype Starship Human Landing System (HLS) will launch and meet the capsule in orbit. According to SpaceX representatives, the vehicle itself won’t be too far removed from the version that completed a test flight back in May. Compared to Blue Origin’s lander, which will feature a boilerplate cabin design and functional life support systems, the Artemis III crew won’t be able to enter this early version of HLS.

Likely in expectation that comparisons would be made between the apparent capabilities of the two landers, SpaceX Vice President of Space Operations Jessica Jensen pointed out that many of the systems that will be used in Starship HLS such as the life support and avionics are derived from the flight-proven hardware used on the Crew Dragon — with some components such as the docking system being effectively identical. From the perspective of SpaceX, it’s more important to focus on testing the new hardware and procedures being developed specifically for the Moon.

Given that astronauts will not be able to enter the Starship HLS prototype, it’s expected the crew will spend significantly less time docked to it. After conducting some maneuvers to see how the two vehicles handle in relation to each other, the Orion will depart orbit and head for a splashdown in the Pacific.

Setting Course For Artemis IV

Although the press conference was about the upcoming mission, Jensen did give some brief details on how SpaceX and NASA are working together to refine the procedures for Artemis IV in 2028.

Back when Artemis III was set to touch down on the lunar surface, the plan was for Starship HLS to first enter into a relatively uncommon Near-Rectilinear Halo Orbit (NRHO) around the Moon, where it would eventually be met by the Orion capsule. However this was largely predicated on the idea that the Lunar Gateway Station would also be in NRHO. Now that the construction of Gateway has been abandoned, there’s no reason to rendezvous in that particular orbit.

Instead Orion will now dock with Starship HLS in low Earth orbit, just like it will on Artemis III. From there, Starship will use its own engines to perform the critical trans-lunar injection burn and put both craft on course towards the Moon.

This approach is not only easier to execute, but will require less propellant and therefore fewer refueling flights — directly addressing a common criticism leveled against the Artemis architecture.

High Risk, High Reward

Calling Artemis III ambitious would be an understatement. A mission involving a trio of spacecraft and their respective launch vehicles, two of which being early prototypes, has never been attempted in the history of spaceflight. Getting just one vehicle off the ground is a challenge in itself, and although experienced gained over the decades thanks to the International Space Station has made the subsequent rendezvous between two craft relatively routine, doing it twice during the same mission adds a whole new dimension.

Even the most ardent space fan has to admit it’s exceptionally difficult to believe that the involved parties can put such a bold plan into action in the next ~18 months, especially given the recent New Glenn explosion that has left Blue Origin’s launchpad in shambles. But it will certainly be exciting to see them try.

After scathing accusations of skimping on due diligence, as well as other feedback to my article on trying to use an ‘AI coding assistant’ for the first time, the only rational, academic response is to lick one’s wounds following a particularly bruising peer review and try to address the raised issues. Reality after all does not care about one’s feelings, and there may be more to this AI assistant technology that can be coaxed out with a more in-depth look.

To this end I’ll do my best to try and work through each raised point, criticism and accusation, to see what I – and perhaps others – can learn of this endeavor. Said points include the use of the wrong frontend – i.e. Copilot – and the wrong model – being Claude Haiku 4.5 – as well as the egregious flaw on my end of ‘prompting wrong’.

For the sake of due diligence the best frontend and models will be investigated for particular tasks, with finally the verbal minefield of ‘prompt engineering’ examined for industry-standard approaches.

Junior Developer

The exact way to refer to an LLM coding assistant is still in flux, with some comparing it to pair programming, while others see the assistant more as a glorified search engine that also has code-complete features as a kind of merger of a web search engine and IntelliSense in Visual Studio. This relationship and how to look at it is the cause of a lot of contention as a result.

Another perspective is that of these assistants being more like junior developers. After all, they can apparently do all the basic boilerplate stuff, write unit tests and perform a range of other basic tasks that are beneath more senior developers. The corollary here is then of course why companies would even want to hire another junior developer if the LLM can fill these jobs. Unsurprisingly, it is already being reported that this happening.

The million dollar question that remains is that if all of this is true whether a junior developer still has value. The answer appears to be ‘yes’, even if you ask Microsoft. The argument would appear to boil down to that these assistants supposedly automate away a lot of the tedium that used to get pushed onto junior developers, leaving them free to develop more advanced skills, naturally supported by the same coding assistants.

Fancier Automation

This gets us to the question of whether these assistants are really much better than the automation tools that have existed in IDEs for many decades now with arguable improvements over time. They certainly do seem to be more capable, but they’ll still never exceed their programming, and require a lot of finagling to make them do the right thing.

Returning to junior developers for a moment: bad apples aside, they will let you know if they didn’t understand something correctly, ask for clarification, admit that they don’t know something and offer to look something up in the documentation if they do not know. None of these are things that these glorified chatbots are capable of, which makes a comparison with IDE automation tools rather fair, especially since junior developers tend to get fired if they screw up as badly as the LLM tools seem to regularly do.

While it’s true that these newfangled coding assistants do have a context window in which they “remember” previous details, you’re still dealing with the limitations of the underlying model no matter how good your prompt engineering skills are. They will also regularly confabulate and you have to accept that they generate code and documentation that is just as likely to be correct as completely wrong, even if many users of these tools seem to believe that they are actually more performant.

Ergo you’ll be writing test cases for the test cases and generated code, while also pulling code review duty, as there is no possibility of ever establishing a level of trust. Especially not after it deletes your entire hard drive or the production database for the second time that week.

If that sounds like the kind of junior developer or automation tool you’d love to be paired up with, then you’re quite the adventurous spirit. Meanwhile I have had enough fun with even code completion tools like the aforementioned IntelliSense or its equivalents in the various other IDEs that I have used over the years to never use them again. It’s bad enough when a code completion tool gets it wrong, it’s worse when the human in the loop fails to catch the glaring mistake.

Model Frontends

Although we generally refer to ChatGPT, Claude or Copilot as an LLM, this is technically incorrect, as these are merely the chatbot frontends that are written to provide a natural language interface experience. The choice here is naturally quite dizzying, as you have a range of major players including the aforementioned, each of which offers a web interface as well as integration with various IDEs and use on the CLI for easy automation.

Hence the claim that one should never use the web frontend for coding, as it needs access to your code and local environment, which makes sense if you want more of the pair programming experience. Since my ‘IDE’ of choice are Notepad++ and Vim, my options here are of course rather limited. There is a third-party OpenAI integration plug for NP++ called NPPOpenAI, but that would seem to be it.

The cool kids are of course all using Visual Studio Code with direct integration of all the frontends, but that option seems about as appealing as ripping half the RAM out of my PC and smashing my fingers with a hammer. Even as a former avid Visual Studio Pro user I feel insulted on a fundamental level at the mere thought.

Maybe that one of the CLI tools like Copilot CLI are a better match for me here as suggested, but this would appear to be more of a way to automate various GitHub tasks. Despite searching around I could not find an objective comparison of the different frontends, just many strong opinions and various pricing plans for model access, so for all intents and purposes they’re being treated as the same.

The Model Catwalk

It was further suggested that I take a look at LiveBench.ai for a comparison of how models perform on various tasks. This does indeed appear to be a valuable resource, if only for providing what appears to be a fairly objective way to compare these individual models against each other.

When sorting by the heading Coding Average, it puts OpenAI’s GPT-5.2 Codex at the top, with Claude 4.7 Opus Thinking High Effort close behind at both a hair over 83%. The Haiku 4.5 model that I was using comes in at a mere 72.17%, which is still much better than the sub-60 percent models near the bottom. Of the free models Haiku 4.5 at least would seem to be not too terrible, with Anthropic marketing it in October of 2025 as equivalent to Sonnet 4 when it comes to coding performance:

Consequently, it would be expected to perform at least decently at given tasks, but we can take a look at what other models are available via GitHub Copilot, for instance.

If you’re not into shelling out any clams for a purported improved experience with at least the Pro+ – not Pro – subscription, you get access to quite a few models to pick from that are apparently not ‘premium’. Of note here is that new sign-ups are currently ‘paused’ as usage-based billing is being introduced.

Of these available free models the following would have theoretically performed better according to the aforementioned benchmarks:

• GPT-5.4 Mini, at 74.70%.
• GPT-5 Mini, at 76.07%.

Following the ‘fast and cost-efficient’ category things get a bit dicey to compare, due to Anthropic’s awesome naming scheme and apparently an additional mode you can use these models in, which may or may not apply here:

• Claude Sonnet 4.6 (Thinking High Effort), 79.9%.
• Claude Sonnet 4.5 (Thinking), 80.36%.

These are apparently ‘more versatile and highly intelligent’, which doesn’t seem to bump up their total score too much compared to the mini models. Following this we get the ‘most powerful at complex tasks’ models:

• GPT-5.4 (Thinking High Effort), 78.18%.
• GPT 5.3 Codex (High), 78.18%.

Taken at face value, the 72.17% for the Haiku 4.5 model is indeed somewhat worse than the other two mini models, yet as this points system relies on a specific methodology it’s important to consider what this means. From the underlying coding tests we can see that they are all Python-based programming examples, which is great if you’re testing Python coding assistants, but rather useless for my purposes as I program in just about any language except Python.

Perhaps more worrying here is the statistic that even in this scenario the best model (GPT-5.2 Codex) only managed to score a rather pitiful 83.62%, so your choice would seem to be roughly between ‘atrocious’ and ‘very bad’. Within the free model selection you’re choosing between roughly 28% and 22% of the answers being incorrect, or roughly a 3/4 chance of getting what you were asking for.

Statistically, this wouldn’t seem to make much of a difference when picking either model.

Prompt Engineering

On my last foray, I was also accused of “prompting the wrong way”, which brings us to the topic of prompt engineering, where you must learn to follow specific rules in order to “correctly” use one of these coding assistants. A crucial aspect that was not obvious to me is that you absolutely must use so-called ‘environmental prompting’, where you set the equivalent of global variables.

To this you then add instructions, such as in the absolute gem that is used by the Livebench code test for an array test:

### Instructions: You are an expert Python programmer. You will be given a question (problem specification) and will generate a correct Python program that matches the specification and passes all tests. You will NOT return anything except for the program.
### Question:
You are given an integer array nums and an integer k.
The frequency of an element x is the number of times it occurs in an array.
An array is called good if the frequency of each element in this array is less than or equal to k.
Return the length of the longest good subarray of nums.
A subarray is a contiguous non-empty sequence of elements within an array.

Example 1:

Input: nums = [1,2,3,1,2,3,1,2], k = 2
Output: 6
Explanation: The longest possible good subarray is [1,2,3,1,2,3] since the values 1, 2, and 3 occur at most twice in this subarray. Note that the subarrays [2,3,1,2,3,1] and [3,1,2,3,1,2] are also good.
It can be shown that there are no good subarrays with length more than 6.

Example 2:

Input: nums = [1,2,1,2,1,2,1,2], k = 1
Output: 2
Explanation: The longest possible good subarray is [1,2] since the values 1 and 2 occur at most once in this subarray. Note that the subarray [2,1] is also good.
It can be shown that there are no good subarrays with length more than 2.

Example 3:

Input: nums = [5,5,5,5,5,5,5], k = 4
Output: 4
Explanation: The longest possible good subarray is [5,5,5,5] since the value 5 occurs 4 times in this subarray.
It can be shown that there are no good subarrays with length more than 4.


Constraints:

1 <= nums.length <= 10^5
1 <= nums[i] <= 10^9
1 <= k <= nums.length

### Format: You will use the following starter code to write the solution to the problem and enclose your code within delimiters.
```python
class Solution:
def maxSubarrayLength(self, nums: List[int], k: int) -> int:

```

### Answer: (use the provided format with backticks)

With this kind of preamble and explicit instructions to the ‘coding assistants’, you may as well just write the code yourself. Even if further brevity is usually ‘good enough’, the need to spend all that time and effort just to get the answer that you know you were looking for. Even a junior developer wouldn’t need this much hand holding.

In this regard, the other uses that people have mentioned, such as bouncing ideas off the chatbot — “rubber ducking” — has merit, but often even talking to potted plants or going on that walk around the block can do just about as much with getting one’s thoughts in order, along with random web searches.

Whether to use “micro prompts” or larger tasks, whether to use the chatbot as a search engine or not, and whether to correct answers to previous prompts are all details that seem to be highly divisive among users of these tools, as is the topic of vibe coding, which some seem to embrace, while others dismiss it as an insult for their artisanal craftwork.

Local Models

There are many more things to cover here, such the use of local models vs these hosted ones, with all the gotchas of subscriptions, private data harvesting and the like that this entails, but that will have to wait for another article. It’s also interesting how much the subscription and usage fees (and limitations) are currently going up across the various services, making the idea of local models seem more attractive, if they are even worth it with such limited inference capacity available.

Suffice it to say that I have learned some things along the way of writing this article, while not changing my overall premise and conclusion of the previous article. Although I could have certainly picked a theoretically better model, this is hard to to substantiate without pitting the models against each other in STM32 CMSIS and Ada coding challenges. Based on the results in Python it’s hard to make the claim that it would have made an amazing distinction, but maybe not using a ‘mini’ model makes all the difference here?

Hopefully the better models won’t be removed from free access before I can even give this idea a shot.

Among so many other technological advances, the Cold War saw the advent of the ballistic missile submarine. The concept was simple—pack enough nuclear warheads to destroy a small civilization into a compact metal tube, and then hide it underwater. The oceans would act as a cloak for your fleet of world-enders, and keep your enemies forever on their toes. A terrifying machine that could both start and end a war with the push of a button.

Most nation states are populated by humans with the will to live. Thus, there has been a great incentive to find ways to keep tabs on these sunken doombringers. Great efforts have gone into improving sonar and magnetic detection methods over the decades, which are the bread and butter of sub hunting to this day. However, military researchers have also explored the prospect of whether submarines could be detected via their effect on the gravitational field alone.

Do You Feel It?

The simple matter is that every object with mass has its own gravitational field. We don’t typically think about it, because gravity is the weakest of the fundamental forces. On anything less than a planetary scale, it’s generally not obvious to us in our daily lives. However, submarines are quite heavy and large, particularly those that are armed with a complement of nuclear-capable ballistic missiles. Thus is raised the prospect of detecting these massive objects via their perturbations to the local gravitational field. This has been a hot-button news item in military commentary circles of late, with much bluster that advanced measurement equipment could potentially render the ocean transparent and reveal the locations of submarines at great distances.

Naturally, it’s difficult to comment accurately on top-secret military capabilities from a civilian viewpoint. Such a technology would be game-changing in a strategic sense, to the point that any nation state with such a capability would have great reason to keep its existence strictly hidden. However, there is some literature on the topic that is in the public domain, which discusses just how hard this feat would be to execute in practice. A great example is a report prepared by the Pacific-Sierra Research Corporation in 1989, under the sponsorship of the Naval Air Development Center.

How It Works

When it comes to detecting the gravitational anomaly of a submarine, you might think it would be easy given the sheer mass of such a craft. However, the way submarines operate frustrates this at a very fundamental level. In normal operation, a submarine is neutrally buoyant, displacing an amount of water roughly equal to its own mass. Thus, the submarine is not really distinguishable from the water around it in terms of its first-order effect on the gravitational field, being roughly as heavy as the water that would otherwise be there.

There is a wrinkle, though, in that a submarine is bottom-heavy for the sake of stability. This does create a variance in the gravitational field versus the otherwise uniform field in open water, and it’s one that could theoretically be detectable with a sensitive enough apparatus.

The device used for measuring gravitational variation is called a gravimeter. They are essentially a special-case variant of accelerometer, specifically designed to very accurately measure the local acceleration due to gravity at a single point. Then there is the gravity gradiometer, which measures the spatial rate of change of gravitational acceleration. By virtue of measuring acceleration gradients, a gradiometer is not sensitive to the acceleration perturbations of a moving platform, making it particularly useful for use in a moving frame of reference such as towing behind a ship or aircraft. Various types of each instrument exist, from portable units to high accuracy laboratory instruments; creating an exhaustive list of all  variants is outside the scope of this article. The real question is, based on the gravitational anomaly generated by a large submarine, to what useful range could a gravimeter or gradiometer detect one?

Unfortunately, the maths says that you have to get very, very close. In the 1989 study, calculations suggested the best gravimeters and gradiometers in the world would maybe be able to pick up a large submarine from a distance of tens of meters, at best. The simple problem being that the gravitational anomaly generated by an underwater submarine, and the gradient of that anomaly, are both so small, that even highly sensitive instruments would struggle to pick it up when the submarine is practically in visual range. Even if the problem were simplified, and one were trying to detect a submarine as a heavy point mass in empty space, detection ranges would stretch to somewhere in the range of 100 meters at most. Of course, this would be largely irrelevant due to the neutral buoyancy considerations explained above.

It’s true that technology has moved on since 1989. We have more advanced gravimeters and gradiometers available now, including quantum units with greater sensitivity than ever. And yet, even with these advances, it would be still be a struggle to detect a submarine at useful range. Sensitivities would have to jump by four or five orders of magnitude to enable detection at ranges of 1000 meters. Even still, if this were achieved with some highly classified system, it would still be relatively limited in capability versus more established techniques in magnetic or acoustic detection.

The parameters of the problem, combined with the sheer weakness of gravitational forces, means that gravitational detection is not some silver bullet for tracking enemy submarines at great range. While it would be desirable to have some kind of sensor that could reveal where these nuclear weapon platforms are lurking at all times, that technology seems beyond the reach of even the most capable navies at this time. For now, strategic planners will continue to sweat over the threat these weapons pose, never quite knowing whether they’re lurking just off the coast or half a world away.

The 2000s was a decade of great change in the computer industry. The world had grown accustomed to corruptible floppy disks, blue screens of death, and achingly slow load times. In a few short years, all of that would change, as USB drives, better operating systems, and faster processors brought forth a new age of stability and speed.

Amidst this era of upheaval, Microsoft introduced a new technology. It was intended to increase performance on the cheap to a new generation of machines, but it would turn out to be little more than a gimmick that never really caught on. Let’s explore the easily-forgotten legacy of ReadyBoost.

Boost or Bluster?

When Windows Vista was launched in 2006, it was built to make the most of new technologies that were rapidly becoming mainstream in the industry. Chief among them was flash memory. The USB flash drive had risen to prominence as a defacto solution for removable storage, while digital cameras and PDAs had made Compact Flash and SD cards familiar items to many.

Microsoft engineers realized that this presented an opportunity. While flash memory was still only available in relatively small capacities at the time compared to magnetic storage, it had a special advantage of its own. NAND flash could offer far quicker reads for random access compared to spinning magnetic hard drives, which were subject to the mechanical limitations of their rotational speed and how quickly their heads could seek across a platter. Thus, the idea for ReadyBoost was born—to use cheap flash storage as a cache to speed up random disk reads.

ReadyBoost had some basic requirements. It could only be activated on USB flash drives or other removable flash media with a capacity in excess of 250 MB. That was the minimum cache size, with a 4 GB maximum size in the initial Windows Vista release. One could decide to dedicate a device to ReadyBoost, or only use a segment of its total storage capacity.

Only a single device could be used at a time for ReadyBoost in Windows Vista, formatted in FAT16, FAT32, or NTFS. The drive in question would be tested to determine if it could achieve 2.5 MB/s read speeds for 4 kB random reads, as well as 1.75 MB/s write speeds for 512 kB random writes, in order to make sure it would be fast enough to work as a higher-speed cache. Similarly, access times had to be below 1 ms for the device to be of use.Any space used for cache could not be used for storing files. The ReadyBoost cache itself was stored as a file called ReadyBoost.sfcache.

ReadyBoost could be enabled on a range of flash media, as long as it met the above minimum specifications. USB flash drives were an obvious choice, if you didn’t mind having a dongle hanging off your PC or laptop all the time. Microsoft also noted that SD cards could be a convenient solution for permanently parking a ReadyBoost cache in machines that had a card reader slot. You could also use CompactFlash cards, too, if so desired.

Approaching the time of release, Microsoft engineers noted that random read performance on flash drives was 10 times quicker than hard disks. However, on larger sequential reads, HDDs were still going to outperform most USB 2.0 flash drives available. Even in 2006, it was noted that the ReadyBoost system would make the biggest difference under high disk use and low free memory conditions. On machines with lots of RAM and during light usage, it didn’t help as much.

ReadyBoost was just one of a range of technologies that was implemented in Windows Vista to aid performance. Microsoft also developed ReadyDrive, which was intended to hurry along boot times with the aid of newly-developed hybrid hard drives that combined magnetic storage with non-volatile flash memory. There was also SuperFetch, which assessed which applications were most commonly used and preloaded them into memory to allow them to load faster. These technologies were both a little more background in operation, though.

Microsoft gradually improved ReadyBoost over the years. Windows 7 brought upgrades, allowing the use of up to eight devices with a cache capacity of 32 GB each—putting the total cache size maximum at a hefty 256 GB. The algorithm behind ReadyBoost was also improved, while newer, faster flash memory and interfaces aided performance further. The technology persisted through later Windows versions, until it was eventually deprecated and eliminated in Windows 11 version 22H2. One suspects this was because use rates were so low that it didn’t make sense to maintain the feature any longer.

How much difference ReadyBoost did make in the real world? While the basis of the technology was sound, it’s not exactly clear how many users actually bothered to use it. The impact was theoretically greatest on systems with slower magnetic hard drives and low RAM. This became increasingly less relevant as the industry moved towards larger amounts of RAM and SSDs as standard. For most Windows users, it remains a footnote in the operating system’s history—an interesting curio that helped in some edge cases, but was perhaps not a gamechanger except for the weakest machines out there. In the end, it couldn’t compete with the tried-and-true method of just having faster primary storage and more RAM in the first place. It might have helped out a bit back when underpowered netbooks were struggling along and RAM in excess of 2 GB was a luxury, but today, ReadyBoost just doesn’t make sense when every PC out there has a blazingly fast SSD under the hood. The times changed, and the world moved on.

If you were around tech in the bad old days, magnets could be really bad news. They were fine on the fridge, no problem at all. Put one near a floppy disk, or a hard drive, or even a computer monitor, though, and you were in for some pain. You’d lose data, possibly permanently destroy a disk or drive, or you’d get ugly smeary rainbow effects all over your screen.

The solid state revolution has eliminated a lot of these problems. We all use SSDs, flash drives, and LCD monitors now, all of which care a lot less about flirting with magnets. However, the same can’t be said about all our modern hardware, for a magnet could cause your smartphone some major grief indeed.

Magnetic Fields

As you might expect, the magnetic susceptibility of certain modern smartphones once again comes down to non-solid state parts. Now, there aren’t exactly a lot of phones out there that are packing hard drives or floppy drives or any sort of magnetic storage. Instead, it all comes down to cameras.

Take the modern iPhone line, for example. Apple is quite careful to warn against carelessly using magnetic accessories with the smartphone, because it can interfere with the cameras. Specifically, it’s because of the optical image stabilization (OIS) and closed-loop autofocus systems that are built into the cameras themselves. These devices use magnetic position sensors to determine lens position to compensate for focus, vibration, and movement, and use magnetic voice coil actuators to move optical elements, in order to take the best possible photos and videos at all times. If there’s a strong magnetic field in the vicinity of the lenses, it can interfere with this operation.

Few of us are sticking fridge magnets on our iPhones, to be sure. However, there are a lot of magnetic cases and mounts and other accessories that give people a great reason to stick magnets on their phone. In the cases of some third-party accessories that are poorly designed, it’s possible for these to cause problems with the camera if the magnets are too strong or too close to the key hardware. It’s worth noting that in typical use, something like a magnetic case or other small magnet won’t cause a lot of permanent harm. It will generally just degrade the operation of the camera until the magnet is removed.

This isn’t solely an iPhone problem, either. It can affect any phone that has any sort of magnetic sensing or actuation involved in the camera mechanism. Indeed, Samsung has even filed a patent on ways to mitigate this problem through carefully orientating the magnets used in folding phone mechanisms, and the appropriate use of shielding. Ultimately, similar camera technology is used in a great many phones, all of which are susceptible to this problem.

It’s true that in day to day use, you’re probably not going to run into a lot of problems waving around a magnet near your smartphone. Nor did floppy disks fail en masse in the 90’s, unless one of your colleagues was feeling vindictive and wiped them all with a fridge magnet on their lunch break. Still, like the oddball helium problem that because apparent with smartphones a few years ago, it’s funny to think that magnets could be causing trouble with computer hardware today. The fact is that a modern smartphone contains multitudes, and thus can surprise you with its edge case frailties.