DEV Community: Алексей Невостребов

Implementing Persona Guardrails: How to Technically Bound an AI "Teacher" or "Coach" Role

Алексей Невостребов — Thu, 06 Aug 2026 19:35:47 +0000

Persona-based AI avatars (teacher, coach, psychologist, etc.) raise a real engineering question that goes beyond prompt design: how do you technically constrain a system so its confidence level actually reflects its competence, rather than defaulting to the same fluent tone regardless of whether it's right? Here's a practical breakdown.

The Core Failure Mode

A generic system prompt like "You are a supportive coach persona" does nothing to bound the model's actual behavior — it just changes tone, not epistemic caution. The LLM will still generate confident-sounding advice on topics it has no real grounding for, because nothing in that prompt tells it when to be uncertain.

Layer 1: Scope the Knowledge, Not Just the Personality

Persona and capability should be separate concerns in your architecture:

python
system_prompt = f"""
You are speaking as: {persona_name} ({persona_role})
Tone: {persona_tone_guidelines}

CAPABILITY BOUNDARY:
You may only give advice grounded in: {approved_knowledge_domains}
For topics outside this scope, you MUST say so explicitly and
suggest a qualified human resource — do not attempt an answer.
"""

This separates "how it talks" from "what it's allowed to claim expertise on" — a persona shouldn't expand the model's actual scope of confident advice.

Layer 2: Confidence-Aware Response Generation

Rather than letting the model self-report uncertainty (unreliable), pair generation with an explicit classification step:

python
def generate_persona_response(query, persona_config):
domain_match = classify_query_domain(query, persona_config.scope)

if domain_match.confidence < CONFIDENCE_THRESHOLD:
    return generate_deflection_response(query, persona_config)

return generate_scoped_response(
    query, 
    persona_config,
    require_hedge_language=domain_match.risk_level == "high"
)

For higher-stakes domains (health, legal, financial, emotional distress detection), force hedge language and human-handoff suggestions into the response template rather than trusting the model to volunteer them.

Layer 3: Crisis/Escalation Detection as a Separate Pass

For personas touching emotionally sensitive territory, run a lightweight classifier before the main persona response — independent of the persona's normal conversational flow:

python
def check_escalation_needed(user_message, conversation_history):
risk_signals = detect_distress_signals(user_message, conversation_history)
if risk_signals.severity >= ESCALATION_THRESHOLD:
return crisis_resource_response() # bypass persona entirely
return None

This should run regardless of what persona is active — a "coach" or "teacher" bot can still receive a message indicating real distress, and the persona framing shouldn't suppress an appropriate response.

Layer 4: Persistent Disclosure, Not One-Time

A disclaimer in message 1 gets forgotten by message 10. Bound this at the UI/session layer, not just the prompt:

javascript
// Re-inject disclosure context periodically, not just at session start
if (messageCount % DISCLOSURE_INTERVAL === 0 || domainMatch.risk_level === 'high') {
injectSystemReminder(session, AI_DISCLOSURE_TEXT);
}
Why This Matters Beyond Ethics

Aside from the responsibility angle, unbounded personas are also a liability and product-quality problem: a "teacher" persona confidently giving wrong explanations, or a "coach" persona giving generic advice framed as personalized strategy, produces bad outcomes that eventually show up as churn, complaints, or worse — not just an abstract harm.

Takeaway

Persona design in AI avatars is usually treated as a prompt-engineering/tone problem. It's really a systems design problem: separating tone from capability boundary, adding confidence classification independent of the model's self-reported certainty, running escalation detection as an unconditional layer, and making disclosure persistent rather than front-loaded. None of this is exotic engineering — it's mostly discipline about not letting a single prompt do all the work a proper system architecture should be doing.

How to Actually A/B Test AI Avatar vs. Text Chat Conversion (A Technical Approach)

Алексей Невостребов — Tue, 04 Aug 2026 20:59:55 +0000

Following up on a common claim in the AI avatar space — that voice/video avatars convert better than plain text chat — there's surprisingly little rigorous testing behind it. If you're building or embedding one of these widgets, here's a practical way to actually measure it instead of trusting vendor case studies.

Why This Is Harder Than a Normal A/B Test

