One thing people building voice AI often overlook is how much information gets lost before the LLM even receives a transcript. Think about someone learning English. They'll pause mid sentence, pronounce words incorrectly, repeat themselves, or make grammatical mistakes. Now imagine your STT model quietly cleans all that up. The transcript might look great, but an AI tutor relying on it could completely miss what the student needs help with. That's why I found this benchmark from Fluently interesting. They tested real time speech recognition on low fluency English spoken by Chinese, Japanese, Korean, Thai and Vietnamese learners. And the differences between models are pretty significant. If you're building anything with voice AI, here's what I'd test before choosing a transcription model: - How well does it handle your actual user's accents? - Does it preserve hesitations, repetitions and grammatical mistakes, or quietly clean them up? - How often does it get important words wrong, especially negatives, names and numbers? - How well does it handle pauses, interruptions and spontaneous conversations? A low word error rate is useful, but it doesn't tell you everything about how well the model will work in your application. So we need to test speech recognition on the people who'll actually use your product, similar to the example of Dessa that I shared few days back.

Most MCP servers are just API endpoints wrapped as AI tools. And that's probably why some agents waste so many calls getting simple work done. If you're building an MCP server, here are 6 things worth thinking about: 1. Build tools around actual tasks. If an agent needs five API calls to investigate a failed payment, consider giving it one tool that gathers the relevant information. Let the server handle the predictable steps. 2. Don't make the model do your database's job. If you're returning thousands of records so the agent can find five matches, move that filtering into the tool. Return the matches and enough context to explain them. 3. Give the agent a way to investigate further. A summary is useful, but it shouldn't hide where the answer came from. Include relevant IDs, timestamps and references so the agent can inspect the original records. 4. Make failures recoverable. If a payment lookup fails because an invoice ID is missing, say exactly what's missing. Give the agent enough information to retry correctly instead of guessing. 5. Keep dangerous actions separate. Investigating a failed payment and issuing a refund shouldn't be the same operation. Let the agent investigate freely within its permissions, but enforce authorization and approval for sensitive actions. 6. Study what your agents actually do. Look at their tool-call traces. Where are they repeating searches, passing invalid parameters or fetching the same information multiple times? Those patterns tell you where your MCP design needs work. Here's an experiment worth trying: Take 20 real tasks from your agent's workflow and record the tool calls needed to complete each one. Find one sequence of 3–5 calls that keeps repeating. Build a new MCP tool that handles the predictable parts of that sequence internally. Now run the same tasks using the original tools and your new implementation. Compare: - How many tasks were completed correctly? - How many agent-level tool calls were needed? - How much context did the tool responses consume? - How long did the tasks take? If the new tool achieves the same or better results with fewer calls and less context, you've found a useful optimization. The interesting part of MCP engineering is deciding which work belongs inside a deterministic tool and which decisions actually need the model.

2B people scroll through Instagram daily and only 24M (1.2%) are categorised as influencers. And that 1.2% is just people who have more than 1000 followers and post 5 days a week. Rest are all consumers. What do you think that number looks like for X ?

REMINDER 🚨 Your employer doesn’t give a f*ck about you. Build your personal brand and business.

People were dissing about Terra that it should be removed. But I think Terra & Anthropic's Haiku will have a user base. Low end models need to find the right adaptive use cases. But yeah, it shouldn't be for these flashy video-graphic demoes. Hope this has a reasonable consumption of credits.

Just crossed 1800+ followers ! 200 away from 2k. We keep the community strong and circle of builders growing ! 🙌 Let’s connect if you are a builder in this space ! 🎃

