u/aistranin

The most important part here is not the benchmark numbers. It is the shift in product logic.

If this approach scales, a huge class of AI products may no longer need an external orchestrator.

Live translation, pronunciation tutors, an assistant that comments on code while you type, workout rep counting, navigation for blind users - a lot of this is currently built with awkward pipelines and noticeable latency.

Here, interactivity becomes a property of the model itself.

The limitations are real too. Long sessions fill up context fast. You need a stable connection. The current checkpoint is not their largest model. Their bigger models are still too slow for realtime use.

But the direction looks strong.

This is not just "ChatGPT with voice." It is an attempt to build AI that does not only answer after you finish. It is AI that can be present in the moment.

Link: https://thinkingmachines.ai/blog/interaction-models/

X released an updated version of the For You algorithm on GitHub.

You can now look at how X builds and ranks the recommendation feed.

The repo xai-org/x-algorithm contains code for the system behind the For You feed, from candidate selection to final post ranking. There are two main content sources:

• posts from accounts you follow
• posts from the global corpus, found through ML retrieval

After that, everything goes through Phoenix, a transformer model based on Grok's architecture. It predicts the chance that a user will take actions like liking, replying, reposting, clicking, and other engagement signals.

The system then combines those signals into a final score and decides what gets shown in the feed.

Worth reading if you want to see which signals actually affect recommendations, how the ranking pipeline works, and where the platform filters content before showing it.

GitHub: https://github.com/xai-org/x-algorithm

A few years ago, I was leading a Python team with a large legacy codebase and uneven testing habits. We wanted more confidence, but the usual advice of "just write more tests" was not enough.

What helped most was weekly shared learning:

• 30-60 minutes discussing the next pytest/testing topic
• about 60 minutes of paired practice on real code
• rotating pairs so testing knowledge spread across the team
• focusing on small improvements instead of huge rewrites

The practice part was the key. It helped turn pytest from an individual skill into a team habit.

I wrote up a longer article about it if someone is curious https://www.istranin.dev/blog/onboard-python-team-pytest-testing-ci-cd/

Looking forward to your feedback and your thoughts on testing today, especially with AI-generated tests. Personally, I do not think AI is good enough yet to handle tests completely on its own instead of developers, but I have heard very different experiences, to be honest.

f you want a structured way to learn agent development without starting from random blog posts, Hugging Face has a free AI Agents course:

https://huggingface.co/learn/agents-course/en/unit0/introduction

It covers the basics first, then moves into actual frameworks and projects.

The syllabus includes:

• What agents are
• How tools, actions, and observations work
• Agent frameworks like smolagents, LlamaIndex, and LangGraph
• Agentic RAG
• A final project where you build, test, and certify an agent
• Bonus material on observability, evaluation, and function-calling

I like this kind of resource because it does not treat agents as just "LLM plus loop."

For junior devs, the useful concept is the agent control loop:

1. The model receives a goal and context
2. It chooses an action
3. A tool runs that action
4. The result comes back as an observation
5. The agent decides what to do next

That loop is the core of most agent systems. The framework changes, but the pattern keeps showing up.

If you are already comfortable with Python and basic LLM APIs, this seems like a good weekend learning path. Build the smallest possible agent first. Then add one tool. Then add logging. Then add a human approval step.

That progression teaches more than trying to build a giant "does everything" agent on day one.

Came across this article and thought it was worth sharing here: How to Build Production-Grade Generative AI Applications

It’s a good practical overview of what teams usually learn the hard way after the prototype phase. A few points it gets right:

• not every problem should use an LLM
• model selection should be based on task fit, latency, cost, context window, and safety, not just hype
• prompt engineering matters, but structured inputs/outputs matter just as much
• guardrails, QA, eval pipelines, and tracing are not “later” concerns
• production failures usually come from accuracy drift, hallucinations, cost, and lack of observability

What I liked most is that it frames GenAI systems as engineered products, not prompt demos. That maps well to agentic dev too: once agents can use tools and run longer workflows, monitoring, constraints, and evaluation become first-class design problems.

The new Stanford AI Index is out: 2026 AI Index Report

35B parameters, ~3B active thanks to MoE.

Key points:

• In agentic coding, it reaches the level of models with ~10× larger active parameter count
• Outperforms Qwen3.5-27B (dense) and the previous Qwen3.5-35B-A3B
• Natively multimodal architecture (text + vision)
• In VLM benchmarks, comparable to Claude Sonnet 4.5, and in some tasks performs better
• Strong metrics in spatial reasoning tasks

Benchmarks:

• MMMU - 81.7 vs 79.6
• MMMU-Pro - 75.3 vs 68.4
• MathVista - 86.4 vs 79.8
• RealWorldQA - 85.3 vs 70.3

Practical implications:

• MoE provides a multiple reduction in compute without sacrificing quality
• Well-suited for agent-based scenarios where sequential actions and planning matter
• Can be used as a unified stack for both code and vision tasks

Apache 2.0 (no restrictions for production use)

https://huggingface.co/Qwen/Qwen3.6-35B-A3B

Source: https://www.anthropic.com/news/claude-opus-4-7

Robotic Process Automation (RPA) in testing refers to the use of “software robots” to mimic and repeat the actions that human testers perform when interacting with an application.

Is RPA the same as an automated testing script? No - RPA is not the same as automated testing scripts. It uses the UI to mimic human actions and execute workflows, while automated testing scripts programmatically verify that software behaves correctly.

• RPA = “Do what a user does”
• Test automation = “Check if the system behaves correctly”

According to https://testfort.com/blog/test-automation-trends, RPA adoption in testing is expected to grow significantly as organizations use it to reduce manual labor costs and scale testing efforts alongside AI-driven automation. Something to look after in the industry 👀

My experience coding with AI has never been like 10× faster (more like 0.8× hehe). Sure, AI copilots can generate OK looking code, but for me it has mostly been a waste of time. The tech debt is leveraged, learning is slower, and you often end up spending more time fixing things than if you had just written the code by hand much more simply (without AI).

I tend to see more benefits from AI code generation when it’s used with Test-Driven Development (TDD), at least when starting with end-to-end or integration tests first. I also shared my thoughts on this on YouTube: https://youtu.be/Mj-72y4Omik

Some developers argue that TDD is too slow and that you should focus on end-to-end tests (writing them manually) and let AI generate unit tests. That kind of works. But when it comes to learning Python (especially for beginners), I see a lot of frustration from overusing AI. TDD seems like a nice approach to avoid just relying on AI.

What do you think?