Standard A/B testing swaps one variable (a button color, a headline) while holding everything else constant. Avatar vs. text chat isn't that clean — you're changing interaction modality, response latency expectations, and visual real estate simultaneously. You need to isolate the variable that actually matters: does voice/video presence drive conversion, independent of the underlying conversation quality?

A Cleaner Experimental Setup
javascript
// Pseudocode for variant assignment
function assignVariant(sessionId) {
const hash = hashSessionId(sessionId);
return hash % 2 === 0 ? 'avatar' : 'text';
}

Key controls to hold constant across both variants:

Same LLM backend and prompt/knowledge base — the conversation logic shouldn't differ, only the presentation layer
Same lead capture form and CTA placement — don't let UI differences beyond avatar-vs-text confound the result
Same traffic source — segment by acquisition channel if traffic mix varies, since paid vs. organic visitors convert differently regardless of chat UI
Minimum sample size before evaluating — novelty effects are real; running this for 3 days will overstate the avatar's lift. Run for at least 2-3 weeks to let novelty decay.
Metrics to Track (Not Just Conversion Rate)

Conversion rate alone hides why one variant wins or loses:

session_start_to_first_message (engagement friction)
message_count_per_session (depth of interaction)
time_to_form_completion (avatar/video adds latency — does it cost or gain time?)
bounce_rate_before_first_response
lead_quality_score (if you can grade downstream — a lead isn't a conversion if it's junk)

A common finding worth watching for: avatar variants sometimes show higher engagement (more messages, longer sessions) but similar or lower completed-lead rates, because the richer interaction takes longer to reach the actual CTA. Aggregate conversion rate alone would miss this entirely.

Statistical Significance, Practically

Don't trust a result until you've checked it properly:

python
from scipy.stats import chi2_contingency

conversions: [avatar_conversions, avatar_total, text_conversions, text_total]

contingency_table = [
[avatar_conversions, avatar_total - avatar_conversions],
[text_conversions, text_total - text_conversions]
]
chi2, p_value, dof, expected = chi2_contingency(contingency_table)

At typical small-business traffic volumes (a few hundred sessions/month), you often won't reach statistical significance within a reasonable testing window — worth calculating required sample size before running the test, not after, to avoid over-interpreting noise.

Why Vendor Case Studies Don't Substitute for This

Case studies published by avatar platforms almost universally compare "avatar" against "no chat widget at all" — a much easier bar than "avatar vs. equivalent text chatbot." If you're deciding whether to pay a 2-3x price premium for voice/video over text, that's the comparison that actually matters, and it's one you'll likely have to run yourself.

Takeaway

If a platform (or your own build) claims avatars convert better, the burden of proof is on a controlled, sufficiently powered test — not a demo video or an aggregated case study. The infrastructure to run this properly (consistent backend, proper metrics, correct statistical test) is straightforward to build and worth doing before committing budget to the premium tier.

Preventing Hallucinations in Customer-Facing AI Avatars: A Practical Architecture

Алексей Невостребов — Mon, 03 Aug 2026 21:44:23 +0000

If you're building (or evaluating) an AI avatar for customer-facing use, the hardest engineering problem isn't voice synthesis or rendering — it's keeping the LLM from confidently making things up. Here's a practical breakdown of how to scope one properly.

The Core Problem

A raw LLM call with a system prompt like "you are a helpful assistant for [business]" will happily generate plausible-sounding, fluent, and sometimes completely wrong answers about pricing, policies, or availability. In a text chatbot, this is bad. In a voice avatar, it's worse — the confident tone of a natural voice makes wrong answers more convincing, not less.

The Fix: Retrieval-Augmented Generation (RAG), Done Tightly

The standard mitigation is RAG — but the implementation details matter more than people assume:

User question
→ embed query
→ vector search against business-specific knowledge base
→ retrieve top-k relevant chunks
→ inject into LLM context with explicit instruction:
"Answer ONLY using the provided context.
If the answer isn't in the context, say you don't know
and offer to connect them with a human."
→ generate response

The key detail most naive implementations get wrong: the fallback instruction has to be explicit and repeated, not just implied. LLMs default toward being "helpful" even when that means fabricating an answer. You have to actively fight that tendency in the prompt.

Confidence Thresholding

Beyond RAG, a second layer helps: score retrieval relevance before even calling the LLM.

python
results = vector_search(query, knowledge_base, top_k=3)
if results[0].similarity_score < THRESHOLD:
return fallback_response() # skip LLM call entirely
else:
return generate_with_context(query, results)