If you're building an AI agent with memory, don't immediately reach for a vector database. First, figure out what you need it to remember. These 5 patterns solve different problems: 1. Use structured profiles for confirmed facts like a user's preferred language or a project's runtime. Save them in database fields the agent can look up by ID. 2. Use conversation summaries to carry decisions and unanswered questions into the next session. Keep the original messages available because summaries can leave things out. 3. Keep a task journal of what the agent tried, what failed and what worked. Before another attempt, it can check that history instead of repeating a failed approach. 4. Use retrieval memory when you have too many documents to load into every prompt. Search for relevant passages and include their sources so the agent can check them. 5. Use persistent files for scripts, notes and unfinished work. The next session can open the actual files and continue where the previous one stopped. Pick one thing your agent keeps forgetting and fix that first. If your agent forgets your project settings, save them somewhere it can read next time. If it needs to reuse a script, keep the file between sessions. You don’t need a vector database for either.

Post your heart out ! Your biggest fear is that someone will see how much you care and find it fucking ridiculous. So you reread what you wrote, remove the sentence that feels too personal. Add a joke so nobody thinks you’re taking yourself too seriously. Eventually, it’s safe enough to post. You’ve removed everything you wanted to say. The same thing happens with niches. At first, the niche helps people find you. Then, slowly, it becomes a character you have to keep playing. You post about the same topic, in the same tone, from the same angle. Not only because the algorithm rewards consistency, but because people have started to expect a certain version of you. And once people know you that way, breaking character can feel like letting them down. You wonder what will happen if you talk about something outside your niche. Will people unfollow? Will the post perform badly? Will they decide you’re no longer credible? Will the algorithm stop knowing where to place you? But underneath those questions is often something more personal… What if people see that I’m more than the image I built? So you edit yourself back into the role. You remove the story that doesn’t fit, turn the opinion into a lesson, make the post useful enough to justify its existence. Eventually, it’s safe enough to publish. You’ve removed everything that made it yours. I think this is why people stay trapped in their niche long after it stops feeling alive. The niche is no longer just a content strategy but a protective shell. If you stay predictable or keep speaking from the same position, nobody can question who you are. Then people praise you for being consistent. But consistency can quietly become self-abandonment. You’re allowed to talk about something that doesn’t fit neatly into your content pillars. You’re allowed to have interests your audience didn’t subscribe for. You’re allowed to change your mind, try a new voice, or post from a part of your life that doesn’t support the character you’ve been playing. You can keep parts of your life private. You can also let one honest sentence through without explaining why it belongs in your niche. Your audience may have found you for one thing. That doesn’t mean you have to remain only that thing. Let people meet you while you’re still changing.

Cloudflare's AI code reviewer flagged nearly 230,000 engineering violations. Almost 16,000 of those caused merge approvals to be withheld. Here's how they built it, and what you can steal for your own coding agents: 1. Maintain a shared, versioned engineering rulebook writing down your security, architecture, APIs, error handling, etc. 2. Separate recommendations (SHOULD) from mandatory rules (MUST). 3. Review rules before enforcing them. Cloudflare approves new rules first, then moves them into enforcement after teams have time to adopt them. 4. Load only relevant rules. Review architecture documents before anyone writes the implementation. 5. Use linters for mechanical checks. They're fast and predictable. Let AI handle the reviews that need context and judgment. 6. Review incident reports for missing timelines, detection signals and follow-up actions. Now here's something you can try with Claude Code or Codex today: - Ask your agent to inspect your repo, lint config, CI checks and architecture docs. - Have it propose 10 repo-specific MUST/SHOULD rules, with reasons. - Review and approve those rules yourself. Save them in AGENTS.md or CLAUDE.md. - Then have your agent review each PR against them, citing the exact file, line and violated rule. It's a pretty useful way to stop your coding agent from repeating the same mistakes across PRs.

In 2003, Dario Amodei the current CEO of Anthropic shared his Anti-war stance as a sophomore at Caltech. Do you think the company still stands by that spirit ?

I tried something different this week. Posted less, and focused on sharing things I genuinely find interesting and useful. One of those posts crossed 11K impressions. It's a small experiment, but it feels good knowing I can nerd out about things I love, help a few people along the way, and still reach an audience. Thank you to everyone who reads and supports my work. 🌻