Skip to main content

Posts

How to Avoid Repeating the “Automate Everything” Mistake Due to AI FOMO

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...
Recent posts

Airlock Digital Completes Independent IRAP Assessment at the PROTECTED Level

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...

What It Really Takes to Run OpenTelemetry

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...

Why Self-Healing Tests Need a Deployment Gate

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...

Are LLMs Equally Good (or Bad) at Building Secure Software?

In the tricky business of choosing the right artificial intelligence coding models for security and cost, development teams need to keep in mind two important factors. First, even the best and best-known AI coding assistants vary widely in performance, both between and within individual frameworks. Each has strengths and weaknesses, and there is no across-the-board best of the bunch; a model that leads the pack in one framework may be in last place in another. And second, when it comes to generating secure code, you don’t necessarily get what you pay for. The real costs of using AI agents can mount quickly depending on an agent’s use of tokens, and some models are more inclined than others to make extensive use of them, but there’s no correlation between cost and the level of security provided. Those are among the findings of an in-depth study conducted by Secure Code Warrior and the Royal Melbourne Institute of Technology (RMIT) to evaluate the security behavior of leading AI codin...

What the Microservices Era Can Teach Us About AI

The most expensive mistake teams are making with AI agents right now is treating them as microservices with a language model bolted on. The approach is understandable; microservices are the architecture most platform engineers know best, agents feel like services that happen to think, and the migration path looks familiar. But the analogy only holds long enough to lead you somewhere painful. Microservices changed how software gets built. The idea was to help teams work independently, ship faster and scale efficiently. In those days, shipping software meant one giant codebase compiled together, tested together and released on 12- or 18-month cycles. Then the cloud came along, and teams needed to ship in weeks or days. The only way to do it was to split systems apart and let each piece move on its own schedule. It worked, but the systems underneath stayed simple in one crucial way: they were deterministic. Distributed systems are hard, but the behavior was predictable. A service receiv...

Cloudsmith Extends Policies and Controls to Secure Application Binaries

Cloudsmith this week revealed it has expanded the policy management and continuous risk detection capabilities it makes available within its software artifact management platform to now include policy templates, cooldown policies, and expanded evaluation triggers. Alison Sickelka, vice president of product for Cloudsmith, said these additions to the platform will make it simpler to prevent malicious packages from inadvertently being incorporated into the binaries that DevOps teams deploy in production environments. For example, policy templates written in the Rego programming language can now be used to provide a set of baseline controls that are consistently implemented across a DevOps workflow. Additionally, DevOps teams can now implement a set of cooldown policies that prevent any recently made available software package from being indexed. That capability ensures that only versions of a validated package are exposed to application developers, noted Sickelka. That’s crucial beca...