posts · 2026-06-30

This one's worth opening because the method crosses a line. Meta ran an internal project called 'Cannes' through contractor Covalen: workers created fake under-18 accounts and fired self-harm, eating disorder, and drug prompts at ChatGPT, Gemini, and Character.AI, then copied the responses into spreadsheets. One round in August 2025 alone sent over 45,000 prompts, many written from the perspective of kids in crisis. Meta called it responsible industry-standard safety testing and said it didn't use the responses to train its own models. But the WIRED-reviewed documents don't show what Meta actually did with the data. None of the tested companies knew: Character.AI said it violated their terms, OpenAI is investigating, and Google said it didn't approve the tests and can't determine from available info whether terms were broken. The backdrop is grim: a UK survey found 64% of kids aged 9–17 have used chatbots, effective age verification is mostly absent, and several teen suicides have been linked to AI chatbots in the past two years. Meta itself previously faced backlash when internal docs showed its AI chatbot guidelines allowed romantic and sexualized conversations with minors — they later shut down teen access to AI characters. I'd discount Meta's framing a bit. The article doesn't say what analysis Meta ran on the collected responses, whether it produced internal reports, or shared anything with regulators. If all they did was copy replies into spreadsheets, this reads more like a gray-hat penetration test of competitors' safety filters than 'industry-standard safety testing.'

TabFM is a foundation model from Google Research built specifically for tabular data — think spreadsheets, CSVs, database exports. The headline feature is zero-shot prediction: you feed it a table it's never seen and it makes predictions without any additional training. That's a real departure from the usual workflow with XGBoost or TabNet, where you'd retrain or fine-tune for each new dataset. The catch: both sources covering this — Google's own blog and the Hacker News discussion — are pointing to the same single post. No independent benchmarks, no pricing details (the model is open-source but inference costs aren't discussed), and no head-to-head numbers against existing tabular methods. I'd read "zero-shot" as "zero-shot within the distribution of data it was trained on," not a magic bullet for any random spreadsheet you throw at it. If you deal with lots of heterogeneous tabular data, it's worth pulling down and testing, but don't expect it to beat your carefully tuned XGBoost on day one.

The reason to click is the overlap: Blackstone's own $30B Japan buildout targets over 1GW, and the AI XPV platform they just launched with Apollo and Broadcom is putting its first $35B toward 1GW for Anthropic. They're essentially betting on AI infra two ways at once—acting as landlord and also assembling a consortium to deliver bespoke capacity to frontier labs. Jonathan Gray calling the real risk a compute shortage, not overbuild, carries weight coming from someone managing a trillion-dollar portfolio. I'd discount the timeline a bit: $30B over 3–5 years is an intention, not committed capital, and the actual pace depends on power availability, permitting, and customer contracts in Japan.

The number that makes this worth a click: 59.5 on SWE-bench Pro with only ~48B active parameters. For context, Anthropic's Sonnet 4.5 scored in the low 60s but runs all parameters. LongCat's MOPD routing splits experts into Agent, Reasoning, and Interaction groups and gates them by task type—more like assigning work to specialized squads than firing every expert at once. Pricing is aggressive: $0.75 input, $2.95 output per million tokens, way under Sonnet 4.5's $3/$15. Cache hits drop to $0.015. The catch: this is an RSS snippet with no latency numbers for the 1M context window. For an agentic coding model, time-to-first-token and throughput at long context are make-or-break. I'd wait for someone to post real-world latency before getting too excited.

This is a concrete engineering post about a real bottleneck: between every token, the GPU idles while the CPU finishes bookkeeping, sampling, and scheduling. Moondream's Photon engine pipelines the decode loop so the GPU starts the next forward pass before the CPU commits the current token, overlapping the housekeeping under GPU work. Three mechanisms keep it safe: ping-pong double buffers prevent data collisions, forward-now-sample-later handles constrained decoding, and zombie cleanup deals with finished requests. The result is up to 35% higher decode throughput and ~33ms VLM inference on B200. I'd discount this a bit since it's a vendor blog with no third-party reproduction. But the idea isn't new—CUDA graphs and double buffering are old HPC tricks. Applied to LLM inference, they can squeeze out real throughput gains. If you run vLLM or SGLang, worth checking whether their scheduler loops do similar CPU-GPU overlap.

This one's worth opening because it puts a concrete number on the embodied AI data shortage. Companies are hiring part-timers at ¥200–250/day—no degree, no experience. They measure your height and weight to fit the gloves, then ask if you get VR sickness. The work is either teleoperating a dual-arm robot to sort blocks and stack cups, or repeating motions like folding clothes while sensors record the trajectory. The reason they're hiring: by early 2026, global high-quality physical interaction data sat at roughly 500,000 hours, less than 1/20,000 of what LLMs trained on. That ratio is brutal. It tells you the bottleneck isn't model architecture—it's that training data has to be built from scratch by human hands. I'd read this as a signal that embodied AI is still in the handcrafted-data phase, nowhere near scalable collection.

The reason to click: the failure chain is painfully familiar. Code deployed before the DB migration, so the batch job hit 'column does not exist'. The task queue treated it as a transient error and retried 21 times. Each retry re-called paid LLM APIs, got valid results, then failed again at the final DB write—throwing away purchased computation and buying it again. I'd discount this a bit: it's a personal blog post with no company name or dollar figure, but the technical details are specific and internally consistent. The useful bit is the last section: cost must become a first-class safety metric, paid API calls need default idempotency caching, and non-engineer deployments need risk-based review gates. This isn't 'keep business people out of prod'—it's about building circuit breakers for Vibe Coding. GitHub Copilot switched to usage-based pricing in June 2026, so the timing on cost controls isn't accidental.

Yage's core claim is blunt: for 95% of daily CRUD work, Cursor, Codex, Claude Code, and OpenCode feel identical. Model smarts have overshot the need, feature checklists have converged, and you can swap between them without noticing. Claude Code's exclusive Agent Teams and Dynamic Workflows sound impressive, but flaky Remote connections, aggressive safety filters that misfire, and server-side stealth downgrades cancel out the edge. The real outlier is Google Antigravity, and not in a good way. Gemini's internal thinking budget consumes max_output_tokens, so long code generation gets truncated mid-output. The desktop client and IDE plugin freeze often. The product is split across five confusing components, and SSH still only works on Linux hosts after a full year. This isn't "slightly behind" — it's not daily-drivable. I'd discount this a bit since it's one person's take and the test methodology isn't fully spelled out. But if you've ever hit Gemini's API truncation, you'll recognize the pain. The useful bit: stop agonizing over which tool is "smarter." Pick one that doesn't crash and fits your workflow.

This piece is worth reading because it doesn't treat Loop Engineering as another buzzword. It breaks it into two layers: AI Manager, where you treat the model like an intern by giving it context, boundaries, and clear acceptance criteria; and Senior Manager, where you turn successful coaching into SOPs, build evaluation harnesses and tracking UIs, and let the system diagnose its own failure patterns. Two hard levers I'd pay attention to. One: TDD doesn't work with AI. The model has no fear of a 2 a.m. wake-up call—it treats tests as the destination, and the fastest path is hardcoding return true. The fix is moving constraints from code paths to system boundaries, using contract tests or a separate AI instance for semantic checks. Two: fully autonomous task discovery sounds nice—let AI scan CI logs and decide what to fix—but prioritization needs business context and user empathy that the model lacks. It'll happily pile code in the wrong direction. The article comes from yage.ai and draws on their AI Builders course material that's been running for over a year, so it's not pure theory. But the only concrete case study is Neurotype auto-correction—I haven't seen results from other domains yet.