📰 English IT Daily · 2026-07-01

Postgres 19 is now in beta, and early signs suggest that this release could matter to both developers and operators. Some Postgres versions are remembered for one headline feature, while others stand out because they smooth out daily work in small but meaningful ways. According to early coverage of the beta, Postgres 19 seems to offer a bit of everything: a major built-in tool for storage maintenance, stronger support for SQL property graph queries, more complete logical replication, and steady upgrades across performance, monitoring, and query planning. Because it is still a beta, some details may shift before the general release, but this is already a good time to look at what is coming and why it matters.

One of the most practical additions is a new REPACK command built into core Postgres, including REPACK CONCURRENTLY. To understand why this is a big deal, it helps to know a common operational problem called table bloat. Over time, updates and deletes can leave behind wasted space, which can hurt performance and make storage less efficient. Existing tools such as VACUUM FULL can reclaim space, but they often require heavy locking. That means applications may need to wait, which is risky in a production environment. For years, many teams relied on external extensions like pg_repack to deal with this pain point. The fact that a similar feature is now built in shows that the need is widespread and long-standing.

The keyword here is “concurrently.” In simple terms, that means the system can reorganize or rewrite a table while reducing the disruption to normal activity. For large production systems, that quality-of-life improvement could be hard to overstate. Database teams often need to choose between maintenance and availability, and that trade-off can become a headache at scale. A built-in concurrent repack feature will not remove every risk, but it lowers the barrier to performing routine maintenance in a safer and more predictable way. For teams that operate busy systems around the clock, this could become one of the most appreciated changes in the whole release, even if it does not sound flashy in the release notes.

Another area getting more practical is partitioning. Partitioning means dividing a very large table into smaller pieces, usually based on time or some other key, so that the system can manage and query it more efficiently. Postgres has supported partitioning for years, but in the past it sometimes felt like a feature that worked best for experts who knew the internals and sharp edges. Postgres 19 continues a gradual shift toward a more approachable model by adding support for merging and splitting partitions. This may sound simple, but it reflects an important truth: good system design is rarely static. A partition strategy that looks reasonable today may become awkward later as workloads, retention rules, and growth patterns evolve.

The ability to merge and split partitions gives teams more room to adjust without redesigning everything from scratch. For example, a company might begin with quarterly partitions, then later decide that some busy periods need monthly partitions instead. Or it may discover that older partitions can be merged because the access pattern has changed. In real operations, these situations come up more often than people expect. Systems grow unevenly, and traffic is not always predictable. Features like this acknowledge that reality. They do not promise perfect design from day one; instead, they make it easier to course-correct as a system matures. That is often more valuable than a feature that looks impressive in a demo but sees limited use in production.

Beyond these changes, Postgres 19 also appears to continue work on logical replication, EXPLAIN, COPY, VACUUM, monitoring, performance, and planner behavior. None of these areas is new, but incremental progress matters because production reliability often depends on many small improvements rather than one dramatic leap. The overall picture is a release that balances eye-catching features with careful operational refinement. That combination may help Postgres keep gaining traction with teams that want both flexibility and a mature foundation. The main thing to watch next is how the beta develops and whether these features remain stable and easy to use by general availability. If they do, Postgres 19 could land as a release that quietly improves a wide range of real-world workloads.

Many developers can write a CUDA kernel that runs correctly, but fewer know what happens under the hood after they launch it. A recent technical deep dive follows a very simple example: adding two vectors on a GPU. On the surface, the code looks short and clear. The programmer allocates memory, copies input arrays from the CPU to the GPU, launches a kernel with many threads, and then copies the result back. However, that clean workflow sets a surprisingly long chain of events in motion inside the compiler, the operating system, the driver, and the GPU itself.

