📰 English IT Daily · 2026-08-03

GitHub has started a public preview of stacked pull requests, a new way to break one large code change into a series of smaller pull requests. Instead of asking reviewers to read one huge diff, developers can organize work into focused layers. Each layer has its own pull request and depends on the one below it. This approach is designed to make code review easier to follow and less tiring. It also fits a wider trend in software teams: trying to ship larger features without letting review quality slip.

In many teams, pull requests have become a bottleneck. Developers can now write code faster than before, partly because AI tools can generate drafts, boilerplate, and test cases in seconds. But that speed can create a new problem. When changes arrive in very large batches, reviewers struggle to understand what really matters. Small mistakes can hide inside a giant diff. Stacked pull requests try to solve that by turning one big piece of work into smaller, dependency-ordered parts that can be reviewed one by one or in parallel.

GitHub says stacks are built into its platform, so existing reviews, checks, and merge requirements still work out of the box. A developer begins with one branch and pull request for the first layer, then adds more branches and pull requests on top of it. Each new pull request targets the layer below, not the main branch. On the pull request page, reviewers can use a stack map to see where that layer fits into the larger effort. This should reduce confusion and keep people from getting lost in the weeds when a feature touches many files.

The company also highlights a practical advantage: teams can merge one layer, several layers, or the whole stack in one click when everything is ready. If only part of the stack is approved, lower layers can be merged first, while the pull requests above stay open and automatically rebase and retarget. That removes some manual branch management, which is often a source of friction in long-running work. GitHub is also offering support through github.com, the CLI, the mobile app, and a CLI extension called gh-stack, so teams can choose the workflow that suits them best.

Early comments shared by GitHub suggest the feature is gaining traction among teams working on complex products. Supporters say stacked pull requests tighten the feedback loop because reviewers can focus on a narrow scope and give more accurate comments. They also argue that stacks preserve momentum on large projects, since different teammates can review separate layers at the same time. For teams with strict branch protections, this matters because speed and safety often pull in opposite directions. A system that keeps both in balance could have broad appeal.

Still, stacked pull requests are not a magic fix. They ask developers to think more carefully about how to split a feature into logical layers, and that discipline may not come naturally to every team. If a stack becomes too deep, people may still find it hard to track dependencies or understand the full picture. There is also a learning curve for new workflows and habits. Even so, the public preview is worth watching. If GitHub can make stacked work feel native rather than like a tool bolted on top, it may reshape how teams handle large code reviews.

A new case study in AI is getting attention because it challenges a common belief in the industry. Many companies assume that the best results always come from the biggest and most expensive frontier models. However, the report argues that a smaller open-source model, after careful fine-tuning, performed better on a real business workflow: catalog review. This task means checking product listings for quality and accuracy. In the test, the model was trained for a very specific job, and the result was not just strong quality. It was also far cheaper than the frontier systems that were compared.

The model in question was a 9B open model, which means it had about nine billion parameters. That is much smaller than many headline-grabbing systems. Still, size was not the whole story. The team used GRPO fine-tuning, a training method that pushes a model toward better decisions on a chosen task. In this case, the workflow, tools, images, and scorer were kept the same across the comparison. According to the source, the fine-tuned open model beat every frontier configuration they tested on that catalog-review process. Just as striking, the cost was reported at about $0.50 per 1,000 listings, which put the price far below the other setups.

This matters because many firms have spent heavily on AI without seeing clear returns at scale. Since the release of ChatGPT in 2022, leaders have asked what AI can do for their business. Early use cases were low-risk, such as summaries, email drafts, and first versions of documents. Later, companies tried to move up the value chain into coding, content production, and even systems connected to internal knowledge and tools. But the source notes that measurable results have often been limited. Some AI-first companies surged ahead, while others lagged behind despite spending time, money, and attention on adoption.

One key lesson is that success may depend less on chasing the newest model and more on redesigning the process around AI. The article says companies often drop a model into an old workflow that was built for humans. When that happens, old bottlenecks can soak up the gains before they reach the business. Research mentioned in the source points to workflow redesign as a major factor in financial impact. In simple terms, firms need to rethink approvals, reviews, and handoffs instead of adding AI on top of an unchanged system. Otherwise, productivity improvements may look good in demos but fail to move the needle in practice.

