📰 English IT Daily · 2026-07-27

Anthropic has announced Claude Opus 5, a new AI model that the company says is available now. According to Anthropic, the model is designed to be thoughtful, proactive, and efficient enough for everyday use. The company presents it as a strong option for coding and knowledge work, while also stressing cost-effectiveness. In simple terms, Anthropic is trying to show that users do not always need the most expensive frontier model to get top-level results on practical tasks.

A key part of the announcement is the balance between performance and price. Anthropic says Opus 5 comes close to the intelligence level of Claude Fable 5, but at about half the price. It also says Opus 5 delivers much better performance than Opus 4.8 for the same cost as that earlier model. This matters because many companies now care not only about raw benchmark scores, but also about how much they must pay to run large numbers of tasks. In business, a model that is slightly less powerful but far cheaper can gain traction very quickly.

Anthropic highlights results on coding and related evaluations. On tests such as Frontier-Bench and CursorBench, the company says Opus 5 reaches state-of-the-art performance in several areas. At higher effort settings, it reportedly comes very close to Fable 5 on some coding tasks while keeping the cost per task much lower. The company also says customers can tune the effort setting depending on their needs. That means teams can optimize for stronger reasoning when accuracy matters most, or conserve tokens when speed and budget are higher priorities.

The company also points to broader knowledge work and problem-solving results. In its description, Opus 5 performs strongly on tasks that involve novel reasoning, business process automation, and computer use. Anthropic says the model can verify its own work and iterate more carefully until it succeeds. That claim is important because many users are no longer impressed by one-shot answers alone. They want systems that can check steps, recover from mistakes, and follow through on tasks from start to finish. In real workplaces, that kind of behavior can be a double-edged sword: it may raise productivity, but it also increases the need for oversight.

Another notable part of the release is science-related performance. Anthropic says Opus 5 improves on Opus 4.8 across its life sciences evaluations, including structural biology, organic chemistry, and bioinformatics. The company especially calls out progress on tasks such as inferring molecular structures from spectroscopy data and predicting the effect of protein sequence changes. At the same time, Anthropic is careful not to claim that Opus 5 leads in every domain. It says the model still lags behind Mythos 5 on cybersecurity tasks. That detail matters because benchmark leadership often depends on the exact field being tested.

For users and technical teams, the launch raises a practical question: what should they watch next? First, real-world reliability will matter as much as headline scores. Benchmarks are useful, but deployment at scale often reveals hidden trade-offs in latency, cost, and consistency. Second, the effort-setting approach may stand out if it gives teams finer control over quality and spending. Finally, competition among model providers is likely to intensify, with companies trying to carve out positions based on coding strength, scientific usefulness, or lower operating cost. In short, Opus 5 is not just another model release; it is part of a larger shift toward AI systems that must prove their value in everyday work.

vocabulary

A GitHub project called esp32-ai shows something that would have sounded unlikely not long ago: a 28.9 million parameter language model running on an ESP32-S3 microcontroller that costs about $8. According to the project page, the model runs fully on the device, without sending anything to a remote system. It writes output to a small screen connected to the chip and reaches roughly 9 tokens per second. On its face, that is a striking result because microcontrollers are usually linked with simple control tasks, not text generation.

The background makes the result more interesting. The project says that the last language model run on a similar class of chip had only around 260,000 parameters. In other words, this new model is about one hundred times larger. That does not mean it can compete head-to-head with modern assistant models on quality or range of skills. The project is clear about that. The model was trained on TinyStories, so it mainly produces short and simple stories. It does not answer questions well, follow instructions, write code, or show broad factual knowledge. Still, from an engineering point of view, the leap in size is hard to ignore.

The key idea is a memory layout that plays to the strengths and weaknesses of the hardware. Microcontrollers have very little fast memory. The ESP32-S3 in the project has 512KB of SRAM, plus 8MB of PSRAM and 16MB of flash storage. Usually, that small amount of fast memory becomes the bottleneck, because a model needs quick access to its weights. This project gets around that limit by keeping most of the model in flash, which is slower but much larger. Only the smaller part that does the main token-by-token computation stays in fast memory.

More specifically, the project stores about 25 million parameters in a flash lookup table. The article explains that this follows an idea from Google’s Gemma models called Per-Layer Embeddings. Instead of loading a huge table into SRAM, the system pulls in only the few rows needed for each token. The amount read per token is tiny, roughly a few hundred bytes, so the model can get by with very limited fast memory. In practical terms, most of the model sits quietly in flash and is sampled a little at a time. That approach is the crux of the project: the model fits not because the chip suddenly became powerful, but because the design avoids wasting scarce memory.

