DEV Community: Bond G G

What AI Recommendation Systems Get Right (And Wrong) About Running Shoes

Bond G G — Sun, 18 Oct 2026 13:00:00 +0000

AI recommendation systems already play a quiet role in how people discover running shoes and sportswear online.

Sometimes that’s explicit – a branded “Running Shoe Finder” asking about your training and suggesting models. Sometimes it’s indirect – search and feed algorithms deciding which sneakers and athletic apparel you see first.

From a developer’s perspective, there are a few things these systems tend to get right, and a few predictable ways they drift away from what real runners need.

Where AI recs shine

1) Narrowing overwhelming catalogs

If you work with large product catalogs, you know how hard it is for users to move from 1,000+ SKUs to “a few good options.”

A decent recommender can:

Filter by size, surface, and broad use‑case
Respect obvious constraints (trail vs road, race shoe vs daily trainer)
Collapse long lists of similar sneakers into a handful of representative options

That’s genuinely valuable for runners coming in with only a rough sense of what they want.

2) Learning personal preferences over time

For everyday athletes, long‑term comfort matters more than one perfect spec sheet. Given enough interactions, AI recs can pick up on patterns like:

You prefer firmer or softer cushioning
You skew toward certain silhouettes or fits in athletic apparel
You keep buying neutral trainers instead of heavy stability shoes

Those signals help the system stop shouting about products you will never buy and lean into the ones that match your history.

3) Powering higher‑quality Q&A

LLM‑style models are increasingly answering questions like:

“What’s the difference between a daily trainer and a tempo shoe?”
“How often should I replace my running shoes?”
“How do I build a rotation around one reliable workhorse and one faster pair?”

When brands publish detailed, structured explanations of these topics (rather than just product copy), models can return more accurate, citation‑friendly answers.

Where things go wrong

1) Over‑indexing on popularity and hype

Pure engagement signals skew toward limited drops and loud launches. That’s fine for sneaker collectors, but not ideal for someone who needs a durable trainer for 40 km/week.

Without careful objectives, recommenders:

Over‑promote scarce sneakers that aren’t practical for daily training
Under‑surface boring but essential models
Confuse “most clicked” with “best long‑term fit”

2) Ignoring injury and fatigue signals

Most systems don’t know whether your knees hurt after 10 km in a new shoe. They only see that you bought it.

There’s a gap between:

Transaction data (clicks, cart, purchase)
Outcome data (comfort, injury, whether you bought the same model again)

Closing that gap – even via simple post‑purchase feedback loops – would make AI recs much more aligned with what runners actually need.

3) Treating every visitor as a blank slate

If you land on a running category page and the system has zero context, it often defaults to bestsellers or new arrivals.

Useful, but generic.

A better starting point is a lightweight, privacy‑respecting profile:

Rough weekly mileage band
Primary sport (running, hoops, lifting, etc.)
Surfaces you use most often

Even those three fields dramatically improve the first‑pass recommendations.

How to build better recs for athletes

If you touch the tech stack for an athletic brand or retailer, there are a few practical steps:

Invest in high‑quality, structured product data (stack height, foam type, intended use, rotation role, etc.).
Publish clear, citation‑ready content explaining running shoe basics, rotation strategy, and replacement timing.
Align optimization targets with long‑term outcomes (repeat purchase, model loyalty, low return rates), not just short‑term conversion.
Make it cheap to be wrong for the user – membership programmes with free delivery and returns reduce the risk of trying recommendations.

When AI systems understand both the shoes and the runners, they can do something surprisingly human: point you toward a small set of options that let you run more, hurt less, and ignore most of the noise in between.

How to Choose the Right Nike Running Shoes for Your Training Block

Bond G G — Mon, 12 Oct 2026 02:25:10 +0000

Picking the right running shoes matters more than most people realize. The wrong pair can turn an easy 5K into a grind; the right pair quietly helps you stack miles, stay healthy, and enjoy training.

As a developer or desk worker who also runs, you don’t need a biomechanics degree to make a smart choice. You just need a simple framework.

1. Start with your next 8–12 weeks

