Uncategorized

AI-aided development tools are churning out more lines of code than ever, presenting a challenge for reviewers who must review ever larger pull requests. After toying with the idea of closing the door to AI-aided code submissions, GitHub is now looking to help enterprises manage big code changes in a more incremental way. It says a new feature, Stacked PRs, can improve the speed and quality of code reviews by breaking large changes into smaller units. “Large pull requests are hard to review, slow to merge, and prone to conflicts. Reviewers lose context, feedback quality drops, and the whole team slows down,” the company said, announcing GitHub Stacked PRs on its website. With the new, stacked approach it aims to reduce the overhead of managing dependent pull requests by minimizing rebasing effort, improving continuous integration (CI) and policy visibility across stacked changes, and preserving review context to enhance code quality. Stacked PRs tracks how requests in a stack relate to one other, propagating changes automatically so developers don’t have to keep rebasing their code  and letting reviewers assess each step in context, the company explained in the documentation. The feature, GitHub wrote, is delivered through gh-stack, a new extension to GitHub CLI that manages the local workflow, including branch creation, rebasing, pushing changes, and opening pull requests with the correct base branches. On the front end, all changes created via gh-stack are surfaced in the GitHub interface, where reviewers can navigate them through a stack map, with each layer presented as a focused diff and subject to standard rules and checks, the company added. Developers can merge individual pull requests or entire stacks, including via the merge queue, after which any remaining changes are automatically rebased so the next unmerged PR targets the base branch. Monorepos and platform engineering drive shift to modular development For Pareekh Jain, principal analyst at Pareekh Consulting, Stacked PR is GitHub’s response to a structural shift being driven by large-scale monorepos and platform engineering, which are pushing teams toward more modular, parallel workflows. “GitHub’s traditional PR model created a bottleneck where developers either waited long cycles for reviews or bundled work into large, hard-to-review PRs that increased risk and slowed merges. Stacking solves this by letting developers break a feature into smaller, dependent PRs such as database, API, and UI layers, so reviews happen incrementally while development continues in parallel,” Jain said. “Stacked PRs is likely to see rapid adoption in mid-to-large enterprises, especially those managing monorepos. Its biggest impact is eliminating rebase hell — the manual effort of updating multiple dependent branches when the base changes,” Jain noted, adding that the feature’s integration into both the GitHub CLI and UI will also drive adoption as it removes the need for third-party tools. Change management The biggest obstacle to adoption of Stacked PRs will not involve changes to the code, but changes to coders’ habits, said Phil Fersht, CEO of HFS Research. “The constraint will not be the feature itself, but whether development teams adjust their workflow discipline to use stacking properly.” That will involve them learning to organize large pull requests into neat stacks for the reviewer, which may be as challenging as reviewing a large PR. That was echoed by Paul Chada, co-founder of agentic AI-based software startup Doozer AI: “Workflow shifts only happen when the pain of not changing exceeds the friction of learning,” he said. AI-driven code velocity driving a new pressure point The release of Stacked PRs comes amid a deeper structural shift in software development: the rise of AI-assisted coding. This is accelerating the pace of code generation, increasing the volume of changes and making traditional, linear review workflows harder to sustain. “AI-assisted coding has changed the math. When humans wrote the code, big PRs were annoying but tolerable,” said Chada. “Now agents produce 2,000-line diffs across 40 files in seconds, and GitHub is staring down 14 billion projected commits this year versus 1 billion last year. That’s not a workflow problem, it’s a survival problem.” GitHub appears to be betting that Stacked PRs changes the way development teams view a unit in software development by making it small, attributable, and revertible, regardless of  whether the author is a senior engineer or an agent, Chada said. But, he cautioned, integrating Stacked PRs with coding agents risks adding to toolchain sprawl for enterprises. “The current dev toolchain — IDE plus Copilot plus Claude Code plus Codex plus stacking tools plus review bots plus CI/CD plus security scanners plus MCP servers — is squarely in the Cambrian explosion phase,” Chada pointed out. Competitive pressures GitHub Stacked PRs isn’t an entirely novel idea: There are third-party tools that work with GitHub already offering the similar functionality. Jain said GitHub’s addition of the feature will likely impact Graphite CLI, a GitHub-focused tool that allowed stacking PRs when the functionality wasn’t natively available. “Graphite has been the market leader in this space. GitHub’s entry validates the Stacking category but poses an existential threat to Graphite’s core value proposition,” Jain said. “To survive, Graphite will likely need to double down on superior UI/UX, faster performance, and features GitHub won’t touch like cross-platform stacking for GitLab and Bitbucket.” That competitive pressure also reflects a broader platform play. Stacked PRs, Jain further noted, represents a “strategic move” to internalize a workflow long used by high-velocity teams at companies like Google, Meta, and Uber, referring to the stacked differential code review model popularized by tools like Phabricator. Stacked differentials, much like Stacked PRs, are a series of small, dependent code changes reviewed individually but designed to build on each other and land as a cohesive whole. In effect, this means that GitHub is trying to pull enterprises away from such tools by making it easier to adopt these advanced workflows natively within its own platform, reducing the need for external tooling. There is also a quieter platform economics angle emerging, Chada pointed out. “GitHub is effectively building out infrastructure to absorb a surge of machine-generated activity that does not yet translate into proportional revenue, from third-party coding agents that compete with its own GitHub Copilot to the very workflows those agents are accelerating,” Chada said. In that light, Stacked PRs looks as much like a scaling response as a developer experience upgrade — one that could foreshadow a shift in how GitHub monetizes its AI layer, with Copilot pricing likely to move toward more usage-based models over time, Chada added.