This matters because it hints at a different path for AI at the edge, meaning AI that runs directly on local devices. For privacy, cost, and reliability, on-device processing can be attractive. A system that does not need network connectivity may work in remote places, respond with predictable delay, and avoid sending user input elsewhere. At the same time, there is a trade-off. Flash is slower than SRAM, and a model optimized to fit on a tiny chip may lag behind larger systems in reasoning and flexibility. In that sense, the project is a proof of concept first and a product blueprint second.

Even so, it may gain traction among engineers because it challenges a common assumption: that serious language models belong only on phones, laptops, or large accelerators. The project does not claim to break the laws of physics. Instead, it shows that clever architecture can squeeze more value out of modest hardware. The likely implication is not that every microcontroller will become a chatbot, but that developers may revisit embedded AI with fresh eyes. The next thing to watch is whether similar techniques can broaden what small devices can do while keeping performance, memory use, and model quality in balance.

Slack has described a new internal platform called Shipyard, which it built to modernize the way it runs EC2 instances. The company says this work is the next step in a longer journey. Earlier, it improved its Chef-based configuration system so it could manage tens of thousands of instances with more reliability and better control. It also added safer rollout methods to reduce the blast radius of failures. Those changes kept the old system stable, but they did not solve a deeper problem. Slack says the basic model of continuously updating long-lived virtual machines was starting to show its limits.

At the heart of the issue was infrastructure drift. Over time, long-running instances can become slightly different from each other because of many small updates, manual fixes, or uneven deployment timing. That makes systems harder to reason about and harder to debug. Slack also found that service-level deployments were tricky when teams had to coordinate changes across several layers at once. Containers had already solved some of these problems for certain workloads, but not every system could move easily. Some infrastructure components, Kubernetes worker nodes, and network-related systems still needed the flexibility of EC2.

Shipyard is Slack’s answer to that challenge. Instead of treating instances as machines that are endlessly modified, the platform treats infrastructure as deployable artifacts. In other words, teams build a versioned image or package, test it, and roll out that artifact in a controlled way. This follows the idea of immutability, where running systems are replaced rather than changed piece by piece. Slack says this gives teams deployment primitives at the service level, along with closer ties to build pipelines and orchestration systems. The goal is to update infrastructure with the same predictability that engineers expect from modern application delivery.

A key part of Shipyard is flexibility without separate platform designs for each case. Slack says the system supports multiple CPU architectures, including AMD64 and ARM-based Graviton, as well as several operating systems such as Ubuntu, RHEL, and Amazon Linux. That matters because different teams may optimize for cost, performance, or compatibility. In many companies, supporting that range can become a patchwork of one-off solutions. Shipyard tries to avoid that by providing one platform with common deployment patterns. For teams, this can lower operational friction while still letting them choose the environment that best fits their workload.

Another major feature is metrics-driven deployments with safety controls. Although the source context only gives part of the explanation, the direction is clear: Shipyard is designed to use automated signals during rollouts so the system can watch service health and react quickly if something goes wrong. This is a pragmatic approach because infrastructure updates can be risky even when they look small on paper. By tying deployments to measurable outcomes, a team is less likely to fly blind. Progressive rollouts also let operators start small, observe behavior, and then expand the change if the results look safe.

The broader significance of Shipyard is that it shows how virtual-machine platforms are still evolving, even in a world shaped by containers. Not every workload can be containerized quickly, cheaply, or safely, and many organizations are in the same boat. Slack’s design suggests that modern delivery practices do not belong only to container platforms; they can also be applied to traditional compute environments. The trade-off, of course, is that building such a system takes time and strong internal engineering. Still, the direction is noteworthy: instead of endlessly patching old workflows, companies may increasingly rebuild infrastructure platforms around immutability, automation, and safer rollouts.

A new engineering guide from workflow startup Hatchet looks at a problem many young companies face: how to stop Postgres from falling over as traffic grows. The post is based on the writer’s experience running Postgres in production over the past two years. Its main idea is simple. Many teams know basic SQL, but when performance suddenly drops, the official manual can feel too broad and too deep to use in a crisis. The guide tries to bridge that gap with practical advice for startups that are moving fast and cannot afford long outages or constant fire drills.

