标签：#LLM

“Something went wrong. Please try again.” is correct for about a third of AI failures and actively harmful for the rest, because for the rest, trying again cannot possibly help and you have just told the user to spend money finding that out. Everything that can go wrong Errors arrive from at least four layers, and the user-facing consequences differ enough that collapsing them into one message destroys the only information you had. Failure Description Transport Connection dropped, DNS, TLS, the stream died mid-token. Retryable, usually transient, and the user did nothing wrong. This is the only class where 'try again' is straightforwardly true. Rate limited (429) Yours or the provider's capacity, not the request. Retryable but only after a wait, and the wait is often stated in a header. Telling the user to retry immediately guarantees a second 429. Provider 5xx / overloaded Retryable with backoff, and the single best case for automatic failover to another provider rather than for any message at all. Timeout Ambiguous by construction: the request may have completed on the provider's side and been billed. Retrying may duplicate a side effect, which is why idempotency matters more here than anywhere. Context length exceeded Deterministic. Retrying the identical request fails identically. The only fix is fewer tokens, and the interface knows that — so the message should offer the fix, not the retry. Content filter The provider blocked the input or the output. Not retryable unchanged. Distinct from a model refusal, and users experience the two very differently. Truncated output The generation hit max_tokens. Not an error at the transport layer at all — status 200, a finish reason of 'length', and an answer that stops mid-sentence. Silently the most common broken experience. Malformed structured output Valid HTTP, invalid JSON or a schema violation. Retryable and often succeeds on a second sample, because it is a sampling accident rather than a capability failure. Empty o