The first step is compilation, and this is where the process already becomes more layered than many people expect. The CUDA tool most developers use, nvcc, is not one compiler but a driver that calls several tools. Host code goes to the normal CPU compiler, while device code goes through extra stages. In the example from the source, one tool produces PTX, which is a virtual instruction set for NVIDIA GPUs. Another tool then turns that PTX into SASS, which is closer to the actual machine instructions the target GPU can execute. In short, the source code is broken down into different forms so both the CPU side and the GPU side can do their own jobs.

This distinction matters because PTX is not the final hardware language. It is more like an intermediate representation that keeps options open. PTX can describe registers and operations in a flexible way, while the later assembler stage maps that logic to a real chip. The sample PTX in the article shows the kernel doing familiar work in a lower-level form: computing each thread’s index, checking whether it is inside the array bounds, loading values from global memory, adding them, and storing the result. When you read it closely, the high-level kernel stops looking magical and starts to look like a set of small, mechanical steps.

After compilation, the next stage is launch and execution. This part can sound abstract, but the key idea is simple: the CPU asks the driver to submit work to the GPU, and that request travels through several system layers before the GPU begins to run the kernel. The source describes a striking amount of activity behind one tiny program, including many CPU instructions, device-file interactions, numerous ioctls, and even a memory-mapped doorbell register used to notify the hardware. That phrase may sound dramatic, but it captures a practical truth: launching a kernel is not a single action. It is a handoff across boundaries, and each boundary has its own rules and overhead.

Once the kernel finally reaches the GPU, the hardware still has to organize the work. CUDA programmers think in blocks and threads, but the chip schedules execution in smaller groups often called warps. That means the GPU is constantly translating the programmer’s broad plan into something that fits the machine’s real execution model. For performance work, this is where developers can get into the weeds very quickly. Small choices about memory access, thread layout, or unnecessary transfers can become a bottleneck, especially at scale. A kernel that is functionally correct may still leave a lot of performance on the table if it does not match the hardware well.

Why does this matter beyond one vector-add example? Because GPUs now sit at the center of AI, scientific computing, graphics, and many production systems, yet the path from source code to execution is easy to take for granted. A clearer mental model can pay off when debugging strange behavior, estimating launch overhead, or deciding where optimization effort is worthwhile. At the same time, there is a trade-off. Most developers do not need to scrutinize every low-level detail every day. But when performance, cost, or reliability is on the line, understanding what happens under the hood can turn a black box into an engineering advantage.

A new HTTP method called QUERY has been defined in RFC 10008. At first, this may sound surprising because HTTP already has familiar methods such as GET, POST, PUT, and DELETE. In theory, an HTTP method is just a text label that tells a server what the client wants to do. In practice, however, the web depends on long-standing behavior around the standard methods. Browsers, proxies, firewalls, and many developer tools all make assumptions about them. That is why adding a new method is not a small step. It tries to solve a real problem without breaking old systems that still rely on older expectations.

The problem appears when developers need to request information with filters that are too complex for a normal GET request. For simple cases, query parameters work well. A client can ask for users by role, status, or sort order by putting these values in the URL. But things get messy when the request needs deep nesting, relational logic, long lists, or special characters. URLs can become very long, hard to read, and difficult to maintain. Some environments also have length limits. On top of that, arrays and nested structures are often represented in inconsistent ways, so one system may encode them differently from another.

A natural question follows: why not send a GET request with a request body, such as JSON? Technically, HTTP does not completely ban this idea, but it has never been a reliable pattern. Different clients and network tools may handle such requests differently. Some may reject the body, some may ignore it, and others may pass it through. That kind of uncertainty is a red flag for production systems. If behavior changes depending on the browser, proxy, or corporate firewall, then the same application may work for one user and fail for another. For engineers, that is exactly the kind of hidden compatibility issue that can turn into a headache later.

Because of that, many teams have used POST as a workaround for read-only queries that need a body. POST can carry JSON easily, so it solves the size and structure problem. Still, this approach comes with a trade-off. In HTTP semantics, POST is mainly intended for creation or processing, not for a safe read operation. It is also generally treated as non-idempotent, which means automatic retries can be risky if something goes wrong. By contrast, GET is expected to be safe and idempotent. Those properties matter for caching, retries, and the overall meaning of an API. Using POST for queries works, but it can blur the line between reading and changing state.