The article starts with schema design, which it describes as one of the hardest things to change later. A schema is the structure of tables, keys, and relationships. The advice is to build it iteratively instead of trying to design the perfect model on day one. Engineers should think about whether a table will be read often, written often, or both. They should also ask which columns are common filters and which ones will be updated the most. The guide mentions database normalization, but it also says strict theory can sometimes be at odds with query efficiency and developer speed. In some cases, storing flexible fields in a jsonb column may be a practical trade-off.

From there, the focus shifts to read queries and indexes. The common beginner lesson is that a slow query often needs an index, but the guide pushes this idea further. It emphasizes writing read queries that match real access patterns, especially when joins and sorting enter the picture. Compound indexes can be useful, and the order of columns matters. The article also notes that ORDER BY should align with an index when possible. This can reduce extra work and keep queries responsive. In short, indexes are not magic. They work best when they reflect how the application actually reads information.

Write-heavy systems bring a different set of problems. Startups often spend most of their early time thinking about reads, then hit a wall when frequent updates, inserts, or large migrations begin to pile up. The guide warns that connection management also matters. Too many open connections can strain the system even before query logic becomes the real bottleneck. It also highlights the query planner, which is the part of Postgres that decides how to run a query. That planner is described as a leaky abstraction because developers cannot ignore it forever. If the planner chooses a poor path, performance can suffer, even when the SQL looks reasonable at first glance.

The guide then moves into maintenance issues that many teams overlook until they are deep in the weeds. One key example is autovacuum, a background process that cleans up old row versions created by updates and deletes. Default settings may be safe for some workloads, but the article argues that they can also become a double-edged sword at scale. If cleanup does not keep up, bloat can grow and query speed can decline. The post also points to bulk updates and large-table migrations as areas where care is needed. For growing services, these tasks can quietly become operational risks rather than simple housekeeping.

Finally, the guide touches on more advanced topics such as FOR UPDATE SKIP LOCKED, partitioning, and tricks for changing very large tables. These are not day-one tools for every startup, but they matter once systems become busier and more complex. Another practical point is about ORMs. The author says the advice still applies, yet some optimizations are hard to do unless engineers break past the abstraction layer and write SQL directly. That reflects the wider message of the piece: Postgres can scale well, but it rarely happens by accident. Teams need good habits, clear visibility into query behavior, and a willingness to make trade-offs early before small design choices spiral into major production problems.

SIMD, short for Single Instruction, Multiple Data, is often seen as a difficult topic that only performance experts need to understand. But a recent article by developer Mitchell Hashimoto argues that this view misses the point. He says SIMD is not just a niche tool for specialists. Instead, it is a practical idea that many developers can learn and apply. The basic concept is simple: a CPU can process several values at the same time instead of handling them one by one. In plain terms, a loop that checks each byte, character, or number individually may be turned into a loop that works on a chunk of values in parallel.

This matters because many programs spend a surprising amount of time in very ordinary loops. A developer may scan text, compare bytes, process arrays, or apply the same math operation to many values. When the input is large enough, SIMD can offer a localized speedup that comes directly from handling multiple items at once. If a vector instruction works on 4, 8, or more values in parallel, the result can be much faster than a naive scalar loop, which handles only one value at a time. Hashimoto stresses that this payoff is most meaningful when code runs over hundreds, thousands, or millions of elements, not when it only touches a tiny amount of input.

One reason SIMD seems intimidating is its reputation. Some famous projects push SIMD to an extreme and use techniques that are hard to read or explain. That can scare developers away and make them think they must get deep in the weeds before they can benefit. Hashimoto argues for a more approachable mental model. In his view, the common case has a clear pattern. First, you broadcast constants and prepare any accumulators. Next, you loop over the input one vector-width chunk at a time. Then you perform the same comparison or arithmetic across all lanes, meaning the separate positions inside the vector. After that, you reduce or store the result, and finally you handle the scalar tail, the small remainder that does not fill a whole vector.

That five-step shape is important because it lowers the barrier to entry. Instead of treating SIMD as magic, developers can break it down into a repeatable process. Hashimoto even suggests that once you learn this pattern, writing basic SIMD can feel almost as natural as writing a normal loop. He uses Zig in his examples, but the lesson is broader than any one language. The main idea is that many languages and platforms expose similar concepts, even if the exact syntax differs. For engineers, this means the skill is portable. Learning to recognize when a loop can be decomposed into vector-friendly work is often more valuable than memorizing one language-specific feature.