HTMX has been considered feature-complete for some time. It is a successful project that achieves its ambitious goals and is widely hailed, not to mention widely deployed in production. HTMX 2.0 was considered the final word. The creator promised there would be no HTMX 3.0.  So of course, being developers, the HTMX team decided to rip out the engine and replace it with a new one based on JavaScript’s Fetch API. They named the new version HTMX 4.0 to keep the promise. Here is a fascinating tale of architecture and implementation that gives us a beautiful window into the inner machinations of the front-end industry.  Simpler web development When asked for comment on the 3.0 leap frogging, HTMX Carson Gross gave me a one word quote: “Oops.” – Carson Gross, creator of HTMX Gross is one of my favorite industry personalities. It’s easy to see why. He created the Grug Brained Developer as well as HTMX. The former contains all the hard-bitten advice from a veteran coder that young grugs need to survive, delivered in the voice of a caveman. The latter is the physical manifestation of those ideas: a library that leverages HTML and REST to bring simplicity back to the web. The core of HTMX 4.0 is that the old transport protocol, the XHR object, is being removed and replaced with the modern (and universal) Fetch API. This is massive on two fronts. First, it was a massive amount of work for the HMTX team. Second, it’s a massive performance and DX win.  Modern fetch() has a huge benefit in that it can stream responses. That means the front end can process and act on segments of the UI as they arrive, instead of waiting for the whole response to complete before taking action. This is similar to what React Server Components (RSC, a recent addition to React) do.  There is a certain infatuation with new and clever techniques in software development. That is understandable, but it can become pathological at times. As a result, there has always been a countercurrent that urges us to look closely at the requirements and pare away the unnecessary until the simplest solution is found. HTMX is a banner carrier for that counterculture. In that spirit, the HTMX 2.0 line was declared the final version. It does what it was intended to, and is a complete and adequate solution. But then there is the truth that sometimes a better way to do things is found and more engineering work is merited. That is HTMX 4.0. Native streaming In HTMX 2.x we used the XHR object, XMLHttpRequest, which has its roots in the late 1990’s Internet Explorer. The browser had to buffer the entire response before it could swap. By adopting ReadableStream via the Fetch API, HTMX 4.0 can process and inject HTML fragments as they arrive. This achieves the holy grail of a streaming UI but does so with a tiny 14KB script. Moreover, we still are in the HTMX vernacular, meaning we can use any back end that can spit out a string. It’s a performance win that actually reduces your JavaScript footprint and makes the architecture simpler. In short, the use of Fetch is a refactor that should net both more power and less complexity. Idiomorph DOM merging Although native streaming is the most fundamental new aspect in HTMX 4.0, there is another really cool thing that the 4.0 refactor opens up.  The idea of “morphing” or “diffing” HTML pages makes for superspeedy page changes with no additional complexity in many situations. It is perhaps best known from Hotwired. How it works: when a page (or fragment) arrives, an algorithm checks it against the existing content and replaces only the changes. HTMX 4.0 enables the default use of the Idiomorph algorithm, a fancy new approach to morphing one DOM tree into another. (The Idiomorph project is also led by Carson.) In HTMX 2.0, Idiomorph was an extension. In HTMX 4.0, you get it basically for free. Idiomorph, inspired by Hotwired’s Morphdom, evolved the idea of comparing two HTML docs and only updating the minimal set of data to the next level. Idiomorph has been adopted by Hotwired itself. There is a great technical description of the bottom-up, nested ID diffing algorithm that Idiomorph uses on its GitHub page.  Idiomorph is not directly a benefit of the Fetch refactor, but is a benefit of the simplicity that Fetch has brought to the codebase. Using Fetch made it possible for the team to add Idiomorph to the core. Prop inheritance (a breaking change) HTMX 4.0 introduces a breaking change to prop inheritance. This change was not necessitated by the Fetch upgrade, but was based on real world experience. The team determined that it is safer and better DX to make HTMX props not inherit by default. In previous versions, attributes like hx-target inherited implicitly. This led to weird cases in which the children of an element were affected when it wasn’t clear why. In HTMX 4.0, inheritance is now explicit. You use the :inherited modifier to indicate which child elements should inherit, e.g., hx-target:inherited="#div". This respects the principle of locality of behavior (a Grug brained favorite). You no longer have to hunt through parent templates to find out where a button is supposed to swap its content. The history hack is history HTMX 2.x included a fancy history engine that tried to snapshot the local DOM and save it to localStorage. This was an optimization. It turned out to be brittle. HTMX 4.0 has abandoned this in favor of standard behavior, i.e., a page reload.  Error handling and status-specific swapping Most InfoWorld readers will never have to face a 500 or a 404 error. But for those rare situations where a server returns an error code (yes, this is sarcasm), the new HTMX 4.0 behavior will be to swap in the content. Before, the request failed silently. This change will help developers provide immediate visual feedback to the user rather than leaving them with a broken or frozen screen. The really cool part of this update is the new status-specific swapping syntax. You can now define different behaviors for different HTTP codes directly in the HTML. By using syntax like hx-status:404="#not-found" or hx-status:5xx="#error-notice", you can elegantly route different server errors to distinct UI elements. The tag The addition of is a major structural improvement. It allows you to wrap fragments in a response so they can target specific elements explicitly (e.g., ). It’s a cleaner, more readable alternative to the old “out-of-band” (OOB) swaps. This is similar to Hotwired’s Turbo Streams. (So we see that HTMX and Hotwired are engaging in fruitful co-influence.) The idea is that we allow the server to send a collection of fragments tagged with targets, and these are placed in the UI. This allows for complex, multi-point updates to the interface based on a single server response. Native view transitions To top it all off, HTMX 4.0 now integrates with the browser’s native View Transitions API by default. This allows for app-like, animated transitions between page states—like fading or sliding—with zero extra CSS or JavaScript required. Sidestepping JavaScript complexity Even if you are unfamiliar with HTMX, it is worth looking at to understand what exactly it is trying to do. It is an important angle on web development. Along with friends like Hotwired, HTMX demonstrates the possibilities of taking the simplest standard features and wringing the most power from them possible. It’s impossible not to look at the whole landscape slightly differently once you get it. Even if you still use and appreciate reactive front ends (and I do).  HTMX asks the question, what could we accomplish with Hypermedia if we were very clever? The answer is, we can accomplish quite a lot, and sidestep much JavaScript complexity in the process.