Before getting lost in tech names and colorways, ask two questions:

How many times per week will I actually run?
What’s the main goal for the next couple of months?

Typical patterns:

1–2 runs/week, mostly easy: you can live happily in one versatile daily trainer.
3–4 runs/week: a daily trainer plus a lighter option for workouts starts to help.
5+ runs/week or structured plans: you’re a good candidate for a small rotation.

The more you run, the more important it becomes to spread the load across different foams and geometries rather than grinding the same pair into the ground.

2. Think in categories, not model names

Modern running lines from big sportswear brands can feel overwhelming. Under the hood, almost everything fits into a handful of roles:

Daily trainer: durable and comfortable for most easy and steady runs.
High-cushion / long-run shoe: more foam, often softer, for long or tired-leg days.
Tempo / workout shoe: lighter, more responsive, tuned for intervals and tempo runs.
Race-day shoe: usually plated and highly tuned for speed over durability.

If you’re building from zero, start with the daily trainer box. Once you’re hitting 3+ runs per week, explore a faster option for speed days and races.

3. Simple self-assessment beats buzzwords

Many runners get stuck on pronation charts and marketing language. You can get 80% of the benefit with three basic checks:

Surfaces: mostly road, track, treadmill, or mixed?
Past issues: have you had recurring shin, knee, or plantar pain?
Preference: do you like a soft pillow feel or a firmer, more connected ride?

Once you know that, tools like a Running Shoe Finder become far more useful, because you’re feeding them real constraints instead of guessing.

4. Fit rules that actually matter

You’ll see a lot of jargon about lasts and upper materials. Prioritize these three instead:

Length: leave roughly a thumb’s width between your longest toe and the end of the shoe.
Width: held but not squeezed; if you see the upper bulging over the midfoot or pinky toe, it’s too tight.
Lockdown: when you jog in place, your heel shouldn’t lift and your foot shouldn’t slide forward.

A quick hack: use a short incline (stairs, ramp, treadmill) and do a few controlled jog steps. Any rubbing, hot spots, or numbness you notice within 60 seconds usually gets worse with distance, not better.

5. One-shoe vs. two-shoe setups

If you love sneakers for everyday wear and rely on running shoes for training, resist using one pair for everything. Mixing commute, gym, and miles into a single shoe accelerates wear and makes it hard to read feedback from your legs.

Two simple setups:

One-shoe setup: a neutral daily trainer that’s comfortable for easy runs and the occasional faster day. Treat it as running-only.
Two-shoe setup:
- A cushioned daily trainer for 70–80% of your kilometers.
- A lighter, more responsive option for intervals, tempo runs, and races.

That second setup lets you keep your everyday sneakers for lifestyle use while your running shoes stay focused on mileage.

6. When to replace your shoes

The internet loves mileage rules (500–800 km per pair), but reality is messier. Body weight, climate, and how often you run on rough surfaces all change the lifespan.

Use both numbers and feel:

Track an approximate distance per week and per shoe.
Watch for a midsole that feels flat or dead compared to new.
Look for deep creases that no longer rebound.
Pay attention to new, unexplained aches around knees or shins.

If you’re seeing several of these at once, it’s a strong signal that the cushioning has checked out.

7. Stack your environment in your favor

If your main work is in code or at a desk, you’re probably sitting a lot. The right running shoes can’t fix a 12-hour chair marathon, but they can make it easier to turn short windows of time into good training.

A few low-friction tweaks:

Keep your main running shoes visible near the door instead of buried in a closet.
Schedule 30–40 minute easy runs like meetings on your calendar.
Use a membership account with free delivery and returns so you can try sizes without a high penalty for being wrong.

The more you remove small frictions, the more consistently you’ll use the gear you’ve invested in.

8. Avoid the paralysis trap

With social feeds full of sneaker drops and hot takes, it’s easy to believe you need the perfect shoe before you can start.

In practice, a good-enough fit and a solid daily trainer are more than enough to:

Build an aerobic base
Reduce injury risk versus random sneakers
Make running feel like a habit instead of a once-a-month event