The article also raises a fair question: why can’t the compiler just do this automatically? Modern compilers can sometimes transform simple loops into vectorized code, and they often do. However, they do not always succeed. Real-world code may have branches, memory patterns, or other details that make automatic optimization difficult. In some cases, the compiler needs very predictable logic before it can safely vectorize a loop. As a result, developers who understand SIMD are in a better position to spot opportunities, write code in a more SIMD-friendly style, and judge when manual effort is worth it. At the same time, Hashimoto is careful not to oversell it: if the work becomes too awkward, that is often a sign to skip SIMD for now.

The broader message is not that every programmer should become a low-level optimization specialist overnight. It is that SIMD deserves a place in every developer’s toolbox, much like understanding basic memory use or algorithmic complexity. As hardware keeps offering parallel features, developers who ignore them may leave performance on the table, especially in text processing, parsing, multimedia, and numeric workloads. The key takeaway is practical rather than ideological: know the basics, learn the common shape, and recognize the trade-off between cleaner code and faster execution. Even a modest grasp of SIMD can sharpen how engineers think about loops, throughput, and performance bottlenecks.

For many years, user experience design mostly meant screen design. Teams focused on menus, buttons, forms, and page flows. That model is still useful, but it is no longer the whole picture. A growing number of products now let people interact through chat, voice, and AI agents that can complete tasks with less direct input. In other words, the interface is starting to move beyond the screen. The change is not just about style. It affects the basic relationship between users and digital products.

One reason this shift matters is that different interfaces solve different problems. Chat works well when a user has a vague goal or needs help expressing what they want. A person can describe a need in natural language and let the system ask follow-up questions. But chat can also create friction. If a user already knows the exact action they want, a conversation may be slower than a clear button or a simple filter. This is why many designers now favor hybrid interfaces. These combine structured controls for predictable tasks with conversation for open-ended requests.

Voice adds another layer to this change. It can feel fast and natural, especially when a person is driving, cooking, walking, or doing another hands-busy task. In those moments, speaking is often easier than tapping through a screen. Still, voice is not a silver bullet. People may not want to speak aloud in public, and spoken commands can be misunderstood. Voice responses are also harder to scan than text. With a screen, users can quickly look over choices. With audio, they must listen in sequence, which can be tiring if the answer is long or complex.

The biggest shift may come from agentic AI. This means systems that do more than answer questions. They can carry out a goal across several steps, such as comparing options, booking something, or handling routine support work in the background. That sounds convenient, but it also rewrites UX from first principles. If the system acts on the user’s behalf, designers must think carefully about trust, visibility, and control. Users need to know what the agent is doing, why it chose one path over another, and how to step in when needed. Otherwise, automation can quickly become a double-edged sword.

This creates new design trade-offs. On one hand, reducing effort can improve the experience and save time. On the other hand, less visible interaction can make products feel opaque. A clean interface is not always a clear interface. Designers may need to surface status updates, permissions, confidence levels, and fallback options without overwhelming the user. They also have to account for errors, edge cases, and moments when AI gets the intent wrong. In practice, good UX in this new era may depend less on drawing perfect screens and more on shaping behavior, setting expectations, and designing recovery paths.

The broader lesson is that UX is not disappearing; it is splintering into new forms. Screens still matter, but they are becoming one channel among several. Products are now expected to switch between text, voice, structured controls, and background automation depending on the situation. For companies, that raises tough questions about consistency, reliability, and measurement. For users, it may bring more convenience, but only if the experience feels predictable and respectful. The next generation of UX will likely belong to teams that know when conversation earns its place, when structure is better, and when the best interface is the one that stays out of the way.

London Gatwick Airport has become the first airport in the UK to introduce a robotic parking service for passengers. The idea is simple: instead of driving around a crowded parking lot and searching for a space, travelers leave their car in a private cabin near the South Terminal. After that, an autonomous robot takes over. The airport says this can save time, reduce stress, and make the whole parking process more convenient. The service has been launched with Stanley Robotics and is available for advance booking before its first customer journeys in August.

The system is designed to be easy to use. A passenger drives into an enclosed drop-off cabin and scans their booking. Then they park the car inside, get out, and keep their keys. This is one of the main selling points of the service. In traditional valet parking, drivers usually hand over their keys to staff, which some people dislike. At Gatwick, the robot slides underneath the vehicle, lifts it by its tires, and carries it to a secure storage area. When the passenger returns from their trip, the system uses their flight details to track their arrival and prepares the car in a collection cabin.

This setup aims to remove some of the usual friction in airport parking. Many drivers find it tiring to circle a large parking area, especially when they are already worried about check-in times, traffic, or family luggage. By cutting out that step, the airport hopes to speed up the journey from car to terminal. The facility is within walking distance of the South Terminal, and a free shuttle bus is also available. Gatwick also says that if someone accidentally leaves an essential item in the car, on-site staff can step in to retrieve it.

