devopsy.kinsta.cloud

Tag: CLI

New Relic Debuts Command-Line Observability Tool for Developers and AI Agents

New Relic has unveiled Ground Truth CLI, a command-line tool that enables software developers and AI agents to analyze system performance and verify whether technical issues have been resolved without needing to use dashboards.

The release reflects a big shift in enterprise IT as AI agents take on more advanced troubleshooting tasks. Traditional observability dashboards are designed for human users, while AI agents need direct, programmatic access to production data to investigate problems and evaluate potential fixes. Ground Truth CLI allows this access through the command line, enabling agents to work with operational data without needing a graphical interface, an approach known as headless observability.

In essence, Ground Truth CLI supports a development environment in which software engineers and AI agents work together to investigate failures, verify fixes and maintain production systems.

Of course, this shared responsibility raises questions about how much responsibility AI agents can assume in production environments. Giving agents access to system data supports more sophisticated troubleshooting, so in many cases engineers still need to evaluate findings and determine whether proposed changes are appropriate.

Currently in limited preview, the tool connects to New Relic Autopilot, NerdGraph and memory APIs, providing access to system telemetry and AI-powered analysis.

Automated Recovery Checks

The CLI also supports automated recovery checks, an important capability for IT teams managing applications that must remain available around the clock. For instance, an engineer troubleshooting errors in an online checkout application could use the tool to examine application behavior and identify possible causes. Following a software update, the engineer could test whether error rates have returned to acceptable levels.

These checks can be repeated automatically, providing evidence about whether the application is operating within specified recovery conditions. Of course, successfully deploying a software fix doesn’t necessarily mean the underlying problem has been resolved. Applications may continue experiencing intermittent failures even after an initial test indicates that a repair was successful.

Ground Truth CLI also records investigation results, enabling engineers to examine earlier findings or transfer an unresolved incident to another team member. The capability could be particularly useful for enterprise IT departments where troubleshooting often involves multiple engineers working across different shifts or development teams.

Another major component is integration with New Relic Autopilot, which uses specialized AI agents to assist with site reliability engineering tasks. Through the CLI, AI coding tools can access operational information and New Relic capabilities programmatically. The tool also supports scripts and continuous integration pipelines, potentially enabling production data to support automated software development processes.

New Relic already offers Ground Truth connectivity through the Model Context Protocol (MCP), which allows compatible AI tools to access operational information. The new CLI provides another method of accessing those capabilities, now designed for terminal-based workflows.

October 8, 2026
Harness Unfurls Source Code Repository Alternative to GitHub

Harness today launched a code repository service that is specifically designed for DevOps teams that are relying on artificial intelligence (AI) agents to generate code.

Martin Reynolds, Field CTO for Harness, said the Agent-Ready Harness Code Repository and AI Code Review service provides an alternative to existing GitHub source code repositories that were not designed to handle the volume of pull requests and updates that are made by AI agents operating at machine speed.

As a result, there are not only more outages but search and file history get slower as indexing falls behind, pull requests pile up faster than anyone can read them, and a permission system designed around a list of developers lacks the ability to identify and track an AI agent that might merge code on its own. The assumption legacy source code management tools make is that a human wrote code and opened a pull request that will be reviewed sometime later.

In contrast, the Harness Code Repository has been tested to handle thousands of simultaneous pull requests and commits from both AI agents and human application developers, said Reynolds. Search, history, and diffs keep working across repositories of any size that can have tens of thousands of branches.

Harness Code Repository and AI Code Review are both designed to be reachable via the Harness Model Context Protocol (MCP) server or command line interface (CLI). DevOps teams can review pull requests by the author’s email instead of an internal ID, see every open pull request across every repository and create, reply to, or resolve comment threads without opening a browser.

AI coding agents can either be assigned specific permissions or they can inherit them from application development teams that have deployed them. DevOps teams can further define what an AI agent can access, merge, or deploy, much like they do for any human software engineer using role-based access controls (RBACs) and policies based on the Open Policy Agent (OPA) framework provided via the Cloud Native Computing Foundation (CNCF).

The AI Code Review then reads a pull request, checks to see what gates are mandatory and prevents any request that fails from being merged. Additionally, differences are grouped by risk rather than by file, so high-risk changes that alter how the software behaves are not lost under a mass of renamed repositories and dependencies. A feedback capability also describes what a change puts at stake rather than noting that a line moved. If the feedback is valid, changes can be merged with a single click.

Any team can start using Harness Code Repository for free. Migrations from another repository, including GitHub, GitLab, Bitbucket and Azure DevOps, only require a few clicks, noted Reynolds.