The new QUERY method aims to fill that gap. It gives developers a standard way to send a query in the request body while still making it clear that the intention is to retrieve information rather than create or update something. In other words, it tries to bring cleaner semantics to a pattern that already exists in the wild. This could be especially useful for search endpoints, analytics requests, and other cases where the request shape is too rich for a URL. It may also reduce the need to squeeze complex logic into query strings that are hard to debug and easy to log by accident.

Still, the road ahead may be gradual. A new standard on paper does not instantly gain traction across the web. Client libraries, gateways, security products, and browser-related tools all need time to catch up. Some systems may lag behind, and cautious teams may wait before rolling it out widely. Even so, the QUERY method is worth watching because it reflects a broader lesson in web engineering: small protocol details can have big practical effects. For API designers, the key question is not only what works today, but also what remains clear, interoperable, and reliable at scale over time.

A new debate about hiring technology started after HackerRank open-sourced an applicant tracking system, or ATS. The tool quickly gained traction online because many people wanted to test how an AI system would judge their resumes. But one writer who tried it found a surprising problem: the same resume did not get the same score each time. In repeated runs, the score moved up and down a lot, even when the resume and command stayed the same. That result raised a basic question: if companies use tools like this to filter candidates, are they measuring skill or simply letting luck decide?

According to the public description, the tool first turns a PDF resume into plain text. Then a language model is called several times to pull out structured details such as basic information, work history, education, skills, projects, and awards. It can also look at a candidate’s GitHub profile and add information from top repositories. After that, the system sends everything together to the model for grading. The score is based on areas such as open-source work, personal projects, work experience, and technical skills, with extra points possible for things like startup experience, a portfolio site, or a technical blog.

The main concern is non-determinism, which means the system can produce different results from the same input. In the reported test, scores spread across a wide range, even at a low temperature setting that should, in theory, make the model more consistent. Lowering the temperature further did not fully solve the issue. That matters because hiring often depends on cutoffs. If a company rejects everyone below a certain score, then a person near that line might pass in one run and fail in another. In that situation, the ATS starts to look less like a screening tool and more like a roll of the dice.

The reported results also suggest that some categories are steadier than others. Technical skills were relatively consistent, probably because they are closer to a checklist: either a resume shows a skill or it does not. Projects, however, varied much more. A model might describe the same project as lacking depth in one run and showing real-world impact in the next. That kind of judgment call is harder to standardize. The same concern applies to broader resume sections where the model must interpret quality, complexity, or business value instead of matching simple facts.

There is another twist. In the source discussion, work experience appeared unusually stable, but that stability may not mean true accuracy. If a scoring prompt is too broad or too generous, the model may give top marks to very different resumes. In other words, a stable result can still be misleading. This is why some critics say the problem is not just about one model or one implementation. Even if a stronger model narrows the score range, the core trade-off remains: AI can speed up evaluation at scale, but it may also hide weak judgment behind a neat-looking number.

To be fair, open-sourcing the ATS is useful because it lets the public inspect how the system works instead of treating it as a black box. Recruiters and engineers can examine prompts, test edge cases, and talk openly about failure modes. That transparency is a step forward. Still, the larger lesson is uncomfortable. When hiring systems rely on AI scoring, companies need careful validation, human review, and clear limits on how scores are used. Otherwise, an automated filter may screen out strong candidates for reasons that are inconsistent, hard to explain, and difficult to challenge.

Anthropic has introduced Claude Science in public beta as a research-focused version of its AI assistant. The product is presented as a partner for scientific work, not just a chatbot for general questions. According to the company, the app can run analyses, search research sources, and trace each step from early data wrangling to publication. In simple terms, it aims to reduce repetitive work so that scientists can spend more time thinking about the science itself. This launch reflects a wider trend: AI companies are trying to build tools for specialized professional tasks, not only for writing emails or summarizing documents.