If nothing in the knowledge base is relevant enough, don't even give the LLM a chance to improvise — route straight to a human handoff or lead-capture form. This is cheaper (no wasted LLM call) and safer (zero chance of hallucination on that turn).

Graceful Handoff as a First-Class Feature

The failure path deserves as much engineering attention as the happy path:

Detect low-confidence turns and log them — this becomes your best source of FAQ gaps
Route to a lead-capture form or human contact instead of a dead-end response
Never let the avatar apologize and just stop — always give the user a next step
Why This Matters for Anyone Evaluating Third-Party Platforms Too

If you're not building this yourself and instead evaluating an embeddable AI avatar platform (there are several regional and international options — NemynAI, HeyGen, D-ID, etc.), this architecture is exactly what to probe for during a trial. Ask directly: is the AI scoped to a knowledge base, or is it a general-purpose LLM with a system prompt? What happens on a low-confidence match — hallucination, silence, or handoff? Most vendors won't volunteer this, but it's the single biggest technical differentiator once voice quality is no longer a distinguishing factor between platforms.

Takeaway

Hallucination prevention isn't a nice-to-have for customer-facing AI — it's the core engineering problem once you move past a demo. RAG with strict grounding instructions, confidence thresholding before generation, and a well-designed fallback path matter far more than which LLM or TTS provider you pick.

Reviewing the Tech Behind NemynAI's AI Avatar Widget

Алексей Невостребов — Sun, 02 Aug 2026 21:29:01 +0000

I spent some time digging into NemynAI (nemynai.com.ua), a Ukrainian AI avatar platform, mostly out of curiosity about how a smaller regional player architects this kind of product compared to the bigger names (HeyGen, Synthesia, D-ID). Here's what the stack looks like from a dev's perspective, based on what's documented and observable.

The Integration Surface

Two install paths are offered:

html

A JS snippet for any site — framework-agnostic, drops into any HTML page
A WordPress plugin wrapping the same widget in a config UI for non-technical setup

This is the standard pattern for embeddable AI widgets: keep the client footprint minimal (one script tag), and push all state/config management server-side behind an API key.

The Voice Layer

Voice synthesis runs through ElevenLabs, which has become close to a default choice for this category — low latency, decent multilingual support, and voice cloning available on higher tiers (NemynAI gates custom voice behind its "Business" tier at €69/month). Using a third-party TTS API instead of building proprietary voice models is the right call here: it lets a small team ship a competitive product without owning model training/hosting costs.

Pricing as a Proxy for Architecture

The tiered pricing (€9 text-only → €199 for 2,000 voice minutes) tells you something about the cost structure underneath: voice minutes are the expensive resource (TTS API costs scale with usage), while text-only chat is cheap enough to offer as a near-entry-level tier. This mirrors what you'd expect if LLM inference + TTS API calls are billed per-use on the backend — a common pattern in this category rather than something unique to this platform.

CRM as a Bundled Feature

Leads captured by the avatar flow into a built-in CRM automatically — a detail worth noting because it removes a common integration step (webhook to your own CRM/spreadsheet) that a lot of "just an AI chat widget" tools leave as homework for the business owner.

What's Not Publicly Documented

There's no visible public API reference or developer docs, which suggests this is currently positioned as a closed, no-code product rather than a platform meant for deeper technical customization. For teams needing to build custom logic around the avatar (beyond persona/voice selection), that's a real limitation worth checking on directly before committing.

Takeaway

NemynAI is a solid example of the current default AI avatar stack — LLM + ElevenLabs TTS + lightweight embed — differentiated mainly through language focus (Ukrainian) and ease of setup (plugin/snippet) rather than novel technology. Worth watching as a case study in how regional players compete against internationally-funded platforms: not on raw capability, but on language fit and simplicity of onboarding.

Streaming Isn't Optional: Lessons from Testing AI Avatar Widgets (Including Our WordPress Plugin)

Алексей Невостребов — Fri, 31 Jul 2026 20:53:32 +0000

When we were building the NemynAI WordPress plugin, the hardest engineering problem wasn't voice quality or avatar rendering — it was latency. Specifically, the gap between "the AI has an answer" and "the user hears it."

The Naive Approach (and Why It Fails)

