Kodex Is Taking Shape
Table of contents
For quite some time, Kodex was more of an idea than a system.
There were pieces of previous projects, design decisions made at different points in time, code that still made sense, and code that clearly belonged to another era. The initial goal was relatively simple: bring kazztor.net back without carrying all the weight of what had come before.
But at some point over the past few weeks, the nature of the work changed.
We’re no longer simply rebuilding the website.
We’re defining how it works.
Recover First, Design Later
One of the most useful decisions was resisting the temptation to rebuild everything from scratch.
When a project has spent years accumulating versions, frameworks, styles, and experiments, starting over can seem appealing. It can also become an elegant way of repeating the same mistakes.
Kodex took a different approach.
First, we recovered what still had value. Then we began separating accidental decisions from the ones we actually wanted to preserve.
That forced us to answer some fairly basic questions.
What should belong to the website?
What should belong to the design system?
How should articles be stored?
Where should their images live?
Which parts of the infrastructure need to know about the content, and which should remain completely independent of it?
These aren’t particularly exciting questions, but they’re probably more important than choosing a framework or writing a new component.
Design Is No Longer a Collection of Numbers
One of the most interesting changes happened with typography.
Over the years, it’s easy to fall into the traditional habit of adjusting a website one value at a time: a font size here, a margin there, a few pixels until everything looks right.
It works.
Until the screen width changes.
Then the patches begin.
With Kodex, we’ve started treating typography as a continuous system. Font size, reading width, spacing, and vertical rhythm need to respond together to the available space.
That means returning to tools like clamp() and calc(), but not simply because they’re modern.
The idea is to let the design breathe across different screen sizes without relying on an endless collection of breakpoints.
Comparing Kodex with platforms like Medium has also been useful, not because we want to copy them, but because it helps us measure something that’s sometimes difficult to describe: rhythm.
How much space separates one idea from the next.
How long a line of text should be.
When a paragraph starts to feel heavy.
When a page feels like a document and when it begins to feel like an interface.
Those small decisions end up defining much of the reading experience.
Style Foundation Has Found Its Purpose
Another piece that’s falling into place is Style Foundation.
Originally, it might have seemed like just another repository of shared styles. Now its role is becoming much clearer.
Kodex shouldn’t independently determine every font size, scale, or responsive rule. Those decisions belong to a lower layer.
Style Foundation can become exactly that: a reusable visual foundation, independent of the specific content on kazztor.net.
When we discover a typography issue in Kodex, the question is no longer just:
“How do I fix this page?”
We can also ask:
“Does this problem reveal something that should be corrected in the system?”
That shift in perspective is small but important.
Solving a problem once is far more valuable than solving it page by page.
Content Needs Architecture Too
Something similar happened with images.
In a traditional blog, it’s easy to end up with an enormous media directory containing images from completely unrelated articles.
It works at first.
Then files start appearing with names like:
hero-final-2-real.webp
Kodex is moving in a simpler direction: each article can own its own assets.
Text and images belong to the same conceptual unit.
If an article disappears, it’s obvious which files belong to it. If it moves, its assets can move with it. If we want to understand how it’s built, we don’t need to navigate half the project.
This isn’t some groundbreaking technological innovation.
It’s simply organization.
And organization starts to matter a great deal when we want both humans and AI agents to understand a project without having to reconstruct its entire history every time.
Codex Is Changing How We Build
This is where perhaps the biggest change of all comes in.
Kodex is being developed at a time when writing code is no longer necessarily the slowest part of software development.
We can ask Codex to investigate a problem, read an issue, review an implementation, and prepare changes.
That shifts the bottleneck.
The important work becomes defining the problem correctly, preserving context, and establishing which decisions belong to which parts of the system.
An agent can write a function in seconds.
But if it doesn’t understand why that function exists, where it belongs, or which principle it’s supposed to protect, it will simply produce code faster.
That’s why Kodex’s architecture is beginning to include something I might once have considered secondary documentation: explicit decisions.
Issues that explain problems.
Repositories with clearly defined responsibilities.
Conventions for managing assets.
Rules that can be understood before modifying the code.
Documentation no longer exists only to help us remember a project six months from now.
It also allows an AI agent to work on it today without inventing half the context.
Even the Server Is Part of the Design
Recovering the infrastructure ended up following the same principle.
The existing server already had responsibilities. Traefik was handling incoming traffic, and other services depended on that architecture.
The easy solution would have been to take over the public ports and get kazztor.net running as quickly as possible.
The right solution was to understand what was already there.
The plan is for Kodex to have its own web server behind Traefik, without interfering with the other services.
Once again, the same idea emerges:
Don’t destroy a working structure just because you want to add something new.
Understand first.
Separate responsibilities second.
Implement last.
The Project No Longer Needs to Prove It Can Work
That may be the most important change.
In the beginning, we had to prove that Kodex could exist.
That the content could be recovered.
That the new technology stack could work.
That kazztor.net could have a modern foundation again.
That stage is nearly behind us.
Now the questions are different.
How do we want to write over the next several years?
How do we make adding an article trivial?
How do we keep the design consistent without freezing it in place?
How do we ensure that improvements made to one page benefit every other page?
How do we build a project that remains understandable when much of its code has been written with the help of AI agents?
These are much better problems to have than the ones we faced at the beginning.
Because they mean Kodex is no longer just a reconstruction.
It’s beginning to become a system.
Category: Development