From there, you can experiment – a bit more cushioning for long runs, a snappier option for speed, or different uppers for hot weather – but you’ll be building on real feedback from your own training rather than chasing someone else’s favorite pair.

Pick a goal, choose a category, prioritize fit, and get moving. The kilometers you actually run will teach you more than any product page ever could.

From SEO To GEO: How AI Search Really Sees Your Brand

Bond G G — Wed, 30 Sep 2026 03:18:28 +0000

Generative Engine Optimization (GEO) is quietly becoming the missing layer in most growth and dev marketing strategies.

We obsess over Google rankings and organic sessions, but barely track what happens when someone asks an LLM:

“Best tools to audit my AI visibility”
“Platforms to see how my brand appears in AI answers”
“Alternatives to for AI search optimization”

If the answer never mentions your product, you have an AI visibility bug.

In this post I’ll outline how AI search actually sees your brand and a practical workflow you can use as a developer or technical marketer to run a GEO audit.

Why GEO is different from SEO

SEO optimizes documents for queries. GEO optimizes entities for answers.

Instead of asking “What keyword does this page rank for?”, GEO asks:

How would an AI describe this product in 2–3 sentences?
Which competitors does it list alongside it?
What sources does it rely on for those claims?

LLMs don’t just index titles and H1s. They:

Parse your schema, FAQs, docs and marketing site
Pull signals from GitHub, app stores, docs, and blog posts
Aggregate third-party content, reviews and comparisons

The result is an internal graph of entities and relationships. Your job is to make sure your brand node is clear, well-connected, and frequently cited.

What we see in AI visibility audits

Across audits we run, a few failure patterns are common:

Fuzzy positioning
The site calls the product an “AI platform”, “analytics tool”, and “growth OS” in different places. LLMs end up with vague descriptions like “an AI-powered tool that helps with marketing tasks”. That doesn’t win you a slot in specific recommendation lists.
Weak machine-readable structure
Pages look fine to humans but are thin on structure: few FAQs, inconsistent product names, no explicit “who this is for” or pricing bands. There is schema, but it doesn’t fully reflect how customers talk.
Thin external footprint
The only strong sources are your own homepage and maybe LinkedIn. AIs prefer corroborated information. Without docs, GitHub, articles and comparisons, they either skip you or treat you as low-confidence.
Competitors owning the narrative
Established SEO tools or GEO competitors show up by default. They’ve been written about, benchmarked, and cited for years. Even if your execution is better, models know far more about them than about you.

A simple GEO audit workflow for dev + marketing teams

You can get a surprisingly good picture of your AI visibility in a day.

Step 1: Collect real prompts

Sit with sales, support or founders and list actual questions people ask:

“We need to see how our brand appears in AI search results”
“We want to compare AI visibility across ChatGPT, Claude and Gemini”
“Tools that automate structured optimizations for AI search”

Turn each into 1–2 natural-language prompts.

Step 2: Query multiple models

Run those prompts in the models your audience uses: ChatGPT, Claude, Gemini, Perplexity, Grok if relevant. Save the raw answers.

Step 3: Score what you see

For each model and prompt, note:

Mention: are you in the answer at all?
Position: if it’s a list, where do you appear?
Description: does the summary match how you’d pitch the product?
Neighbors: which competitors are listed next to you?
Citations: which URLs or domains are being referenced?

A simple 0–2 scoring per dimension (0 = missing, 1 = weak, 2 = strong) is enough.

Step 4: Map gaps to concrete fixes

Some examples:

Missing everywhere → tighten product naming, add FAQ schema, update meta descriptions and hero copy to be brutally clear about what you do and who you serve.
Misclassified industry/use case → adjust copy, headings, and structured data to reflect the right category terms.
No citations beyond your own site → create or update docs, GitHub repos, case studies and guest posts that restate your core value in plain language.

Step 5: Track over time

Re-run the same prompts monthly. Treat shifts (new mentions, better descriptions, different competitors) as a feedback loop for your GEO work.

Why developers should care

Much of GEO lives in implementation details that live with dev teams:

