News and Tech Update

For years, stacked pull requests have been something of an open secret in software engineering. Teams at Meta and Google have used internal versions of the workflow for over a decade, and open source developers cobbled together their own approach with tools like ghstack. Now GitHub is making it a native feature. The company announced this week that stacked pull requests are in public preview, rolling out to all repositories over the coming days. The idea behind stacking is simple, even if the mechanics take some getting used to. Instead of building one large pull request that captures an entire feature, developers break the work into an ordered series of smaller PRs. Each one sits on top of the last, representing a single layer of the change. A schema update might be the base layer, with business logic stacked on top of that, and a UI change stacked on top of that. Reviewers can look at each layer on its own, without wading through a diff that spans a thousand lines. That distinction...

Open source can be just as safe as proprietary software, though government agencies (and private enterprises) should take additional measures to secure it properly, according to a new guide published by the U.S. Cybersecurity and Infrastructure Security Agency ( CISA ). The report, “ Open Source Software: Security Principles and Practices ,” provides with guidance to help agencies comply with two Presidential Executive Orders ( 14144 and 14306 ) which both urged them to do a more thorough job securing the software they use, a response to recent exploits like Log4Shell and XZ utils. CISA acknowledges that open source can provide immeasurable benefits to government agencies, not merely because it is available without licensing fees, but also because agencies can extend the software to meet their own requirements. But at the same time, open source software must be managed differently than proprietary software. Malicious hackers (and increasingly AI agents) use vulnerabilities to gain ...

Modern engineering teams have invested heavily in observability. Dashboards are populated, alerts are configured, on-call rotations are set. Yet when production incidents occur, the average time to resolution hasn’t dropped nearly as fast as the tooling has improved. The reason, in many cases, comes down to one overlooked gap: logs aren’t being used the way they should be during active incidents. This isn’t a tooling problem. Most organizations already have log data flowing somewhere. It’s a workflow problem, specifically, how logs integrate (or fail to integrate) into the broader incident response process. The Three-Tool Problem A typical incident response scenario looks something like this: an alert fires, the on-call engineer opens a metrics dashboard to understand the scope, then switches to a separate logging tool to investigate root cause, then jumps to a tracing tool to follow the request path. Three tools. Three contexts. Three sets of query syntax. B...

CISA just gave software supply chain security a long-overdue refresh. Working with the NSA, the FBI, and a roster of international partners, the agency released the 2026 Minimum Elements for a Software Bill of Materials, updating and replacing the baseline that the National Telecommunications and Information Administration published back in 2021. Five years is a long time in software security terms, and the update shows. The timing isn’t random. The revision incorporates feedback from more than 90 comments submitted during a public comment period, and CISA circulated a draft in 2025 specifically to update elements like SBOM author, software producer, and component version for better clarity. This wasn’t a quiet policy tweak. It was a deliberate, multi-year rework built on real feedback from people who actually generate and consume SBOMs for a living. What’s New The headline change is scope. The minimum elements now apply to SBOMs across all software types, including...

Tricentis today revealed it is acquiring Tabnine to gain access to a knowledge graph that will be used to provide context to AI agents that have been trained to automate a range of testing tasks. Once the acquisition is complete, Tricentis plans to integrate the knowledge graph developed by Tabnine, dubbed the Enterprise Context Engine, into the company’s Agentic Quality Engineering Platform. Coupled with a vector model, that knowledge graph makes it possible to extract entities, relationships, dependencies, and architectural patterns from repositories, documentation, tickets, application programming interfaces (APIs) and infrastructure metadata in a way that is much easier for AI agents to consume and understand. The end result will be a platform that continuously ingests code, documentation, tickets, and APIs, providing organizational intelligence in real time and enabling multiple AI agents to share memory and context to both verify outputs and better understand the potential dow...

The gap between how fast AI writes code and how reliably teams verify it is quietly becoming a balance-sheet risk. Enterprise leaders are learning to measure it before it forces repayment. Every engineering organization that adopted AI coding assistants over the past two years has quietly taken on a liability that never appears on the dashboards leadership actually reviews. Developers now generate more code than their teams can meaningfully verify, and the gap between the two compounds on every passing build until an incident forces the account to settle. The cost tends to land late and all at once, usually as an outage or a failed audit that traces back to a change nobody fully checked. For the executives who answer for delivery risk, the trouble is not the tooling their engineers reach for but the plain fact that verification capacity never scaled to match the new pace of output. The Liability That Never Reaches the Dashboard Leadership reporting evolved to track the things that ...

Not long ago, some business leaders seemed to view enterprise search as a “nice-to-have.” Or, at the very least, they considered it more of a supporting utility than a strategic, business-critical platform. Organizations use enterprise search tools to help employees locate internal documents and enable support teams to surface relevant information. And, of course, retailers have long needed search to help customers navigate their product catalogs. But historically, expectations have been relatively modest: Users entered a few keywords and received a list of links, and then they did the remaining legwork themselves to figure out which results were relevant. It’s little surprise, then, that many companies have historically relied on self-managed open-source solutions like Apache Solr for enterprise search. But even though the role of enterprise search has changed, many organizations’ approach to search has not. The rise of GenAI has trained customers to expect companies’ search tools ...