Let’s build ideas! Reach out via the links below.

Building Website with AI

How this GitHub Pages site was built step by step with an AI coding assistant—Jekyll, Minimal Mistakes, design tokens, bilingual content, and practical lessons.

Building this site with an AI agent (step by step)

This site is a GitHub Pages project. Most of the customization, content passes and troubleshooting happened in the editor together with an AI agent (the same kind of workflow you get in Cursor, Copilot Chat, or similar): I described the goal, reviewed proposed diffs, ran the site locally, and steered when something looked wrong. Note: document the progress into separate notebook etc., that will help to remember the tasks.

Below is the path we actually followed—not a generic tutorial, but the sequence that got this repository to a shippable state.

1. Start from a working baseline

Jekyll via github-pages, theme loaded with remote_theme: mmistakes/minimal-mistakes in _config.yml, plus the usual plugin group (jekyll-paginate, jekyll-feed, and friends in the Gemfile).
Synced with GitHub.
Outcome: One clear source of truth: whatever is on main is what visitors see after the Pages workflow runs.

2. Install gems

Installed gems with bundle install and ran bundle exec jekyll serve to catch Liquid errors and broken includes before pushing.
Ruby 3.4 on Windows: the optional wdm watcher gem was dropped from the Gemfile because its native extension often fails on newer Ruby—the site still builds; auto-reload during serve is just a bit slower.
Outcome: A repeatable command (jekyll serve) that validates changes in minutes.

3. Make the site yours in `_config.yml` and data files

Site identity: title, url / baseurl, GitHub username, search toggle, and defaults for layouts (posts, pages).
Author profile: wired through _data/authors.yml so posts can set author: … and pick up bio, avatar, and social links consistently.
Outcome: Shared metadata instead of duplicating author blocks in every file.

4. Layer a custom look without forking the theme

_sass/design-tokens.scss — colors, radii, spacing, and motion variables used across the skin.
SCSS overrides — files such as _sass/default.scss, nav.scss, home.scss, grid_layout.scss, footer.scss, post.scss, and taxonomy.scss adjust layout density, cards, and archive presentation while following the theme’s structure.
assets/css/custom.scss — entry point that pulls overrides together for the build.
_includes/head/custom.html — extra font links (for example Cormorant Garamond, Newsreader, DM Sans) and any head snippets the theme leaves open.
_includes/footer/custom.html — small extensions to the shared footer when needed.

We iterated visually more than once: try a direction, preview in the browser, revert or refine when something felt too heavy or off-brand. The AI was useful for generating coherent SCSS across many files; I still chose what matched the site’s tone.

Custom layouts under _layouts/ (for example home.html, posts.html, category layouts) shape how listings and hero sections behave.
_data/navigation.yml and _data/translations.yml feed the primary nav and language switcher.
_includes/language-switcher.html connects English pages with their Finnish counterparts.
Finnish section lives under fi/ (pages mirrored from the root where it makes sense), and Finnish posts use lang: fi, permalink: /fi/..., and lang_ref back to the English URL.

Outcome: One repo, two languages, with explicit cross-links instead of duplicate sites.

6. Content workflow: posts as small projects

Each post is a Markdown file under _posts/ with front matter (title, tags, categories, header, description, optional highlight_home).
Long-form or spec-style posts (for example the expense tracker write-up) were drafted in passes: outline → sections → tables → tighten wording; the assistant helped keep structure and terminology consistent.
Parallel EN/FI posts share the same factual content; Finnish versions carry translated titles, descriptions, and body copy, plus lang_ref for pairing.

What worked well

Concrete prompts beat vague ones: “match Minimal Mistakes variables,” “do not fork the theme,” “keep fi/ permalinks stable.”
Letting the agent run terminal checks (bundle exec jekyll build, status, diff) caught issues early.
Treating AI output as a proposal: always skim the diff; typography and spacing need a human eye.

What I still do myself

Final editorial voice on posts and bios.
Deciding what not to ship (experiments removed, dependencies dropped).
Privacy and accuracy—anything public-facing is still my responsibility.

If you are building something similar: clone a Minimal Mistakes starter, turn on jekyll serve, keep overrides in _sass + _includes, and use an AI agent as a fast editor and refactor partner—not a substitute for reviewing what goes to main.

Finnish version: Verkkosivuston rakentaminen tekoälyagentilla.