News and Tech Update

Every team that has turned coding agents loose on real work has run into the same wall. The agents write fast. They write a lot. And somewhere between the tenth and twentieth pull request of the day, the humans responsible for reviewing that code start falling behind. That’s not a hypothetical. It’s the operating reality on teams that have adopted agentic development this year, and it’s the problem Tessl is aiming to address with the launch of Tessl Code Review, a new tool the company rolled out this week and is offering for free during its beta period. The pitch is simple: teams don’t need another reviewer catching naming nits and formatting issues. They need a reviewer that runs on its own, filters out the noise, and actually knows the team’s standards. Tessl Code Review checks pull requests against those standards, written once and stored as a skill the team owns and controls. That last part matters more than it might sound. A lot of AI code review to...

Developers for years have been using vm2, an open-source Node.js library , to run untrusted JavaScript inside a secure and isolated sandbox environment. It uses Node.js’s built-in modules and JavaScript Proxies and lets developers whitelist particular built-in Node modules or limit what the script can access. During that time, vm2 has been the default for safely running untrusted JavaScript, which Cris Staicu, senior security researcher for Endor Labs, calls “one of the hardest problems in the Node.js ecosystem.” However, over the years, there have been some two dozen instances of code breaking out of the sandbox, including one Endor Labs documented earlier this year . The problem is that vm2 is used to build a security boundary inside a single V8 execution environment using proxies and prototype scrubbing, and untrusted code shares some of the same elements, according to Staicu. Another method, isolated-vm, uses stronger techniques, a key one being that each sandbox given its own V...

The DevOps community has already experienced technological extremes. You might recall the time when automation was thought of as a panacea for all possible engineering issues, and the slogan “Automate Everything” was ringing out everywhere. Over time, the industry came to an important conclusion: Automation should not become the end goal. Along with faster software delivery, companies ended up with new dependencies, more complex infrastructure, and additional tools that also needed to be maintained. Today, a similar story is unfolding around artificial intelligence. Only instead of the call to automate everything in sight, we’re increasingly hearing a different mantra: Implement AI everywhere. Is this really necessary, though? Why AI Adoption Pressure is Growing in DevOps Three principal factors can be highlighted here. The first one is the pace of change. It’s hard even to mention a week that does not bring news about some AI solution for DevOps: From Terraform generation assistan...

Adelaide, Australia, August 19th, 2026, CyberNewswire Independent assessment provides Australian organisations with additional evidence when evaluating application control for sensitive, government, defence and critical infrastructure environments. Airlock Digital, a global provider of application control and allowlisting solutions, today announced that it has completed an independent Information Security Registered Assessors Program (IRAP) assessment at the PROTECTED classification level. The assessment was conducted by an Australian Signals Directorate (ASD)-endorsed IRAP assessor against the Australian Government Information Security Manual (ISM). It provides Australian organisations with additional independent evidence when evaluating Airlock Digital’s security controls and their alignment with applicable Australian Government security expectations, including the ISM and Protective Security Policy Framework (PSPF). For Australian security teams, confidence in a technology pr...

OpenTelemetry solved a real problem. Before it, every APM vendor had you install a proprietary agent, which meant switching vendors meant re-instrumenting everything. OTel gave engineering teams a vendor-neutral way to generate traces, metrics, and logs once and send them wherever they wanted. That part of the pitch is true, and open-source deserves credit for it. What gets left out of most OTel adoption conversations is what happens after the SDKs are wired up. The framework is free. Running it well is not. The Pain Points That Show Up After Rollout Collector sprawl. A production OTel deployment usually means running collector instances per region or per cluster, tuning batch and memory limiter settings, and watching for the collector itself becoming a bottleneck under load. This is the infrastructure your team now owns and patches, on top of the infrastructure it was supposed to help you monitor. Storage and retention decisions become your job. OTel defines how telemetry is gener...

When an end-to-end test fails after a front-end change, the repair often looks routine. A class name changed. A button moved. A selector that used to be unique now matches two elements. A self-healing system inspects the page, proposes a new locator, reruns the test, and gets a green result. That green result is useful, but it does not prove the test was repaired. The new locator may point to the wrong button, a hidden duplicate, or an element from another part of the page. The run passes because the automation found something clickable. The test may no longer check the behavior it was written to protect. I call that a false heal. It is worse than an ordinary failure because it removes the visible warning. A red test creates work. A false heal makes the suite look healthy while weakening its signal. The practical fix is to treat an AI-generated repair like any other untrusted code change. The healer can propose the patch, but a separate deployment gate must decide whether the patch...