TL;DR Hand-drawn diagrams in Lucidchart, Visio, draw.io or Confluence rot because they live outside the codebase, cannot be diffed, and have no compiler to flag when they go stale. Diagrams as code closes all three gaps by treating the text source as truth and the rendered image as a build artefact. Pick by the question you are answering, not by taste. Mermaid for embedded docs and anything that has to render in GitHub. D2 for aesthetically polished architecture with real cloud icons. Python diagrams for AWS-heavy decks. PlantUML or Structurizr when you need formal UML or the C4 model. The conventions that make trust explicit: co-locate diagrams with the code they describe, add a metadata header with last_verified and next_review_due, encode confidence visually ( verified / stale / proposed ), pair each non-obvious diagram with an ADR, and render in CI. The highest-leverage move is to generate diagrams from the system itself - Terraform state, lineage graphs, dbt manifests, Airflow DAGs. A generated diagram is provably current by construction, which is a much stronger guarantee than “I reviewed it last quarter.” If you have ever opened a Confluence page from two years ago and wondered whether the architecture it shows is still real, you have already met the problem this post is trying to fix. Hand-drawn diagrams in Lucidchart, Visio, draw.io or PowerPoint share three failure modes that no amount of governance ever quite eliminates. They live somewhere your code does not, so nobody updates them in the same PR that changes the system. They cannot be diffed, reviewed, or merged. And they rot silently, because there is no compiler error for “this picture is now a lie.” ...

TL;DR Composer 2.5 is Cursor’s most capable in-house coding model yet, built on Moonshot’s open-source Kimi K2.5 checkpoint with about 85% of total training compute spent on Cursor’s own continued pretraining and RL The model is purpose-built for the agent loop inside Cursor - long-horizon tasks, hundreds of tool calls, multi-step instructions - rather than as a general-purpose chat model Cursor claims parity with Claude Opus 4.7 and GPT-5.5 on its own CursorBench v3.1 (63.2%) and a strong 79.8% on SWE-Bench Multilingual Pricing is dramatically lower: $0.50 / $2.50 per million input/output tokens on the default variant, with included usage doubled for the first week Together with SpaceXAI, Cursor is now training a much larger successor model from scratch on Colossus 2 with around 10x the compute - so 2.5 is a waypoint, not the endgame For a while, Cursor was an IDE wrapped around someone else’s models - Claude, GPT, Gemini. That story has shifted. With Composer 2.5, released this week, Cursor has shipped its most capable first-party coding model yet, and it is a serious enough piece of work that it deserves real consideration as a daily driver rather than a budget fallback. ...

A common dismissal of modern AI goes like this: “It is just a fancy autocomplete. It memorises text and stitches it back together. There is no real understanding, only retrieval.” It is a comforting story, and it has the shape of a critique that ought to be true. But spend enough time with frontier systems and a different picture starts to form. The thing that large models actually seem to be good at is not memorisation. It is something stranger and arguably more important: the formation of analogies, the combination of distant concepts, and the generation of conceptual relationships that were not explicitly present in any one place in the training data. ...

Dario Amodei is one of the few frontier-lab CEOs whose public talking points have not changed materially in five years. The same message he gave to small audiences in 2021 - that powerful AI is coming faster than people think, that the safety problem is real, and that the companies building it have an obligation to do so carefully - is the message he is giving to Congress and Davos in 2026. The thing that has changed is that he now runs the company most aggressively turning that message into a commercial position. ...

AlphaFold’s release in 2021 was the AI-for-science moment that broke through to the general public. A computational solution to a 50-year-old problem in biology - predicting protein structure from sequence - that produced a tool used by hundreds of thousands of researchers. The narrative around AI-for-science crystallised: deep learning would produce a series of similar breakthroughs across scientific domains. The 2026 reality is more interesting and less clean. AlphaFold-class breakthroughs have been rarer than the early narrative suggested. But AI has spread across scientific practice in subtler ways that, in aggregate, have done more to change how science is actually done than the few headline breakthroughs. ...

For most of the deep-learning era, the answer to “why is this happening in our data?” was “we do not actually care - we care that our model predicts well.” For a wide range of problems, that pragmatism worked. The models did predict well. The business outcomes followed. The causal questions were left to academics and economists. The mood has shifted in 2026. The cases where prediction-without-understanding fails are now visible enough, and expensive enough, that causal inference has moved back from the academic margins to something practitioners need to know about. It is not displacing predictive ML - it is filling in the gap that became unignorable. ...

For most of the AI conversation in 2024 and 2025, the binding constraints on the build-out were chips and capital. By 2026 the conversation has shifted, and the constraint that gets discussed most seriously inside the hyperscalers is electricity. Not the cost of electricity. The actual physical availability of electrons - at gigawatt scale, in the places where the data centres need to be, on the schedule the model labs need them to be. The story does not have a single villain or a single number, but it has a shape, and the shape is becoming the story of the second half of the decade. ...

For most of the last decade, talking about AI hardware meant talking about Nvidia. In 2026 that has stopped being true at the inference layer. Three companies - Cerebras, Groq, and SambaNova - have built genuinely different chips around the same insight: that the workload economics of running models in production are not the same as the workload economics of training them, and that the chip architecture should follow the workload. The bet has been right enough that Nvidia has now licensed pieces of it. ...

For most of the LLM era the open-weight story was framed as a trailing one. Open models were cheaper, smaller, and a generation behind. That framing has not survived 2026. The gap between the best open-weight model and the best closed model is now narrow enough on most workloads that the choice is no longer “settle for less” - it is “decide what you actually need.” TL;DR Open weights have closed the headline gap. Top open-weight models are within striking distance of closed frontier models on reasoning, coding, and general knowledge benchmarks. The economics changed first. DeepSeek’s R1 made it credible that a frontier model could be trained for tens of millions, not billions - and that the weights could be released for free. Llama, Mistral, Qwen, and DeepSeek lead on different axes: Llama for broad ecosystem support, Mistral for European deployment and tool use, Qwen for multilingual and long-context work, DeepSeek for raw reasoning. Inference flexibility is the underrated win. Open weights mean you can run on your own hardware, fine-tune freely, and avoid surprises from a closed provider’s roadmap. The remaining closed-model advantages are real but narrowing - agentic depth, multimodal performance, and the polished tool-use stacks around them. Where the gap actually is in 2026 Benchmarks are imperfect, but the picture they sketch is consistent. On standard reasoning suites - MMLU, GPQA, MATH - open-weight models are within a few percentage points of the closed frontier. On coding - HumanEval, SWE-Bench - the gap is similar. On long-context retrieval, the gap is mostly gone. ...

If you spend enough time in data engineering, you will eventually encounter the conviction that batch processing is dying and streaming is the future. This is the third or fourth time the industry has had this conversation in my career, and the answer has been the same every time. Streaming is not the future. Batch is not the past. They are different tools with different operational profiles, and the systems that age well use both, with discipline about which is the right choice for which problem. ...