How to Build the Best Website with AI — A Complete Guide

Make a navbar

Create a responsive navigation component in Next.js App Router using TypeScript.
It should have:
- A logo on the left linking to /
- Links to /blog, /projects, /about on the right
- A mobile hamburger menu that slides in from the right
- Use Tailwind CSS for styling
- Follow the existing component patterns in app/components/

Review the code you just generated for:
- Code smells and anti-patterns
- Unused variables or imports
- Missing error handling
- Accessibility issues
- Performance concerns
- Any hardcoded values that should be constants or env vars
- Violations of DRY principle

Be brutally honest. Pretend you're a senior engineer who's annoyed
about code quality.

Build an image gallery component that is fully WCAG 2.1 AA compliant.
Requirements:
- All images must have descriptive alt text
- Gallery must be keyboard navigable (arrow keys)
- Focus indicators must be visible
- Use semantic HTML (not divs for everything)
- Include appropriate ARIA labels
- Ensure 4.5:1 color contrast ratio for all text
- Support reduced-motion preferences

<div class="nav">
  <div class="nav-item" onclick="navigate('/home')">Home</div>
  <div class="nav-item" onclick="navigate('/about')">About</div>
  <div class="nav-item" onclick="navigate('/contact')">Contact</div>
</div>

<nav aria-label="Main navigation">
  <ul role="list">
    <li>
      <a href="/home" aria-current="page">Home</a>
    </li>
    <li>
      <a href="/about">About</a>
    </li>
    <li>
      <a href="/contact">Contact</a>
    </li>
  </ul>
</nav>

Audit this component for WCAG 2.1 AA compliance:
- Are all interactive elements keyboard accessible?
- Do all images have meaningful alt text?
- Is the heading hierarchy logical (h1 > h2 > h3)?
- Are form inputs properly labeled?
- Do color combinations meet 4.5:1 contrast ratio?
- Are focus states visible and clear?
- Does it work with prefers-reduced-motion?
- Are ARIA roles and properties used correctly?

Generate a Next.js page with complete SEO setup including:
- Dynamic meta title and description
- Open Graph tags (og:title, og:description, og:image, og:type)
- Twitter card meta tags
- JSON-LD structured data for Article schema
- Canonical URL
- Proper heading hierarchy (single h1)
- Semantic HTML structure

// Ask AI: "Generate JSON-LD structured data for a blog post page"
export default function BlogPost({ post }) {
  const jsonLd = {
    '@context': 'https://schema.org',
    '@type': 'Article',
    headline: post.title,
    description: post.summary,
    author: {
      '@type': 'Person',
      name: 'Your Name',
      url: 'https://yoursite.com',
    },
    datePublished: post.publishedAt,
    dateModified: post.updatedAt || post.publishedAt,
    image: post.ogImage,
    publisher: {
      '@type': 'Organization',
      name: 'Your Site',
      logo: {
        '@type': 'ImageObject',
        url: 'https://yoursite.com/logo.png',
      },
    },
  };

  return (
    <>
      <script
        type="application/ld+json"
        dangerouslySetInnerHTML={{ __html: JSON.stringify(jsonLd) }}
      />
      <article>{/* content */}</article>
    </>
  );
}

// app/sitemap.ts
export default async function sitemap() {
  const posts = getBlogPosts();

  const blogEntries = posts.map((post) => ({
    url: `https://yoursite.com/blog/${post.slug}`,
    lastModified: new Date(post.metadata.publishedAt),
    changeFrequency: 'monthly' as const,
    priority: 0.8,
  }));

  return [
    { url: 'https://yoursite.com', priority: 1.0 },
    { url: 'https://yoursite.com/blog', priority: 0.9 },
    ...blogEntries,
  ];
}

Refactor this code following these principles:
- DRY: Extract duplicated logic into shared functions
- Single Responsibility: Each function does one thing
- Descriptive naming: Variables and functions describe their purpose
- No magic numbers: Extract constants
- TypeScript strict mode: No 'any' types, proper interfaces
- Small functions: Nothing over 30 lines
- Early returns: Avoid deep nesting

// AI sometimes generates unnecessary abstractions
const ButtonFactory = createFactory({
  variants: {
    primary: createVariant({ base: 'bg-blue-500', hover: 'bg-blue-600' }),
    secondary: createVariant({ base: 'bg-gray-500', hover: 'bg-gray-600' }),
  },
  sizes: createSizeMap({ sm: 'px-2 py-1', md: 'px-4 py-2', lg: 'px-6 py-3' }),
});