Estimates of the energy in one model query differ by orders of magnitude across credible sources. Most of that spread is not disagreement about physics. It is disagreement about where the system boundary is drawn, and a figure quoted without its boundary is not a figure. Why the published figures disagree Before comparing two numbers, establish which of these each one includes. Any of them can change the answer by more than the model choice does: Which model, and how much output. A short answer from a small model and a long answer from a large reasoning model differ by several orders of magnitude on their own. A single “per query” figure averages over a distribution nobody specifies. Batch size and utilisation. The dominant engineering term. Serving many requests concurrently amortises the weight read across all of them; the same hardware at low occupancy spends nearly the same power for a fraction of the tokens. Facility overhead. Cooling, power conversion and distribution, captured as power usage effectiveness. It multiplies everything, and whether a figure includes it is frequently unstated. Training amortisation. Some analyses divide training energy across expected lifetime queries. Defensible, and it produces a different quantity from marginal serving energy. They are not comparable. Embodied energy. Manufacturing the accelerators, the building and the power infrastructure. Usually excluded, occasionally included, rarely flagged. Idle and provisioned capacity. Capacity is held for peak. Charging queries only for the seconds they compute understates the system; charging them for provisioned capacity overstates the marginal query. Both are used. Building the estimate yourself The marginal serving calculation is not complicated, and doing it once makes every published figure legible. Serving side, per accelerator: E_per_token = (P_device · n_devices · PUE) / R_tokens_per_second P_device average power draw under load, from the spec sheet (below the rated maximum in

Economists modelling AI reach conclusions ranging from a modest productivity bump to a change in the growth regime. They are not using different data. They are using different values for three or four parameters, and the parameters are where the argument should be. Two families of model Task-based automation models Associated most closely with Daron Acemoglu and Pascual Restrepo, these treat production as a continuum of tasks, each performed by labour or by capital. Automation moves tasks from labour to capital, which raises productivity and displaces workers; new task creation moves the boundary back. Growth and distributional effects both fall out of the movement of that boundary. The framework’s virtue is that it makes the aggregate effect an explicit function of quantities you can in principle measure: what share of tasks is exposed, how much cost is saved on each, and how fast new tasks appear. Acemoglu’s own applications of it to AI produce deliberately conservative aggregate numbers, and the reasoning is transparent — the effect is bounded by the exposed share times the saving on that share, so a large aggregate effect requires both terms to be large. Idea-production models The semi-endogenous growth tradition, associated with Charles Jones, models growth as driven by ideas, with ideas produced by researchers. Its central empirical observation is that ideas are getting harder to find: research effort has risen dramatically while growth has not, so productivity per researcher is falling. Aghion, Jones and Jones applied this framework to AI directly, and the key move is that AI enters not as a better tool but as a substitute for researchers themselves. That changes the mathematics qualitatively rather than quantitatively. If the population of effective researchers can be expanded by producing more compute rather than by waiting for demographic growth, the constraint that keeps growth steady in these models is loosened, and under some parameter values the models

This page is about method, not about any particular medicine, and nothing here is medical advice. It is written to answer one question: when a company says a drug was discovered with AI, which part of a decade-long process is that sentence about? The pipeline, and where the years go Roughly, and with enormous variation: pick a target, find molecules that do something to it, optimise those molecules into something drug-like, test in animals and in safety assays, then run the clinical stages — first for safety in a small number of people, then for efficacy in patients, then in a large confirmatory trial — and then apply to a regulator. Start to finish is usually over a decade. Two facts about that pipeline determine everything else on this page. The first is that the calendar and the money are dominated by the clinical stages, not the discovery ones. The second is that failure is the normal outcome, and it is concentrated where the drug first meets human biology: a candidate can be a beautiful molecule, hit its target exactly as designed, and still not help anyone, because the target was the wrong thing to hit. Where models are genuinely used Application Description Virtual screening Score enormous make-on-demand chemical libraries against a target site far faster than physics-based docking can. The output is a shortlist to synthesise and assay, and it replaces a search, not an experiment. Generative chemistry Propose molecules conditioned on a target, a scaffold or a set of property constraints, rather than picking from a catalogue. Whether the molecule can be made at all is a separate model. Property prediction Solubility, permeability, metabolic stability, cardiac ion channel liability. These filter a list early and cheaply. They are trained on assay data and inherit its coverage: they are most reliable on chemistry that resembles what has been tested. Retrosynthesis Plan a route from purchasable starting materials. This is the application closest to a solved probl

There's an argument running about MCP right now. You've probably seen it: a 400-point thread called "MCP is dead?" with real token numbers in it, four connected servers eating 21,077 tokens of context before anyone asks a question. The argument is about what MCP costs. Almost nobody in it has measured what agents actually do with the data a tool returns. I ended up measuring that, not because I planned to, but because a maintainer refused to let me guess. The question nobody wanted to answer with opinions I contribute to CNCF Jaeger's MCP server. Last April I proposed exposing service performance metrics (latencies, call rates, error rates) as an MCP tool, and hit an immediate design fork: what shape should the output be? Option one, summary rows: pre-aggregated stats per service, compact, cheap. Option two, per-bucket time series: the raw points, roughly 720 of them per service at default resolution, expensive but complete. I asked which the maintainer preferred. The answer, verbatim, from the issue thread: This type of decision should not be based on opinion, but on benchmarks with a real agent troubleshooting some issues and using this MCP tool to access metrics, where you could do A/B testing of different output formats. Fair. So I built the A/B. The setup Everything below is public in jaeger-mcp-bench , including the harness, the tasks, the scorer, and a research log of everything that went wrong. The fixture is Jaeger v2 with the spanmetrics connector, hotrod generating traffic, and Prometheus behind it, snapshotted so every run sees identical metric state. In front of the metrics API sits a thin bench server with exactly one switch: --format=summary|series . No new semantics, just the shape of what comes back. Six troubleshooting tasks, and this part matters: three were chosen because I predicted summary would win them (point questions: current latency, ranking, threshold checks) and three because I predicted series would win (temporal questions: spike detect

With the help of Claude Code, I finished a task that I had pushed aside for years in two days: To move away from WordPress for my blog . 1. Background WordPress had served well between 2016 and 2019, when I was still learning how to write apps with a framework like Ember. Over time, however, the annual cost of $48 (plus $28 for the domain, excluding taxes) felt overpriced, given the lack of features (e.g. no syntax highlighting for *.{gjs,gts} ) and many paywalls for customization. Reposting a blog post on dev.to was also tedious, since I need to write the content on WordPress using a proprietary, interactive editor, while in Markdown on dev.to. I would copy the output text from WordPress, then convert the output to Markdown. I finally had enough when WordPress broke the styles for code blocks again : Once after I had migrated from the classic editor to the current one, and the second time recently while playing with the admin dashboard. 2. Move to Next.js I decided to rebuild my blog in Next.js, a framework suited for blogs and in demand. The app is to be deployed on Netlify, and the domain stays with WordPress through a DNS configuration. I saw the opportunity to use Claude Code for the first time, as I had little experience with Next.js and wanted to see how far I can get with unknown technologies in two days. Thanks to prior experience in blogging on different platforms, I had a good idea of how to store blog content and metadata ( front matter ) in a Markdown file and what users should be able to do when they visit my blog. I also studied the current URLs so that (1) I can tell Claude how to structure the project in Next.js and (2) URLs won't be broken after the migration. What I knew would take the most time and delegated to Claude Code: Create components and routes to provide a similar functionality. Generate Markdown files for blog posts that I didn't repost on dev.to. Many of these were related to math and engineering and included LaTeX in inline and block

A malicious Ollama model is not a virus you double click, but it is untrusted input handed to a C parser, a template engine and your filesystem in one request. The realistic damage from a hostile /api/pull is disk exhaustion, VRAM starvation, blob writes under ~/.ollama/models , a poisoned chat template that silently rewrites every prompt, and memory corruption in the GGUF loader if the file is crafted for it. None of that requires a vulnerability in your app code, only an Ollama daemon that trusts whoever can reach port 11434 and whichever registry a tag points at. Bind the daemon to localhost, pin models by SHA256 digest, run the container as a non root user with a read only root filesystem and a capped model volume, and the entire class collapses to a bad model that answers badly. TL;DR by reader profile: Solo developer running Ollama on a laptop, for example a contractor testing llama3.1:8b locally: leave OLLAMA_HOST at 127.0.0.1:11434 and pin digests, because your only real exposure is pulling a model whose tag moved under you. Two person startup running Ollama on one rented GPU box, for example a founder pair serving an internal assistant: run it in Docker as UID 1000 with --read-only , --cap-drop ALL and a sized model volume, because a single unbounded pull can fill the disk that also holds your Postgres data. Team fronting Ollama with Open WebUI or Continue, for example five engineers sharing one workstation: put model management behind the proxy and block /api/pull , /api/create , /api/push and /api/delete for normal users, because chat access and registry access are not the same privilege. Anyone building agents or RAG on Ollama, for example a support bot with tool calling: treat the Modelfile TEMPLATE and SYSTEM blocks as attacker controlled text, because a poisoned template reaches the model before your prompt does. Consultancies holding client data, for example a two person shop under an NDA: keep model pulls on a staging host, mirror approved blobs int

Automatic speech recognition is very good until somebody mentions the name of a local school, a village, a politician, a festival, or a cricket ground. Then things get strange. In an earlier test with audio from Barbados, GPT Transcribe and GPT Audio 1.5 heard the event name “Rise Together” as “Rice Together”, while Qwen3.5-Omni Plus and Flash got it right. Those are different models from the Qwen3-Omni checkpoint used here, but the result motivated this experiment. Acoustically, the mistake is understandable. Culturally, it is wrong. A person who knows the local context has another signal available: they know that Rise Together is the plausible name. That led me to a question: can we give an audio-native model a stronger model of Barbados, using text that already contains the names, institutions, places, events and relationships it is likely to hear? So I took an archive of Barbados newspapers, turned it into 51.6 million tokens, and used it for domain-adaptive pretraining of the Thinker inside Qwen3-Omni. The result is promising, but not conclusive. The adapted model produced higher scores on our preliminary Barbados knowledge probe, particularly on people and institutions. It also got slightly worse on a small set of general-knowledge controls. And, most importantly, we have not yet shown that it transcribes audio more accurately. This is a very preliminary result. It came from our first training run, which we stopped at step 500 of a planned 801 steps. We were also still extracting the newspaper archive, so the 51.6 million training tokens represent the material available for that run rather than the full corpus we ultimately intend to use. This post is about what we have actually demonstrated, what broke along the way, and why I think the experiment is still worth pursuing. The Problem Is Not Just Acoustic A transcription model is doing more than converting sound into letters. When audio is clean and a word is common, the acoustic evidence can be enough. But re

I benchmarked a vision-language model and scored it at 0.31. The real number was 0.70. Same model, same weights, same hardware, same 100 questions. The only thing that changed was how I read its output. I had already written up the 0.31 as a capability finding and concluded the model was unsuitable. That conclusion was wrong, and the failure was entirely in my harness. Here is the mistake, because I doubt I am the only one making it. The setup I was evaluating a batch of open-weight and frontier models on a multiple-choice benchmark: multi-view driving scenes, four options per question, one correct answer. Standard stuff. The prompt asked for reasoning followed by a final line, Answer: X . My scoring code did the obvious thing: m = re . search ( r " Answer:\s*([A-D]) " , output ) pred = m . group ( 1 ) if m else None # None scores as wrong That last comment is the bug. What actually happened The model I was testing is a "thinking" model. It emits a long internal reasoning trace before it commits to an answer. I had a generation budget of 1024 tokens. On easy questions it reasoned briefly, emitted Answer: B , and scored fine. On hard questions it reasoned at length, hit the token cap mid-thought, and never emitted the answer line at all. So the harness scored every one of those as wrong. 64 of 100 questions returned no parseable answer. Zero of those were image-loading errors or crashes. They were all truncation. And the truncation was not random: Uncertainty 0/8 answered Counterfactual 0/3 answered Safety-critical Planning 1/11 answered Safety-critical Prediction 3/12 answered Look at that distribution. The questions the model failed to answer were precisely the questions that required the most reasoning. My harness was systematically discarding the model's performance on exactly the hard subset I was trying to measure, and reporting the result as a capability ceiling. Of the 36 it did answer, it got 86% right. The model was fine. My measurement was garbage. The fix

The first time I ran my vulnerability scanner against the industry-standard benchmark, the bottom line of the scorer's report was this: $ python scripts/score_benchmark.py --findings out/java.findings.json \ --truth benchmark-java/expectedresults-1.2.csv OVERALL precision 0.60 recall 0.07 F1 0.13 # abridged Three numbers, and here is what each one means. Precision 0.60 — of all the alarms the scanner raised, 60% pointed at real bugs: when it spoke, it was right more often than not. Recall 0.07 — of all the real bugs in the benchmark, it found 7%. In the four vulnerability classes my scanner covers, the benchmark contains 777 real, labeled vulnerabilities; it missed 93% of the bugs it exists to find. F1 0.13 — precision and recall combined into one score (their harmonic mean), dragged down to almost nothing by that recall. My first instinct was to fix it before anyone saw it. Instead I saved the output, wrote the number into my benchmark log, and kept it — because that number was always going to be published, and this is the article that publishes it. The Context For the past months I've been deep in AI — reading, building, measuring. One of the projects that came out of it is an AI vulnerability scanner. The design in one sentence: deterministic static-analysis rules do all the searching, and an LLM judges each finding — is this a real bug or a false alarm? The full architecture gets its own article. This one is about the first measured number. The test set is the OWASP Benchmark — 2,740 labeled Java test cases, the standard exam for Java security scanners. In my scanner's four vulnerability classes (SQL injection, command injection, path traversal, XSS) there are 1,478 cases: 777 real vulnerabilities and 701 cases deliberately designed to bait scanners into raising false alarms. Every tool I compare against — Semgrep, CodeQL — takes the same exam, scored by the same scoring code. Same rules for everyone. New to this? Three words carry this article. A source is wher

The last lesson was about validating what a model hands you. The story behind it: a set of prompts that had returned real, criteria-matched vendors for weeks came back in staging with placeholder junk, literally the words Vendor A, Vendor B, Vendor C. So I built the validation layer, and the last gate in it is a model checking a model. Then FromZeroToShip asked three questions in the comments, and all three were about the gate rather than the model. That's the harder thing to look at, and I hadn't written all of it down. Here's the long version. What was on the fail list that I hadn't already been burned by? More than the question assumes, and not because I got clever about imagining failures. The placeholder output changed what I do with a failure . I stopped fixing the instance and asked what class it belonged to, and that class is a lot wider than "the model emitted example data." It's a suggestion that looks fine and isn't usable. Two of those I had never hit went in on the back of it: A vendor that's wrong for the category. A vendor that's no longer in business. Neither has anything to do with placeholder text, and both would sail through a schema check looking like a perfectly real answer. They also changed the prompt that produces the suggestions, not just the gate. Fixing only the failure I actually met would have left both of them live. So the list isn't purely retrospective. It grows by generalizing from the one failure you hit to the class it sits in, and it keeps growing from what the running system actually throws at me rather than from what I remembered to imagine. Is it foolproof? No. What's left is the case worth worrying about: results that read as real, pass the schema, satisfy every criterion I gave, and are still wrong. You can't validate the truth of a guess from inside the system. You can only lower the cost of it being wrong. That means a human in the loop at the stage where being wrong is expensive, the confidence surfaced so the answer is ch

Anthropic and OpenAI are racing to scale up while reducing dependence on Nvidia.

Everyone's talking about agentic AI shipping production code. Nobody's talking about what happens when you actually sit down and grade thousands of lines of it against a rubric, line by line, for months. I have. And the failure pattern that shows up over and over isn't the one Twitter/X is arguing about. The job title that didn't exist two years ago "AI evaluator." "AI trainer." "Expert contributor to frontier model training data." None of these existed as job titles when I started my career. Now they're where a chunk of the most interesting engineering signal in the industry is actually happening — quietly, behind NDAs, far from the demo videos. Here's what the job actually is: agentic coding outputs land on your desk, and you grade them against a structured rubric — correctness, instruction adherence, quality, edge-case handling. You design adversarial prompts to find where the model's reasoning breaks. You decide which checks can be programmatic and deterministic, and which genuinely need a human who's shipped production systems to make the call. This is RL environment design and LLMOps in its rawest form, and it's a completely different skill from "prompt engineer" or "ML researcher." It's closer to being a QA lead for a junior engineer who never sleeps, never gets embarrassed, and will confidently ship the wrong answer with perfect syntax. The pattern: agents are great at code, bad at consequences Here's the uncomfortable part. The failure mode people are loudest about — hallucinated APIs, made-up library functions — is the easy failure mode. It's loud, it's obvious, and any decent test suite catches it in seconds. The failure mode that actually matters, the one that slips past a surface read and even past a naive test suite, looks like this: The code is syntactically perfect and semantically wrong about failure. It handles the happy path beautifully and quietly assumes the retry, the timeout, the partial write, the duplicate message never happens. It optimises

Recently, I've added a bunch of hype-monsters to my AI Werewolf : Kimi K3 Qwen 3.8 Max, Qwen 3.7 Plus, Qwen 3.7 Flash MiniMax M3 Plus the ones I've had for a while DeepSeek V4 Pro and Flash GLM-5.2 Sakana Fugu base and Ultra The last one is Japanese, not Chinese, but it was in the news a month or two ago and it belongs in this story. I sat down to write about how slow Chinese models are. Because they are all annoyingly slow even with a small context. I had the numbers, the thesis wrote itself, and then... I discovered something I didn't expect. Okay, let me go straight to the problem All Chinese official APIs are extremely slow. DeepSeek got better with their v4, the rest are just terrible. So slow that they are barely usable in a text game. No, seriously, take a look. Time to produce one four-sentence vote: Kimi K3 : 29 to 34 seconds MiniMax M3 : 25 to 30 seconds Qwen 3.8 Max : 25 to 27 seconds, and only because I capped its thinking. Uncapped it hit 100. DeepSeek V4 Pro : 14 to 22 seconds, the best of the group Same prompt, same afternoon: Claude 5 Opus answers in 5.9 seconds. I have a test which simulates the voting at the end of a game day. Some chat has happened, some players have already cast their votes, and now the model under test has to do the same. The prompt contains all of that: 36,000 characters, which works out to 8-13k tokens depending on the model's tokenizer. Not much, assuming those models have 1M contexts. More US/EU models: Model Time Input Output tokens Avg cost GPT-5.6 Luna 3.2-3.6s 12,124 190-231 $0.0020 Mistral Large 3 2.9-5.2s 8,175 73-134 $0.0042 Claude Fable 5 4.8-6.0s 13,027 183-209 $0.1399 Gemini 3.6 Flash 4.6-7.1s 7,979 297-532 $0.0152 GPT-5.6 Sol 6.7-7.3s 12,124 150-156 $0.0471 Claude 5 Opus 5.9-7.8s 13,027 220-387 $0.0726 Gemini 3.1 Pro 11.6-12.1s 7,979 821-940 $0.0263 Claude 5 Sonnet 6.8-14.8s 13,027 252-821 $0.0464 Grok 4.5 10.0-14.8s 8,190 428-607 $0.0149 Mistral Medium 3.5 2.9-35.0s 8,175 57-109 $0.0128 Worth staring at the input

Intro Day 20! I lined up 10 AIs that turn a single photo into a few seconds of video. Half ran locally on my DGX Spark, half in the cloud 🐱 What I used: DGX Spark (LTX-2.3 / Wan 2.2) / 8 cloud models via fal.ai / ComfyUI / ffmpeg The setup Item Value Input One identical photo (my cat on a desk) Length 6 seconds Settings Identical The only variable The prompt Easy prompt The cat looks at the camera and meows once. It opens its mouth, meows, then closes it. Its tail flicks and its ears twitch. Hard prompt The cat stands upright on its hind legs in a kitchen, wearing a small apron, holding a knife in its front paws and chopping vegetables on a cutting board. Steam rises from a pot behind it. Please, just watch it Some of the cats came out with very long legs. Anyway. First half is the easy prompt, second half the hard one. On the easy prompt, local and cloud were a fair match . On the hard one... cloud, I think...! Three rankings below. Ranking 1: Time Time per 6-second clip on the hard prompt. Rank Model Where Time 🥇 LTX-2.3 Cloud 41s 🥈 Wan 2.7 Cloud 92s 🥉 Happy Horse 1.1 Cloud 97s 4 Veo 3.1 Cloud 128s 5 Kling 3 Pro Cloud 205s 6 Seedance 2.0 Cloud 210s 7 LTX-2.3 Local 315s 8 Wan 2.2 Local 651s 9 daVinci-MagiHuman Cloud 710s 10 HunyuanVideo 1.5 Cloud 796s A 19x spread. Look at 1st and 7th. Same model, LTX-2.3 , nearly the same resolution. The only difference is where it ran — 7.6x . Local setup DGX Spark (GB10, 128GB unified memory, ~273GB/s). ComfyUI headless, workflows over its API. LTX-2.3 is distilled fp8 at 8 steps. At 1088×1920 peak memory hit 77.8GB, about 60% of 128GB. That was the ceiling. Dropping to 512×768 finishes in 70s, but with one-fifth the pixels. Wan 2.2 is I2V-A14B fp8, 20 steps, 480×640. Higher resolution does not finish in reasonable time. Ranking 2: Cost Rank Model Per 6 seconds 🥇 Local Electricity only 🥈 LTX-2.3 (cloud) $0.36 🥉 Wan 2.7 $0.90 4 Kling 3 Pro $1.01 5 Happy Horse 1.1 $1.08 6 Veo 3.1 $2.40 7 Seedance 2.0 $4.09 — HunyuanVideo / MagiHum

Originally published in Spanish on El Rack. Browser translation handles the rest of the site fine if you're into homelab/self-hosting content. Moonshot AI released Kimi K3 on July 17, 2026, and made the weights publicly downloadable on July 27. At 2.8 trillion parameters, it's the largest open-weight model ever published — and according to multiple benchmarks, it rivals Claude Opus and GPT on coding, reasoning, and general knowledge work, at a fraction of the training cost. The New York Times ran an in-depth piece on it a few days after release, which tells you this isn't just another model drop. What "open weights" actually gets you here Publicly downloadable weights mean any company or researcher can run this locally and modify it without depending on a third-party API. If you already run Ollama or LM Studio in your homelab, that's the tempting part: a frontier-level model, no monthly quota, running on your own hardware. The practical reality is different. "2.8 trillion parameters isn't a number that runs on homelab hardware — it needs an enterprise-grade GPU cluster. The weight release is real, but "downloadable" and "runnable" are very different things at this scale." The bigger debate this reopened What makes Kimi K3 interesting isn't just the benchmark numbers — it's what it represents in the ongoing dispute over AI's geopolitics. The same fracture that opened up around DeepSeek-R1 in January 2025 is back: some argue US labs need to close up more in response to Chinese competition, others see openness as the only real way to stay relevant against an ecosystem that ships open weights at a pace closed labs can't match on transparency. There's also a real technical concern underneath: the possibility that outside actors use massive querying of closed American models to distill their outputs and train competing open models. Where this actually matters for a homelab Even though K3 itself is unrunnable on consumer hardware, its release pushes down what smaller, actu

"A Trie isn't designed to store words. It's designed to make finding everything that shares the same beginning incredibly efficient." In the previous article, we explored a different kind of software problem. Some systems don't search using complete values. Instead, users provide only part of the information they know. The system must immediately suggest possible matches. Once you recognize that requirement, another question naturally follows. How should the system organize data so prefix searches become fast and natural? This is exactly the problem a Trie solves. Think About a Dictionary Imagine opening a physical dictionary. Suppose you're looking for the word: Application Do you start reading from page one? Of course not. You first go to the words beginning with: A Then you narrow further. Ap Then: App Every additional letter reduces the search space. A Trie works in a very similar way. Instead of repeatedly searching through every word, it follows the characters one by one. What Is a Trie? A Trie is a tree-like data structure where each node represents a character. Words that begin with the same characters share the same path. Consider these words. car card care cart A Trie stores them like this. Root ↓ c ↓ a ↓ r ├── end ├── d → end ├── e → end └── t → end Notice something interesting. The prefix: car is stored only once. Every longer word simply continues from that shared path. Every Data Structure Answers a Different Question By now we've seen several data structures, each solving a different design problem. A HashMap asks: Where is this exact object? A Heap asks: Which item has the highest priority? A Queue asks: Which task should happen next? A Stack asks: What is the current working context? A Trie asks: What begins with these characters? Choosing the right data structure starts with identifying which question your software needs to answer. Inserting a Word Imagine inserting: cat The Trie creates a path. Root ↓ c ↓ a ↓ t Now insert: car The beginning alread

Small ask, on paper. A clinician types something like "any allergy conflicts for this patient's current meds?", and before the model answers it needs to actually go get the medication list and the allergy list rather than guess at what's plausible. Two functions, both of which already existed. The interesting part was never the lookups, it was getting a model to decide when to call them and hand back arguments I could trust. Then compliance sat in on the review and asked the question I should have seen coming: "what checks this model's answer?" Fair question, this is going in front of a clinician. Their answer was a second model, from a different provider, running the same lookups independently and flagging if it disagreed. Reasonable. Also, as it turned out, the thing that broke my code. The first version worked. That was the problem. I had the OpenAI SDK already wired into this project, so version one was straightforward: define tools , send the request, read message.tool_calls , run whichever function it asked for, push a role: "tool" message back with the result, loop until it stops asking. Twenty minutes, maybe. It worked on the first real test and I remember thinking this was going to be a short ticket. It was a short ticket, right up until "second model, different provider" landed in the same sprint. I went to point the exact same loop at Claude and it just doesn't speak that dialect - Anthropic sends tool requests back as tool_use blocks sitting inside the message content, not a separate tool_calls array, and the result has to go back as a tool_result block inside a user message. There's no tool role at all on their side. Same idea, completely different shape, and I was about two minutes from just writing a second version of the loop and calling it a day. I'd already installed the thing that fixes this I only stopped because I already had @aviasole/shapecraft in this project for the FHIR schema work, and figured it was worth thirty seconds to check whether g

Is the Future of Enterprise AI Local? For the past couple of years, the standard approach to AI has been pure brute force: take the biggest, most expensive cloud-hosted frontier model you can get hold of and throw it at every single problem. But this "one-size-fits-all" approach is not going to last forever. We are approaching a transition phase where the capabilities of local models will soon pass the threshold of "good enough," just as the growing costs of frontier models become impossible for businesses to ignore. Here is why I believe the pendulum is about to swing firmly toward local, controlled hardware. 1. The Looming API Cost vs. Value Reality Check Right now, companies are actively encouraging their staff to jump on the AI bandwagon. But this honeymoon phase will eventually hit a wall. In the near future, businesses are going to start heavily scrutinising the cost-versus-reward ratio of their AI deployments. Consider the typical enterprise token burn: If an engineer is burning through £10,000 worth of tokens each month on API calls, are they actually adding £10,000 worth of value? Or have they just established an expensive new habit to climb the internal AI usage leaderboard? When CFOs eventually demand budget cuts, teams relying entirely on cloud APIs are going to be forced to unlearn those expensive habits overnight, or find alternative options. Beyond raw cost, cloud providers will likely continue introducing workflow friction. We've already seen instances where providers shrink token allowances, enforce dynamic rate-limiting based on the time of day, or push traffic to lower-tier models during peak utilisation. Building your core workflows on a third-party API means you will never truly control the throttle. This is not even considering the data ownership issue, up until now the only powerful models were closed weight and there was not much choice in ownership, however now that open weight models are available that can offer similar performance and can

Most comparisons of AI coding models are useless to you. Not because the authors are dishonest, but because they test on their problems: greenfield LeetCode-style prompts, demo TODO apps, or a framework you don't use. Your codebase has different failure modes — a weird build system, a legacy module nobody wants to touch, tests that take 40 minutes. This article is a small, reproducible harness you can run in an afternoon to compare coding models against your own repository, with scoring based on your own test suite instead of vibes. The artifact is ~120 lines of shell and Python, plus a scoring rubric you can adapt. The core idea Instead of asking "which model is best?", ask: on a fixed set of real tasks from my repo, which model produces patches that pass my tests, fastest, with the least hand-holding? That gives you three measurable axes: Correctness — does the resulting diff pass the relevant tests? Edit locality — did the model touch only the files it should have? Iteration cost — how many prompt rounds did it take to get there? Step 1: Build a task set from your own git history The cheapest source of realistic tasks is your own commit log. Find commits that fixed a bug or added a small feature, then check out the parent commit and ask the model to reproduce the fix (without showing it the actual fix). #!/usr/bin/env bash # extract_tasks.sh — mine candidate tasks from git history # Usage: ./extract_tasks.sh <repo_path> <count> set -euo pipefail REPO = " $1 " ; COUNT = " ${ 2 :- 8 } " cd " $REPO " # Small, self-contained commits: <= 3 files, <= 80 changed lines, has a test file touched git log --oneline --no-merges -n 300 | while read -r sha msg ; do files = $( git diff-tree --no-commit-id --name-only -r " $sha " | wc -l ) lines = $( git diff --shortstat " $sha ^" " $sha " | grep -oE '[0-9]+ insertion|[0-9]+ deletion' | grep -oE '[0-9]+' | paste -sd + | bc ) if [ " $files " -le 3 ] && [ " ${ lines :- 999 } " -le 80 ] ; then echo " $sha | $files | $lines | $msg "