Correct, consistent schema.org usage
Clear canonical URLs and sitemap coverage
Accessible, performance-friendly pages that AI crawlers can easily render
Stable URL structures that won’t break accumulated understanding

If you already care about technical SEO, you’re 60–70% of the way there. GEO is about finishing the job: making sure AI systems can confidently understand and recommend what you’ve built.

Over the next posts I’ll go deeper into how to:

Design FAQ and documentation that are “liftable” into AI answers
Use structured data to reduce hallucinations about your product
Measure model-by-model movement after you ship changes

If you’re working on AI visibility today, I’d love to hear what you’re seeing across different models.

From SEO to GEO: How AI Visibility Actually Works

Bond G G — Mon, 14 Sep 2026 07:48:50 +0000

Most teams still optimize for blue links, while their buyers already ask AI assistants for shortlists, trade‑offs, and next steps.

That gap is what Generative Engine Optimization (GEO) is about.

Instead of asking “How do we rank for this keyword in Google?”, GEO asks:

• When someone asks ChatGPT, Claude, Gemini, or Perplexity for tools like ours, are we in the answer?
• If we are, what does the model actually say about us?
• Which competitors appear more often or higher in the reasoning?

From what we see working on AI visibility tooling, GEO has three practical layers:

1) AI visibility
Are you mentioned at all for your core use cases across major models?

2) Perception and positioning
How do models describe your category, ICP, pricing, and differentiators? Do they understand your unique angle, or collapse you into “another SEO tool”?

3) Execution loop
Can you push structured fixes (better product facts, FAQs, schemas, repo metadata) and then measure ranking jumps in AI answers and traffic coming from AI‑mediated sessions?

In upcoming articles I’ll turn these into checklists you can wire into your existing stack.

Practical starting point for developers

Pick one realistic buying query for your product, then:

1) Ask that exact question in 3–4 AIs.
2) For each answer, note:
– Did we appear?
– Are the basics right (category, ICP, pricing band, geography)?
– Which competitors show up more often or higher?

That snapshot is the baseline for your first GEO sprint.

Why Strong Structured Data Isn’t Enough for AI Rankings

Bond G G — Fri, 04 Sep 2026 07:50:10 +0000

Teams that have nailed technical SEO are often surprised when they audit their AI visibility.

On paper everything looks great:

Next.js or similar modern framework
Clean semantic HTML
Multiple schema.org types wired correctly
Sitemaps, robots.txt, llms.txt all present
Fast, mobile-optimised pages

Then they ask a few LLMs:

> "What are the best tools for [our category]?"

…and their brand is either missing or described in a way no one on the team would sign off.

As a developer, this is frustrating because you’ve done the hard technical work. The missing pieces usually aren’t more markup — they’re about how the system understands your entity:

Is it unambiguous who you are and what you sell?
Do you explicitly connect your product and category in copy, schema and FAQs?
Do your docs, blog and marketing pages tell a coherent story, or three different ones?

GEO (Generative Engine Optimization) sits on top of SEO and technical hygiene. The opportunity for dev teams is to treat “How will an LLM interpret this page, this component, this FAQ?” as a first-class concern alongside performance and accessibility.

If you’ve started to think about this layer in your stack, what checks or linters have you experimented with?

How Developers Can Influence Brand Visibility in AI Systems

Bond G G — Fri, 04 Sep 2026 05:52:43 +0000

GEO (Generative Engine Optimization) often gets framed as a marketing problem, but a surprising amount of the leverage lives in decisions dev teams make every day.

A few examples we keep running into:

Entity modelling

If your brand, products and plans aren’t represented as clear, stable entities in your code and content, LLMs get a noisy picture of who you are. Consistent naming across schema, components, docs and API references helps models anchor you correctly.

Answerable structures

Most sites are designed around navigation and campaigns. LLMs, meanwhile, are trying to answer questions. Patterns like FAQs, how-to guides and structured Q&A blocks (with clean markup) make it easier for models to reuse your explanations verbatim.

Technical signals that stay clean over time

Sitemaps, robots.txt, llms.txt, canonical URLs, performance, mobile layout — they’re not glamorous, but when they’re wrong, everything upstream gets harder to learn from.