In general, DevOps teams are starting to realize that a piecemeal approach to agentic AI engineering isn’t going to be sufficient, said Reynolds. Instead, the entire software development lifecycle (SDLC) will need to be re-engineered to manage what is becoming massive amounts of code that is overwhelming existing DevOps workflows, he added.

In the case of Harness, that means commits, review, builds, tests, security and deployments all stem from a single sequence within the platform. The Harness Software Delivery Agent then runs those workflows from commit to production using policies created via a single common engine. All workflows are then mapped in the Harness SDLC Knowledge Graph to provide the context needed for every review. Based on early testing, Harness claims DevOps teams have seen savings of 10,000 hours over the last month alone.

Mitch Ashley, vice president and practice lead for the Futurum Group, said the bottleneck in AI-assisted development has moved to review and approval. Agents produce code faster than teams can verify it, and verification debt builds faster than anyone can hire reviewers, he added.
The key here is still accountability, noted Ashley.

Regardless of the approach to software engineering in the age of AI, it’s now more a question of when rather than if DevOps workflows will be re-engineered. The only thing that remains to be seen now is how long that might actually require.

August 27, 2026
OpenAI Open Sources Codex Security CLI for the Merge Path

OpenAI has released its Codex Security command-line interface and software development kit as open source software under the Apache 2.0 license, providing a new way to bring its AI security scanner into development workflows.

The CLI can scan repositories, review staged and unstaged changes before a commit, compare findings across scans and export results for use in other code-scanning tools. Teams can also run it in CI and set a severity threshold that returns a failing status when a completed scan identifies a finding at or above that level. OpenAI recommends starting with advisory results before allowing findings to affect the CI check.

Because the client code is public, teams can inspect and adapt the CLI or SDK to fit their own tooling. But that openness stops at the integration layer, as the service that performs the underlying analysis remains under OpenAI’s control.

“OpenAI open-sourced the client and kept the scanner. That is distribution, not openness,” said Mitch Ashley, VP and practice lead for DevOps and application development with the Futurum Group. “The Apache-2.0 CLI lands in CI configs and pre-commit hooks while the beta-gated backend holds the model, triage logic, and the billing relationship.”

In practice, teams cannot use the published client code alone to operate a standalone scanner. The CLI and SDK remain in limited beta and are available only to approved customers and partners, according to OpenAI. Local users sign in with a ChatGPT account, while CI and other automated workflows use an OpenAI API key. Full repository scans may also require Trusted Access for Cyber. Developers can therefore inspect and modify the integration software, but the system that generates and evaluates findings still depends on OpenAI’s hosted service.

Security scanning in CI is already common, and established application security platforms are increasingly adding AI features to help assess findings, generate fixes and check whether those fixes work. Codex Security combines those activities in a more integrated agent workflow. According to OpenAI, the agent creates a threat model for the repository, examines possible attack paths, attempts to reproduce suspected vulnerabilities in an isolated environment and proposes patches for human review. It can then check whether a vulnerability remains after a fix is merged.

“Every team already runs a scanner in CI,” Ashley said. “The advance is an agent that confirms the finding, writes the patch, and verifies it across runs.”

Giving the agent responsibility for validating potential vulnerabilities and proposed fixes raises the standard it must meet before teams allow its output to block code changes. OpenAI says AI scans can produce different results even when the configuration remains unchanged, and that a previously reported issue disappearing from a later scan does not prove the vulnerability was fixed.

Ashley said Codex Security should earn a role as a merge gate only after OpenAI demonstrates that repeated scans of the same code produce sufficiently consistent findings. For DevOps teams, the unresolved question is whether those results can become dependable enough to decide whether a code change should be allowed to merge.

July 29, 2026
LocalStack Revamps CLI for Emulating AWS Cloud Services on Local Machines

LocalStack at the KubeCon + CloudNativeCon Europe conference this week unveiled a revamped command line interface (CLI), dubbed 1stk, for its framework that enables emulations of Amazon Web Services (AWS) environments to be run on a local machine.

The CLI in version 3 of the AWS 2026 edition of the framework, in addition to providing a single binary that is easier to install, also adds a Terminal UI (TUI) that walks developers through steps such as authentication or setting up an AWS profile. Additionally, it offers better log viewing, which is now also turned off by default.

At the same time, LocalStack has extended its Resource Groups Tagging API (RGTA) to enable developers to query and manage tags across multiple AWS services. Elastic Kubernetes Services (EKS) and CloudWatch resources are now fully integrated with the RGTA, and support for the Elastic Compute Cloud has been extended to provide an API for creating and deleting actual fleets of IT infrastructure resources versus providing a set of mock responses. Support for the libvirt VM manager is planned for a future release.

