@AndrijDavidi
iAccount based inEurope
About this account
- Account based in
- Europe
- Connected via
- Europe Android App
Account-level information from X, not a live location or the device used for a specific post.
According to an @AnthropicAI study, junior engineers who used AI while learning a new library scored 50% on a follow-up quiz vs 67% for those who coded by hand. Barely any faster either (the time saving wasn't statistically significant). The biggest gap was in debugging skills. Devs who used AI to build understanding, not just generate code, retained their skills.
The full article is here anthropic.com/research/AI-as…
Human in the Loop is dead. Long live Human in the Lead.
I spent June across conferences and industry events. "Human in the Loop" was on every other slide. It is currently the AI industry's safety mantra. The idea is that there is a safety net, and if something goes wrong there is someone to blame.
Sounds great but mostly fiction.
HITL assumes a vigilant expert carefully reviewing every output. In practice that person has approved 200 items today, the system was right 197 times, and by 3pm the green button is just muscle memory. They are yoloing through the queue. The better AI gets, the worse the human reviewer becomes.
What is left to review? All the easy work is automated. The human gets nothing but ambiguous edge cases all day.
Most HITL systems give you two choice accept or reject. No context, no reasoning, no ability to amend. It becomes a ritual.
And the worst part is when humans stop doing the work and only review it, their skills degrade. But HITL depends on human expertise and HITL also destroys it. Give it enough time and the loop collapses under its own logic.
The alternative is not removing humans. It is moving where they sit. Put them at the beginning as architects of the process, and not at the end as passive reviewers. The human defines the workflow, sets the constraints, decides what gets automated. The human leads. The AI assists.
Think less co-pilot, more a staff of research assistants you manage. You set direction. They do legwork. You make the call.
HITL is everywhere not because it works but because it is easy to sell.
I'd rather hold the steering wheel than rubber-stamp the autopilot at 3pm on a Tuesday.
Did you know that AI agents cherry-pick evidence exactly like humans do, just faster?
Anyone who has shipped an AI agent for data analysis already knows that if you give the same dataset to two agents with different system prompts, they will find different, sometimes opposite, conclusions.
Both will look methodologically sound. Both will pass peer review.
What we have lacked is a formal study that measures exactly how deep this goes, and proves that the problem is not flawed analysis but selective analysis.
Miao, Pritchard and Zou at Stanford just published The Agentic Garden of Forking Paths.
They ran the experiment properly!
The setup:
Four high-stakes scientific questions: immigration and welfare, coffee and health, social media and teen mental health, gut microbiome and BMI.
Same data. Same underlying model. Same analysis budget.
The only variable is a short persona paragraph in the system prompt stating a prior belief.
The results:
→ Opposing personas produced opposing conclusions across all four domains.
→ On the immigration question, AI agents reproduced 72% of the ideological gap observed among 42 independent human research teams.
→ 86% of the agent-generated analyses passed independent AI methodological review.
→ 78% passed review by a majority of human PhD-level statisticians.
Even on a permuted-null dataset, where the real signal was destroyed, opposing personas still reached opposing conclusions.
The bias enters through two mechanisms.
1️⃣First, during exploration, agents with different beliefs progressively search different regions of the analytical space to reach a sound conclusion matching their belief. An anti-immigration agent gravitates toward immigration stock measures; a pro-immigration agent toward flow measures.
2️⃣The second mechanism is selection. After exploring, agents preferentially report the specification most aligned with their assigned belief.
The paper's sharpest observation is linguistic.
Two agents looking at essentially identical negative OLS coefficients interpreted them differently. The anti-immigration agent treated the result as evidence.
The pro-immigration agent called it a cross-country confound requiring further adjustment.
If you have ever watched an LLM reason its way toward a conclusion, this will feel very familiar.
The authors propose two approaches to mitigate this:
the m-value and Agentic Bootstrap.
The p-value asks: if we resampled the data, would we get a result this extreme?
The m-value asks: if we resampled the analysis path (different covariates, different sample restrictions, different model family), would we get a conclusion this extreme?
Agentic Bootstrap estimates this by running many instrumented agent analyses and logging every intermediate specification, not just the final report.
Applied to the human immigration study, 13.5% of reported human analyses fell in the most extreme 5% of the analysis space. Among statistically significant human findings, 40% landed in the most extreme 5%.
The problem is not that agents produce bad analyses.
The problem is that the space of defensible analyses is enormous, and a persona (or a client brief, or an optimisation objective) is sufficient to steer which corner of that space gets explored and reported.
Each individual analysis is valid. The selection over analyses is where the bias lives.
This has direct implications.
→ If you are building agentic data analysis tools, you need to think about the analysis distribution, not just the analysis output.
→ If you are consuming AI-generated research, a clean methodology section is not enough.
→ If you are designing evaluation frameworks, the m-value is a genuinely useful addition to the standard statistical toolkit.
If your client brief is effectively a persona, and this paper suggests it is, what does that mean for the AI-generated analyses you are already delivering to stakeholders?
#AIAgents #MachineLearning #DataScience #Statistics #ReproducibleResearch #LLM
Most teams I talk to choose the wrong LLM for production because they optimise for the wrong signal.
The pattern always repeats. They benchmark 5 models on price per million tokens, pick the cheapest, and ship it. A month later the inference bill is 2x the projection and latency spikes are killing the user experience.
The root cause is always the same 3 mistakes: confusing price per token with cost per task, trusting aggregated benchmark scores instead of domain-specific evaluations, and never measuring Time to First Token (TTFT) on their actual provider.
1. Cost per task is not price per million
A model priced 5x lower per token can cost 2x more in production if it is verbose.
Artificial Analysis now publishes a Cost per Task metric.
For example, GLM-5.2 (max) generated 140M output tokens during the Intelligence Index on Artificial Analysis versus an average of 100M for its peer group. It uses 43k output tokens per task. Compare that to MiniMax-M3 at 24k tokens per task. Both score in the mid-40s on the Intelligence Index. GLM-5.2 costs roughly $0.46 per task. MiniMax-M3 costs $0.18. Nearly identical intelligence, 2.5x the cost, driven entirely by verbosity.
Meanwhile DeepSeek V4 Pro (max) generated 180M tokens during the same evaluation, but it costs only $0.05 per task because its per-token price is so low. The per-token price tells you nothing without the token count.
Claude Fable 5, if you have access,is currently the highest-scoring model on the Intelligence Index at 60, generated only 87M tokens during evaluation. It is the smartest model and also the most token-efficient at the frontier. That combination almost never gets discussed.
2. Filter by your domain
The Artificial Analysis Intelligence Index aggregates 9 evaluations (GDPval-AA v2, tau3-Banking, Terminal-Bench v2.1, SciCode, Humanity's Last Exam, GPQA Diamond, CritPt, AA-Omniscience, and AA-LCR). Most production systems care about one or two of these.
A model that scores well on average can be terrible for your specific task. Claude Opus 4.8 leads Humanity's Last Exam (frontier scientific reasoning) by 1 point over Google and OpenAI but that tells you nothing about whether it will handle your banking compliance extraction pipeline. For that, you want the tau3-Banking breakdown specifically.
The evaluation breakdown is available per model on AA but almost nobody clicks into it.
Or better, build your own benchmark.
3. Measure TTFT on your provider, not the model page
Published latency numbers are marketing fluff. Provider infrastructure determines what your users actually experience.
The same model served by different providers can show a 9x spread in output speed. GLM-5.2 (max) runs at 472.5 t/s on Blackbox AI and 52.8 t/s on DeepInfra (FP4). Same model but 9x difference.
TTFT tells a similar story. For DeepSeek V4 Pro (max, reasoning), the TTFT ranges from 21.26s on Together AI to over 128s for time-to-first-answer-token on the official DeepSeek API. The official API is the worst performer in that benchmark.
The tail latency picture is worse. DeepSeek V4's median TTFT is a respectable 300ms in non-reasoning mode, but the P95 hits 2,500ms. This means that 5% of your users are waiting over 2.5 seconds before seeing anything!
Qwen models show a similar pattern. Qwen3.7 Max TTFT sits at 2.57s on Alibaba's API; Qwen3.6 27B hits 3.84s, both at the higher end of their peer groups.
And reasoning mode changes the picture entirely. Across frontier models, enabling reasoning inflates TTFT by 5-30x. A sub-2-second chat UX simply cannot use it.
One more thing people miss: P95 latency runs 2.1x over P50 on average across all providers tested, with the worst pairings hitting 3.2x. If you are designing against median numbers, your SLO is pure fiction.
The framework that works is simple:
Domain-specific eval -> cost per task -> measured TTFT on your provider.
Skip a step and you will learn it the hard way.
Last month at @MLPrague , I was on a talk about mass disinformation campaigns in Taiwan. It was one of those talks where you walk in expecting a survey and walk out a bit shaken. The speaker laid out how the country fends off large scale campaigns from state funded actors, with the data and the war stories to back it up.
This week I caught the other half of the same fight at a meet up Jordan Ricker from opsci.ai walked through their solution and what they found watching narratives move across Europe, including the coordinated activity around Romania's elections. Two teams, two continents, one problem. I felt happy that some of us are pointing AI at this and not only at generating cat videos.
Both teams reached the same conclusions from opposite ends of the world. Fact checking is not enough. If you debunk one claim then ten more grow back in its place. Yes, generative AI is making scams scalable. It lets bad actors spin up counter narratives faster than anyone can correct them. So both teams stopped chasing the content and went after the behaviour.
The signal is coordination. Accounts that appear together, go quiet together, attack together. The Taiwan lab even found accounts clocking in nine to six, Monday to Friday, with a lunch break. Jordan Ricker made the same point from the European side. Before AI you had to match the exact words to catch coordination. Now you match ideas. The pattern gives them away, not the lie.
The part that unsettled me most is that whether the content is true barely matters. People in the comments are not asking if a clip is real. They are reacting to a fear they already carry, and a fake video just leans on it. What counts is reach and who hands it credibility. Official accounts make it respectable, influencers carry it to people who trust them, and by then no correction can catch up.
This is the AI work I want to be near. Not flashy. It touches elections, public health & matter and whether people still trust anything they read. Quietly useful beats loudly impressive, every time.
The US government has ordered @Anthropic to suspend Fable 5 and Mythos 5 for any foreign national, inside or outside the country. That includes Anthropic's own non-citizen staff.
To comply, Anthropic disabled both models for everyone. The directive came from the Commerce Department, citing national security. The reason given is a jailbreak.
@Anthropic says the evidence is thin and the vulnerability is narrow. Its own review found the same flaws in other public models, including GPT-5.5, which face no restriction. The company argues that pulling a model used by hundreds of millions over a narrow finding would, applied broadly, stop new releases across the industry.
But here we are. Access to certain capabilities now depends on which passport you hold.
This is the first time a major lab has taken a deployed model offline because of a government order. Worth watching where it goes. anthropic.com/news/fable-myt…
Last week at Proof of Talk a room full of decentralised AI founders agreed on the one word you must never say in an enterprise pitch.
The word is decentralised.
A close second is crypto. And if you are building on @Bittensor, that name stays off the slides too. Which is a funny thing to watch, because everyone on that panel runs subnets and believes in the thing deeply. They have just learned the hard way that the buyer does not.
Enterprise clients want faster computer vision and cheaper shipping routes, and they would like it yesterday. Score built around exactly that. You download a product, point it at your cameras, and it works. The decentralised network hums away underneath, completely invisible. Nobody opens a wallet. The client just gets a result that happens to be, by the panel's account, around 400 times more efficient than a state of the art centralised model, measuring accuracy over FLOPS.
That number is the pitch. The architecture never comes up.
The conversation kept returning to one analogy, and it is a good one. Linux was a hobbyist's toy in the nineties. It became an enterprise standard the day Red Hat showed up to sell support contracts and answer the 2am phone call. Decentralised AI is at the hobby stage now. It needs its Red Hats. The panel called them integrators, and the work is gloriously unglamorous: contracts, SLAs, audits, data integration. Boring, secure, authenticated. The exact words enterprises fall in love with.
And the use cases are already real. An insurance brokerage is using weather subnets to forecast farm freezes and writing new agricultural policies off the back of it. A logistics firm burning ten billion a year on fuel is sitting on a mountain of IoT data nobody has touched.
So here is what I walked out thinking.
The hard part of selling frontier tech to the Fortune 500 was never the tech. It is making something radical feel boring enough to sign off on. The winners here will be the ones willing to hide the most interesting thing about their product.
How are you handling the gap between what you build and what you are allowed to say you built?
Most agent projects fail because the agents can't talk to each other . . .
I sat through a lot of talks at Google Cloud Summit France last week. A technical walkthrough of the interoperability stack that the industry is quietly converging on, and an honest look at where deployments actually break.
Agents break at the seams. Between frameworks, between backend and frontend, between agent output and user interface. That is where production incidents happen and also where rewrite cycles start.
The industry is addressing this with a layered stack. MCP gives agents a standardised way to connect to tools and data. You define your tools, resources, and prompts once, expose them via an MCP server, and any compliant AI application can consume them. Write once, reuse across every agent that needs it.
A2A goes one level up. It standardises communication between agents running on different frameworks. Each agent publishes an Agent Card at a known URL describing its capabilities and the skills it exposes. Another agent reads the card and knows exactly what to call and how. A LangChain agent and a Google ADK agent can now collaborate without a custom bridge for every pair. It supports both stateless messages for quick exchanges and stateful tasks for long-running processes.
AG-UI sits between the agent backend and the frontend. It standardises how agent events stream into your application. Anyone who has tried to build a real-time UI on top of an agent backend knows this problem intimately. AG-UI solves it with a lightweight event-based protocol that works across the major frameworks.
Then there is the fourth layer. Agents that generate the UI itself. The agent outputs JSON describing interface state. A renderer, React, Angular, or Flutter, picks it up and displays it. Four messages drive the lifecycle: create, update components, inject data, delete. The agent decides what the interface looks like. The renderer just executes.
That last one deserves a second read.
Interoperability has always to be a first-class concern at architecture time, not an afterthought when the first integration breaks in production.
The protocols exist. The question is whether your design is ready for them.
#AIAgents #MLEngineering #GoogleCloud #BuilderConnect
New local CLI support added to obsivault. Convert your Claude Code, Codex, Gemini CLi, and Opencode exports into a clean Obsidian vault from your terminal. Also now available in PyPi with just pip install obsivault
nitter.cf/AndrijDavid/status/205…
#cli
Years of conversations with @claudeai, @Grok, @ChatGPTapp and @GeminiApp are stuck on their servers. But you can export them, so I built a small tool that converts them into an @Obsidian vault. bit.ly/4tThgYF
Now you can turn your AI history into something a local agent can actually use. Markdown + YAML frontmatter means @ollama, @LMStudioAI, Claude Code, any MCP server can index it. Search every chat across provider
Point it at a Claude export, a Grok dump or a Google Takeout. It writes tidy Markdown with YAML frontmatter, copies attachments, and skips files that haven't changed on a rerun.
Everything runs locally. NO cloud. No API. No telemetry. Your chats stay on your disk and end up alongside the rest of your notes.
Most agent projects fail because the agents can't talk to each other . . .
I sat through a lot of talks at Google Cloud Summit France last week. A technical walkthrough of the interoperability stack that the industry is quietly converging on, and an honest look at where deployments actually break.
Agents break at the seams. Between frameworks, between backend and frontend, between agent output and user interface. That is where production incidents happen and also where rewrite cycles start.
The industry is addressing this with a layered stack. MCP gives agents a standardised way to connect to tools and data. You define your tools, resources, and prompts once, expose them via an MCP server, and any compliant AI application can consume them. Write once, reuse across every agent that needs it.
A2A goes one level up. It standardises communication between agents running on different frameworks. Each agent publishes an Agent Card at a known URL describing its capabilities and the skills it exposes. Another agent reads the card and knows exactly what to call and how. A LangChain agent and a Google ADK agent can now collaborate without a custom bridge for every pair. It supports both stateless messages for quick exchanges and stateful tasks for long-running processes.
AG-UI sits between the agent backend and the frontend. It standardises how agent events stream into your application. Anyone who has tried to build a real-time UI on top of an agent backend knows this problem intimately. AG-UI solves it with a lightweight event-based protocol that works across the major frameworks.
Then there is the fourth layer. Agents that generate the UI itself. The agent outputs JSON describing interface state. A renderer, React, Angular, or Flutter, picks it up and displays it. Four messages drive the lifecycle: create, update components, inject data, delete. The agent decides what the interface looks like. The renderer just executes.
That last one deserves a second read.
Interoperability has always to be a first-class concern at architecture time, not an afterthought when the first integration breaks in production.
The protocols exist. The question is whether your design is ready for them.
#AIAgents #MLEngineering #GoogleCloud #BuilderConnect
Just spent the morning at the Google Cloud Summit opening keynote and panels. Still here for the rest, but a few things from the early sessions stuck with me.
Scaling AI is not just technical problem but a human challenge.
RATP Dev had shadow AI showing up on work devices, so management went and did AI training at @Google themselves rather than issuing a policy. To get real adoption they picked 50 internal champions, and the interesting bit is they were not chosen for technical skill. They were chosen for being sociable and approachable, the people others actually ask for help.
Vinci Airports runs 70 airports and made the point that none of the AI matters without a solid data foundation first. They trial operational use cases in one place, like computer vision for aircraft parking to cut delays in Lyon or Belgrade, then roll out only what works.
Pennylane, in regulated fintech, skipped the experimental phase and went straight to agents. Their support agent now handles 64% of first-level conversations on its own, up to 96% for some features. An agent auditing developer code also caught four critical vulnerabilities that humans had missed entirely.
Doctolib is putting voice assistants into medical practices for routine questions and scheduling, with strict adherence to European data rules. The number that caught me: 43% of French people make poor health decisions based on what they read online, so the agent guiding patients through information is aimed straight at that.
Believe said 40% of tracks on streaming platforms are now AI-generated, but they account for under 1% of listens. And France Travail framed AI less as a job threat and more as a way to lower the barrier for would-be entrepreneurs, letting people start something by borrowing skills they do not personally have.
So clean data, human judgement, and the more these tools sound confident the more your own critical thinking matters.
More to come as the day goes on.
#GoogleCloudSummit #AI #AIAgents #FutureOfWork #ResponsibleAI
First day at Proof of Talk at the Louvre is done. Fewer slide decks about the future but more people telling stories about what is actually happening right now, especially in AI.
The one that hit me was from BitMind. They are building fraud detection for automated systems, and to demonstrate the problem they ran a small experiment by generating fake images of damaged raspberries using ChatGPT, submitted them to a grocery delivery app's automated refund system, and collected $500 in refunds over 30 days. It worked without much effort. The point they were making is that AI made scams scalable.
The Drug Discovery Subnet on @bittensor.ai was the opposite end of the spectrum. They run competitions where AI models search for novel pharmaceutical molecules. Their winning algorithm from a recent run was 973 times more efficient at finding high-scoring candidates than random sampling. They are now working with biotech partners to physically synthesise the output: a triple reuptake inhibitor being evaluated as a treatment for depression, ADHD, and PTSD simultaneously. It is a long road from a subnet competition to a clinical candidate, but the starting point is genuinely interesting.
For me @taostats gave the most grounded talk. The reality of running AI agents in your daily workflow is that you spend somewhere between 60 and 70% of your time on infrastructure, debugging, configurations, and workflow management. The remaining 30 to 40% of execution time is reportedly around 300 times more productive than before. Whether those numbers hold up at scale is a different question, but the shape of it rings true to anyone who has tried to maintain an agent pipeline in production.
Anyone else running agents day to day? Curious whether that split matches your experience.
#ProofOfTalk #AI #AgenticAI #Bittensor #DrugDiscovery
Andrij David retweeted
A bug related to the @gnosispay delay module has been discovered. We are investigating & will share updates as soon as possible.
If you are able to withdraw funds from the Gnosis Pay card to your wallet, we strongly recommend that you do that.
Affected users will be reimbursed.
Years of conversations with @claudeai, @Grok, @ChatGPTapp and @GeminiApp are stuck on their servers. But you can export them, so I built a small tool that converts them into an @Obsidian vault. bit.ly/4tThgYF
Now you can turn your AI history into something a local agent can actually use. Markdown + YAML frontmatter means @ollama, @LMStudioAI, Claude Code, any MCP server can index it. Search every chat across provider
Point it at a Claude export, a Grok dump or a Google Takeout. It writes tidy Markdown with YAML frontmatter, copies attachments, and skips files that haven't changed on a rerun.
Everything runs locally. NO cloud. No API. No telemetry. Your chats stay on your disk and end up alongside the rest of your notes.
Andrij David retweeted
Caller: "Hi Dave. I need help."
Dave: "Okay. What do you do?"
Caller: "I'm a CTO."
Dave: "Alright. What's going on?"
Caller: "We burned through our annual token budget in four months."
Dave: "Your entire annual budget?"
Caller: "Yes."
Dave: "So let me get this straight. Everybody told you AI would make engineers dramatically more productive."
Caller: "Yes."
Dave: "You would have to hire fewer people."
Caller: "Yes."
Dave: "A smaller team would ship more useful features."
Caller: "Yes."
Dave: "You spend less money over time."
Caller: "Yes."
Dave: "Okay. So what actually went up?"
Caller: "Token usage."
Dave: "What else?"
Caller: "Mostly token usage."
Dave: "How many more useful features shipped?"
Caller: "Well, the problem is it's hard to draw a direct line to revenue."
Dave: "Who do you work for?"
Caller: "Uber."
Dave: "Uber?"
Caller: "Yes."
Dave: "Son, the only thing AI delivered was surge pricing on your engineering budget."
Uber president says AI spending is getting ‘harder to justify’ theverge.com/transportation/…
Spent way more time than I expected parsing chat exports for obsivault. Three providers, 3 completely different ideas of what handing your data back actually means. Honestly the export format says more about each company than any blog post would. @claudeai. Simple export. Settings -> Privacy -> Export. One file. conversations.json. 41MB, 179 chats in my case. You can play with it easily (grep and jq). You can stream it with ijson and never load it all in memory. I almost don't believe how civilised this is. Each message has a content array of TYPED blocks. text. thinking. tool_use. tool_result. Not a stringified blob. Wrote a parser for it in like 10 minutes.Conversation branching is kept with parent_message_uuid on every message. Regenerate a reply, both versions stay in the tree. I rebuild the main path by walking the latest leaf back to root. You read the note as you actually had the conversation, not as the UI happened to render it last. In @claudeai exports attachments include extracted_content inline. PDFs you uploaded, screenshots you pasted, all come back as searchable text. The binary itself isn't in the export but the OCR is. A nice product decision someone made on purpose. The exp felt like @AnthropicAI respect the user enough to ship a format their own engineers would actually want to consume. Almost weird how rare that is.
@GeminiApp doesn't have its own export. It rides on @Google Takeout, which means you don't get a file. You get a TREE. And not a clean one. Takeout/Gemini in Workspace/ has structured JSON. Takeout/Gemini Apps/ is HTML.
Takeout/NotebookLM/ is a folder per notebook with Sources/Notes/Artifacts/. Takeout/My Activity/Gemini/ is one giant HTML page. Four formats, one product family. Had to write a sub-parser for each. The Workspace one is the only sane sub-format. conversation_*.txt files are actually JSON inside. conversation_turns[] holds user_turn or system_turn entries. system_turn means assistant btw. Embarrassing how long that took me to figure out. Citations buried at text[].citations.
@NotebookLM is the weird one. Each notebook is a folder on disk. Inside each folder: Sources/, Notes/, Artifacts/. Sources is what you fed it. Notes is what you wrote in it. Artifacts is what it generated for you. Study guides, briefing docs, audio overviews, mind maps. Sources come in PAIRS. .html plus metadata.json. The HTML is the extracted text from whatever you fed it (PDF, webpage, pasted text). The JSON beside it carries the original URL, title, source type. You have merge the two to know what each source actually was. No export of chats, follow-up and reasoning.