The obvious implementation looks like this:

User sends message
Wait for full LLM response
Send full text to TTS
Wait for full audio generation
Play audio

This works fine in a demo. In production, with real network conditions and longer responses, it creates 2-4+ seconds of silence before the avatar says anything — long enough that users assume the widget is broken and either repeat their message or abandon the chat entirely.

What We Actually Built

For the plugin to feel usable on real customer traffic (not just office wifi during a demo), the pipeline needed to be streaming end-to-end:

LLM streams tokens
→ chunked at sentence boundaries
→ each chunk sent to TTS (ElevenLabs) as it's ready
→ audio chunks played back sequentially
→ lip-sync animation timed to each audio chunk

This means the avatar starts speaking on the first completed sentence instead of waiting for the entire response — cutting perceived latency dramatically even though total generation time is roughly the same.

Why This Matters More for a Plugin Specifically

A WordPress plugin adds its own constraints: it has to work across wildly different hosting environments, PHP versions, and client-side network conditions — not a controlled staging environment. We couldn't assume good bandwidth or a nearby CDN edge. The plugin's widget connects over a persistent WebSocket rather than polling, specifically to avoid the overhead of repeated HTTP handshakes per conversational turn, which matters a lot on slower shared hosting setups.

The Non-Obvious Lesson

Voice quality and avatar visuals get all the marketing attention, but they've become fairly commoditized — most platforms in this space (including ours) lean on similar TTS providers. The actual differentiator, especially for something meant to drop into any WordPress site with zero configuration, is how well the orchestration layer hides network and inference latency from the end user.

If you're building (or embedding) something similar: benchmark under realistic conditions — throttled connections, shared hosting, mobile networks — not your dev machine. That's where streaming architecture decisions actually pay off or fall apart.

Latency Is the Real UX Problem in AI Avatars, Not the Voice

Алексей Невостребов — Wed, 29 Jul 2026 21:21:42 +0000

Everyone evaluating AI avatar platforms focuses on voice quality. The bigger UX killer is almost always latency — and it's a harder problem than picking a good TTS provider.

Where the delay actually comes from:

User speaks/types
→ STT (if voice input)
→ LLM generates response (streaming helps, but first-token latency matters)
→ TTS converts text to audio
→ Audio playback + lip-sync rendering

Each hop adds latency. A naive implementation that waits for the full LLM response before starting TTS can easily hit 2-4 seconds of dead air — long enough for a user to assume the bot is broken.

How production systems actually solve this:

Token streaming into TTS — start synthesizing audio on partial LLM output (sentence-by-sentence chunks) instead of waiting for the full response
Speculative rendering — start lip-sync animation slightly ahead of audio using predicted phoneme timing
WebSocket/SSE persistent connections — avoid the overhead of repeated HTTP round-trips per turn
Regional API routing — TTS/LLM provider latency varies a lot by user geography; this matters more than most benchmarks show

A practical note: platforms that advertise "real-time" avatars but load all logic behind a single request/response cycle will feel noticeably worse than ones built around streaming pipelines, even if they use the identical LLM and TTS providers underneath. If you're evaluating a platform (or building one), test with realistic network conditions, not office wifi — that's where the architecture differences actually show up.

Bottom line: the voice provider matters less than people think. The orchestration around it — how aggressively you stream and pipeline each stage — is what separates a "wow" demo from a production-ready conversational agent.

Building AI Avatars: A Developer's Breakdown of the Stack

Алексей Невостребов — Mon, 27 Jul 2026 21:55:36 +0000

AI avatars — video/voice-based conversational agents — have moved from novelty demos to production features on business websites. If you're a developer evaluating whether to build one in-house or use a drop-in platform, here's a breakdown of what's actually happening under the hood.

The Core Pipeline

An AI avatar typically chains together three separate systems:

LLM / conversation logic — handles intent, context, and response generation. Usually GPT-class or Claude-class models via API, sometimes fine-tuned or wrapped with a RAG layer for business-specific knowledge.
Voice synthesis (TTS) — converts the LLM's text output into natural speech. This is where most of the perceived "quality" comes from. ElevenLabs has become a common default here because of low latency and voice cloning support, but alternatives like Azure TTS, PlayHT, and Cartesia are also viable depending on latency/cost tradeoffs.
Visual rendering — ranges from a static image with lip-sync animation to full video generation. Platforms like HeyGen and D-ID handle this via pre-trained avatar models; building this in-house is by far the most resource-intensive part of the stack.
Why Most Teams Don't Build This From Scratch