Beyond convenience, robotic parking could give airports a practical way to use limited space more efficiently. In a normal parking lot, cars need enough room around them for drivers to open doors and walk away. In a robotic system, that is not necessary once the vehicle has been dropped off. As a result, cars can be parked much closer together. This means an airport may be able to increase parking capacity without building a new structure. For a busy airport facing future growth, that could be a major advantage, especially where land and construction costs are high.

Still, the service also raises questions that often come up when automation gains traction in public spaces. Some travelers may welcome a hassle-free experience, while others may feel uneasy about letting a machine move their car. Trust, reliability, and clear communication will be important. If the robot system stops working, passengers will expect quick support and a backup plan. There are also limits on which vehicles can use the service, so it is not a one-size-fits-all solution. In other words, the technology sounds promising, but its real value will depend on smooth day-to-day operation.

For the wider transport and tech sectors, Gatwick’s move is worth watching. Airports are under pressure to improve customer experience while getting more out of existing infrastructure. Robotic parking tries to do both at once. If the rollout goes well, other airports may follow, not only in the UK but in other crowded travel hubs. The bigger lesson is that automation is not always about flashy robots in public view. Sometimes it works best behind the scenes, taking over repetitive tasks and freeing people from small but stressful parts of a journey.

Code migration used to be a long and risky job. Moving a production codebase from one language to another could take years, and many teams put these plans on the back burner. A recent Anthropic article argues that AI agents are changing that picture. It describes how engineers used Claude Code to run large migrations much faster than before. In one example, Bun was ported from Zig to Rust, producing about a million lines of code in less than two weeks. Another example involved moving a Python codebase to 165,000 lines of TypeScript over a weekend. The main idea is simple but powerful: instead of fixing every line by hand, engineers should tighten up the process that creates, tests, and reviews the new code.

According to the article, an AI code migration is not just automatic translation. Engineers first define rules for how the old code should map to the new language. Then AI agents generate code, compile it, run tests, and compare behavior with the original system. This loop repeats until the results match closely enough. Anthropic says this approach can compress work that once felt like a multi-year endeavor into weeks. The article presents this as a shift in how teams think about migration. The focus moves away from file-by-file rewriting and toward building a reliable verification loop. In other words, the process becomes the real product, and the generated code is the output of that process.

The article also explains why companies migrate in the first place. A language choice that once made perfect sense can become a constraint later. Ecosystems change, tools improve, and team needs evolve. In Bun's case, Zig had offered strong performance and simplicity at an earlier stage. But as the project grew and usage expanded, the trade-offs became harder to ignore. Anthropic suggests that many teams have long-deferred migrations for similar reasons. They may want a larger talent pool, stronger tooling, easier maintenance, or better alignment with the future roadmap. In the past, those benefits were often not enough to justify freezing major work for months or years. With AI, that calculation may start to look different.

Still, the article does not claim that migration is suddenly effortless. A fast port can be a double-edged sword if teams trust the output too quickly. Anthropic stresses the need for phase gates, adversarial review rounds, and parity checks. These are practical ways to challenge the new code instead of assuming it is correct. For example, one final check compared every command's output against the original Python version. In the Bun migration, the existing test suite passed in continuous integration before the code was merged, but regressions still appeared later and had to be fixed. That detail matters because it shows that strong testing lowers risk but does not wipe it out. Human judgment still matters, especially when systems are used at scale.

One useful lesson from the article is that AI works best when engineers stay out of the weeds and think carefully about feedback loops. If a migration produces wrong results, the answer is not only to patch the latest file. The deeper task is to improve the instructions, tests, review steps, and stopping rules so the system can correct itself repeatedly. This mindset is familiar in engineering: a weak process creates weak results. Anthropic's examples suggest that AI agents are most effective when they operate inside a disciplined workflow rather than as free-form coding assistants. That may be the part of the story that gains traction beyond these specific projects.

For software teams, the bigger implication is not that every old codebase should be rewritten tomorrow. Migration still costs time, attention, and operational risk. It can also disrupt feature work if leaders chase a shiny new language without a clear reason. But AI may lower the threshold for projects that were previously too expensive to consider. Teams will now need to ask sharper questions: Is the current stack truly holding us back? Do we have enough tests to verify behavior? Can we roll out the new system safely and measure regressions early? The answers will decide whether AI-driven migration becomes a breakthrough tool or just another source of technical debt.