A key point in Claude Science is reproducibility. In science, a result matters much more if other people can repeat the same process and check the same evidence. Anthropic says the app keeps track of how a result was produced and links outputs to the code behind them. The company also highlights rich scientific artifacts, including native views for proteins, structures, and molecules. That focus is notable because scientific users often need more than plain text. They work with images, tables, equations, lab notes, and complex file types, so an AI system must handle materials that are far more varied than ordinary office documents.

The promise of a tool like this is easy to understand. Scientific research often involves many small but time-consuming tasks: cleaning messy files, checking formats, comparing sources, and preparing results for papers. These tasks can slow teams down and pull researchers away from higher-level questions. If an assistant can take care of part of this workload, it could free up time and help projects gain traction faster. For small labs in particular, this kind of support may level the playing field by giving researchers access to stronger analytical help without requiring a large support staff.

Still, AI in research is a double-edged sword. Speed is useful, but scientific work also demands rigor, transparency, and caution. An AI tool may produce answers that sound confident even when they are incomplete or wrong. In a research setting, that risk is not just embarrassing; it can mislead a project or waste months of effort. That is why traceability matters. If users can inspect each step, review the code, and understand where a conclusion came from, they are in a better position to catch errors. Even then, human judgment remains at the heart of the process, especially in fields where small mistakes can have serious consequences.

There are also practical questions about adoption. Research organizations will want to know how well the app fits into existing workflows, how it handles sensitive information, and whether it performs reliably at scale. Some scientists may welcome an assistant that keeps them out of the weeds on routine tasks. Others may worry that too much automation could create distance between researchers and their own methods. In many technical fields, people do not only care about the final answer. They also care about the path that led there, because that path often reveals hidden assumptions, weak points, or new ideas.

For the broader AI industry, Claude Science is another sign that competition is moving toward domain-specific products. General-purpose models are still valuable, but companies increasingly want tools tailored to law, finance, medicine, engineering, and research. Public beta status means the product is still being tested in real-world use, so observers will be watching to see whether it can live up to its claims. The main question is not whether AI can assist science in principle. It is whether such systems can become trustworthy collaborators in work where accuracy, reproducibility, and accountability are non-negotiable.

Anthropic has announced Claude Sonnet 5, a new AI model designed to be its most agentic Sonnet model so far. In simple terms, “agentic” means the model can do more than answer a single question. It can plan a series of steps, use tools such as a browser or terminal, and carry out tasks with less human guidance. According to Anthropic, this kind of behavior was once limited to larger and more expensive models. Now, Sonnet 5 aims to bring similar abilities to a smaller and cheaper class of model, which could make advanced AI systems easier for more developers to adopt.

The launch also matters because the Sonnet line has played a key role in the rise of practical AI agents. Anthropic says earlier Sonnet models, including versions 3.5, 3.6, and 3.7, were among the first to show strong coding and tool-use skills in real workflows. More recently, however, the biggest gains in autonomous behavior came from the company’s larger Opus models. Sonnet 5 is meant to narrow the gap. Anthropic says its performance is close to Opus 4.8 in some areas, while costing less. That claim puts cost efficiency at the center of the story, not just raw capability.

Anthropic highlights improvements in reasoning, tool use, coding, and knowledge work, which refers to tasks that involve understanding information and making useful decisions from it. The company also describes Sonnet 5 as a strict improvement over Sonnet 4.6 on several evaluations. In tests related to agentic search and computer use, the model appears to offer a wider range of cost-performance options than earlier Sonnet models. At medium effort levels, it is said to deliver substantially better efficiency, and at higher effort levels, it can match Opus 4.8 on some tasks. For customers, this trade-off may be one of the biggest selling points.