Another lesson is that AI systems need tailored business context. Prompting and retrieval can give a model the right information at the right time, but doing that well is its own engineering challenge. Teams must connect the right sources, control access, and make sure each request sees only the information it should. There is also a trade-off between general power and task focus. Frontier models are more flexible across many jobs, but a smaller model tuned for one narrow workflow can sometimes outperform them where precision matters most. For companies reviewing large volumes of listings, that can be a game changer.

Still, this does not mean frontier models are no longer useful. A task-trained model can shine in a narrow lane, but businesses rarely run on one task alone. They need systems that are reliable, maintainable, and safe, and they must watch how performance changes over time. Even so, the broader message is clear: intelligence ownership is gaining traction. Instead of renting the most advanced model for every request, companies may build an advantage by training open models on their own high-value workflows. For technical teams, the takeaway is to test carefully, measure outcomes, and focus on where a custom system can deliver both quality and cost control.

A new open-source project called TurboFieldfare is drawing attention because it runs Gemma 4 26B-A4B, a large language model, on any Apple Silicon Mac with only about 2 GB of RAM for model weights and cache. That claim stands out because models of this size usually need far more memory. The project is built in Swift and Metal, and it is designed for M-series Macs, including lower-memory machines such as 8 GB MacBooks. In simple terms, TurboFieldfare tries to squeeze a very large model into a much smaller memory budget so more people can test it locally.

The basic idea is not to load the full model into memory at once. According to the project page, the installed text-only model takes about 14.3 GB of storage, but the runtime keeps only a shared core and the KV cache in memory. The KV cache stores information from earlier tokens so the model can continue a conversation without starting from zero each time. Instead of keeping everything in RAM, TurboFieldfare streams in only the experts needed for each token from the SSD. This design is model-specific, not a wrapper around more general inference tools, and that is one reason it has gained traction online.

This approach matters because memory has become a bottleneck for local AI. Many users have strong interest in running models on their own devices for privacy, offline use, lower cost, or simple curiosity. However, large models often push consumer hardware to its limits. TurboFieldfare offers a workaround: trade some dependence on fast storage for much lower memory use. That does not mean there is no catch. Reading pieces of the model from an SSD can affect speed, and real performance depends on prompt length, generated length, hardware, and the state of the page cache.

The repository includes a native Mac app, a command-line interface, and an experimental local server that follows an OpenAI-compatible style. The first run downloads and repacks the pinned model, which is a fairly large download. After that, users can load the model and start generating text. The project page also shares benchmark reference points, showing that output speed varies a lot across devices. In other words, the headline result is impressive, but the fine print still matters. A system that fits in memory is not automatically fast in every real-world case.

For developers, TurboFieldfare is interesting not only as a product but also as an engineering statement. It shows how tightly tuned runtimes can challenge common assumptions about what consumer hardware can do. Instead of chasing a one-size-fits-all design, the project focuses on one model and tries to optimize deeply around it. That trade-off can pay off in performance or efficiency, but it may also narrow flexibility. If a team wants broad model support, a specialized engine may be harder to maintain than a more general platform.

The bigger picture is that local AI is moving into a new phase. For years, people often assumed that larger models belonged mainly in the cloud or on expensive workstations. Projects like TurboFieldfare complicate that view by showing that careful systems design can move the goalposts. Still, this is not a magic bullet. Users must consider storage needs, setup time, and possible speed limits. Even so, the project hints at a future where advanced models become more accessible on everyday laptops, and where clever engineering can punch above its weight.

Bun, a fast JavaScript runtime, recently drew attention for a very unusual engineering story. Its creator, Jarred Sumner, described how parts of Bun were rewritten from Zig to Rust in a very short time with the help of an AI tool called Fable. The speed of the rewrite made headlines, but the bigger question is not just how fast it happened. The more useful question for engineers is what this case reveals about where AI fits into real production work, especially in large and complex codebases.

To understand why this matters, it helps to know what Bun does. Bun is not a small side project. It supports tasks such as JavaScript, TypeScript, and CSS transpiling, minifying, bundling, test running, and npm-compatible package management. It also handles module resolution and other runtime features. In other words, it has many moving parts, and a lot of production systems depend on it. That means any major rewrite is high stakes. A team cannot simply move fast and hope for the best when reliability is on the line.

