Category: Features

  • Deepgram Enables Developers to Issue Voice Commands to DevOps Tools

    Deepgram Enables Developers to Issue Voice Commands to DevOps Tools

    Deepgram has developed a framework that leverages artificial intelligence (AI) technologies to enable developers to automate multiple tasks using a single voice command.

    Natalie Rutgers, vice president of product for Deepgram, said Deepgram Saga is essentially a voice operating system that can be layered on top of existing tools and platform that converts natural speech into a set of prompts that invokes the Model Context Protocol (MCP) developed by Anthropic.

    Via a single voice command, an application developer can verbally request, for example, to run tests, commit changes, deploy, and then update the team using any tool or platform that exposes an MCP server, thereby eliminating the need to type commands or switch between AI chat windows.

    Alternatively, an application developer can now verbally describe an idea, which Deepgram Saga transforms into a set of prompts for AI coding tools to then execute. Deepgram Saga will capture that stream-of-consciousness and transform it into structured documentation, tickets or pull request descriptions.

     

     

     

     

     

     

     

     

     

     

     

     

    Deepgram has been enabling developers to build speech-enabled applications for the better part of a decade but is now making an AI framework designed specifically for software engineering tasks. Deepgram Saga understands technical context, domain-specific terminology, and the nuanced terms that developers commonly use, noted Rutgers.

    It’s not clear just how readily application developers might give up their keyboards, but there are a wide range of tasks that many of them would probably prefer to verbally assign to an AI agent to complete. An application developer would still need to review that output generated by those AI agents but via a voice interface it now becomes easier to chain various tasks together to create a workflow.

    The pace at which application development teams are embracing AI is already accelerating. A recent Futurum Group survey finds that 41% of respondents expect generative AI tools and platforms will be used to generate, review and test code. Additionally, The Futurum Group finds that over the next 12 to 18 months organizations plan to increase spending on not only AI code generation (83%) and agentic AI technologies (76%) but also existing familiar tools that have been augmented with AI. Deepgram is essentially making a case for using a speech interface to accelerate the adoption of these tools by eliminating the need to master prompt engineering.

    Each developer will need to determine for themselves the degree to which they might be willing to give up typing altogether, but the one thing that is certain is many of them will be spending more time reviewing the output of AI agents than actually writing code and creating scripts they then have to maintain. That may require a significant amount of cultural adjustment and there may still be times when it is simply easier to type something than it is to verbally explain it.

    Regardless of any attachment developers might have to typing, the need to become more productive will almost assuredly force them to rely a lot less on keyboards when a faster speech interface for issuing orders to an army of AI agents is readily available.

  • Red Hat Woos Corporate Developers with Free Instances of RHEL

    Red Hat Woos Corporate Developers with Free Instances of RHEL

    Red Hat today launched an initiative intended to make a free distribution of Red Hat Enterprise Linux (RHEL) available to individual developers working within a corporate environment.

    Chris Wells, senior director of product marketing for RHEL, said the Red Hat Enterprise Linux for Business Developers program will reduce the level of friction that developers of corporate applications might otherwise encounter.

    Red Hat already has a long-standing developer program that is structured around organizations rather than individual developers. Rather than needing to become part of a program set up by an internal IT organization in collaboration with Red Hat, the Red Hat Enterprise Linux for Business Developers program provides application developers with direct access to a repository through which they can download up to 25 physical, virtual or cloud-based instances of RHEL. Previously, Red Hat also made available a free personal RHEL license option to application developers.

    The overall goal is to not only encourage developers to build applications using RHEL but also reduce the level of friction that might occur when applications are deployed in production environments that are based on RHEL, said Wells. Otherwise, a DevOps team would have to migrate an application developed on another distribution of Linux to RHEL, he added.

    Red Hat now provides access to instances of RHEL that can be deployed using traditional package management tools or as an immutable container. That latter approach tends to especially appeal to individual developers who would rather rip and replace a set of containers versus trying to apply a patch each time a new RHEL update is made available, noted Wells.

    There are, of course, any number of additional commercial services that application developers can also subscribe to if needed, he added.

    As always, there is an ongoing battle for the hearts and minds of application developers. In the wake of changes made to how Red Hat makes its offerings available to organizations, Red Hat is now clearly trying to make sure that application developers are able to build applications on top of its operating system without incurring any cost.

    It’s not clear how many application developers are building software on top of RHEL, but should application developers opt for a different operating system, Red Hat is concerned those platforms might one day supplant RHEL in production environments. Red Hat is also hoping that DevOps teams will encourage developers to build applications on top of RHEL to streamline application deployments.

    Regardless of motivation, making it possible for application developers to self-service their own for building applications is generally a good thing as long as it complies with existing corporate standards. The challenge is that many application developers when it comes to tooling have a lot of personal preferences that often fall outside the scope of those standards.

    Each organization will, naturally, need to determine how much freedom of choice they want to provide application developers, realizing, of course, that most of them have the resources and skills required to set up their own application development environments. Fortunately, it’s also not too long before most of those developers also conclude they would prefer to have somebody else manage those environments on their behalf.