interface ButtonProps {
  variant?: 'primary' | 'secondary';
  size?: 'sm' | 'md' | 'lg';
  children: React.ReactNode;
  onClick?: () => void;
}

const styles = {
  variant: {
    primary: 'bg-blue-500 hover:bg-blue-600 text-white',
    secondary: 'bg-gray-500 hover:bg-gray-600 text-white',
  },
  size: {
    sm: 'px-2 py-1 text-sm',
    md: 'px-4 py-2 text-base',
    lg: 'px-6 py-3 text-lg',
  },
} as const;

export function Button({
  variant = 'primary',
  size = 'md',
  children,
  onClick,
}: ButtonProps) {
  return (
    <button
      className={`rounded font-medium ${styles.variant[variant]} ${styles.size[size]}`}
      onClick={onClick}
    >
      {children}
    </button>
  );
}

Review this code for security vulnerabilities:
- XSS: Is user input properly sanitized before rendering?
- CSRF: Are state-changing requests protected?
- SQL Injection: Are queries parameterized?
- Input validation: Are all inputs validated and typed?
- Secrets: Are any API keys or credentials hardcoded?
- Dependencies: Are we using any packages with known vulnerabilities?
- Headers: Are security headers (CSP, HSTS, X-Frame-Options) configured?
- Auth: Are tokens stored securely? Are routes properly protected?

// DANGEROUS: AI-generated code that uses dangerouslySetInnerHTML
<div dangerouslySetInnerHTML={{ __html: userComment }} />

import DOMPurify from 'dompurify';

// Sanitized version
<div dangerouslySetInnerHTML={{ __html: DOMPurify.sanitize(userComment) }} />

// WRONG: AI sometimes does this in examples
const apiKey = 'sk-1234567890abcdef';

// CORRECT: Always use environment variables
const apiKey = process.env.API_SECRET_KEY;
if (!apiKey) throw new Error('API_SECRET_KEY is not configured');

// next.config.js
const securityHeaders = [
  {
    key: 'Content-Security-Policy',
    value: [
      "default-src 'self'",
      "script-src 'self' 'unsafe-inline'",
      "style-src 'self' 'unsafe-inline'",
      "img-src 'self' data: https:",
      "font-src 'self'",
      "connect-src 'self' https://api.example.com",
    ].join('; '),
  },
  { key: 'X-Frame-Options', value: 'DENY' },
  { key: 'X-Content-Type-Options', value: 'nosniff' },
  { key: 'Referrer-Policy', value: 'strict-origin-when-cross-origin' },
];

Review this code for performance issues:
- Are there unnecessary re-renders in React components?
- Should any components use React.memo or useMemo?
- Are images optimized (next/image, WebP, lazy loading)?
- Is there code that could be split or lazy loaded?
- Are there N+1 query problems in data fetching?
- Are expensive computations cached?
- Would any API calls benefit from stale-while-revalidate?

// AI default output
<img src="/hero.png" alt="Hero image" />

// What you should ask for
import Image from 'next/image';

<Image
  src="/hero.png"
  alt="Descriptive alt text for the hero section"
  width={1200}
  height={630}
  priority // Above the fold
  placeholder="blur"
  blurDataURL={shimmer(1200, 630)}
/>

// Ask AI: "Lazy load this heavy component"
import dynamic from 'next/dynamic';

const HeavyChart = dynamic(() => import('@/components/chart'), {
  loading: () => <ChartSkeleton />,
  ssr: false, // If it uses browser-only APIs
});

Analyze this page for Core Web Vitals impact:
- LCP: What's the largest contentful paint element? Is it optimized?
- FID/INP: Are there long tasks blocking interactivity?
- CLS: Are there any layout shifts from dynamic content?
Suggest specific improvements for each metric.

Write tests for this component covering:
- Happy path: renders correctly with valid props
- Edge cases: empty data, null values, very long strings
- Error states: API failure, network timeout, invalid input
- Accessibility: proper ARIA attributes, keyboard interaction
- User interactions: clicks, form submissions, navigation

Use Vitest and React Testing Library. Follow the Arrange-Act-Assert pattern.
No snapshot tests. Test behavior, not implementation details.

import { render, screen, fireEvent } from '@testing-library/react';
import { describe, it, expect, vi } from 'vitest';
import { SearchBar } from './search-bar';