One key reason for the rewrite was memory safety. According to the source material, Bun had ongoing memory-related bugs while using Zig. These included memory leaks, crashes, and out-of-bounds writes. The team had already put safeguards in place, such as memory leak tests, and even patched the Zig compiler to reduce some issues. Still, the problem did not go away. Sumner explained that mixing garbage-collected values with manually managed memory became a constant source of stability concerns. In practical terms, engineers had to be meticulous about every allocation, every free, and every possible exception path.

This is where Rust came in. Rust is known for offering memory safety without garbage collection in many common cases, while still aiming for strong performance. For a project like Bun, that promise is appealing. If the language can prevent a class of bugs before the code even ships, the team may spend less time firefighting production issues later. The AI angle made the story even more striking. Instead of treating AI as a chatbot for small code snippets, this project suggests AI may be gaining traction as a migration tool for difficult, repetitive, and structurally complex rewrites.

Still, this does not mean every team should rush to copy the same playbook. A rapid rewrite is a double-edged sword. AI can speed up translation between languages, but it can also introduce subtle errors, weak assumptions, or code that looks correct at first glance yet behaves badly in edge cases. For systems work, those edge cases matter. A migration also depends on strong tests, clear architecture, and engineers who can review the output with care. AI may reduce the manual burden, but it does not remove the need for judgment, especially when production reliability is on the line.

The bigger lesson is that AI may be most valuable not when it replaces engineers, but when it helps them tackle work they already understand but would rather not do line by line. Language migration, refactoring, and mechanical rewrites are good examples. Bun’s story also reminds teams to look beyond raw speed. The real benchmark is whether the new codebase becomes easier to maintain, more stable, and less stressful to operate at scale. In the months ahead, engineers will be watching whether this rewrite delivers those long-term benefits, not just impressive short-term velocity.

vocabulary

A new open-source tool called agent-device is drawing attention in the AI world. It is a command-line interface, or CLI, designed to let AI agents inspect and control real or virtual devices. According to its GitHub page, the tool works across iOS, Android, web, macOS, Linux, and some TV platforms. The basic idea is simple: instead of only reading code, an AI agent can also look at a running app, take actions inside it, and check whether a change really works. That could close a long-standing gap between writing code and verifying it in practice.

The project comes from Callstack, and its description says that it follows an inspect-act-verify process. In other words, an agent first inspects the current screen, then performs an action, and finally verifies the result. Where supported, the tool can read token-efficient accessibility snapshots. This means it can get a compact text view of what is on the screen, including buttons and other elements, without relying only on screenshots. The agent can then find elements by reference or selector, run actions on the device, and save evidence for later review. In theory, this gives an AI system a tighter feedback loop when it is testing app behavior.

This matters because many coding agents are still strong in code generation but weaker when software meets the messy reality of actual devices. Mobile apps, TV apps, and desktop apps often behave in ways that are hard to predict from source files alone. Layout issues, missing buttons, focus problems, or broken navigation can slip through the cracks if no one checks the running app. A tool like agent-device aims to bridge that gap. It may also reduce the amount of manual testing needed for routine tasks, especially when a developer wants an agent to confirm a fix before asking a human reviewer to spend time on it.

The repository also points to practical setup details. The quick start says the CLI requires a recent version of Node.js, and web automation needs an even newer one. It also includes a doctor command so users can check whether their environment is ready before giving the tool to an agent. That advice is more than housekeeping. Device automation can be fragile if permissions, emulators, simulators, or local dependencies are not configured correctly. Running checks early can head off confusion later. For engineering teams, this is a reminder that agent-based workflows still depend on careful setup and clear operational discipline.

Still, this kind of tool is a double-edged sword. Giving an AI agent the power to control a device sounds efficient, but it also raises questions about reliability, safety, and scope. If an agent taps the wrong button or misunderstands the screen state, it may produce misleading test results. Evidence saving can help with audit and review, yet teams will still need guardrails. They must decide which actions are safe, how much autonomy to allow, and when a human should step in. For now, the sensible view is that these tools are assistants, not replacements for thoughtful QA and engineering judgment.

