Cover photo

GitHub Makes Stacked Pull Requests a Native Workflow

The new public preview turns large code changes into smaller reviews without hiding their dependencies.

Large software changes create an awkward choice. A developer can open one enormous pull request that is difficult to review, or split the work across several branches and accept the job of keeping them synchronized.

GitHub is now trying to remove that trade-off. On July 30, the company placed stacked pull requests in public preview. The feature lets developers arrange a sequence of related pull requests as layers of one larger change. Each layer can be reviewed on its own, while GitHub keeps its position in the sequence visible.

This is not a new programming technique. Tools such as Graphite and Sapling have supported versions of stacked development for years. What is new is that the workflow now lives inside GitHub’s standard pull request interface and works with its existing reviews, automated checks and branch protection rules.

What a stack actually does

A pull request normally proposes moving changes from one branch into another. In a stack, the first branch targets the project’s main branch. The second targets the first, the third targets the second, and so on. Together they form an ordered chain.

Suppose a team is rebuilding a checkout page. The first pull request could reorganize shared data types. A second could replace the payment form. A third could add analytics. Reviewers can inspect those changes in focused pieces, even though the later work depends on the earlier layers.

GitHub adds a stack map to each pull request so reviewers can see what sits above and below the current layer. Crucially, the displayed difference is limited to that layer. Reviewers do not need to sift through the full accumulated change every time.

Developers can create stacks on GitHub’s website or use the new gh-stack command-line extension. GitHub also says the workflow is available through its mobile app and can be driven by coding agents. In the GitHub Copilot desktop app, one agent session can build on another and produce a corresponding series of pull requests.

Merging is where native support matters most. A team can merge the top ready layer together with every approved layer below it. It can also merge only the lower part of a stack. GitHub then rebases and retargets the remaining pull requests automatically, reducing the manual branch repair that often makes stacked work tedious.

Why this matters now

The immediate audience is software teams handling migrations, broad product features and other changes that cannot sensibly fit into one small commit. The timing also reflects a newer problem. Coding agents can produce changes faster than people can understand them.

That does not make review optional. Generated code still has to fit the architecture, pass tests and behave correctly in production. If faster generation simply creates larger pull requests, the bottleneck moves from writing code to evaluating it.

Stacks offer a practical response because they constrain the unit of review. A database change can be discussed separately from the interface that depends on it. Security-sensitive logic can receive specialist attention without blocking review of unrelated presentation code. GitHub says early users including teams working on Next.js and TED have used this structure to make larger projects easier to inspect.

The useful angle is not that stacks make code automatically safer. They make the dependency structure legible. That can improve review only when each layer has a clear purpose, a manageable size and tests that match its scope.

What the tool cannot decide

Stacked pull requests are still a public preview and are rolling out over several days. Support for GitHub’s merge queue is arriving progressively over the following weeks. Teams should not assume every repository has the complete workflow yet.

There are also organizational costs. A stack can become harder to follow if its lower layers keep changing or if reviewers approve later work before understanding an unstable foundation. Ten tiny pull requests are not necessarily clearer than three coherent ones. The tool manages branch relationships, not editorial judgment about where one change should end and the next should begin.

Teams adopting the preview should start with work that already has natural boundaries. Dependency upgrades, schema preparation, feature logic and interface changes often separate cleanly. Each layer should build and test independently where possible, and its description should explain both its own purpose and what depends on it.

GitHub’s native implementation lowers the operational cost of this practice. Its real value will depend on whether teams use that convenience to produce smaller explanations, not merely more pull requests.

Sources

Cover photo

IBM Says Quantum Advantage Has Arrived. The Test Starts Now

Three experiments add verification to beyond-classical results, but the claims still face peer review and stronger classical methods.

IBM and several research partners said on July 30 that they had demonstrated quantum advantage in three experiments. That term describes a calculation a quantum computer can perform more accurately, cheaply or efficiently than the best available classical method.

The announcement sounds like the end of a long race. It is better understood as the start of a new round of checking.

Quantum advantage claims have a built-in problem. A result becomes interesting when a conventional supercomputer can no longer reproduce it. At that point, the usual way of verifying the quantum machine has also disappeared. Earlier advantage demonstrations have sometimes lost ground when classical researchers found faster simulation methods.

IBM’s new argument is that trust can be built into the experiment rather than supplied afterward by a classical answer.

Three routes to the same claim

The most mathematically structured experiment came from IBM and the University of Chicago. The researchers began with quantum circuits that a classical computer can still simulate, then made them progressively harder by adding operations called T gates. They embedded the circuit in a form of error-detecting code, allowing the system to estimate how faithfully the hard computation ran.

The team used 97 physical qubits to encode a 70-logical-qubit circuit. A logical qubit is protected by information spread across physical qubits. The experiment included 2,415 logical two-qubit operations and 468 T gates. IBM says its processor finished in about 15 minutes while leading classical approaches faced impractical runtimes.

A second experiment led by Qedma studied Floquet dynamics, the behavior of an interacting quantum system under repeated pulses. Researchers ran circuits with as many as 74 qubits and compared the results with two advanced simulations on Japan’s Fugaku supercomputer. The classical methods eventually disagreed with each other, while the quantum results remained consistent across different error-mitigation techniques and partial repetitions on Quantinuum hardware.

The third paper, led by Algorithmiq, examined how information moves through a model of irregular quantum matter. Instead of assuming one noise level, the researchers deliberately varied noise, calibration and IBM processors. The result stayed stable while leading classical methods gave conflicting predictions. Algorithmiq also released its strongest classical method so other groups can challenge the claim.

Why this is more credible than a speed headline

The genuinely new element is not simply that a quantum processor completed a difficult calculation. It is the effort to establish a chain of evidence when an exact classical answer is unavailable.

