Building a Portfolio with Generative AI

The repository is the design system

The site is not a collection of isolated screens. Astro layouts provide the shared
shell. Components handle recurring patterns such as navigation, footers, project cards,
badges, case study gates, and the chat experience. Global CSS holds the visual language,
while page-level styles support the places where a case study needs its own structure.

That organization matters because design decisions become visible in code. Typography,
spacing, color, responsive behavior, accessibility, and content structure are not only
Figma properties. They are rules the repository can repeat.

A screenshot describes one state. A component describes how a pattern behaves across
pages, content lengths, devices, and future changes. That is where design starts to
become a product capability.

Build patterns, not screenshots

A screenshot describes one state. A component describes how a pattern behaves across
pages, content lengths, devices, and future changes. That is where design starts to
become a product capability.

Why Astro fits this kind of work

Most portfolio pages are content-heavy and interaction-light. Astro lets the site ship
mostly static HTML, with JavaScript added only where the experience needs it. That keeps
the default path fast and makes the architecture easy to understand.

The project still supports dynamic pieces where they create real value: the case study
chat, server-side unlock flows, analytics, and integrations. The point is not avoiding
complexity. It is giving every piece a clear reason to exist.

For a designer, this is a useful constraint. You can see which decisions belong to
content, which belong to the interface, and which belong to the runtime. That clarity
makes iteration more deliberate.

Where generative AI helped

GenAI was most useful as a fast design engineering partner. I could describe a change,
inspect the result, test it in the browser, and ask for the next adjustment without
leaving the repository or translating every decision into a separate handoff document.

Early ideas become cheap to prototype. I can compare different content structures,
responsive behaviors, interaction models, or visual treatments before committing to
one. The value is not accepting the first generated answer. The value is making more
alternatives visible.

GenAI can turn a clear design intention into a first component, route, style change,
or data structure. That removes repetitive translation work and gives designers a
working artifact they can evaluate instead of an abstract promise.

When the work happens inside the repository, the tool can work with existing layouts,
naming, routes, content models, and constraints. The output is more useful when it
belongs to the system rather than looking correct in isolation.

Designers do not need to know every part of a stack before they start. Reading the
generated code, questioning it, and testing it creates a practical route into the
implementation. The browser becomes part of the design toolset.

1. Explore more directions

Early ideas become cheap to prototype. I can compare different content structures,
responsive behaviors, interaction models, or visual treatments before committing to
one. The value is not accepting the first generated answer. The value is making more
alternatives visible.

2. Reduce implementation friction

GenAI can turn a clear design intention into a first component, route, style change,
or data structure. That removes repetitive translation work and gives designers a
working artifact they can evaluate instead of an abstract promise.

3. Keep context close

When the work happens inside the repository, the tool can work with existing layouts,
naming, routes, content models, and constraints. The output is more useful when it
belongs to the system rather than looking correct in isolation.

4. Learn by inspecting

Designers do not need to know every part of a stack before they start. Reading the
generated code, questioning it, and testing it creates a practical route into the
implementation. The browser becomes part of the design toolset.

What GenAI does not replace

A model can generate a plausible interface quickly. It cannot decide whether the
problem is worth solving, whether the tone is honest, whether a case study protects
confidential information, or whether a choice supports the person using the product.

It also does not remove the need to understand the codebase. Generated code can be
inconsistent, inaccessible, unnecessarily complex, or wrong for the architecture. The
designer still owns the brief, the constraints, the review, and the consequences.

My useful loop is simple: define the intent, ask for a small change, inspect the diff,
run the site, test the behavior, and refine. GenAI accelerates the loop. It does not
remove the loop.

How this changes the designer's role

The most interesting shift is not that designers can write more code. It is that they
can participate earlier and later in the product cycle. They can explore a constraint
with a real component, understand a technical tradeoff before handoff, and make sure
the shipped experience still expresses the original intent.

Working with routes, data, components, and states makes hidden product rules visible.
That perspective improves the design, even when an engineer owns the final production
implementation.

Instead of debating a screenshot, the team can review a working behavior. Engineers
can focus on architecture and quality. Designers can focus on intent, usability, and
the experience across states.

This is not a case for every designer becoming a full-time engineer. It is a case for
giving designers enough access to implementation that ideas can be tested in the real
environment where users will experience them.

Designers become better system thinkers

Working with routes, data, components, and states makes hidden product rules visible.
That perspective improves the design, even when an engineer owns the final production
implementation.

Collaboration becomes more concrete

Instead of debating a screenshot, the team can review a working behavior. Engineers
can focus on architecture and quality. Designers can focus on intent, usability, and
the experience across states.

The practical advantage

The practical advantage of GenAI is compounding speed with context. A designer can test
more ideas, learn more from the actual system, and keep more design intent alive between
concept and launch. That creates better conditions for judgment instead of trying to
automate judgment away.

This portfolio is an ongoing example. New pages, content, experiments, and product
features can be added to a system I understand and own. The tool makes the work faster.
The quality still comes from choosing what to build, why it matters, and when to stop.