I used Claude to build a Rust TrueType hinter, just to explore how far I could build the boundaries and test cases around a problem and let an agent go on fixing it. It worked very well and quickly got to a point where it was a decent hinter, based on visual comparisons, across a wide variety of fonts. But then I discovered that a similar Rust-based hinter existed in the training data, so the novelty of "can an agent work on a new problem space?" wasn't really satisfied.
So I looked around and found that there wasn't a native Swift DNG decoder. This is a good target for a few reasons:
- Some libraries exist but they either wrap CoreImage or use FFI to interact with C++.
- There are multiple ways of checking validity of the solution - libraw, the Adobe dng_sdk, as well as the DNG Spec.
- Fixture files are easy enough to find, and using a convertor, you can use the same file in the camera RAW format as well as DNG.
- Since there are multiple potential reference implementations, we can compare across multiple of those to make sure there is alignment in their output.
From the earlier experiment, I learned a couple of things:
- Give instructions to not just reference other implementations - only use the oracles as headless CLI to generate an image.
- Keep track of various decisions, divergences and successes in logs, as this is useful reference to keep the agent on track.
- Instructing the agent to build something that can be tested across phases, instead of just input/output. For the TrueType hinter, I had it take FreeType and use that to give phased outputs to check against so it could more easily diagnose divergences across the whole path. For this one, it mainly uses the phased approach for internal pipeline checks. In DNG decoding, the trace follows the causal chain (container parse → tag reads → decompression → color pipeline). This makes it easier to see where values are changed in the process, so there is more specific information for the agent to react to.
After a few days of letting the agent work through the spec, and providing some reference images with different DNG parameters, it can now match Adobe dng_sdk Bayer decoding
What I wanted to learn from this is: Can you rebuild a program in a new language, given access to the old program and documentation. I'm not a Swift expert by any means, nor a DNG expert. But the outputs demonstrate that this process can work, and work pretty cheaply. The reason this matters is that we are constantly considering whether or not it is economically viable to update old code to new languages, which may be safer, more efficient, or just have easier access to platform advancements. LLMs haven't solved all problems here, but they do drastically change the economic math.