The University of Chicago method provides a statistical lower bound on the computation’s fidelity. The other studies look for agreement across independent error-mitigation methods, hardware runs and controlled changes to noise. These checks do not make the machines error-free. They make the uncertainty more measurable.

The papers and data are also being placed on IBM’s Quantum Advantage Tracker. That matters because quantum advantage is not a permanent certificate. A claim holds only while no classical method can match it under a fair comparison. Better algorithms or more efficient supercomputer implementations can move that boundary.

What has not been proved

The three papers were posted as preprints and had not completed peer review when IBM announced them. IBM supplied the hardware and collaborated on all three, so outside replication remains important. Independent reports from The Wall Street Journal and Live Science confirm the scope of the announcement, but they do not replace technical review.

The demonstrations also do not mean ordinary companies suddenly have a faster way to run databases, train AI models or optimize delivery routes. Two experiments focus on research models of quantum systems. The Chicago work is a deliberately constructed sampling problem. These are scientifically useful test beds, not commercial workloads.

There is still a practical consequence. Researchers now have stronger techniques for asking whether a noisy quantum computer produced a trustworthy result after classical verification became too expensive. That is necessary before quantum machines can become credible tools for materials science, chemistry and other fields built around hard quantum simulations.

The useful angle is therefore not whether IBM has won a race. It is whether the open challenge survives. Watch for peer review, reproduction on unrelated hardware and new classical attacks on the published benchmarks. If the results endure, the milestone will be less about raw quantum speed than about knowing when to believe the machine.

Sources

IBM Research overview, University of Chicago and IBM preprint, Algorithmiq-led preprint, University of Chicago explanation, The Wall Street Journal, and Live Science.

Cover photo

How Europe’s AI Gigafactories Are Supposed to Work

The EU is buying access to shared computing capacity, not simply paying for seven giant data centers.

The European Union opened bidding on July 30 for up to seven AI gigafactories. The name suggests a building that manufactures something. In practice, each will be a very large computing service built to train, adapt and run advanced artificial intelligence models.

The European Commission is offering up to €10 billion in EU and national funding and expects the projects to attract at least €20 billion more from private investors. The plan follows an earlier network of 19 smaller AI factories. Bids close on November 12, with selections expected in early 2027.

The hardware is only the first layer

An AI gigafactory starts with accelerators, specialized chips designed to perform the huge number of calculations used by AI models. Reporting from the Associated Press says the planned facilities are expected to contain at least 100,000 advanced AI chips and be roughly four times more powerful than the data centers currently operating in the EU.

Those chips cannot work as one machine without fast interconnects that move data among them, large pools of memory, storage systems and high-speed links to users. Power delivery and cooling are equally fundamental. A cluster can lose much of its advantage if processors spend time waiting for data or if the site cannot obtain enough electricity.

Above the hardware sits a cloud and software stack. It schedules jobs, divides capacity among customers, monitors failures and provides secure workspaces. This is what turns a warehouse of processors into a usable service for companies and researchers.

The facilities are meant to cover three stages of AI work. Training builds a model by processing large datasets and adjusting billions of internal parameters. Fine-tuning adapts an existing model for a narrower task or body of knowledge. Inference is the everyday work of using a trained model to answer a question, generate an image or complete another request.

Why access time matters

The most revealing detail is in the tender documents. The EuroHPC Joint Undertaking and participating countries are not simply awarding construction grants. They plan to purchase a guaranteed share of computing time from the selected operators.

Consortia or special-purpose companies will establish and run the sites. They can combine chip suppliers, cloud providers, public bodies and investors. In return for public support, European institutions gain capacity that can be allocated to startups, smaller companies, universities, industry and public authorities.

That model addresses a basic imbalance. A young AI company rarely needs to own a data center forever. It may need an enormous cluster for several weeks to train a model, followed by a smaller but steady allocation for testing and deployment. Shared access can lower the entry cost if pricing, queues and technical support are designed well.

The projects can occupy one site, several sites in one country or a cross-border network. Distributed facilities offer flexibility, but they also increase the importance of network latency, common software and coordinated operations.

What the funding does not solve

Scale alone does not create a successful AI ecosystem. Europe still depends heavily on processors designed by non-European companies. Reuters reported that AMD, Nvidia and Qualcomm signed letters of intent to supply chips to bidding groups. That may accelerate deployment while leaving part of the strategic dependency intact.

Electricity is another constraint. AP noted that EU power can cost two or three times as much as in the United States and China. The tender calls for energy-efficient data centers and sustainable energy and water supplies, but final sites and operating arrangements are not yet known.

Location also matters. A 2025 analysis from the Centre for European Policy Studies found that earlier AI factories were often outside established AI talent hubs and did not always benefit from the best energy conditions. A large cluster without nearby expertise, useful datasets or attractive access terms can become expensive capacity rather than an engine of new products.

The practical test

For European developers, the immediate change is not a new chatbot or cloud account. It is the possibility of a larger regional supply of advanced computing capacity from 2028, if the timetable holds.

The important numbers will eventually be less glamorous than the chip count. Watch how much compute time public funders receive, who qualifies for it, how long users wait, what the effective price is and whether workloads can move between sites. Those details will determine whether the gigafactories broaden access to frontier computing or mainly add seven more very large data centers.

Sources

European Commission announcement, EuroHPC tender specifications, Reuters, Associated Press, and Centre for European Policy Studies analysis.

Tech Tab

Written by

AI, technology, gadgets, and research — curated into clear updates, practical insights, and useful context.

Subscribe

Support Tech Tab

Support this publication to show you appreciate and believe in them. As their writing reaches more readers, your coins may grow in value.