Agnel Nieves - AI https://agnelnieves.com/blog/tag/ai Blog posts on AI by Agnel Nieves. en-US Fri, 15 May 2026 01:12:14 GMT <![CDATA[Optimizing Your Website for AI Agents and LLMs]]> https://agnelnieves.com/blog/optimizing-your-website-for-ai-agents-and-llms https://agnelnieves.com/blog/optimizing-your-website-for-ai-agents-and-llms Your website has two audiences now. Humans, obviously. But also AI agents — LLMs that crawl, summarize, cite, and recommend your content to millions of people. If your site isn't optimized for both, you're leaving visibility on the table.

I just finished optimizing this site for AI consumption, and the process revealed something interesting: most of what makes a site good for AI also makes it better for humans. Clear structure, machine-readable content, and explicit metadata benefit everyone.

Here's what I did and why it matters.

What Are AI Agents Actually Doing with Your Site?

When someone asks ChatGPT, Claude, Perplexity, or Google's AI Overview a question, those systems don't just generate answers from training data. Increasingly, they fetch and cite live web content. Your site might get:

  • Crawled for training data by bots like GPTBot, ClaudeBot, and Google-Extended
  • Fetched at query time by Perplexity, ChatGPT browsing, and similar agents
  • Cited as a source in AI-generated responses
  • Summarized in featured snippets and AI overviews
  • Navigated by autonomous agents that interact with your APIs

Each of these has different needs, but they all benefit from the same foundation: structured, discoverable, machine-readable content.

The llms.txt Standard

The llms.txt spec is the equivalent of robots.txt for AI agents. While robots.txt tells crawlers what they can access, llms.txt tells them what your site is — a structured markdown index served at your domain root.

The format is simple:

# Your Name or Site

> A one-line summary of what this site is.

A longer description paragraph.

## Section Name