describe('SearchBar', () => {
  it('calls onSearch with the input value on submit', async () => {
    const onSearch = vi.fn();
    render(<SearchBar onSearch={onSearch} />);

    const input = screen.getByRole('searchbox', { name: /search/i });
    await fireEvent.change(input, { target: { value: 'next.js' } });
    await fireEvent.submit(input.closest('form')!);

    expect(onSearch).toHaveBeenCalledWith('next.js');
  });

  it('does not submit with empty input', async () => {
    const onSearch = vi.fn();
    render(<SearchBar onSearch={onSearch} />);

    const form = screen.getByRole('search');
    await fireEvent.submit(form);

    expect(onSearch).not.toHaveBeenCalled();
  });

  it('is accessible via keyboard', async () => {
    render(<SearchBar onSearch={vi.fn()} />);

    const input = screen.getByRole('searchbox');
    input.focus();
    expect(document.activeElement).toBe(input);
  });
});

Build this component using a mobile-first approach:
- Start with the mobile layout as the default
- Use min-width breakpoints to enhance for larger screens
- Ensure touch targets are at least 44x44px
- Use fluid typography with clamp()
- Test that nothing overflows on 320px viewport width
- Use Tailwind's responsive prefixes (sm:, md:, lg:)

/* Ask AI to generate fluid type scales */
h1 {
  font-size: clamp(1.75rem, 4vw + 0.5rem, 3rem);
  line-height: 1.2;
}

p {
  font-size: clamp(1rem, 1vw + 0.75rem, 1.25rem);
  line-height: 1.6;
}

.card-container {
  container-type: inline-size;
}

@container (min-width: 400px) {
  .card {
    display: grid;
    grid-template-columns: 200px 1fr;
    gap: 1rem;
  }
}

@container (min-width: 600px) {
  .card {
    grid-template-columns: 300px 1fr;
  }
}

Add comprehensive error handling to this code:
- What happens if the API returns an error?
- What happens if the data is empty or null?
- What happens if the network is offline?
- What happens if the user double-clicks the submit button?
- What should the loading state look like?
- What should the empty state look like?
- Add an error boundary for unexpected crashes

Show me the loading, empty, error, and success states.

export default async function UserProfile({ userId }: { userId: string }) {
  const user = await fetchUser(userId);

  return (
    <div>
      <h1>{user.name}</h1>
      <p>{user.bio}</p>
    </div>
  );
}

import { notFound } from 'next/navigation';
import { ErrorFallback } from '@/components/error-fallback';

export default async function UserProfile({ userId }: { userId: string }) {
  if (!userId || typeof userId !== 'string') {
    notFound();
  }

  let user;
  try {
    user = await fetchUser(userId);
  } catch (error) {
    console.error(`Failed to fetch user ${userId}:`, error);
    return <ErrorFallback message="Unable to load profile. Please try again." />;
  }

  if (!user) {
    notFound();
  }

  return (
    <div>
      <h1>{user.name || 'Anonymous User'}</h1>
      <p>{user.bio || 'No bio provided.'}</p>
    </div>
  );
}

Pretend you're a principal engineer conducting a thorough code review
of this pull request. Be critical and specific. For each issue:

1. Explain what's wrong
2. Explain why it matters (security? performance? maintainability?)
3. Show the fix

Check for:
- Logic errors and off-by-one bugs
- Race conditions in async code
- Memory leaks (event listeners, subscriptions)
- Missing cleanup in useEffect
- Inconsistent error handling
- Type safety gaps (any, as assertions)
- Dead code and unused imports

Review the architecture of this project:
- Are components properly separated by concern?
- Is state management appropriate for the complexity?
- Are there circular dependencies?
- Is the folder structure scalable?
- Are there any coupling issues between modules?
- Would you recommend any structural changes before this grows?

// AI might generate:
import { useOptimistic } from 'react'; // This exists in React 19
import { useFormState } from 'react-dom'; // Renamed to useActionState in React 19

// Always check: "Is this API real? What version introduced it?"

# Project: My App

## Tech Stack
- Next.js 16 (App Router)
- React 19
- TypeScript (strict mode)
- Tailwind CSS 4.2
- pnpm for package management

## Commands
- `pnpm dev` - Start dev server
- `pnpm build` - Production build
- `pnpm test` - Run tests

## Conventions
- Components go in app/components/
- Use functional components with TypeScript interfaces
- Shared icons go in icons.tsx with a `size` prop
- Use the existing PostCard component — don't duplicate markup
- Mobile nav and desktop nav are separate components
- Dark mode uses the .dark class on <html>

## Don'ts
- Never use `any` type
- Never hardcode API keys or secrets
- Never use default exports for components (except pages)
- Never install new dependencies without asking
- Don't use deprecated APIs (getServerSideProps, etc.)