Finally, LocalStack as previously promised has now consolidated its community and enterprise edition into a single platform and removed continuous integration (CI) credit limitations from all tiers, including the non-commercial free tier. As of now, an auth token or continuous integration (CI) auth token is also required to start LocalStack for AWS.

LocalStack CTO Waldemar Hummer said that, in general, application developers still prefer to build software on a local machine that they have more control over. LocalStack was created to provide a local instance of an AWS environment that enables developers to build software that is destined to run in a cloud environment. That approach reduces the number of instances where code that runs on a local machine doesn’t actually run as intended in the cloud, noted Hummer.

At present, LocalStack supports AWS but the company is also building a set of emulation services for Microsoft Azure that will be made available later this year.

It’s not clear how much code is developed first on a notebook or desktop PC, but in the age of artificial intelligence (AI) the amount of code being generated by individual developers is increasing exponentially. Every time code has to be sent back to be revised only serves to slow the overall pace of application development. DevOps and platform engineering teams will need to streamline workflows in a way that reduces the amount of overall friction that is currently encountered as code moves into a production environment, noted Hummer.

The speed at which DevOps teams make that adjustment will naturally vary from one team to another, but the sooner everyone realizes that a piece of AI generated code might not run as intended in a cloud computing environment the less stress there is likely to be for all concerned. The challenge and the opportunity, of course, is identifying those points of friction before the amount of code being created might soon become too overwhelming to effectively deploy and manage.

March 24, 2026
AWS Extends Kiro AI Tool to Generate Higher Quality Code

Amazon Web Services (AWS) today with the general availability of its Kiro artificial intelligence (AI) coding tool added additional capabilities, including a version that can now be invoked via a command line interface (CLI).

At the same time, Kiro now enables property-based testing (PBT) to measure whether the code generated matches the behavior defined in the original specification.

Kiro now also provides the ability to rewind to a previous checkpoint the tool creates, enabling developers to rollback changes in addition to allowing Kiro to work across multiple project roots simultaneously.

Finally, AWS announced that it is giving away one year’s worth of Kiro Pro+ for qualifying startups that sign up by the end of this year.

David Yanacek, a senior principal engineer for agentic AI at AWS, said these capabilities collectively will make it simpler for developers to generate higher-quality code using an approach based on specifications that focus the AI model on a narrow range of tasks to ensure better outputs. That output can now also be tested using a set of properties that the tool creates based on those initial specifications.

PBT is designed to probe code using a technique called “shrinking” that functions almost like a red team trying to break your code. When it finds violations or counter-examples of better code, Kiro can automatically update your implementation, or surface options for you to fix the original specification, the code created or, if necessary, the PBT itself.

The overall goal is to produce more secure code that is easily understood by application developers that might need to debug it, he added. That approach provides the added benefit of reducing stress on DevOps engineers that might otherwise be created using AI coding tools that don’t rely on specification and PBT to generate better code, noted Yanacek.

Additionally, application development teams that opt for the CLI version of Kiro can make use of custom AI agents they have created to automate specific tasks versus relying on the steering files embedded with the AI coding tool, he added.

Mitch Ashley, vice president and practice lead for software lifecycle engineering at the Futurum Group, said CLI support in Kiro reinforces how important it is to have development tools that fit cleanly into the AWS ecosystem. Developers need an IDE and terminal workflow that share the same agents, steering files, and security settings so they can move between environments without losing context. The added capabilities in this release move Kiro beyond code generation into disciplined, verifiable development to provide a more dependable path for organizations that want AI powered development to scale with quality, not just speed.

There is, of course, no shortage of AI coding tools. AWS, however, is making a case for a more structured approach that walks developers first through requirements and visual designs to generate a specification. That approach enables developers to keep AI models focused on a specific task versus more arbitrarily adding steps that are beyond the scope of the task assigned, noted Yanacek.

That capability is critical because otherwise application developers will spend a significant amount of time creating their own prompt and context engineering workflows to achieve the same outcome, he added.

Alternatively, application developers can also revert to more of vibecoding technique if, for example, all they need to create is a simple script, noted Yanacek.

It’s not clear how much code is being generated using AI or, more importantly, how much of that code is considered good enough to use in a production environment. The one thing that is for certain is that without the proper guardrails in place AI coding tools quickly become too much of a good thing that may do more to reduce productivity than enhance it.

November 17, 2025
Flox CLI Tool Makes Managing Custom Developer Environments Simpler

Flox today made generally available an open source command line interface (CLI) for a namesake tool that enables developers to more easily spin up multiple custom development environments.

