News and Tech Update

Ask any developer who works with multiple AI coding assistants how they choose a model for a given task, and you’ll get some version of the same answer: Trial and error. A quick model for simple edits. A stronger, pricier one for hard debugging. Sometimes a second model gets pulled in just to check the first one’s work. It’s a manual routing problem, and it falls on the developer every single time. GitHub thinks it has a fix. The company just introduced Project HydraFusion , a research preview built into GitHub Copilot that handles that routing automatically. Instead of a developer deciding which model gets which task, HydraFusion evaluates the request and builds the workflow itself. The system leans on three execution patterns. In “single” mode, one model handles the task outright. In “cascade” mode, an efficient model drafts a solution first, and only escalates to a stronger, more expensive model if the draft doesn’t clear a quality g...

During my doctoral research on modern engineering practices and operational efficiency, one pattern kept surfacing that I did not expect to find. The engineering teams making the most measurable progress on sustainability were not the ones that had appointed green committees. They were the ones running tight DevOps discipline: right-sized fleets, lean pipelines, tuned alerting, progressive rollout, carbon-aware routing. The same practices that cut cost and toil were quietly cutting emissions at the same time. Nobody was measuring it that way. That observation became a thread I kept pulling. The more I looked at how modern engineering practices drive operational efficiency, the more I found sustainability outcomes hiding inside work that engineering teams were already doing, and already getting credit for on the cost side. The carbon savings were real. They just were not being captured. The problem is not that enterprises lack green intent. It is that sustainability is being treated as...

A familiar pattern is emerging in observability conversations. As telemetry volumes grow and costs rise, the default recommendation is often to collect less data: Sample more, retain less, index selectively, filter earlier, and reduce cardinality until the economics become manageable. Some of this is reasonable. No system benefits from unlimited accumulation without curation. But when “send less data” becomes the center of the strategy, it creates a deeper problem: Teams are asked to reduce fidelity before they understand what level of fidelity they actually need. There’s a Hidden Cost of Reducing Fidelity Too Early This is the gaslight problem. The organization is told the issue is its telemetry behavior. Too many logs . Too many spans. Too much cardinality. Too much retention. But often, the underlying issue is that the economic model makes necessary fidelity feel excessive before the team has enough evidence to know what is safe to reduce. Observability is most valuable under...

For a long time, monitoring just meant staring at dashboards and waiting for something to flash red. Engineers tracked things like CPU usage, memory, response times, error rates, and uptime. If a number crossed a certain line, you’d get an alert. Then, someone dived in to figure out what was wrong. That basic approach isn’t useless, but it’s just not enough anymore. Today’s systems are way more complicated. Apps run across containers, Kubernetes clusters, cloud services, databases, APIs, queues, and all sorts of third-party services. A single user’s request might hop through dozens of different pieces just to finish. Simply knowing “something broke” isn’t helpful. You need to find out why it happened and what’s actually affected. This is where observability steps in. Monitoring Just Says Something’s Wrong Traditional monitoring works fine when you already know where things can break. You set a threshold, collect some numbers, and get pinged when something’s outside the e...

The software industry has heard plenty about how artificial intelligence will transform software development. Analysts have analyzed it. Consultants have built practices around it. Vendors have attached AI to just about every product description they could find. It is a little different when the message comes from one of the companies building the AI responsible for the disruption. Anthropic recently published “ The AI-Native SDLC Playbook ,” a detailed proposal for transforming the software development lifecycle one stage at a time. Written by Louis Claxton and drawing on practices from Anthropic’s Applied AI team and its customers, the playbook makes a deceptively simple assertion: Code is no longer necessarily the bottleneck. This is not literally Claude writing its own review of the software industry. Still, it is about as close to hearing it from the horse’s mouth as we are likely to get. The company whose AI helped accelerate software development is now telling us that the pro...

JFrog CEO Shlomi Ben Haim told approximately 500 software engineers today that in the age of artificial intelligence (AI) no one will soon care much about source code anymore. Speaking at the company’s swampUP 2026 conference, Ben Haim said AI tools are now creating executable binaries directly without relying on source code that historically existed to provide a method for humans to review code. However, in an era where AI tools are creating code that often isn’t even readable by a human application developer, the focal point for securing software supply chains is now moving to scanning application binaries, said Ben Haim. No one cares how many lines of source there are, he added. It’s not clear to what degree DevSecOps teams might be coming to a similar conclusion, but it’s apparent that the volume of code being created using AI coding tools is overwhelming existing DevSecOps workflows. An alternative approach to application security in the AI era would be to focus more on applyi...