- [Link Title](https://url): Description of what's at this link

I implemented two variants:

  • /llms.txt — the index. A table of contents with links to all pages, blog posts, projects, social profiles, and feeds. Think of it as a menu for AI agents to browse selectively.
  • /llms-full.txt — the full dump. Every blog post's complete markdown content, every project description, biographical context. For agents that want to load everything into context at once.

Both are served as text/plain with markdown formatting. Both are generated dynamically from the same data sources that power the site, so they never go stale.

Inline LLM Instructions in HTML

This one comes from a Vercel proposal and it's clever: embed AI-readable instructions directly in your page's <head> using a script tag browsers ignore.

<script type="text/llms.txt">
# Your Site Name

This is the personal website of [name], a [role] based in [location].

## Site Structure
- / — Home: Description
- /blog — Blog: Description
- /about — About: Description

## Key Facts
- Name: Your Name
- Role: Your Role
- Specialties: Thing 1, Thing 2, Thing 3
</script>

Browsers skip <script> tags with unknown types. LLMs process them. It's a zero-cost way to give every page on your site a machine-readable context block. I added one to my root layout that describes who I am, the site structure, and where to find machine-readable content.

Structured Data That AI Engines Actually Use

JSON-LD structured data has always been important for Google. It's now equally important for AI engines. When an LLM encounters schema.org markup, it understands the semantics of your content — not just the text, but what the text represents.

I already had structured data for my blog posts (BlogPosting schema with breadcrumbs). What I added was CreativeWork schema for my portfolio projects, giving each project a machine-readable identity:

{
  "@context": "https://schema.org",
  "@type": "CreativeWork",
  "name": "Project Name",
  "description": "What this project is",
  "url": "https://project-url.com",
  "creator": {
    "@type": "Person",
    "name": "Your Name"
  }
}

The more schema types you cover, the more AI engines can understand and cite your work with proper attribution.

Machine-Readable Feeds

RSS is great, but it's XML — not the most natural format for AI agents to parse. I added a JSON Feed endpoint alongside my existing RSS feed:

  • /feed.xml — RSS 2.0 for traditional feed readers
  • /feed.json — JSON Feed 1.1 for programmatic consumption

JSON Feed is cleaner for AI agents to parse and reference. Both are registered in the site's metadata so they're auto-discoverable.

Making robots.txt AI-Aware

Most sites already have a robots.txt. The key addition is explicitly allowing AI crawlers and pointing them to your llms.txt:

User-agent: GPTBot
Allow: /

User-agent: ClaudeBot
Allow: /

User-agent: PerplexityBot
Allow: /

Sitemap: https://yoursite.com/sitemap.xml

# AI/LLM Content
# llms.txt: https://yoursite.com/llms.txt
# llms-full.txt: https://yoursite.com/llms-full.txt

Many sites block AI crawlers by default. If you want your content cited and discovered by AI, explicitly allow the major bots: GPTBot, ChatGPT-User, Google-Extended, ClaudeBot, anthropic-ai, PerplexityBot, Applebot-Extended, Bytespider, and cohere-ai.

Why This Matters for Creators

As a design engineer with 15+ years of building products, I've watched SEO evolve from keyword stuffing to semantic web to AI-native discovery. We're at an inflection point. The sites that get cited by AI aren't necessarily the ones with the best domain authority — they're the ones with the clearest, most structured, most machine-readable content.

This is especially important for personal sites and portfolios. When someone asks an AI "who are the best design engineers in Miami?" or "what's a good article about design tokens?", you want your site to be citable. That requires more than good content — it requires content that AI can find, understand, and attribute.

The Full Stack of AI Optimization

Here's the complete checklist of what I now have in place:

Layer What Why
robots.txt Explicitly allow AI bots Let them crawl
sitemap.xml Dynamic sitemap with all content Let them discover
llms.txt Markdown index of the site Let them understand structure
llms-full.txt Full content in one file Let them ingest everything
Inline <script> Page-level LLM instructions Let them understand context
JSON-LD Structured data on every page Let them understand semantics
RSS + JSON Feed Machine-readable content feeds Let them subscribe
Meta tags OpenGraph, Twitter, canonical Let them cite accurately

None of these changes affect how the site looks or feels for human visitors. They're invisible additions that make the site dramatically more useful for AI.

What's Next

The AI web is evolving fast. Standards like llms.txt are still emerging, and new patterns will appear. But the fundamentals won't change: structure your content clearly, make it discoverable, and give machines the metadata they need to understand it.

If you want to replicate this setup, I've published a full implementation guide with code examples for Next.js. The approach works for any framework — the concepts are universal.

Building something and want to talk AI optimization? Let's connect.

]]> Tue, 14 Apr 2026 00:00:00 GMT agnel@agnelnieves.com (Agnel Nieves) AI SEO Web Development LLMs <![CDATA[We Found a Hidden Pet System in Claude Code's Leaked Source and Shipped It Overnight]]> https://agnelnieves.com/blog/we-found-a-hidden-pet-system-in-claude-codes-leaked-source-and-shipped-it-overnight https://agnelnieves.com/blog/we-found-a-hidden-pet-system-in-claude-codes-leaked-source-and-shipped-it-overnight On March 30th, 2026, Anthropic accidentally shipped a 59.8 MB source map file inside their Claude Code npm package. Within hours, the entire 512,000-line TypeScript codebase was mirrored across GitHub and picked apart by thousands of developers. Buried inside that code, alongside feature flags for autonomous agents and undercover commit modes, was something nobody expected: a fully built virtual pet system called Buddy.

My co-founder peroni and I did the only sensible thing. We shipped it.

We all know what happened yday with Claude Code. Buried in the source: a hidden pet system called "Buddy." Every user gets a unique pixel creature based on their ID. Deterministic, same hash, same buddy, every time. So @peronif5 and I did the most sensible thing... Shipped it.… pic.twitter.com/YE4ZSEIXq7

— Agnel (🇵🇷) (@agnelnieves) April 1, 2026

What Happened with the Claude Code Leak

If you missed it, here's the short version. Chaofan Shou (@Fried_rice) noticed that version 2.1.88 of the @anthropic-ai/claude-code package on npm included an unminified source map — cli.js.map — containing the full, readable TypeScript source. By 4:23 AM ET, it was public. By noon, the internet had catalogued every hidden feature, internal codename, and unreleased capability Anthropic had been quietly building.

Among the bigger discoveries:

  • KAIROS — an always-on daemon mode that lets Claude Code operate as a persistent background agent, watching, logging, and acting without waiting for user input
  • Undercover mode — auto-activated for Anthropic employees on public repos, stripping AI attribution from commits
  • 44 feature flags covering unreleased functionality
  • And tucked away, a complete companion pet system called Buddy

The Buddy System: A Pixel Pet for Every User

The Buddy system was fully implemented. Every Claude Code user was supposed to get a unique pixel creature generated deterministically from their user ID. Same hash, same buddy, every time. The code included 18 species across rarity tiers, stat generation, personality descriptions — the whole gacha experience, just waiting to be turned on.

It was the kind of detail that makes you smile. In a tool built for productivity and code generation, someone at Anthropic took the time to build a pet system. A little pixel friend that lives in your terminal. That's the kind of craft and whimsy that makes developer tools memorable.

The moment I saw it, I knew what we had to do.

From Discovery to Deploy in a Day

Peroni and I have a rhythm. We spot something interesting, we build. No planning committee, no Jira tickets, no "let's circle back Monday." As a design engineer with 15+ years of shipping products, I've learned that the best side projects are the ones you can't not build. This was one of those.

We built Claude Buddy — a web app that lets anyone generate their own pixel companion. Type your name or your Claude Code user ID, and watch it draw your buddy pixel by pixel, complete with retro CRT animations and pop sounds.

Here's what we shipped:

  • 12 unique pixel art species across 5 rarity tiers — from common Blobbits to the legendary Nebulynx (3% chance)
  • Deterministic generation — same name always produces the same buddy, making them feel like yours
  • Shiny variants with a 5% drop rate, because of course
  • Buddy stats — Vibe, Chaos, Focus, and Luck, each randomly rolled but consistent to your hash
  • One-command terminal install — curl a script and your buddy appears in your Claude Code statusline
  • Social sharing — download as PNG, share via URL, generate QR codes, post to X/LinkedIn with pre-populated text

The whole thing runs on Next.js 15, renders sprites on HTML5 Canvas, and uses a Mulberry32 PRNG seeded by a DJB2 hash of your input. No backend, no database, no authentication. Pure deterministic fun.

Why Build This?

Partly because it's fun. Partly because of how I approach creative work — I try to ship a hackathon-style project every quarter to stay sharp and experiment with new patterns. But mostly because I think the Buddy system represents something important about how we relate to our tools.

Developer tools don't have to be purely utilitarian. The best ones have personality. They reward curiosity. They make you want to open the terminal. A pixel pet that lives next to your cursor won't make you a better programmer, but it might make the work feel a little less solitary.

Anthropic clearly felt the same way — they built the whole thing, ready to ship. We just opened the door a little early.

How the Generation Algorithm Works

For the technically curious, the generation is straightforward:

  1. Take the input string (name or user ID), lowercase and trim it
  2. Salt it with a fixed string to avoid collisions
  3. Run a DJB2 hash to convert it to a numeric seed
  4. Feed that seed into a Mulberry32 PRNG
  5. Roll for species (weighted by rarity tier probabilities)
  6. Roll for shiny status (5% chance)
  7. Generate four stats between 1 and 99
  8. Select a soul description from the species pool

Same input, same seed, same rolls, same buddy. Every time. No server involved.

It's Open Source

The entire project is open source on GitHub. Built by the Basement team. Fork it, remix it, hatch your own buddy.

If you want to see what came out of this, check the thread on X where we announced it. And if you're building with Claude Code, maybe your buddy is already waiting — just type your name and find out.

Have thoughts on this or want to collaborate on something weird? Let's connect.

]]> Wed, 01 Apr 2026 00:00:00 GMT agnel@agnelnieves.com (Agnel Nieves) AI Claude Code Open Source Side Projects Creative Coding <![CDATA[The AI-Native Design Gap: From Static to Dynamic Experiences]]> https://agnelnieves.com/blog/ai-native-design-gap-from-static-to-dynamic-experiences https://agnelnieves.com/blog/ai-native-design-gap-from-static-to-dynamic-experiences Here's something I see all the time: teams spend weeks perfecting static mockups in Figma, present them with confidence, and then watch as stakeholders nod politely but don't quite get it. Why? Well, we're designing static artifacts for dynamic experiences.

