Illustration of vibe coding

Building This Website Together with an LLM

2025-09-09

Introduction

I had wanted to build a personal introduction site for a while, but I never had enough time to start. Recently, vibe coding, where you drive tools such as Claude Code and Codex through conversation, has become a popular topic. When I finally had some time, I built this site that way.

Process

Here is what I did:

  • Define requirements
  • Ask Codex to implement them
  • Give feedback on the generated code several times
  • Write the self-introduction text myself, then ask AI to polish it

Requirements Definition

I use ChatGPT Plus, so I started from there. I gave GPT a bullet list of routing ideas and the technical stack, then asked it to turn them into requirements.

Prompt
I want to create my own web page.
Please help me think through the requirements.
I do not need implementation yet. Please create a requirements document that I can give to Codex.

## Routing idea
- Structure
    - /
        - Self-introduction and routing overview
        - /links
            - External URLs
        - /articls
            - Articles, papers, and similar items
        - /blogs
            - Articles rendered from Markdown

## Implementation requirements
- Use TypeScript and Next.js for a modern React-based UI/UX.
- Use GitHub Pages to build the static site automatically and keep operating cost down.
- I do not want to touch code every time I update the blog, so writing Markdown should be enough to build automatically.
- Pages other than the ones generated from Markdown, such as the home page, should support both Japanese and English.
- The route name "articles" may not be ideal, because I will write about papers I have authored and technical blog posts on external sites.

Requirements Output
# Overview

Requirements definition for a personal website. A modern UI/UX built with TypeScript + Next.js. It is built and hosted automatically on GitHub Pages, and the site is regenerated whenever Markdown is updated.

---

## 1. Purpose / Deliverables

* **Purpose**: build a static site that brings the self-introduction, the external link collection, the article/paper listing, and blog operation together in one place and keeps the update cost minimal.
* **Deliverables**: a repository that follows these requirements, the design and component set, CI/CD (GitHub Actions), content templates, and a full set of documentation.

---

## 2. Information Architecture / Routing

### 2.1 Route structure (proposal)

* `/`

  * Self-introduction (supports JP/EN switching)
  * Entry points into the main sections
* `/links`

  * List of external URLs (social accounts, GitHub, talk slides, and so on)
* `/publications` (name under review, see §2.2 for details)

  * Collected metadata for authored papers, technical blog posts on external sites, and similar work (card list + detail)
* `/blogs`

  * List of blog articles generated from Markdown + detail

> ※ `/articls` → fix the typo. `/articles` is too generic, so consider the naming options below.

### 2.2 Alternatives to the "articles" name

* **/publications**: broadly covers "published work" such as peer-reviewed papers, contributed posts, and external technical blogs (recommended)
* **/writings**: written work in general (a little vague)
* **/notes**: notes and observations (suited to lighter content)
* **/library**: a collection-like framing (a little abstract)

**Selection criterion**: if the targets are "own papers + contributions to external sites + explanatory articles", make `/publications` the first choice.

### 2.3 Global navigation

* Home | Links | Publications | Blogs
* Footer: copyright, license, sitemap, RSS (for the blog)

---

## 3. Non-functional Requirements

* Fast rendering (Core Web Vitals targets: LCP < 2.5s, CLS < 0.1, INP < 200ms)
* Accessibility (targeting WCAG 2.1 AA conformance)
* SEO (OGP/Twitter Card/structured data, sitemap.xml/robots.txt)
* Responsive (mobile first)
* Easy operation (updating Markdown is all it takes, with automatic deployment from CI)

---

## 4. Implementation Stack / Policy

* **Language/framework**: TypeScript, Next.js (App Router)

  * `output: 'export'` in `next.config.js` (static export)
* **Styling**: Tailwind CSS + in-house UI components (light/dark themes)
* **Markdown processing**: use `.md` (remark/rehype based, extensible to MDX if needed)
* **Highlighting**: Shiki or rehype-prism-plus
* **Image optimization**: statically generated images (watch how `next/image` behaves on export)
* **Icons**: lucide-react recommended
* **State management**: minimal (essentially static, no more than search/filter)

---

## 5. Internationalization (i18n)

* **Scope**: static UI such as the top page, excluding Markdown-generated pages, must be switchable between **Japanese and English**.
* **Approach**: adopt `next-intl` or `next-i18next`. Manage dictionaries under `/locales/ja|en/*.json`.
* **Language switch UI**: a toggle in the header (ja/en). Keep the language in a cookie or a URL prefix (/ja, /en).
* **Default language**: Japanese (ja).

---

## 6. Content Design

### 6.1 Directory structure (example)

/content
  /blogs
    yyyy-mm-dd-slug.md
  /publications
    item-*.md
/data
  links.yaml
/public
  /images

