import { ArticleLayout } from '@/components/ArticleLayout'

export const meta = {
  author: 'Roberto Lázaro Meireles',
  date: '2026-07-22',
  title: 'Shipping My New Homepage with a Team of AI Agents',
  description:
    'My homepage is now a live dither shader poster — and I did not type the code. A build log of directing Claude Code agents through spec, build, design review, and one humbling mid-course correction.',
}

export default function Article(props) {
  return <ArticleLayout meta={meta} {...props} />
}

If you open [meireles.com](https://meireles.com) right now, you get a full-viewport poster: a slow-breathing field of teal dither, a couple of floating shader orbs, and one giant wordmark. No scrolling, no cards, no feed. It replaced a perfectly respectable homepage — hero, photos, six project cards, articles, résumé — that looked like everyone else's perfectly respectable homepage.

Here is the part I actually want to write about: I didn't type the code. Not the shader wiring, not the reduced-motion handling, not the page rewrite. It was built by a small team of AI agents running inside [Claude Code](https://claude.com/claude-code), working from specs we wrote together, reviewed by another agent whose only job is design taste, and course-corrected by me — once, significantly — when the first shipped version turned out to be the wrong idea.

This is the build log.

## The setup

My site's repo is wired for what I think of as orchestrated development. A `CLAUDE.md` file at the root sets the ground rules, and the important ones are about division of labor:

- The **orchestrator** — the main session I talk to — plans, dispatches, and reviews. It does not write feature code.
- **Implementor agents** execute. Well-scoped, mechanical work goes to a cheaper, faster model; architecture-sensitive work (bundler config, the CMS pipeline, subtle bugs) goes to a heavier one.
- A **design-reviewer agent** runs after any UI change. It checks hierarchy, spacing, responsiveness, and — because this bites everyone — both light and dark mode, every time.
- There's no test suite on a site like this, so a **verify skill** encodes what "checked" means: boot the dev server, walk the pages, test dark mode, keyboard navigation, reduced motion.

None of this is exotic. It's a text file, some agent definitions, and discipline. The interesting part is what the discipline produces.

## Spec first, always

The poster didn't start as code. It started as an argument — a brainstorming session where the orchestrator asked me one question at a time. What dies from the old homepage? (Everything except the wordmark and nav.) What personality should the shader have? (A layered dither world, cohesive with the ambient accents already on my /ai page.) How interactive? (Reactive touches only; the pointer-tracking playground stays deferred.)

The output was a design spec, committed to the repo before any implementation:

> Replace the content-heavy homepage (hero + photo strip + 6 project cards + articles + resume) with a designer-first shader "poster": a full-viewport dither hero built around the `meireles.` wordmark... First step toward a future experiential space.

Specs in git turn out to matter more with agents than with humans. An agent will cheerfully build the wrong thing with total confidence; a committed spec is the thing you diff its enthusiasm against.

## Dispatch

From the spec came an implementation plan, and from the plan, dispatches. The commit trail reads like a relay race:

```text
3bf08ce Add design spec for homepage dither poster redesign
e46e3a2 Add implementation plan for homepage dither poster
a7696b5 Add HomeHero full-viewport dither poster component
36354ef Add Trailheads reactive link rows
b3e183b Rewrite homepage as dither poster with trailheads
```

The shader itself comes from [`@paper-design/shaders-react`](https://www.npmjs.com/package/@paper-design/shaders-react), a genuinely lovely library of WebGL shaders as React components — browse the live gallery at [shaders.paper.design](https://shaders.paper.design). The implementor's job was integration judgment: the canvas must never render on the server, and it must respect people who ask for less motion.

```tsx
const Dithering = dynamic(
  () => import('@paper-design/shaders-react').then((mod) => mod.Dithering),
  { ssr: false },
)

// inside HomeHero — one full-bleed canvas behind the wordmark
<Dithering
  colorBack="rgba(0, 0, 0, 0)"
  colorFront="rgba(20, 184, 166, 0.5)"
  shape="warp"
  type="8x8"
  size={2.5}
  speed={reducedMotion ? 0 : 0.1}
  style={{ width: '100%', height: '100%' }}
/>
```

`reducedMotion` tracks `prefers-reduced-motion` via a media-query listener, so the poster renders as a still image for anyone who wants it still. The spec also set a hard canvas budget — the page runs at most a handful of small, slow shader canvases on desktop and exactly one on mobile — because "it's pretty" is not a performance strategy.

Notice what the implementors *don't* do: they don't run lint, typecheck, or git. The orchestrator runs the gates once per batch. Agents are enthusiastic; the process is the adult in the room.

## The review gate

After the build, the design-reviewer agent did its pass — and earned its keep. Its notes from this cycle: the floating depth orbs were being swallowed by the legibility scrim (they moved above it and got nudged outward), the hover chips on the link rows read better resting at full invisibility, and the focus rings needed to be solid teal with an offset instead of the subtle default. Small things. Small things are most of what design is.

## The part where I was wrong

Then I looked at the shipped page in a real browser, and the direction was off. The first version was a poster *plus a page* — you could scroll past the shader to a band of "trailhead" links. It diluted the whole gesture. A poster you can scroll past is just a tall hero.

So: revision. The spec got a formal amendment — the commit is literally titled `Spec revision 1: no-scroll poster, floating header, Trailheads to /about` — and the agents executed it: the hero became exactly `100svh` with nothing below, the site header now floats over the shader with its wordmark hidden (the giant one *is* the logo there), and the trailhead links moved to the bottom of /about, where they self-filter so the About page doesn't link to itself. The scroll-reactivity code, now dead on a page that can't scroll, was deleted rather than left as a souvenir.

This is the honest core of the workflow. The agents didn't catch that the concept was wrong — they can't, really; the first version matched the spec I approved. What they did do was make the correction *cheap*. Re-specifying and re-shipping the new direction took an evening, not a week, and the paper trail (spec → revision → synced docs) means the repo remembers why.

## What this is and isn't

After a few cycles of working this way, my honest scorecard:

**It's good at:** volume without drift (specs keep parallel work coherent); the review gate catching the polish I'd rationalize skipping; leaving a paper trail my future self can actually follow; making wrong turns cheap to unwind.

**It isn't:** taste. Every judgment call in this story — what the homepage should *feel* like, that the first version was wrong, where the line sits between playful and gimmicky — was human. The agents amplified the decisions; they didn't make them.

The poster is phase one. The spec's own words — "first step toward a future experiential space" — are a promise I intend to keep: pointer-tracking, little toys, a homepage that notices you're there. When that ships, it'll get the same treatment: brainstorm, spec, dispatch, review, and at least one revision where I discover what I actually meant.

That last part I can promise.


My homepage is now a live dither shader poster — and I did not type the code. A build log of directing Claude Code agents through spec, build, design review, and one humbling mid-course correction.

Shipping My New Homepage with a Team of AI Agents

I’m a left-handed designer working in a world—and using tools—built for the right-handed majority. This isn’t just ergonomic trivia. It subtly changes how I sketch, where I place elements, how I read movement in a layout, and the workflows I choose. In this piece, I explore how handedness might influence design decisions, how bias sneaks in through tools and interfaces, and how to turn that “lefty friction” into a creative edge.

Handedness can nudge how we compose, sequence, and interact with tools.

Left-handed designers often develop mirrored instincts (e.g., left-to-right vs right-to-left movement cues).

The industry’s right-hand standard introduces ergonomic bias—but that constraint can spark original solutions.

Awareness beats myth: handedness isn’t destiny, but it’s a lens. Use it to design more inclusively.

I’m Roberto Meireles. I build brands, systems, and visuals under tight timelines and high expectations. I’m also left-handed. For years, I’ve noticed small frictions nobody talks about: smudged pencil lines as I pull across the page, hotkeys that live on the wrong side of a keyboard, stylus buttons placed where my thumb never lands naturally. These micro-irritations don’t stop me. They shape me. And—quietly—they shape the work.

Does being left-handed influence design outcomes?

 Not in a “lefties are more creative” cliché. More like this: handedness changes how we physically approach composition, which affects our first instincts and default flows—especially in early, fast, analog stages. Those first moves often anchor the final.

A Quick Primer on Handedness & Perception (No Myths, Just Useful Bits)

 Left hand pushes from right to left. Right hand pulls from left to right. On paper or tablet, that means different smudge patterns, stroke angles, and natural arcs.

 In left-to-right cultures, “forward” often reads as moving rightward. As a lefty, I sometimes feel “acceleration” pulling the other way. That tug can change how I stage hero images, arrows, or progress visuals.

 Most hardware, UI defaults, and shortcut maps assume right-hand use. If I remap or rotate, my workflow literally reorients. Over time, those micro-adjustments become style.

None of this means left-handed designers 

 design a certain way. It means we experience different 

I often enter a canvas from the right and sweep left. When I sketch, my first marks favor diagonal strokes that feel natural to my wrist. This can produce:

 (a reverse “read”) that still feel balanced

In interfaces and brand systems, “progress” is often aligned left→right. I don’t reject that convention—but I question it. You’ll see me:

Flip storyboards to test if a sequence still communicates when mirrored

Right-dominant hotkeys make left-handed use slower or awkward. I remap. Over time this builds:

, which change eye travel and decision cadence

Pencil first? I rotate pages often. My notes ladder down the right edge. On iPad, I tend to park palettes on the right to keep my drawing hand clear. These habits:

The Right-Handed Bias in Our Tools (And Why That’s Useful)

 From mouse mold to stylus buttons, the “natural” configuration is rarely neutral.

 Panels default left. Shortcuts cluster under the left side of the keyboard, built for right-hand mouse use.

 Educators teach “top-left entry” as “correct.” It’s a convention—not a law of physics.

 Constraints drive invention. Lefties hack. When I remap a workspace, I’m not just making it comfortable—I’m forcing myself to see composition differently. That friction can generate signature moves: unexpected visual weight, fresh pacing, nonstandard narrative flow.

What the Science Probably Won’t Solve for You

Studies on handedness, creativity, and lateralization are mixed. You’ll find papers that hint at differences in spatial reasoning or divergent thinking and others that say “not so fast.” I treat the science as context, not verdict. The most practical truth is simple: 

. The way you hold a pen, the travel of your wrist, the side you park your panels—these shape your defaults. Know them. Use them.

Practical Ways I Channel the Lefty Factor


I flip key layouts horizontally. If the story breaks when mirrored, my direction cues were too one-way.


Grids that tolerate left→right and right→left scan. Arrows with meaning that isn’t tied to culture alone.


Left-handed mouse, stylus remap, panel docking to the right. Comfort equals speed; speed frees cognition.


Custom brushes that respect my wrist angle and pressure curve. Consistency reduces cleanup and keeps the “lefty line” intentional.


I’ll ask a right-handed teammate to test a prototype cold. If their instincts fight the flow, I refine affordances.


I duplicate key clusters on both sides. No matter where my stylus rests, the next action is one beat away.

Handedness is one axis of inclusivity we rarely discuss. If tools, signage, and product flows privilege a single motor approach, we lose speed, comfort, and sometimes clarity for everyone else. Designing for ambidexterity nudges products toward universality: adaptable panels, mirrored gestures, symmetric entry points, flexible motion cues.

Your “weird” habits are data. Keep what improves flow.

Build mirrored templates and test both ways.

Remap without apology. Your setup is part of your craft.

When a convention doesn’t serve the story, break it with intent.

For Right-Handed Teams, Leads, and Clients

Avoid declaring left-to-right flow “correct.” Say “conventional.”

When directionality is key (onboarding, checkout), test both orientations with users.

Left-handed or right-handed, we design with our bodies first—then our tools, then our minds. Handedness won’t determine your taste. It will whisper suggestions about where to start, how to move, and what “feels natural.” Hear it. Then decide on purpose.

Left-Handed Design in a Right-Handed Industry

Designing Against the Grain: My Left-Hand Lens

Mirrors, Margins, and Movement: How Handedness Nudges Design

 /left-handed-designer-right-handed-world

 Left-Handed in a Right-Handed World: How Handedness Nudges Design

 Roberto Meireles on how being left-handed subtly shapes composition, motion, and tools—and how to turn that friction into an inclusive design advantage.

 left-handed designer, handedness and design, design ergonomics, directional bias, inclusive design, UI directionality

“Your body is part of your design system.”

“Conventions aren’t physics—they’re habits.”

“Constraints don’t limit taste. They reveal it.”

 A mirrored grid where the “primary” focal block sits on the right, annotated with motion arrows both ways.

 “editorial photo of a design sketchbook with mirrored grid layouts, focal block on right, directional arrows both left and right, clean studio desk, overhead shot, soft daylight —ar 16:9 —v 7”

 Stylus-in-hand close-up from a left-hander’s POV; UI panels docked on the right.

 “close-up photo, left hand holding digital stylus, design app panels docked on right side, minimal workstation, depth of field, natural light —ar 16:9 —v 7”

 Side-by-side mirrored UI screens demonstrating equal clarity in both orientations.

 “two mirrored interface mockups side by side, neutral color palette, clear hierarchy, arrows indicating bi-directional flow, minimal background —ar 16:9 —v 7”

 showing conventional left→right acceleration vs. mirrored right→left acceleration, with notes on where to place CTAs, imagery weight, and scan anchors.

If you’re building a product, brand, or design system and want it to work beautifully from either side of the canvas, let’s talk. I’ll bring the left-hand lens—and the rigor to prove it out both ways.

Being left-handed doesn’t decide my taste, but it does set my defaults—and defaults have gravity. By mirror-testing layouts and remapping tools, I turn that bias into clearer, bi-directional design.

Left-Handed in a Right-Handed World: Does It Shape My Design?

The Model Context Protocol (MCP) is revolutionizing how AI agents interact with content management systems like Sanity. By providing a structured and efficient way to manage content, MCP enables seamless integration and interaction.

: MCP allows AI agents to understand and manipulate content in a more human-like manner.

: Easily scale your content operations with automated processes.

: Adapt to various content structures without extensive reconfiguration.

: Begin by installing the MCP SDK in your project.

: Ensure your Sanity project is set up to interact with MCP.

: Use the MCP API to connect your AI agents with Sanity.

: Automate the creation of blog posts, articles, and more.

: Use AI to review and approve content before publication.

: Tailor content to individual user preferences using AI insights.

This is the introductory text for the post. It contains important information about the topic.

This is the concluding section of the post.

Explore how the Model Context Protocol (MCP) empowers AI agents to seamlessly interact with Sanity's content management system.

Testing MCP Integration with Sanity

During the development of Provalit, my property assessment application, I made a decision that significantly improved development efficiency and UI consistency: creating a dedicated style guide page. This simple addition has proven to be invaluable, and I wanted to share why you might consider adding one to your own projects.

For those unfamiliar, a style guide page is essentially a visual inventory of all your UI components, design patterns, and styling rules in one place. In Provalit, I created a 

 route that's accessible in development environments, displaying every component with different states and variations.

Before the style guide page, testing a component meant navigating to a specific part of the app where that component was used. Now, I can:

See all variations of a component in one view

Make changes and immediately see how they affect different states

Test edge cases without having to recreate specific app scenarios

This has cut down development time dramatically when working on UI adjustments.

It's easy for inconsistencies to creep in when components are scattered across dozens of files. The style guide provides:

A single source of truth for how components should look

Immediate visual feedback when styles drift

A reference point for new team members to understand design standards

In Provalit, this has helped maintain the cohesive, polished look that users appreciate.

Having a style guide page has transformed our designer-developer workflow:

Designers can reference specific components by navigating to the style guide

We discuss changes while looking at the complete component set

Design iterations are faster since we're working from a shared visual reference

Unlike static documentation that quickly becomes outdated:

The style guide shows the actual rendered components

It updates automatically as the components evolve

New developers can see working examples rather than just reading about them

The implementation was surprisingly straightforward:

Organized sections for different component types (buttons, cards, forms, etc.)

Added examples of each component with different props and states

Included simple code snippets showing how to use each component

Here's a simplified example of how the button section looks:

<section>
  <h2>Buttons</h2>
  
  <div className="space-y-4">
    <div>
      <h3>Variants</h3>
      <div className="flex flex-wrap gap-4">
        <Button>Default</Button>
        <Button variant="secondary">Secondary</Button>
        <Button variant="destructive">Destructive</Button>
        <Button variant="outline">Outline</Button>
        <Button variant="ghost">Ghost</Button>
        <Button variant="link">Link</Button>
      </div>
    </div>
    
    <div>
      <h3>Sizes</h3>
      <div className="flex flex-wrap items-center gap-4">
        <Button size="sm">Small</Button>
        <Button>Default</Button>
        <Button size="lg">Large</Button>
      </div>
    </div>
    
    <div>
      <h3>States</h3>
      <div className="flex flex-wrap gap-4">
        <Button>Default</Button>
        <Button disabled>Disabled</Button>
        <Button isLoading>Loading</Button>
      </div>
    </div>
  </div>
</section>


You don't need to build a comprehensive style guide all at once. In Provalit, I started with just basic buttons, cards, and form elements. Over time, it grew to include:

An unexpected benefit: the style guide has become useful in client presentations. It showcases the attention to detail and design quality in the application, which has been a nice bonus.

If you're working on a web application, I strongly recommend setting aside a day to create even a basic style guide page. The time investment pays off quickly in development efficiency and design quality.

Have you implemented a style guide in your projects? I'd love to hear about your experiences or any tips you might have!

Check out the full Provalit project at github.com/sphereboy/provalit-app-2

During the development of Provalit, my property assessment application, I made a decision that significantly improved development efficiency and UI consistency: creating a dedicated style guide page. 

Why Every Web App Needs a Style Guide Page: Lessons from Provalit

Hey everyone! Just wanted to share a quick update on Provalit, my property assessment app. I recently integrated Google's Gemini Pro 2.5 model, and I'm genuinely impressed with the results.

After seeing the capabilities of Gemini Pro 2.5, I decided to upgrade our spatial analysis feature from the previous model. The integration was surprisingly straightforward:

Updated our API endpoints to use the new Gemini Pro 2.5 model

Refined our prompting to take advantage of the improved spatial reasoning

Added a new comparison feature to highlight the differences between model versions

The improvement is substantial. Gemini Pro 2.5 is delivering much more detailed and accurate spatial relationship analysis for property photos:

: The model now correctly identifies subtle positioning (e.g., "partially behind," "adjacent to but not touching") that the previous version missed

: It recognizes functional relationships between objects in a room, not just their physical arrangement

: Even in crowded rooms with many objects, the analysis remains coherent and accurate

In one test case with a complex living room photo containing 15+ objects, the previous model produced this type of output:

"There is a sofa. There is a coffee table in front of the sofa. There is a TV."

"The gray sectional sofa dominates the west wall, with a rectangular glass coffee table positioned centrally in front of it. A flat-screen TV is mounted on the opposite wall, aligned with the sofa for optimal viewing. Between the sofa and TV, two accent chairs create a conversational area, with the beige chair at approximately 45° to the north edge of the coffee table and the blue chair positioned symmetrically across."

The level of detail and spatial precision is remarkable, providing much more useful information for property assessment reports.

Given these promising results, I'm planning to expand the Gemini Pro 2.5 integration across more features in Provalit:

Comparative analysis between similar properties

If you're working on projects involving spatial understanding or detailed image analysis, I highly recommend giving Gemini Pro 2.5 a try. The improvement over previous models is substantial enough to justify the upgrade.

Have you tried Gemini Pro 2.5 in your projects? I'd love to hear about your experiences in the comments!

Find out more about Provalit at github.com/sphereboy/provalit-app-2

Enhancing Provalit with Gemini Pro 2.5: Impressive Results in Spatial Analysis

Welcome to the fifth installment of our Sqrdo development journey! After exploring the technical foundations, authentication system, demo mode implementation, and performance optimizations, today I want to share my vision for the future of Sqrdo. As we prepare for the upcoming 0.5.0 release, it's the perfect time to reflect on where we've been and where we're headed.

Before diving into future plans, let's recap where Sqrdo stands today with the recent 0.4.0 release:

: Interactive analytics showing revenue trends, order statistics, and key performance indicators

: Comprehensive customer listing and details with filtering capabilities

: Complete order history with status tracking and filtering

: Product listing with performance metrics and inventory status

: Secure login process with Supabase integration

: Ability to try the application with realistic sample data

: Direct connection to store data with proper credentials

: Fully functional on desktop, tablet, and mobile devices

: Adaptable interface that respects user preferences

This foundation provides a solid platform for Squarespace store owners to visualize and manage their commerce data. However, there's still tremendous potential for growth and enhancement.

Let's explore the exciting new features and improvements planned for the coming releases:

One of the most requested features is more sophisticated analytics. Future versions will include:

: More flexible time period selection beyond the current presets

: Compare performance across different time periods

: Download reports in PDF, CSV, and Excel formats

: Create personalized views with the metrics that matter most

: Schedule regular reports to be delivered via email

Beyond user-facing features, I'm planning significant technical improvements:

The application architecture will continue to evolve:

: Breaking down the monolithic application into smaller, specialized services

: Leveraging edge functions for faster global performance

: Comprehensive unit, integration, and end-to-end tests

: Visual regression testing for UI components

: Automated performance testing in CI pipeline

: Ensuring stability under high traffic conditions

: Systematic review of codebase and dependencies

: Enhanced data protection and privacy controls

: Identifying suspicious activities and potential security risks

Building a vibrant community around Sqrdo is an important goal:

: Documented API for external integrations

: Framework for third-party developers to extend functionality

: API for integrating custom data sources

Supporting users through comprehensive resources:

: Step-by-step walkthroughs of key workflows

: Real-world examples of how businesses use Sqrdo

: Place for users to share ideas and solutions

To ensure Sqrdo's long-term sustainability, I'm planning a fair and transparent pricing model:

: Basic analytics and single-store support

: Advanced analytics, multi-store support, API access

Welcome to the fifth installment of our Sqrdo development journey! 

The Road Ahead: Future Plans for Sqrdo

Welcome to the fourth installment of our Sqrdo development journey! In this post, I'll be discussing one of the most critical aspects of any modern web application: 

. As Sqrdo has evolved, I've continually refined its architecture and code to create a fast, responsive experience for users.

When building a data-heavy application like Sqrdo, performance isn't just a nice-to-have—it's essential. Users need quick access to their commerce data to make informed business decisions. Slow loading times or laggy interfaces can lead to frustration and, ultimately, abandonment of the platform.

My performance optimization journey for Sqrdo has focused on several key areas:

1. Optimizing API Requests and Data Fetching

One of the earliest performance challenges was efficiently fetching data from the Squarespace API. Initial implementations had several issues:

I implemented several improvements to streamline the data fetching process:

 state in the Dashboard component to prevent multiple fetches and improve loading state management:

I refactored the Squarespace API handler by removing unnecessary cookie store initialization and directly using the cookies function in createRouteHandlerClient:

React's rendering behavior sometimes led to unnecessary re-renders, especially in data-heavy components like charts and tables. This was particularly noticeable when:

I implemented several techniques to optimize rendering:

For expensive components, I used React.memo and careful dependency management:

For long lists of customers or orders, I implemented virtualization to only render what's visible:

I implemented React Suspense throughout the application to improve the loading experience:

As the application grew, the bundle size increased, affecting initial load times. Additionally, ESLint and TypeScript checks during builds sometimes slowed down the development workflow.

I made several configuration changes to optimize the build process:

Added ESLint and TypeScript build error handling in next.config.ts, allowing for skips based on environment variables:

Introduced a new build script in package.json for building without linting:

Added image optimization configurations to improve loading performance:

4. Progressive Web App (PWA) Enhancements

Users needed access to their dashboard from various devices, including mobile, and expected a native-like experience.

I implemented PWA features to enhance the user experience across devices:

Added app icons and a web manifest for improved PWA support:

Welcome to the fourth installment of our Sqrdo development journey! In this post, I'll be discussing one of the most critical aspects of any modern web application: performance optimization. 

Writing on software design, company building, and the aerospace industry.

Shipping My New Homepage with a Team of AI Agents

Left-Handed in a Right-Handed World: Does It Shape My Design?

Testing MCP Integration with Sanity

Why Every Web App Needs a Style Guide Page: Lessons from Provalit

Enhancing Provalit with Gemini Pro 2.5: Impressive Results in Spatial Analysis

The Road Ahead: Future Plans for Sqrdo

Performance Optimization: Making Sqrdo Fast and Responsive

Authentication and User Experience: Building Trust from the Start

Building the Demo Mode: Making Data Accessible in Sqrdo

Introducing Sqrdo: A Modern Squarespace Commerce Dashboard

Hello World!