Every scroll, swipe, and tap in a real product triggers visual feedback. It's how users actually understand what's happening. Yet we keep pitching ideas as if they exist in freeze-frame.

The AI-Native Design Challenge

This gap matters more than ever, especially if you're working on AI-native products. Whether it's OpenAI's ChatGPT, Perplexity's search interface, or Claude's conversations—these products are rewriting the rules of digital interaction. They're introducing entirely new patterns: streaming responses, conversational flows, adaptive interfaces that feel less like traditional apps and more like living dialogues. Even more so if the interactions include voice motion which is supposed to react to the user's voice.

You can't capture that in a static frame. You have to show it in motion.

Why Interaction Design Is an Unlocked Skill

Here's the thing about motion and interaction design: it's a toolkit you unlock through experimentation, not strictly tied to theory or studies. You learn it by thinking about physics, natural movement, user intent—concepts you absorb from using dozens of different apps and noticing what feels right. Think about it, try to explain a motion ui pattern to someone, try to explain the core concept of what you have in your mind. It's difficult… It's open to interpretation of the person to whom you're explaining it to, and limited by their imagination (which is highly likely different from yours).

This creates a knowledge gap. Most designers haven't had the chance to experiment enough with motion to build that intuition. But here's what I've learned: even designing interactions frame-by-frame, storyboard-style like old Disney animations, can be enough to transform how you communicate ideas. It forces you to think through every transition, every state change, every moment of feedback.