At the same time, the company revealed at the 21st annual Southern California Linux Expo (SCALE 21) that it is now providing access to FloxHub, a free repository for sharing development environments across teams.

Flox is based on the same declarative framework used to invoke the Nix package management and configuration tool. It allows developers to create environments that contain everything they need to build software, including automatic creation of a software bill of materials (SBOM).

Ross Turk, head of marketing and developer relations for Flox, said that approach provides developers with a framework for managing multiple development environments that they can spin up using the same methods commonly used to invoke the package managers versus having to master a less familiar approach to manage development environments, he added.

That capability makes it simpler for developers to both replicate development environments across machines and, when needed, dynamically switch between projects in a way that can be continuously audited by a centralized DevOps team. Instead of requiring a DevOps team to apply the same rigid standard environment across all development projects, each developer is still free to customize their environment based on their personal preferences.

In addition, developers trying to fix a bug can also now easily reproduce the development environment they were using at the time they were writing the code they needed to review.

DevOps teams are increasingly finding themselves caught between competing agendas. Many IT leaders are driving the adoption of platform engineering methodologies to centralize the management of DevOps workflows in the hopes of increasing developer productivity and reducing total costs. Conceptually, developers would prefer to have more backend processes managed by those teams, but not to the point where it forces them to use a development environment that has been defined for them. Each developer typically prefers to customize their development environment as the project evolves.

Arguably, one of the primary reasons developers embrace DevOps is that it gives them more control over their development environments. The challenge is that as each team defines its own DevOps workflow, organizations often later discover they are licensing redundant DevOps tools and platforms.

In the meantime, it’s not clear to what degree platform engineering might boost developer productivity. It no doubt will reduce the amount of time developers spend managing backend processes, but having that extra time doesn’t directly equate to better code being delivered faster. Writing code is as much an art as science, so it creates levels of inspiration that don’t always occur whenever a developer starts to write code. Instead, platform engineering creates more opportunities for inspiration to strike because they are not spending time on other tasks. At the very least, it should provide more time to run tests on the code that is produced.

One way or another, as application development continues to evolve, most organizations will find the middle ground that best suits their needs. The challenge now is reducing the amount of time between now and when that goal is eventually achieved.

March 13, 2024
GitHub Updates CLI to Make Creating Extensions Easier

GitHub this week made available an update to its command-line interface (CLI) that enables DevOps teams to add extensions to workflows.

Billy Griffin, director of engineering for GitHub, said the company’s initial focus was providing DevOps teams with a set of workflows that could be invoked easily via a CLI. Now GitHub is encouraging developers to extend those workflows using version 2.0 of its CLI that hopefully will be shared with the larger community, he added.

For example, extensions have already been created that order branches by how recently they were created and then display all associated pull requests.

At the other end of the spectrum, developers are creating simple screensaver extensions for their own amusement.

The level of interest in extensions varies widely across DevOps teams. Many of them simply want to employ an opinionated workflow that has been created on their behalf. Other DevOps teams want to be able to make modest modifications. Others prefer to customize workflows as much as possible to fit their specific purposes. Version 2.0 of the CLI provided by GitHub enables each DevOps team to decide how much to modify their workflows. However, as a DevOps team gains more experience, increasingly they tend to want to customize workflows.

The number of workflows being created around the GitHub repository continues to increase steadily as more organizations embrace best GitOps practices. GitHub is the most widely employed repository for managing software artifacts, and the level of sophistication of workflows built using either scripts or GitHub actions is increasing steadily. Much of that effort is focused on streamlining processes that otherwise would get in the way of enabling developers to spend more time writing code.

Of course, the pressure on developers to write more code faster has never been greater. As organizations embrace digital business transformation, they are discovering how dependent they are on software to create customer experiences that drive revenue. The challenge comes at a time when many developers are working from home to help combat the spread of the COVID-19 pandemic and many existing workflows need to be re-engineered. At the same time, development teams are becoming more distributed as organizations become more comfortable with hiring developers anywhere in the world.

It’s not clear to what degree the changing application development landscape might drive organizations to re-evaluate what platforms they are employing to drive DevOps processes. Many on-premises development platforms have been replaced by cloud-based alternatives in the past year. However, because necessity is the mother of invention, the workflows relied on prior to the pandemic are not only now forever changed, but they will also likely be altered again as development teams work more intermittently in-office and from home once the pandemic subsides.

Regardless of how those workflows evolve, the single-valued DevOps attribute is going to be flexibility. The challenge now is determining which platform does the most to enable that flexibility at a time when uncertainty continues to prevail.

August 27, 2021