Unless avatar rendering is your product, replicating the visual layer isn't worth it. Most teams that want an "AI avatar" on their site are really solving a narrower problem: conversational lead capture with a more engaging UX than a text widget. For that, wiring up an LLM + TTS API behind a lightweight video/lip-sync layer (or using a third-party embed) gets you 90% of the value with a fraction of the engineering cost.

Integration Patterns

Two dominant integration approaches exist for site owners who don't want to build the pipeline themselves:

html

JS snippet — a single script tag that renders an iframe/canvas widget, handles the WebSocket connection to the backend, and manages session state client-side.
CMS plugin (e.g., WordPress) — wraps the same snippet in a plugin UI so non-technical users can configure persona, voice, and placement without editing template files.

Under the hood, both usually rely on a persistent WebSocket or SSE connection to stream partial LLM tokens to TTS in near real-time, minimizing the "thinking" delay that kills conversational feel.

A Regional Example

Worth noting as a case study: NemynAI (nemynai.com.ua), a Ukrainian platform, follows this exact pattern — LLM conversation layer + ElevenLabs for voice + a simple script/WordPress embed, with a CRM layer bolted on to capture leads server-side. It's a good illustration of how commoditized the underlying components have become — the differentiation isn't the tech, it's the language support, pricing, and UX polish around it.

Build vs. Buy Considerations

If you're deciding whether to build or embed a third-party avatar:

Factor Build in-house Use a platform
Time to ship Weeks–months Minutes–hours
Customization Full control Limited to platform's config options
Cost at low volume High (dev time) Low (subscription)
Cost at high volume Can be cheaper Scales with usage tiers
Data ownership Full Depends on platform's ToS

For an MVP or a lead-gen widget, buying almost always wins. For a core product feature where the avatar is the differentiator, building (or heavily customizing) makes more sense.

Takeaway

The AI avatar stack isn't magic — it's an LLM, a TTS API, and a rendering layer glued together with a real-time transport protocol. What's genuinely hard is orchestration (latency, interruption handling, session state) and product decisions (persona design, language support, CRM integration), not the individual components themselves.

The NemynAI WordPress Plugin: Add a Talking AI Avatar to Your Site in 2 Minutes

Алексей Невостребов — Thu, 23 Jul 2026 21:32:03 +0000

If you're running a WordPress site and want to add an AI-powered lead-gen assistant without touching a line of code, our NemynAI WordPress plugin is built exactly for that.

What It Does

The plugin embeds a talking AI avatar directly into your site — a bot that chats with visitors in Ukrainian, answers common questions, and captures leads automatically, 24/7. No custom widget building, no backend setup, no API wiring required on your end.

Installation
Install the plugin from your WP dashboard (or upload the zip manually)
Activate it
Connect your NemynAI account from the B2B dashboard
Pick an avatar persona and drop it live

That's it — under 2 minutes from install to a live avatar on your site.

Under the Hood
Voice synthesis powered by ElevenLabs for natural-sounding responses
Lead capture flows automatically into the built-in NemynAI CRM — every conversation becomes a tracked contact, no manual export needed
Telegram integration available on higher tiers, so leads/notifications can reach your team in real time
No conflicts with typical WP setups — it's a lightweight embed, not a page builder or heavy dependency
Why We Built It This Way

Most small business owners running WordPress don't want to manage API keys or write JavaScript. The plugin abstracts all of that away — you configure your avatar once in the dashboard (persona, voice, greeting, lead form fields), and the plugin handles rendering it correctly on the front end.

What's Next

We're working on expanding plugin-level customization — more control over widget placement, styling, and trigger conditions (e.g., show on exit-intent, after N seconds, on specific pages only) — for teams that want more than the default drop-in experience.

If you're running WordPress and want to test it, plans start at €9/month with a 3-day free trial — no voice minutes needed if you just want to try the text-only version first.

Embedding a talking AI avatar with one script tag — tried NemynAI, here's what's under the hood

Алексей Невостребов — Tue, 21 Jul 2026 23:15:49 +0000

