Building QRity from the specification
From the workshop

Building QRity from the specification

Adam Kalisz
clojurespec-driven-developmentai

How do QR codes work, and what does practical specification-driven development look like? Building QRity and clj-png-adapter gave me an answer—and produced useful software for Clojure and ClojureScript along the way.

I began with the QR specification, sketched a progressive implementation path, and defined a small version-one encoder as the minimum viable product. From there, each step was checked against the specification and other implementations.

Decoding raised a different challenge: real images are rarely ideal. The tests therefore generate QR codes as images, distort and transform them in randomized ways, and then try to read them again.

Profiling guided the next stage. Moving critical paths to byte arrays reduced memory use and brought performance into competition with widely used libraries.

Interoperability widened the design further. Babashka and nbb lack Java ImageIO, while Node lacks a browser canvas. A small PNG encoder and decoder built on deflate and zlib covers those runtimes. CompressionStream and DecompressionStream also permit canvas-free browser operation, including environments with anti-tracking protections.

AI agents did much of the implementation work. The goal was not to type every Galois-field operation by hand, but to understand the stages, verify them against a detailed standard, and learn how this development style behaves when the specification is strong enough to act as a shared reference.