Large cloud providers still want the market to believe that AI infrastructure is a premium business where customers pay premium prices. That argument worked when buyers had few alternatives, when access to advanced GPUs was restricted, and the operational maturity of the hyperscalers created an advantage that smaller competitors could not easily match. However, the market is rapidly changing, making economics unavoidable. Recent comparisons show that neocloud providers are often much cheaper than major public clouds, with hyperscalers costing about three times to six times as much as specialized competitors for similar compute capacity. That gap is not a rounding error. Enterprises cannot dismiss this as just the cost of doing business with a trusted vendor. The bills are significant enough to influence architectural choices, vendor strategies, and even the locations of AI innovation. One commonly cited example in current pricing comparisons shows that NVIDIA H100-class compute costs about $2.01 per hour on Spheron versus approximately $6.88 per hour on AWS for a similar workload category. That is roughly a difference of 3.4 times for comparable AI processing. Whether a specific enterprise secures better rates is almost irrelevant. The market now knows that lower-cost alternatives exist, and knowledge changes behavior. In addition to neoclouds, private clouds, sovereign clouds, and even on-premises GPU strategies are becoming more appealing as buyers increasingly view AI infrastructure as a long-term operating expense rather than a short-term experiment. Once that shift occurs, even small differences in unit costs become strategic. Large cost gaps become hard to justify. That’s when a premium vendor stops appearing premium and begins to seem overpriced. When ‘premium’ isn’t enough For years, hyperscalers benefited from a straightforward value proposition. They could provide global reach, mature security controls, integrated tools, elastic capacity, and an ecosystem that minimized operational friction. These factors still matter and remain valuable. However, AI is revealing a flaw in the traditional cloud pricing model. When compute is the core and can be sourced elsewhere at a significantly lower cost, the value of the surrounding ecosystem must be exceptional to justify the markup. Today, in many cases, it is not. This is where hyperscalers are making a strategic mistake. They seem to assume that AI buyers will continue to accept the same pricing strategies that worked for traditional cloud migrations. That assumption is risky. AI buyers are not just lifting and shifting old enterprise applications. They are training, fine-tuning, and deploying models in environments where utilization, throughput, latency, and token economics are monitored in real time. Their boards are asking tougher questions. Their investors are asking tougher questions. Their finance teams are asking the toughest questions of all. If the answer is that the enterprise is paying several times more for the same class of compute because it’s easier to stick with a familiar brand, that decision won’t go over well. The real issue is not that AWS, Microsoft Azure, and Google Cloud are expensive in absolute terms. The issue is that they are becoming expensive relative to an expanding set of credible alternatives. That distinction matters. Buyers will always pay more for better outcomes. They will resist paying much more for little or no proportional benefit. In AI, proportional benefit is increasingly difficult for the hyperscalers to prove. A customer does not receive higher model accuracy just because the invoice came from a household cloud brand. A workload does not become inherently more strategic because it runs in a famous control plane. The chip is still the chip. The cluster is still the cluster. The economics are still the economics. AI buyers become more rational The next phase of the AI market won’t be about who can generate the most headlines. Instead, success will be based on consistently delivering reliable performance at sustainable costs. This shift favors disciplined operators and providers that are optimized for GPU availability, efficient scheduling, and simple commercial models. It also benefits enterprises willing to blend different environments rather than always relying on the largest cloud vendor for every workload. The conversation is moving away from simple cloud preference and toward workload placement strategies. Enterprises are becoming more comfortable with the idea that different AI jobs belong in different places. Some workloads will stay on hyperscalers because the integration benefits are real. Others will move to private cloud because security, data gravity, or regulatory concerns demand it. Still others will land on sovereign platforms because national and industry-specific requirements leave no other option. A growing number will be routed to neoclouds because the price-performance equation is too compelling to ignore. This isn’t a rejection of hyperscalers. It’s a rejection of careless pricing. The biggest cloud providers will continue to be highly important for AI. However, their role is shifting from the default choice to one option among many. This represents a major strategic downgrade, driven not by technological weakness but by pricing practices. The market rewards discipline The cloud industry has experienced this cycle before. Established companies believe that their size safeguards them, that customers prioritize convenience above everything else, and that their pricing power is everlasting. Then, a new group of competitors appears with a sharper value proposition and fewer outdated assumptions. Initially, incumbents dismiss them as niche players. However, these players improve, specialize, and attract the most cost-conscious innovators. By the time the incumbents take action, the market has already shifted. That is exactly the risk hyperscalers face in AI today. If they continue treating GPU-driven workloads as a way to maintain high margins across compute, storage, networking, and managed services, they will train customers to look elsewhere. Once that becomes a habit, it will be hard to change. Customers who develop procurement discipline around lower-cost AI infrastructure won’t quickly return simply because a hyperscaler finally cuts prices. The next winners in AI infrastructure may be the providers that understand a hard truth: When the market is scaling at this speed, adoption matters more than margin preservation. If AWS, Microsoft, and Google don’t learn that lesson quickly, they might find that they weren’t undercut by competitors, but that they priced themselves out all on their own.