I Redesigned My Website Using Codex

I redesigned this website using Codex.

That sentence sounds more magical than the process actually was. It was not "make me a beautiful personal website" followed by a finished result. It was closer to working with a very fast junior-to-mid engineer who can read the repo, make changes, run checks, take screenshots, and keep iterating as long as the feedback is concrete.

The important part was not that Codex wrote code. The important part was that the design process moved into the same loop as the implementation process.

The Iterations

The first useful question was not about colors, layout, or animation. It was about reading.

I asked Codex to research typography principles from books and printed publishing, then recommend what could apply to this site. That forced the work into a good frame: this is a text-first personal site. Most of the experience is paragraphs, not components.

The recommendation was simple: tune the reading measure, leading, type scale, paragraph rhythm, and contrast before decorating the page. The site already had the right ingredients: Bitter for headings, IBM Plex Sans for body copy, Markdown as the publishing surface, and a lot of whitespace. The problem was that the typography lived in scattered Tailwind classes rather than in a deliberate reading system.

So we designed before implementing. Codex built a standalone HTML prototype with a few directions, and the useful ones were the quieter editorial treatment and the more distinct experiments treatment. That became the first real direction: the public site should be calm and readable, while experiments could feel more separate.

The first implemented version looked good, but it still did not explain itself.

Was it a book? A magazine? A personal website? A digital garden?

That distinction matters. A personal site has to orient the reader quickly. It should answer: whose place is this, what lives here, and what should I look at first?

We tried a few homepage structures: a human front door, a living garden map, recent activity, and combinations of those. The more the page explained itself, the less clear it became. It started to feel like a system the reader had to understand before they could read anything.

The better version was more boring:

1. Hello, I am Alex.
2. Recent writing.

That was it. The site did not need to explain itself as a system before it had enough system to show. It needed to show the writing.

From there, the design work became mostly subtraction. When something competed for attention, we removed it or made it quieter. Duplicate labels, decorative rules, card backgrounds, and borders all looked intentional in isolation, but together they made the page feel more designed than read.

This was the useful loop:

1. Inspect the actual page.
2. Notice the thing that feels off.
3. Make the smallest source change.
4. Run the checks.
5. Reload the browser.

It sounds mundane, but that was the point. Design was not one big decision; it was a series of small removals and corrections. I did not know what I wanted until I saw what I did not want.

The post page was the clearest example. The first hierarchy put title, subtitle, date, reading time, and body content in a layout that made the supporting text compete with the actual post. The fix was not decorative. It was semantic:

1. Title
2. Subtitle
3. Date and reading time
4. Body

Once that order was right, the page needed less visual scaffolding. The hierarchy could come from type, spacing, and source order instead of a bunch of visual furniture.

Markdown Stayed The Source Of Truth

The content model stayed intentionally boring.

Posts and pages are Markdown files under content/. We imported the old Ghost posts from an export, preserved drafts as drafts, and added route guards so non-public posts are not accidentally reachable by slug.

That constraint is important. Once a personal website needs a database, migrations, content models, and a separate backend, the maintenance cost goes up. I wanted the site to remain close to the files.

Links Became Part Of The Reading Surface

The latest iteration came from reading an Every article and liking its citation treatment.

Codex explored a few citation and link-preview variants, then tested the ideas inside a realistic article shell. That was useful because a design can look good as a specimen and fail inside an actual post.

For links, the rule became:

• Inline links stay inline.
• A preview appears only when metadata exists in a local cache.
• Metadata is fetched at edit/build time, not during page render.

That produced content/link-previews.json and a pnpm previews:update script. The renderer stays deterministic, and old or failed links stay normal instead of turning into weak cards.

Again: boring infrastructure, better reading experience.

What Codex Was Good At

Codex was good at keeping the whole surface in view.

It could read the existing code, inspect prior decisions, modify the right files, run checks, and verify the browser output. It also did not get tired of small corrections.

That is probably the most useful part. The work was not one giant prompt. It was a long sequence of small decisions:

• make the homepage less like a publication
• remove this duplicate label
• make the footer stick to the bottom
• align this content to the left
• make the experiment surface feel distinct, not like a dark card on a light page
• make the post hierarchy read correctly
• generate link previews, but do not make every link noisy

Each one is small. Together, they changed the site.

What Still Needed Human Judgment

Codex could propose directions, but I had to say which ones were wrong. It could make a homepage more "digital garden", but I had to notice when that became conceptual overhead. It could add a logo, but I had to say the simpler wordmark felt better.

The taste did not come from the model. The model compressed the distance between taste and implementation.

That is the part I keep thinking about. AI coding tools are often discussed as if the main question is whether they can replace the engineer. That framing misses something more practical: they can make iteration cheap enough that you are willing to try more things.

The site is not finished. It probably should not be. But it is closer to the thing I wanted: quiet, text-first, Markdown-backed, private where it should be private, and flexible enough for experiments.