Even so, tools like agent-device may gain traction as AI coding systems become more common in daily development. The strongest appeal is not magic automation but a more grounded way for agents to interact with software as users do. If that approach matures, developers may spend less time in the weeds on repetitive checks and more time on design, debugging, and product decisions. It is also worth watching how support expands across platforms and how teams integrate this kind of CLI into testing and review pipelines. The bigger trend is clear: AI agents are moving beyond text and into real interfaces.

A new benchmark from Wafer has drawn attention to an unusual result in AI hardware. The company says AMD’s MI355X can run the open model Kimi K3 with better performance per dollar than NVIDIA’s B300. That matters because Kimi K3 is not a small model. In the source context, it is described as having 2.8 trillion parameters, which means it needs a huge amount of high-bandwidth memory, or HBM, just to hold the model weights. Once a long context window and its KV cache are added, memory capacity becomes a serious limit, not just raw speed.

This is why the comparison is interesting. The B300 is still faster in total throughput on a node, according to Wafer’s results. However, the MI355X has the same 288 GB memory capacity per GPU and costs much less per GPU on average. In Wafer’s benchmark, that price gap tipped the scales. On a test with a 1,024-token input and a 400-token output, the MI355X reached 952 tokens per second per node and 118 tokens per second in single-stream decoding. Wafer says that means the AMD system came out ahead on performance per dollar, even though the B300 remained the absolute throughput leader.

The result also highlights a broader shift in AI infrastructure. For years, many teams have focused mainly on compute power. But frontier open models are getting so large that memory capacity can become the deciding factor. Wafer argues that Kimi K3 is one of the first models where this memory-heavy design gives AMD a practical edge over a B200 setup. In the reported comparison, the B200 deployment needed two nodes because one node could not fit the model weights together with a large KV cache pool. That created extra communication overhead between nodes, which dragged down decoding speed on the critical path.

Even so, this was not simply a plug-and-play win for AMD. The article makes clear that software support has often been the sticking point for AMD GPUs. Inference tools may arrive later, and some kernels can lag behind CUDA-based versions. Wafer says that gap is beginning to narrow, partly because model optimization work is improving and partly because AMD provided day-0 support for Kimi K3. Still, Wafer had to tune the system further to reach its current numbers. A key lever was speculative decoding, a method that uses a draft model or draft path to predict tokens and speed up generation when the guesses are accepted.

According to the source context, Kimi K3 did not ship with built-in draft tensors for common speculative methods, so Wafer used an external block-diffusion draft approach. On CUDA, that path worked more smoothly. On ROCm, the team ran into a scheduler error related to a missing function in the accept-sampling verifier. This detail may sound in the weeds, but it shows a real point about modern AI systems: benchmark headlines often hide a lot of engineering effort. Hardware value is not only about chip specs. It also depends on kernel quality, framework maturity, debugging time, and how quickly a team can iron out edge cases.

For engineers and buyers, the main takeaway is not that one vendor wins across the board. It is that model size is reshaping the buying decision. If a model fits cleanly on one node with enough memory, a cheaper GPU can punch above its weight on value. If software support is weak, that advantage can disappear just as quickly. In other words, memory capacity, interconnect costs, and optimization effort now matter almost as much as peak speed. As open models continue to grow, more teams will likely watch not only benchmark charts but also how efficiently different systems serve very large models in real production settings.

Technical documentation often grows in a messy way. A team starts with a few guides, then adds reference pages, onboarding notes, and troubleshooting tips. Over time, users struggle to find what they need, and writers are not sure what kind of page they should create. Diátaxis is a method that tries to solve this problem. It presents a systematic approach to writing and organizing technical documentation. Instead of treating all docs as the same, it begins with a simple idea: different users have different needs, so documentation should reflect those needs clearly.

At the center of Diátaxis are four forms of documentation: tutorials, how-to guides, technical reference, and explanation. Tutorials are for learning by doing, usually step by step, with the goal of helping a beginner complete something successfully. How-to guides are more practical and task-focused. They show users how to solve a specific problem. Technical reference is different again. It gives factual, structured information, such as commands, options, rules, or behaviors. Explanation goes one level deeper and answers why something works the way it does. Diátaxis argues that these four types should not be mixed up, because each one serves a distinct purpose.