And it doesn't just help you—it helps engineering understand exactly what you're trying to build.

Design Is Taking the Spotlight Again

We're in an exciting moment. With AI tools and no-code platforms, pretty much anyone can spin up a functional prototype. The technical barrier to entry has lowered significantly.

What does that mean? Design becomes the differentiator. When everyone can build something that works, the products that win are the ones that feel incredible to use. Motion, polish, and thoughtful interaction patterns aren't nice-to-haves anymore—they're what separates successful products from forgettable ones.

My Approach: Build to Learn

I try to ship a hackathon-style project every quarter. Not because I need more side projects, but because it's the only way to stay ahead and fresh. New patterns emerge constantly. AI products iterate at light speed. Existing products unveil interactions you never even considered.

The only way to keep your intuition sharp is to experiment relentlessly with what's out there.

This comes from personal experience. My background has helped me a lot in this area—I started as a designer, shifted to software engineering, and eventually came back to design. That engineering foundation changed everything. I can quickly prototype motion patterns directly in code (often faster than in design tools), play with them until something clicks, then bring those learnings back to Figma to polish everything together.

This workflow might sound backwards, but to me, it makes sense and it just works: code/define the motion first, design and polish last. Code gives you the freedom to experiment rapidly. Spin up prototypes quickly, and gather feedback. Design tools give you the precision to perfect it.

The Practical Takeaway

If you're trying to sell an idea—whether to stakeholders, users, or investors—don't stop at static screens. Invest time in showing how it moves. Show how it responds. Show how it feels.

You don't need to be an engineer to do this. Start simple:

  • Sketch interaction sequences frame-by-frame
  • Use Figma's prototyping features to simulate key transitions
  • Try tools like ProtoPie, Lottie Lab for more complex motion
  • Or, if you're comfortable with code, prototype directly in React or HTML

The medium matters less than the commitment: design for motion, not just for pixels.

Because in an era where AI is democratizing creation, the products that win won't just work—they'll feel magical. And you can't explain magic in a static mockup.

]]> Thu, 16 Oct 2025 00:00:00 GMT agnel@agnelnieves.com (Agnel Nieves) Design Motion AI Prototyping