Building this portfolio with generative AI
I did not use generative AI to skip the design work. I used it to reduce the distance between an idea and a working version. This portfolio is built with Astro, plain CSS, reusable components, static pages, server-side features, and a lot of iteration. GenAI helped me move through that system faster while keeping the important decisions mine.
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.
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.
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.
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.
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.
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.