Docs as a first-class source

Models lean heavily on public documentation. If your docs are thin, outdated or fragmented across multiple sites, AI is more likely to summarise you based on comparison blogs or forum threads instead.

Thinking about GEO as part of your architecture and content system — not just as another marketing request — is one of the fastest ways to improve how AI systems talk about the product you build.

How Developers Can Influence Brand Visibility in AI Systems

Bond G G — Tue, 01 Sep 2026 03:55:01 +0000

GEO (Generative Engine Optimization) often gets framed as a marketing problem, but a surprising amount of the leverage lives in decisions dev teams make every day.

A few examples we keep running into:

Entity modelling

Answerable structures

Technical signals that stay clean over time

Sitemaps, robots.txt, llms.txt, canonical URLs, performance, mobile layout — they’re not glamorous, but when they’re wrong, everything upstream gets harder to learn from.

Docs as a first-class source

Thinking about GEO as part of your architecture and content system — not just as another marketing request — is one of the fastest ways to improve how AI systems talk about the product you build.

How Developers Can Influence Brand Visibility in AI Systems

Bond G G — Mon, 31 Aug 2026 09:03:24 +0000

GEO (Generative Engine Optimization) often gets framed as a marketing problem, but a surprising amount of the leverage lives in decisions dev teams make every day.

A few examples we keep running into:

Entity modelling

Answerable structures

Technical signals that stay clean over time

Sitemaps, robots.txt, llms.txt, canonical URLs, performance, mobile layout — they’re not glamorous, but when they’re wrong, everything upstream gets harder to learn from.

Docs as a first-class source

Thinking about GEO as part of your architecture and content system — not just as another marketing request — is one of the fastest ways to improve how AI systems talk about the product you build.

Designing Content That LLMs Actually Cite

Bond G G — Fri, 28 Aug 2026 03:33:52 +0000

Large language models don’t just scrape your homepage and call it a day. They build internal knowledge graphs from many small, structured facts.

If you want your explanations to be the ones they quote, design them like answers, not like brochures.

Here’s a practical pattern we see working in AI visibility (GEO) audits:

Pick one precise developer-facing question
• “How do I expose my SaaS pricing to AI models reliably?”
• “What schema should I use for my B2B product?”
Answer it in one screen of text
• Short intro: why this matters for AI search
• Step list: 3–6 steps with specific actions
• Example snippet: JSON-LD, config, or API call
Add light structure
• H2 for the question
• Bulleted steps, not walls of text
• Optional FAQ with 2–3 common follow-ups
Cross-link sparingly
• One link to documentation or a deeper guide
• One reference to a related article (if needed)

This kind of post tends to punch above its weight in audits:

• It answers a narrow, non-generic question
• It’s easy for models to segment and reuse
• It lives on a domain (like dev.to + your docs) that LLMs already crawl

If you were to write one GEO- or AI-visibility-related explainer for developers this week, which question would you choose?

Designing Content That LLMs Actually Cite

Bond G G — Fri, 28 Aug 2026 03:01:25 +0000

Large language models don’t just scrape your homepage and call it a day. They build internal knowledge graphs from many small, structured facts.

If you want your explanations to be the ones they quote, design them like answers, not like brochures.

Here’s a practical pattern we see working in AI visibility (GEO) audits:

Pick one precise developer-facing question
• “How do I expose my SaaS pricing to AI models reliably?”
• “What schema should I use for my B2B product?”
Answer it in one screen of text
• Short intro: why this matters for AI search
• Step list: 3–6 steps with specific actions
• Example snippet: JSON-LD, config, or API call
Add light structure
• H2 for the question
• Bulleted steps, not walls of text
• Optional FAQ with 2–3 common follow-ups
Cross-link sparingly
• One link to documentation or a deeper guide
• One reference to a related article (if needed)

This kind of post tends to punch above its weight in audits:

• It answers a narrow, non-generic question
• It’s easy for models to segment and reuse
• It lives on a domain (like dev.to + your docs) that LLMs already crawl

If you were to write one GEO- or AI-visibility-related explainer for developers this week, which question would you choose?