### 6.2 Frontmatter definitions

* **Blog (/blogs)**

  * `title` (string, required)
  * `date` (ISO string, required)
  * `updated` (ISO string, optional)
  * `tags` (string\[])
  * `summary` (string)
  * `thumbnail` (path)
  * `draft` (boolean)
* **Published work (/publications)**

  * `title` (string, required)
  * `type` (enum: paper | article | talk | slide | media)
  * `publishedAt` (ISO string)
  * `venue` (string) / `publisher` (string)
  * `authors` (string\[])
  * `links` ({ kind: 'pdf'|'doi'|'post'|'slides'|'video'|'code', url: string }\[])
  * `tags` (string\[])
  * `abstract` (string, optional)

### 6.3 Links page data

* Define `{ title, url, desc, icon? }[]` in `/data/links.yaml`. Categories are allowed.

### 6.4 List/detail UI

* Shared card layout, tags/search (client side)
* Pagination (blog)
* Drafts are excluded from the build (previewable only on PRs in CI)

---

## 7. Build / Deploy (GitHub Pages)

* **Repository**: `<user>/<user>.github.io`, or any repository plus a `gh-pages` branch
* **CI/CD**: GitHub Actions workflow

  1. Runs on `push` to `main`
  2. `bun install` / `bun build` (`next build && next export`)
  3. Deploy `out/` to Pages
* **Custom domain** (optional): configure `CNAME`
* **Routing note**: generate `404.html`/`index.html` correctly for the static export

---

## 8. Developer Experience (DX)

* Package manager: `bun`
* Lint/Format: ESLint + Prettier + stylelint (as needed)
* Type safety: strict mode, frontmatter validation with `zod`
* Tests: basic snapshots (Vitest + Testing Library)
* Commit convention: Conventional Commits + Changeset (optional)

---

## 9. Per-page Requirements

### 9.1 `/` (top page, i18n target)

* Self-introduction (title, short bio, photo)
* Highlights of the latest blog posts and published work
* Language switch, theme switch

### 9.2 `/links`

* Link cards grouped by category (with icons and descriptions)

### 9.3 `/publications` (equivalent to the former `articles`)

* List: filters (type, year, tag) and search
* Detail: metadata + external links (DOI, PDF, and so on)

### 9.4 `/blogs`

* List: newest first, tags/search, pagination
* Detail: table of contents (auto-generated), footnotes, code blocks, OGP generation

---

## 10. Security/Privacy

* Load external embeds only after consent (YouTube and similar)
* CSP header (meta-based where possible)

---

## 11. Acceptance Criteria (excerpt)

* Adding an article .md on GitHub → merging into `main` builds and deploys automatically, and it goes live within a few minutes
* `/` can switch between ja/en, and `/blogs` articles can be published from Markdown alone
* Filtering and search on `/publications` work on the client
* The LCP/CLS/INP targets are met in lab tests
* Basic accessibility checks (keyboard operation, contrast, labels) pass

---

## 12. Implementation Notes (specifics for Codex)

* **Markdown processing idea**: parse with `gray-matter` + `remark/rehype`, together with `zod` for type safety
* **OGP**: statically generate dynamic images at `/blogs/[slug]/opengraph-image` (Satori + html-to-image)
* **Search**: simple full-text search with `Fuse.js` on the client
* **Theme**: dark mode with `next-themes`

---

## 13. Future Extensions (optional)

* Automatic feed generation (RSS/Atom)
* Automatic updates for the feed and sitemap
* Comments (external: Giscus and similar)
* Contact form (integration with an external form)

---

## 14. Undecided Items / Open Questions

* Final decision on the formal name of `/publications`
* Design direction for the top page (minimal, bold, photo-heavy, and so on)
* Policy for generating eyecatch images (manual or automatic)
* Wording for the English top page (how to express any differences from the Japanese)

---

## Appendix: Sample `links.yaml`

```yaml
- title: GitHub
  url: https://github.com/yourname
  desc: Source code and projects
  icon: github
- title: X (Twitter)
  url: https://x.com/yourname
  desc: Day-to-day updates
  icon: x

Asking Codex

I set up Codex using the article below as a reference. Then I gave it the requirements above and moved forward with development.

Zenn
Codex CLIを使いこなすための機能・設定まとめ
zenn.dev/dely_jp/articles/codex-cli-matome

Feedback on the Generated Site

I ran the site, pointed out anything that felt off in a few words, and let Codex fix it. I repeated that a few times.

Impressions

I barely implemented anything myself, yet a practical site came together in a short time. I kept Reasoning Effort at high in ChatGPT Plus and never hit a rate limit.

Development with a coding agent works well enough with only minimal hands-on experience. There was not much stress, either.

Related Posts

Related Posts

Comments