How this journal came about
Why write about development when you could just develop? Because the most interesting thing about Katlog isn’t the code but the journey: questions, mistakes, decisions. That journey was worth recording.
By the time the idea of a journal came up, the project already had a history: the Aleph export, the catalogue prototype, the accounts, the real system written by the agent, dozens of bugs found and fixed. All of it lived in one long conversation with an AI and in briefs for the agent.
Why a developer journal
New library systems are usually presented when they are finished: a slide deck, a feature list, screenshots. But a librarian thinking about their own project benefits more from something else: how decisions were made, what went wrong and how it was noticed. You can look at a finished system. The path to it you can only read about.
How the material is organised
- Sections — so the system can be read about from different angles: as a story, an interface walkthrough, data, a lesson.
- Article call numbers — like books in a catalogue: a section code and a number. A journal about a catalogue is itself organised like a catalogue.
- Real screenshots of the prototype and the demo system. All names and accounts in them are test data.
- Honest bug reports — because bugs show best how a system is built.
How the texts are written
The texts are prepared together with the AI assistant that took part in the development and remembers its details. The author reviews and edits them. The numbers come from the real data of the open catalogue; feature descriptions come from the code and the briefs.
The journal is an experiment too
The site is as simple as possible: no accounts, no comments, no tracking or analytics. Fonts are hosted on the site itself. This isn’t only about saving money: the fewer parts a system has, the fewer things can break.
This English edition was added at the request of colleagues abroad. The original texts were written in Russian.