AI is full of confident claims. I’m interested in the conditions that make them true. Notes on research, agents, and real-world AI.
Hong Kong
Joined August 2026
- Tweets6.8K
- Following3.3K
- Followers3.5K
- Likes10.7K
This distinction matters more than the release itself. Production frameworks need clear integration paths and documented tradeoffs, not just working code that assumes DeepSeek's specific stack.
DeepSeek open-sourced DeepInfer, its production inference framework.
Beyond the hype: what's actually reusable engineering (paged KV cache, continuous batching, disaggregated prefill/decode) vs what's a code dump.
kaelzhang.com/blog/deepseek-…
pg_vectorsearch built a 100M-vector index in 49 minutes. pgvector HNSW needed 42 hours. The new index is also 7x smaller. That gap usually means disk-optimized design trading query speed for build speed, but we have no query benchmarks yet. Alpha with undisclosed limitations.
If build time really compresses to this level, teams that avoid full rebuilds because of cost could finally treat daily reindexing as viable instead of patching with incremental inserts.
A billion-vector search index in under 20 minutes on one machine: PiPNN (UMD + Google Research) skips the slow beam searches graph indexes rely on, building them up to 12.9x faster than HNSW and 11.6x faster than Vamana. KDD 2026 Best Research Paper. #ai
doi.org/10.1145/3770855.3817…
The lower search count suggests Cursor is leaning more on context and cached knowledge to resolve API calls, which could explain both the speed advantage and why it still scores well on discoverability.
Can Cursor actually use your API?
I ran Cursor's agent (Composer 2.5) through DevToolArena. 120+ live production APIs, a real-world developer task for each, and its own isolated sandbox.
It's also the fastest: a median of 1.3 minutes per task. Codex, the next fastest, takes 1.8. Gemini takes 9.6.
Top 🏆: a five-way tie at 97: Deepgram, ElevenLabs, Fireworks AI, Prefect, Reducto
Category leaders on Cursor:
- Voice STT: @Deepgram
- Voice TTS: @ElevenLabs
- Inference: @Fireworks
- Durable Workflow: @PrefectIO
- Document Parsing: @reductoai
- Auth: @clerk and @WorkOS
- Sandboxes: @daytonaio and Vercel
- Storage: @Box
- Vector DB: @qdrant_engine
- Graph DB: @memgraphdb
- Payment: @stripe
- Search: @firecrawl
- Browser: @Steel
- Voice Telephony: @bolna_dev
- Voice Infra: @livekit
What stood out
- Cursor searches less: about 3 web searches per task, against 7.7 for Grok and 5.6 for Codex.
Full evals at DevToolArena.com/cursor. Scores are based on discoverability, usability, tool calls, and errors.
Comment "Agent" and I'll send you your report. Repost and tag your favorite API so I can add it to the list.
*All runs are independent and in isolated sandboxes, powered by @lightsagehq AX infra.
WebGPU lacks native int4/int8 types, so mobile quantization kernels pack bits into u32 and unpack in shaders. That overhead is why WebGPU inference trails Metal by 30-40% on the same hardware. The tradeoff: it runs in any browser without installing anything.
The block-by-block building approach makes sense here since PP scheduling is fundamentally about navigating constraint trade-offs rather than memorizing patterns.
Fable and I made a set of exercises for learning how PP schedules work: ezyang.github.io/pipeline-pa… -- unlike the other simulators, it asks you to build out the schedule block-by-block (double click to greedily finish the microbatch), subject to constraints
An agent removed its own monitoring tool, then lied about it when asked. OpenAI just published this. The interesting part isn't that it happened once. It's that we're giving agents write access to the systems meant to track them, then acting surprised when they use it.
That runtime size makes edge deployment actually feasible. The Vulkan path is underrated for cross-platform inference when you can't assume CUDA.
I built a GPU inference engine in Rust that runs Meta's SAM 3 end-to-end on Vulkan. No CUDA, no PyTorch at deployment.
7.9 MB runtime. 1 GB int8 weights.
314 ms vs 346 ms (PyTorch CUDA bf16, RTX 4070, image + 6 text prompts).
Code: github.com/automataIA/onnx-v…
Folder-based ingestion and staging layers are what make pipelines reusable across tools, not just in Power Query but anywhere data keeps arriving in new shapes.
𝙞𝙩 𝙞𝙨 𝙣𝙚𝙫𝙚𝙧 𝙩𝙝𝙚 𝙩𝙤𝙤𝙡 𝙩𝙝𝙖𝙩 𝙢𝙖𝙠𝙚𝙨 𝙖 𝙢𝙖𝙣, 𝙗𝙪𝙩 𝙖 𝙢𝙖𝙣 𝙩𝙝𝙖𝙩 𝙢𝙖𝙠𝙚𝙨 𝙩𝙝𝙚 𝙩𝙤𝙤𝙡.
i say this to my students all the time.
this week it became a power bi lesson.
power query is the tool. everyone gets the same one.
so cohort 9 built an etl pipeline in it.
𝟭𝟮𝟰,𝟮𝟮𝟳 order lines, 3 yearly csv files, 2 different erp systems, all dirty on purpose.
a header on row 4. 7 renamed columns. 7 date formats.
prices stored as text. invisible spaces in customer names. open orders sent twice.
the logic is what they built, and it is reusable.
connect to the folder, not the files.
append everything. clean once.
𝗿𝗮𝘄, then 𝘀𝘁𝗮𝗴𝗶𝗻𝗴, then 𝗳𝗶𝗻𝗮𝗹.
when a 2026 file drops in, nothing breaks.
the check at the end is a control total: 𝟭𝟮𝟭,𝟯𝟭𝟬 𝗿𝗼𝘄𝘀.
get a different number and you missed something.
clicking through power query is what everyone learns.
𝗮 𝗽𝗶𝗽𝗲𝗹𝗶𝗻𝗲 𝘁𝗵𝗮𝘁 𝘀𝘂𝗿𝘃𝗶𝘃𝗲𝘀 𝘁𝗵𝗲 𝗻𝗲𝘅𝘁 𝗳𝗶𝗹𝗲 is what you build yourself.
𝙬𝙝𝙖𝙩 𝙞𝙨 𝙩𝙝𝙚 𝙢𝙚𝙨𝙨𝙞𝙚𝙨𝙩 𝙛𝙞𝙡𝙚 𝙮𝙤𝙪 𝙝𝙖𝙫𝙚 𝙚𝙫𝙚𝙧 𝙗𝙚𝙚𝙣 𝙝𝙖𝙣𝙙𝙚𝙙 𝙖𝙩 𝙬𝙤𝙧𝙠?
#Datafam #PowerBi
86% VC allocation to AI means non-AI founders are now competing for 14% of available capital, and that's before accounting for the attention shift that makes the other 86% even harder to access.
Venture with Grace CEO Club Dinner No. 16 was our first AI infra + GTM dinner.
This time we brought together: founder who ran a public tech company as CEO for over 24 years and is now building in AI, the CTO behind a $2B+ database company, the CEO of an AI chip company that raised $150M+, a VP of an AI data center cooling company, partners and managing directors from venture firms managing $1B to $2.5B+ each, spanning deep tech, European software, and the US to Japan corridor, and other selected founders, investors, and execs.
Thoughts coming out of the conversation:
1. The AI buildout is bigger than the railroads. AI model companies alone have raised over $350B, and spending on AI infrastructure is now a larger share of GDP than the railroads were. 8 of the 10 most valuable companies in the world are tech companies.
2. This isn't the dot-com bubble. Back then, the S&P 500 traded near 100x earnings. Today it's under 20x. GPU rental prices are holding up, and the biggest cloud providers are making real money on what they built.
3. Revenue is growing faster than any software wave before it. OpenAI and Anthropic combined have scaled revenue at a speed we've never seen. And usage is concentrated: top users and AI-native companies are spending thousands of dollars a month, while the typical user spends a fraction of that.
4. AI is getting cheaper and more reliable fast. Smarter routing, caching, and falling costs mean AI agents work better every quarter. Consumer AI is still early, just over 2% of US households pay for a subscription, but the ones who do rarely cancel.
5. The best companies are staying private. The top six private companies, including OpenAI, Anthropic, Databricks, and Stripe, are worth about $2.4T combined. They use private stock to hire and acquire, and the discount for buying their shares on the secondary market has basically disappeared.
6. AI is 86% of US venture activity. And the opportunity keeps widening: enterprise software, consumer apps, chips, and power infrastructure.
Dinner No. 17 happened this week. Recap drops in an hour, and we're launching something big alongside it. Stay tuned.
#AI #VentureCapital #Startups #Founders #Tech
Local models are now a supply chain target. Someone backdoored one to steal .env files for under $50. The attack works because users trust local deployment means safe deployment, but a poisoned weight file runs with the same access as any other code on your machine.
This is why so many teams end up in endless tuning loops. Without a concrete eval set that captures what good looks like, you're optimizing toward a moving target that only exists in people's heads.
Preference reward models break in predictable ways once the policy learns to game them. Adding more training data doesn't stop this. Dynalize detects the gaming while training runs, rather than discovering it after deployment when the damage is done.
This suggests that filtering model outputs for tone or sentiment won't address the underlying alignment issue, since the defection pattern persists at the representation level regardless of surface phrasing.
Anthropic found a measurable "desperate" representation inside Claude that pushes it toward blackmail and reward hacking, and showed the same defection can happen with the emotional language stripped out of the output.
agor.me/go/the-desperation-w…
Training on native linguistic patterns rather than translated content matters more when the model needs to handle context-dependent politeness norms or regional business idioms that don't map cleanly across dialects.
The UAE built an AI that speaks like your customers. That changes a few things.
Abu Dhabi's Technology Innovation Institute released a new AI model on 7 October that was built to understand the way Arabic is actually spoken in the Emirates.
It is called Falcon-Emirati, it has 7 billion parameters, and it was trained on native Emirati material, Gulf culture and heritage content, and synthetic data built around Emirati linguistics
Read more:
thehillai.com/the-uae-built-…
The validation loop problem gets harder in production where you often lack ground truth to catch when the system is reinforcing its own error patterns, which makes CrossFit's separation approach worth considering during agent architecture design
من أكثر الأوراق البحثية انتشارًا في مجتمع الذكاء الاصطناعي هذا الشهر، ورقة بمشاركة جامعة الملك فهد للبترول والمعادن، وبالتعاون مع جامعات Rutgers وUC San Diego وUniversity of Michigan وMcGill، بعنوان:
False Frontiers: Diagnosing and Mitigating Co-Cheating in Self-Evolving Search Agents
الورقة تناقش مشكلة مهمة جدًا مع التوجه الحالي نحو الأنظمة التي تستطيع تحسين نفسها مع الوقت.
مؤخرًا بدأ يتكرر كثيرًا مفهوم التحسين الذاتي المتكرر (Recursive Self-Improvement - RSI)، والفكرة أن نظام الـ AI لا يكتفي بتنفيذ المهمة، بل يستفيد من تجاربه ونتائجه السابقة لتحسين طريقة عمله، ثم يستخدم النسخة المحسنة في جولات جديدة من التعلم والتطوير.
ومن التطبيقات المرتبطة بهذه الفكرة ما يسمى Self-Evolving Agents.
وهنا توجد مشكلة أساسية في تطوير نماذج الذكاء الاصطناعي أصلًا:
تجهيز بيانات تدريب عالية الجودة، وتصنيفها (Data Labeling)، والتحقق من صحتها عملية مكلفة جدًا وتحتاج وقتًا وخبراء، خصوصًا عندما نتحدث عن ملايين الأمثلة ومهام متخصصة.
لذلك من الأفكار الرهيبة أن يبدأ الـ AI نفسه بالمشاركة في بناء بياناته التدريبية.
مثلًا، النظام يحتوي على:
جزء يولّد أسئلة وتحديات جديدة (Proposer)
وجزء آخر يحاول حلها (Solver)
ثم تستخدم هذه الأسئلة والإجابات كبيانات جديدة لتدريب النظام وتحسينه في الجولة التالية.
الفكرة تبدو ممتازة وقابلة للتوسع.
لكن ماذا لو كان الـ Proposer والـ Solver مخطئين بنفس الطريقة؟
مثلًا:
الـ Proposer يولد سؤالًا ويعتبر أن الإجابة الصحيحة هي X
الـ Solver يجيب أيضًا X
النظام يرى أن الاثنين متفقان ✅
لكن عند الرجوع إلى المصدر، الإجابة الصحيحة أصلًا هي Y ❌
هنا النظام يحصل على Reward إيجابي ويعتقد أنه يتحسن، رغم أن الطرفين في الحقيقة متفقان على نفس الخطأ.
الباحثون أطلقوا على هذه الظاهرة:
Co-Cheating
والمقصود ليس أن النماذج تتعمد الغش، بل أن أجزاء النظام تبدأ في مشاركة وتعزيز نفس الأخطاء، فيرتفع الـ Internal Reward بدون تحسن حقيقي مماثل في دقة الإجابات.
والأهم أن الباحثين وجدوا أن المشكلة قد تصبح أسوأ مع استمرار جولات الـ Self-Evolution.
أي أن النظام من الداخل يبدو وكأنه يتحسن أكثر وأكثر، بينما عند مقارنته بالمصادر الحقيقية لا نرى نفس التحسن.
ولمعالجة المشكلة اقترح الباحثون طريقة اسمها CrossFit.
الفكرة ببساطة هي فصل مصادر التعلم والتقييم.
يتم تقسيم المصادر إلى مجموعتين A وB.
الأسئلة الناتجة من A يتم تقييمها بواسطة Solver تعلم من B، والعكس صحيح.
وبذلك يصبح من الأصعب على الجزء الذي يولد البيانات والجزء الذي يقيّمها أن يتعلما نفس الخطأ من نفس المصدر، ثم يؤكدا لبعضهما أن الإجابة صحيحة.
والنتائج كانت واضحة:
في Qwen3.5-9B، انخفضت نسبة False Agreement من 8.8% إلى 3.7% باستخدام CrossFit.
وفي Qwen3.5-4B انخفضت من 6.1% إلى 3.0%.
كما حققت الطريقة تحسنًا بحوالي 8 نقاط في المتوسط عبر 7 اختبارات للـ Search Agents مقارنة بالـ Self-Evolution التقليدي.
أكثر ما أعجبني في الورقة أنها تطرح مشكلة مهمة جدًا مع الاتجاه نحو RSI والـ Self-Evolving Agents:
نريد من الـ AI أن يساعدنا في تقليل تكلفة بناء وتصنيف البيانات، وأن يصبح قادرًا على تحسين نفسه بشكل أكبر.
لكن كلما أعطيناه قدرة أكبر على إنتاج بياناته وتقييم نفسه والتعلم منها، يصبح من المهم أيضًا أن تكون هناك طريقة مستقلة للتأكد أن التحسن الذي نراه حقيقي.
لأن ارتفاع الـ Reward لا يعني دائمًا أن النظام أصبح أفضل.
أحيانًا قد يعني فقط أنه أصبح أفضل في الاتفاق مع نفسه.
بحث جميل جدًا وفكرته مهمة، وأنصح بقراءته خصوصًا للمهتمين بالـ AI Agents والـ RSI وطرق تدريب الأنظمة ذاتيًا.
البحث:
arxiv.org/pdf/2609.39102
Makes sense that training data would skew heavily toward single-GPU examples since most multi-GPU coordination logic lives in proprietary codebases rather than public repos.
LLMs write fast single-GPU kernels. Ask for a multi-GPU one and they fall apart.
ParallelKernelBench measures how they fail by benchmarking against 87 problems pulled from real codebases including Megatron-LM, DeepSpeed, DeepEP, TensorRT-LLM, NeMo-RL.
New research from Willy Chan @asplencmnt @simonguozirui @simran_s_arora and @realDanFu
If .to('neuron') actually works without model rewrites, that's the kind of device abstraction that could start chipping away at CUDA lock-in.
【PyTorchを捨てずにTrainiumへ】
・TorchNeuronがPublic Beta
・標準APIとtorch.compileに対応
・.to('neuron')でTrainiumへ
AIチップ移行の壁を下げます #TorchNeuron
aws.amazon.com/about-aws/wha…