Been exploring AI avatar widgets for a client project and wanted to share a quick find: NemynAI (nemynai.com.ua), a Ukrainian AI avatar platform aimed at businesses that want a chat/voice bot on their site without building anything custom.

Integration is dead simple:

One JS snippet, drop it anywhere in your HTML
Or a WordPress plugin if you're on WP
No SDK, no complex config — pretty much copy-paste

Stack (from what's documented):

Voice synthesis via ElevenLabs (so decent latency/quality out of the box)
Built-in CRM for lead capture — no need to wire up your own backend for that part
Telegram integration on higher tiers

Pricing tiers run €9–199/month depending on voice minutes needed (text-only vs. full voice + custom voice clone).

What I like as a dev: zero backend work required if you just want a lead-gen widget live in minutes. What's unclear: no public docs/API reference visible yet, so if you need deeper customization (custom logic, webhooks, etc.) beyond the widget, you might hit a wall.

Anyone else tested drop-in AI avatar widgets like this (vs. building your own via raw ElevenLabs + LLM API)? Curious if the "no-code" trade-off is worth it for MVP/lead-gen use cases vs. rolling your own.

Stop Optimizing the Wrong Part of Your AI Content Pipeline

Алексей Невостребов — Mon, 20 Jul 2026 20:30:00 +0000

Teams building AI content workflows tend to spend 90% of their effort on the generation step — better prompts, better models, fancier templates. That's usually not where the bottleneck actually is anymore.
Where time actually leaks:

Manually moving text from a chat window into a CMS
Manually sourcing/uploading images per article
Manually re-typing the same metadata fields every time
Publishing "whenever someone remembers to click the button"

None of that requires AI. It's just plumbing — and plumbing is the cheapest, most reliable thing to automate, because there's no judgment call involved.
Where you should not try to save time:

Fact-checking claims, numbers, dates
Making sure the piece actually reflects real expertise, not generic phrasing
A final human read before it goes live

That's the one step where automation quietly kills quality if you skip it, and it's also the step teams are most tempted to skip once the pipeline "just works."
Rule of thumb: automate everything mechanical, keep exactly one human checkpoint before publish, and don't confuse "the pipeline runs itself" with "the pipeline doesn't need anyone watching it."

The Content Pipeline Nobody Talks About: What Happens After AI Generates the Draft

Алексей Невостребов — Sun, 19 Jul 2026 23:12:49 +0000

A lot of AI-content discourse stops at "generate the text." That's actually the easy part now. The interesting engineering problem is everything after it.
The gap most teams miss: generation is a solved problem. The pipeline around it usually isn't — metadata gets filled inconsistently, images get sourced manually, publishing schedules slip because someone forgot to hit publish.
Where the real time savings live: not in the writing itself, but in closing the loop between draft and published, reviewed content. If your team is still copy-pasting AI output between a chat window and a CMS, you're doing manual work in exactly the spot automation is cheapest and easiest to build.
Where you shouldn't automate: the review gate. Whatever your pipeline looks like, keep one deliberate human checkpoint — fact-checking and adding real expertise — before anything goes live. That's the step that actually determines whether content performs, not how it was drafted.
If you're building internal tooling around this, the ROI order is usually: automate the plumbing first (formatting, scheduling, metadata), automate generation second, and never automate the judgment call at the end.

Why "AI-generated" Isn't the Real Question Anymore for Web Content

Алексей Невостребов — Fri, 17 Jul 2026 19:21:43 +0000

Most debates about AI content still frame it as a binary: human-written vs AI-written. That's the wrong axis in 2026.
The real question is where the human review happens — before publish or never.
Pattern that works: AI drafts, human edits for accuracy, adds real context/expertise, then publishes. This is genuinely fast — most of the time savings come from skipping the blank-page problem, not from skipping editorial judgment.
Pattern that doesn't: AI drafts, zero review, publish. This is where "AI content" got its bad reputation — not because generation is bad, but because the verification step got skipped.
For anyone building or maintaining a content pipeline (WordPress, headless CMS, whatever), the technical lesson is the same as any automation project: automate the repetitive part, keep a human checkpoint at the judgment part. Metadata, formatting, image sourcing — automate freely. Facts, tone, expertise — that's still a human gate, and skipping it is where quality (and rankings) actually break down.
The tooling around this has gotten genuinely good. The discipline around using it hasn't caught up yet for a lot of teams.