Pricing is another reason the release could gain traction quickly. Sonnet 5 is available across all Claude plans and becomes the default model for Free and Pro users. It is also offered to Max, Team, and Enterprise users, as well as in Claude Code and on the Claude Platform. Anthropic introduced temporary launch pricing through August 31, 2026, with lower token costs before moving to standard pricing afterward. The broader message is clear: the company wants this model to be widely used, from individual developers testing ideas to organizations that need dependable performance at scale.

Safety remains a major part of the conversation around agentic AI, and this is where the announcement takes a careful tone. Anthropic says its assessments found a lower rate of undesirable behavior than in Sonnet 4.6, and it describes Sonnet 5 as generally safer in agentic contexts. The company also says the model shows a much lower ability to perform cybersecurity tasks than its current Opus models. That could reassure some users, because a powerful system that can browse, plan, and act on its own is a double-edged sword. The same features that save time for developers can also raise concerns if the system goes off the rails or is directed toward harmful goals.

For the wider AI market, Sonnet 5 reflects a shift in what customers now expect from models. The focus is no longer only on benchmark scores or chatbot quality. Businesses increasingly want systems that can take initiative, work with external tools, and complete parts of a workflow autonomously. At the same time, they need predictable costs and manageable risks. If Sonnet 5 lives up to its claims, it may strengthen the case for agentic AI in everyday engineering and knowledge work. The next thing to watch is whether developers find that the real-world gains outweigh the complexity of giving AI more freedom to act.

A recent essay on engineering leadership argues that the rules for managing technical teams are being rewritten. The writer reflects on lessons from fast-growing companies, where problems appear quickly and mistakes become visible much sooner than in slower organizations. He connects those lessons to today’s AI tooling, which is changing how fast engineers can build, test, and ship work. His main idea is simple: when writing first-pass code becomes much easier, leadership must focus less on raw coding speed and more on judgment, safety, and team design.

One major claim is that migrations, or large technical moves from one system to another, may no longer need a big team in every case. With better tools, one engineer or a very small group can drive most of the work and finish it far faster than before. However, this speed is a double-edged sword. If the migration is done poorly, even small rough points can confuse coworkers and damage their mental model of how the system works. In other words, lower execution cost raises the value of careful design. Individual judgment now carries more weight because one person can reshape shared systems much more quickly.

The essay also says that while first-pass code is almost free, working code is not. Code only becomes truly useful when it is supported by a strong development harness. That harness includes tests, delivery pipelines, validation environments, and ways to preview changes safely before they reach users. This is an important distinction. Many people now say that everyone in a company should write code, especially with AI assistants. But the harder part is not producing code on demand. The harder part is handling messy edge cases and making sure the result behaves well in the real world.

From that view, the writer suggests that companies should optimize the base case of process for agents, meaning software tools or automated systems. He argues that much of the routine path in modern engineering can be automated if the guardrails are good enough. For example, some parts of code review may be slower and less effective when handled only by humans, especially in low-risk areas. Automation will still miss things, but people miss things too. The key is to draw a clear line between ordinary changes and higher-risk work. If a company gets that distinction right, it can move faster without opening the door to unnecessary risk.

This thinking also leads to a challenge for common planning habits. Weekly or biweekly sprints may be too low-level if teams are spending too much time in the weeds. Human planning still matters, but leaders may need to work at a higher altitude, focusing on direction, ownership, and system boundaries rather than managing every small task. In this model, durable teams become even more important. Teams that stay together over time build domain context, trust, and a sharper sense of what good judgment looks like in their own area.

The broader message is not that AI replaces engineering leaders or that process no longer matters. Instead, leadership may become more demanding because leverage has increased. A strong engineer with good tools can accomplish far more than before, but can also create larger problems at speed. That means companies must invest in review systems, safe defaults, and team structures that support responsible autonomy. For engineering managers and senior developers, the revised rules are a reminder that modern productivity is not only about moving fast. It is about knowing where speed pays off, where caution is essential, and how to build an environment where both can coexist.