This distinction may sound obvious, but in practice many docs blur these categories. A page called "Getting Started" may begin like a tutorial, turn into a reference list, and end with design background. That can leave readers in the weeds. A newcomer may want guided learning, while an experienced engineer may just need one exact setting. If both audiences land on the same page, neither may get what they came for. Diátaxis tries to cut through that confusion by giving writers a clearer map. It also supports better information architecture, meaning the overall structure of a documentation site.

Another reason the idea is gaining traction is that it is light-weight. It does not force teams to use one tool, one publishing system, or one company style. Instead, it acts more like a compass. Teams can apply it to internal docs, open-source projects, product manuals, or developer portals. The method also gives maintainers a practical way to think about quality. When a document feels weak, they can ask a direct question: is this page trying to do too many jobs at once? That simple test can be surprisingly effective, especially in large projects where content builds up over time.

Supporters say Diátaxis improves docs for both readers and contributors. Readers can discover the right resource more quickly. Contributors have a shared language for deciding what to write and where it belongs. The source material behind Diátaxis also notes that the approach has been adopted in many documentation projects, including well-known technology organizations. Still, it is not a magic fix. A poor tutorial does not become good just because it has the right label. Teams still need editorial discipline, regular review, and a real understanding of user needs. In that sense, Diátaxis is a guide for thinking, not a shortcut.

For engineering teams, the broader lesson is that documentation is not only a writing task; it is part of product design and developer experience. Clear docs can reduce onboarding time, lower support costs, and make a system easier to trust. As systems become more complex, the need for docs that are easy to navigate will only grow. Diátaxis offers one structured way to meet that need. It helps teams step back, look at the purpose of each page, and organize content with more intention. In a field where documentation often lags behind the product, that kind of clarity can go a long way.

A new idea is gaining traction in the tech world: do not just automate old systems — remove the need for them entirely. This view was recently restated by Union Square Ventures, or USV, a venture capital firm. The phrase comes from an older business argument: the biggest opportunities often come from replacing a market structure, not from making it a little faster or cheaper. In simple terms, a company does something much bigger than selling tools to the current players. It changes who holds power, who can join the market, and what customers expect.

USV says this idea has shaped its thinking for years. It points to earlier shifts such as direct-to-learner education, programmable money, and publishing without traditional publishers. In each case, the internet lowered the cost of distribution. That weakened companies that had acted as gatekeepers. A gatekeeper is a person or institution that controls access to something valuable. When that control is reduced, customers can often go straight to the source. According to USV, AI may now do something similar for expertise, which means specialized knowledge that was once hard to reach.

The key claim is that expert-level intelligence is becoming more abundant. If people can access useful advice, analysis, or decision support through AI agents, they may no longer need to rent expertise from established institutions in the same way. That could reset the table in many industries. Instead of improving the current workflow at the margins, an AI product could let customers bypass the old path completely. The result is not just higher efficiency. It is a shift from the supply side, where experts and firms hold most of the power, to the demand side, where users can act more directly.

USV gives several examples. One is Doctronic, which aims to put an AI doctor into a smartphone and, in some cases, even support legal prescription writing. Another is Isembard, which is described as packaging the know-how of running a high-precision manufacturing line into software, so industrial capability is not limited to a few experienced machine shops. A third example is Cofounder, which aims to launch and manage full businesses for customers instead of only offering separate tools for product, sales, or marketing. The common thread is clear: these companies are not just streamlining old processes. They are trying to overhaul the structure underneath them.

This argument is exciting, but it is also a double-edged sword. If AI removes gatekeepers, it may expand access and lower costs. That could be good for patients, founders, small manufacturers, and many others. But gatekeepers do not only slow things down; they also provide quality control, accountability, and legal responsibility. In medicine, for example, trust, safety, and regulation matter a great deal. In manufacturing, mistakes can be expensive or dangerous. So the real test is not whether AI can imitate expert work in a demo. It is whether these systems can perform reliably in the real world and at scale.

For engineers, founders, and business leaders, the larger lesson is strategic. When a new technology appears, it is tempting to ask how it can automate an existing job. That is still useful, but the bigger question may be whether the job, team, or company exists only because access to expertise has been scarce. If AI makes that expertise easier to deploy, whole categories could be up for grabs. Still, not every market will be obliterated overnight. Adoption usually depends on trust, regulation, user habits, and economics. The next few years will show which industries merely add AI features and which ones are truly rebuilt around it.