devopsy.kinsta.cloud

Category: Blogs

Tricentis Taps Generative AI to Automate Application Testing

Tricentis this week added a generative artificial intelligence (AI) capability, dubbed Tricentis Copilot, to its application testing automation platform. It aims to reduce the amount of code that DevOps teams need to manually create.

Tricentus Copilot is based on an instance of the large language model (LLM) created by Open AI which has been deployed on the Microsoft Azure cloud. It’s the first iteration in what will eventually become multiple AI assistants is Tricentis Testim Copilot, which makes it possible to use natural language to describe a test that is then automatically generated in JavaScript. Additional Tricentis Copilot solutions for the Tricentis Tosca and Tricentis qTest platforms will be added later this year.

Mav Turner, chief product and strategy officer for Tricentis, said the user interfaces that the company created for each platform will also continue to evolve, to make it simpler to launch the appropriate prompts during any workflow.

The goal is to make it easier to create tests to improve application quality, said Turner. For example, organizations that have been using the beta editions of the Tricentis Copilot have already seen a 20% to 50% increase in the number of tests created, while reducing test failure rates by 16% to 43% so far, he added.

There’s no doubt that generative AI makes it substantially easier to create tests in ways that should enable DevOps teams to run more tests across the entire software development life cycle (SDLC). Rather than always having to wait for dedicated testing teams to write the code required, it will be increasingly feasible for any member of a DevOps team to generate a test, including application developers, who should be testing code as it is iteratively created.

Generative AI should also make it easier for DevOps teams to reuse tests once created and understand how they are being run using the summarization capabilities enabled by generative AI platforms that will also be able to provide recommendations to improve testing code. Collectively, those capabilities will make it possible to run tests faster, have fewer errors, reduce costs and increase productivity.

Those capabilities can all be provided in a way that doesn’t result in any of the testing code being used to later train any update to the core LLM provided by OpenAI, noted Turner. Longer term, Tricentis will continue to research which LLMs might be best applied to any given use case in a way that is transparent to a DevOps team that might not be interested in which LLM is being employed to automate a task. Currently, however, it doesn’t make much economic sense for Tricentis to build its own LLM, said Turner.

It’s not clear yet to what degree generative AI will democratize application testing, but as they become easier to create there should be more time to run more complex tests that might, for example, address cybersecurity issues. Most of the tests that are run today typically surface common programming mistakes. However, as testing becomes faster in the age of AI there should be more time to run a wider range of tests to ensure the best application experiences possible.

April 20, 2024
Valkey is Rapidly Overtaking Redis

In March, Redis announced that it was dumping the open source BSD 3-clause license for its Redis in-memory key-value database, instead adopting a “source-available” Redis Source Available License (RSALv2) and Server Side Public License (SSPLv1). That made both developers and users unhappy. So as open source people do, members of the community forked the code into Valkey with the support of The Linux Foundation. This move has proved much more popular than expected.

Madelyn Olson, an Amazon Web Services (AWS) software engineer and a Valkey maintainer, announced at the Open Source Summit in Seattle the availability of the first release, Valkey 7.2.5 GA. This release is based on the last open source version of Redis, 7.2.4. That’s good news, but it’s not big news. That’s what we expect from forks.

Rather, the important news is the immediate support for Valkey.

AWS, Ericsson, Google Cloud, Oracle and Verizon had all said they were supporting the fork. Now Alibaba Cloud, Aiven, Heroku and Percona are backing Valkey as well. I’ve seen many forks take off and overcome their parent projects – LibreOffice over OpenOffice comes to mind — but I’ve never seen one where so many Fortune 500 businesses spun on their heels to drop one project for another.

Olson said in her keynote speech, “These companies are planning to continue or even increase their contributions. Their support is needed for the long-term health and viability of the project. The community is thankful for their support, which will help keep the project open and keep our developers moving at the pace that our users demand.”

The Valkey fork’s maintainers have the technical chops needed to fulfill those business needs. As Olson pointed out, its technical leadership committee has 26 years of experience and over 1,000 commits to the open source project. Indeed, Tencent’s Binbin Zhu, a committee member, alone contributed almost a quarter of the open source Redis commits.

This response is not what Redis had in mind.

At the time of the fork, Redis CEO Rowan Trollope didn’t seem too worried. “The major cloud service providers have all benefited commercially from the Redis open source project, so it’s not surprising that they are launching a fork within a foundation,” he wrote. And he added, “Innovation has been and always will be the differentiating factor between the success of Redis and any alternative solution.”

With so many top maintainers now at Valkey, that assertion may be hard to pull off. As Heroku’s CTO Gail Frederick said during the conference, “With this group of experienced contributors and broad industry backing, Valkey is continuing the open source model that’s been transformative for developers everywhere.”

So many top Redis (the software) customers shifting to Valkey presents Redis (the company) with serious challenges. After all, Redis was the most popular database on AWS and by DB-Engine’s latest count, it’s the most popular key-value DBMS.

It appears that many of those customers are now on their way to Valkey.

Kyle Davis, an AWS senior developer advocate and former Redis employee, said, “AWS is committed to supporting open source Valkey for the long term. We are adding Valkey support to our ElastiCache and MemoryDB managed database services, which are built on open source Redis.”

Karan Singh, Oracle’s Director of Data and AI Product Management, wrote that “Oracle Cloud Infrastructure (OCI) Cache will continue supporting its current Redis 7.0-based service because the license changes don’t impact it.” However, Oracle is dropping the name Redis from its offering and is “working on integrating Valkey support into the OCI Cache service to ensure our unique in-memory database offerings on OCI continue to benefit from open source advancements, enhancing value for our customers.”

Empirical data suggests users are also moving away from Redis. Peter Zaitsev, Percona CEO, noted that DB-Engine is already showing a drop of interest in Redis.

Redis’s move attracted a lot of snarkiness. For example, Corey Quinn, chief cloud economist at The Duckbill Group, an AWS analyst firm, tweeted, “Good morning to everyone except the thieves at Redis. You didn’t build it; you stole it from the community. If you want it from the ones who built it, it’s called Valkey.”

What we’re seeing here is not open source fans copping an attitude. It’s companies and developers alike making a major move away from Redis.

Photo credit: Happy Lee on Unsplash

April 19, 2024
GitLab Adds AI Chat Interface to Increase DevOps Productivity

GitLab this week announced the general availability of GitLab Duo Chat, a natural language interface through which DevOps teams can invoke generative artificial intelligence (AI) to generate code, create tests and access summarizations of code. It is available as an add-on to the GitLab Duo Pro AI framework, which the company is embedding across its DevOps platforms. GitLab Duo Chat can be invoked via the GitLab user interface or GitLab’s web integrated development environment (IDE) in addition to third-party IDEs, including VS Code and the IDE provided by JetBrains.

Over the last few years, GitLab has been working with Google to embed a range of AI capabilities into its core platform. With the addition of GitLab Duo Chat, these are now more accessible.

As part of that effort, GitLab is also now adding privacy controls for GitLab Premium and Ultimate customers. These enable organizations to control sensitive data at the project, group, and subgroup levels to address security and compliance concerns.

David DeSanto, chief product officer for GitLab, said as AI capabilities become more accessible, the pace at which applications can be built and deployed is about to significantly accelerate. The most immediate impact should be a reduction in the number of instances where builds fail to deploy because the quality of the code used to construct them has improved, he added.

AI should make it easier for subject matter experts who have little software engineering expertise to participate in the application development process, noted DeSanto.

The immediate challenge DevOps teams will encounter is to determine how best to employ the prompts to generate code and tests within the context of their existing DevOps workflows. Over time, however, as the reasoning engines embedded within the large language models (LLMs) that are at the core genAI platforms improve, it will become feasible to automate a series of actions involving multiple tasks, DeSanto noted.

In the meantime, DevOps teams should start determining which manual tasks might be automated using a generative AI platform. In many organizations, there are still numerous bottlenecks in DevOps workflows that conspire to slow down the pace of application development.

AI platforms are unlikely to eliminate the need for application developers and software engineers any time soon. However, many scripts that DevOps teams have historically written themselves will soon be written and tested by machines. DevOps teams will soon find themselves supervising the development of more applications that, in addition to being constructed faster than ever, are less troublesome to update and maintain without having to add a small army of software engineers. The tradeoff is the overall size of the codebases that DevOps teams will be expected to manage is about to substantially increase, noted DeSanto.

In an era where organizations are more dependent than ever on software, the demand for applications already exceeds the ability of DevOps teams to address. AI should enable DevOps team to build and deploy applications at a level of scale that only a couple of years ago would have seemed unimaginable.

Photo credit: Ondrej Supitar on Unsplash

April 19, 2024
The Role of AI in Securing Software and Data Supply Chains

Supply-chain vulnerabilities loom large on the cybersecurity landscape, with threats and attacks such as SolarWinds, 3CX, Log4Shell and now XZ Utils underscoring the potentially devastating impact of these security breaches. The latter examples of Open Source Software (OSS) attacks are a growing attack vector. Capterra’s research reveals that software supply-chain attacks impacted almost two-thirds (61%) of all U.S. businesses from April 2022 to April 2023.

Expect attacks on the open source software supply chain to accelerate, with attackers automating attacks in common open source software projects and package managers. Many CISOs and DevSecOps teams are unprepared to implement controls in their existing build systems to mitigate these threats. In 2024, DevSecOps teams will migrate away from shift-left security models in favor of “shifting down” by using AI to automate security out of the developers’ workflows.

Here are the factors fueling the increase in software supply-chain attacks and the role of AI in helping developers work more efficiently while creating more secure code.

Attacks on the Open Source Software Supply Chain Will Accelerate

Open source libraries and languages are the foundation of over 90% of the world’s software. In a U.S. survey of nearly 300 IT and IT security professionals, 94% reported their companies use open source software, and 57% employ multiple open source platforms. Exactly half of the respondents say the threat level is “high” or “extreme,” while another 41% view it as “moderate.” At the time of writing, details of the backdoor implanted in the XZ library and several other OSS packages have just been published. The ubiquity of open source worldwide is one key factor fueling the rise of supply chain attacks.

Data Governance and the Data Supply Chain Will Become Critical Issues

Security pros must also consider how security vulnerabilities extend to their data supply chains. Although organizations typically integrate externally developed software through their software supply chains, their data supply chains often need clearer mechanisms for understanding or contextualizing data. In contrast to software’s structured systems or functions, data is unstructured or semi-structured and faces a wide array of regulatory standards.

Many companies are building AI or ML systems on top of enormous data pools with heterogeneous sources. ML models on model zoos are published with minimal understanding of the code and content used to produce the models. Software engineers need to handle these models and data just as carefully as they do the code going into the software they’re creating, with attention to its provenance.

DevSecOps teams must assess the liabilities of using data, especially when building LLMs to train AI tools. That demands careful data management within models to prevent the accidental transmission of sensitive data to third parties like OpenAI.

Organizations should adopt strict policies outlining the approved usage of AI-generated code, and when incorporating third-party platforms for AI, conduct a thorough due diligence assessment ensuring that their data will not be used for AI/ML model training and fine-tuning

AI Security Automation Will Help Organizations Transition From ‘Shift-Left’ to ‘Shift-Down’

The industry adopted the shift-left concept a decade ago to address security flaws early in the software development lifecycle and to enhance developer workflows. Defenders of systems have long been at a disadvantage. AI has the potential to level the playing field. As DevSecOps teams navigate the intricacies of data governance, they must also assess the impact of the evolving shift-left paradigm on their organizations’ security postures.

Companies will begin moving beyond shift-left to embrace AI to fully automate security processes and remove them from the developer’s workflow. This is called “shifting-down,” because it pushes security into automated and lower-level functions in the tech stack instead of burdening developers with complicated and often difficult decisions.

GitLab’s Global DevSecOps Report: The State of AI in Software Development found that developers only spend 25% of their time on code generation. AI can elevate their output by optimizing the remaining 75% of their workload. That’s one way to leverage AI’s capacity to solve specific technical issues and improve the efficiency and productivity of the entire software development life cycle.

Expect to look back on 2024 as the year that the escalating threats OSS ecosystems adversely affecting global software supply chains, catalyzed substantial changes in cybersecurity strategies, including a heightened dependence on AI to safeguard digital infrastructures. The cybersecurity landscape is already transforming, with a growing focus on mitigating supply chain vulnerabilities, enforcing data governance and incorporating AI into security measures. This transformation promises to steer DevSecOps teams toward software development processes with efficiency and security at the forefront.

April 19, 2024
Exploring Low/No-Code Platforms, GenAI, Copilots and Code Generators

The emergence of low/no-code platforms is challenging traditional notions of coding expertise. Gone are the days when coding was an exclusive skill set reserved for a knowledgeable few. Low/no-code platforms have democratized software development. They empower individuals from non-IT or technical backgrounds to translate their business ideas into applications without the need to master complex programming languages.

These low/no-code platforms, with their user-friendly drag-and-drop interfaces and pre-built components, have simplified application development. Imagine building a smart home application with just a few clicks and drags — low/no-code platforms are making it possible.

Add generative artificial intelligence (Gen AI) into the mix, and the new development practices change the field remarkably.

The Impact of Gen AI on Low-Code Platforms

Expect low-code platforms to evolve further, becoming more intelligent, adaptable and seamlessly integrated into the software development lifecycle. There will be a shift towards platforms that use Gen AI to understand user intent, automate routine tasks and generate complex code snippets.

Gartner predicts that, by 2026, over 80% of enterprises will use GenAI APIs and models or deploy GenAI-enabled applications in production environments, up from less than 5% in early 2023.

Combining low-code and Gen AI will empower developers by automating routine tasks and allowing them to focus on high-level logic and creativity. Gen AI acts as a multiplier that can accelerate and optimize developmental operations.
McKinsey estimates that generative AI could add $2.6 trillion to $4.4 trillion annually to the global economy by 2040.

Another Tool: AI Copilots and Code Generators

Another promising application for AI large language models (LLMs) is AI-powered assistants. Enter copilots and code generators — AI assistants that take the hassle out of coding.

While low/no-code platforms have transformed application development, copilots and code generators add an extra layer of efficiency.

AI copilots use a chat interface to simplify coding through a chat interface, where developers articulate their code requirements in natural language prompts, and the copilot generates the code accordingly. These assistants provide real-time assistance, offering contextual suggestions and code snippets, and they can anticipate potential bugs. Moreover, they can explain code blocks, generate unit tests and propose bug fixes, which enhances the coding process.
AI copilots are like trusted assistants, ready to aid you with specific coding tasks or generate complex code – and they do it swiftly.

The Big Question

As a result of low/no-code platforms gaining traction, the skill sets required in the tech industry will transform. Gone are the days when proficiency in multiple programming languages was a must-have.

With low/no-code tools taking center stage, does this mean coding is becoming obsolete?

A big no.

While basic programming knowledge remains valuable, it’s no longer the sole requirement for building innovative applications. With low/no-code platforms democratizing application development, individuals from diverse backgrounds can leverage technology to create impactful solutions.

Do GenAI, copilots, and code generators render low/no-code platforms obsolete?

Again, no.

While GenAI, copilots, and code generators excel at certain specific tasks, low/no-code platforms offer a holistic solution, combining visual interface design, database integration and more. They’re the Swiss army knives of development, catering to a wide range of needs beyond just code generation.

Gen AI, copilots and code generators are not here to replace low/no-code platforms or traditional coding practices. Instead, they are positioned to complement and enhance them. The fusion of these technologies holds great promise in simplifying software development, boosting efficiency, and unlocking new avenues for innovation.

The Final Word

With better code suggestions and automated testing capabilities, low/no-code platforms deliver high-quality solutions that meet the demands of today’s tech-savvy users.

With the thrilling combination of low/no-code platforms and GenAI, the future of software development is promising. While these advancements may disrupt traditional coding, they also present opportunities for innovation and creativity.

It’s time for us to embrace this change and build a brighter tomorrow, one line of code — or lack thereof — at a time.

April 18, 2024
Datadog DevSecOps Report Shines Spotlight on Java Security Issues

Datadog today published a State of DevSecOps report that finds 90% of Java services running in a production environment are vulnerable to one or more critical or high severity vulnerabilities introduced by a third-party library, versus an average of 47% for alternative programming languages.

Based on an analysis of IT environments being monitored using the Datadog platform, the report also notes 63% of high and critical vulnerabilities in Java applications derive from indirect dependencies that are traced back to third-party libraries that have been indirectly packaged with an application.

The report also notes that Java applications are disproportionately affected by the Known Exploited Vulnerabilities (KEV) catalog of vulnerabilities compiled by the U.S. Cybersecurity and Infrastructure Security Agency (CISA). Java applications can be impacted by 55% of these vulnerabilities, compared to 7% for other programming languages.

Just under a quarter of Java services (23%) are vulnerable to remote code execution (RCE), impacting 42% of organizations, according to the report.

It’s not clear to what degree organizations might be willing to abandon Java to improve application security, but there are already millions of Java services running in enterprise IT environments that DevSecOps teams need to secure.

Andrew Krug, team lead for security evangelism at Datadog, said it’s not likely organizations will resolve application security issues overnight. Instead, they should be focusing on continuous improvement over time that relies more on automation to ensure best DevSecOps practices are implemented and maintained. The report notes that 38% of organizations running applications in Amazon Web Services (AWS) were still manually deploying applications using “ClickOps” processes versus relying on a continuous integration/continuous delivery (CI/CD) platform.

The biggest challenge with DevSecOps is that not every vulnerability is always present in every application. The Datadog report, for example, noted that while the average service is vulnerable to 19 vulnerabilities, only 5% of vulnerabilities are being actively exploited.

DevSecOps teams should also assume every vulnerability rating is accurate. Datadog applied the Exploit Prediction Scoring System (EPSS) to rank the criticality of vulnerabilities. After applying an adjusted score, 63% of organizations that had vulnerabilities with a critical CVE severity no longer have any critical vulnerabilities. Just under a third (30%) of organizations saw their number of critical vulnerabilities reduced by half or more.

The report also noted that the smaller a container image is, the fewer vulnerabilities it is likely to have. On average, container images smaller than 100 MB have 4.4 high or critical vulnerabilities, versus 42.2 for images between 250 and 500 MB, and almost 80 for larger images.

In general, DevSecOps teams need to carefully evaluate not just how serious a vulnerability is, but also whether the vulnerability can be reached and is running, whether there is a known exploit and whether the software containing the vulnerability is running in a production environment. That’s critical because in 2023 there were more than 4,000 high and 1,000 critical Common Vulnerabilities and Exposures (CVEs) identified, but not every one of them represents the same level of actual risk to a business.

The Datadog report also noted automated security scanners employed by cybercriminals are more of a nuisance than an actual threat. Out of tens of millions of malicious requests that we identified coming from such scanners, only 0.0065% successfully triggered a vulnerability. It’s more important to have a framework to prioritize better prioritize alerts by monitoring raw web server logs or perimeter web application firewall (WAF) alerts. Failing to triage those alerts ultimately leads to a higher level of fatigue that, when vulnerabilities are missed, leads to higher levels of security nihilism, resulting in IT teams being blamed for breaches that are not really their fault, noted Krug.

It’ll be a while before software supply chains become more secure, but the one thing that is certain is that determining which vulnerabilities require immediate attention is critical to ensure developers still have enough time to build and deploy additional applications.

April 17, 2024
OpenSSF warns of Open Source Social Engineering Threats

Linux dodged a bullet. If the XZ exploit had gone undiscovered for only a few more weeks, millions of Linux systems would have been compromised with a backdoor.

We were lucky. But can we stay lucky?

The Open Source Security Foundation (OpenSF) and the OpenJS Foundation revealed that a similar hackling attempt had targeted several JavaScript programs.

Just as with XZ Utils, a few people wanted OpenJS to designate them as new project maintainers despite having little prior involvement. They “implored OpenJS to take action to update one of its popular JavaScript projects to address any critical vulnerabilities, yet cited no specifics,” wrote Robin Bender Ginn, OpenJS executive director, and Omkhar Arasaratnam, Open SSF general manager.

Well, that was never going to happen.

Jia Tan, the mysterious hacker who became a top XZ programmer and maintainer, before inserting a backdoor in the code, had spent years establishing his project credibility before making his move.

Still, warned Ginn and Arasaratnam, we’ll see more of these kinds of social engineering attacks. In such instances, the friendly attacker seeks to exploit “the sense of duty that maintainers have with their project and community in order to manipulate them.”

Specifically, these security leaders warn against pull requests containing blobs as artifacts. For example, they point out that the XZ backdoor included a cleverly crafted file in the test suite that wasn’t human-readable.

Dubious source code may also be intentionally obfuscated or difficult to understand. For example, the XZ issue started with a relatively innocuous replacement of safe_fprintf() with fprintf() to see if anyone would notice. No one did.

The question now is: Are such attacks already ongoing? Or, far worse, have they already been made, and they weren’t spotted? Chris Hughes, chief security advisor at Endor Labs, told me, he “suspects that many of these are already underway and may have already been successful but haven’t been exposed or identified yet.”

How? Hughes explained, “Most open source projects are incredibly underfunded and run by a single or small group of maintainers, so utilizing social engineering attacks on them isn’t surprising, and given the pressures maintainers are under, they will likely welcome the help. If done well by the attackers, it may be difficult for the maintainers to determine which involvement is from those interested in collaborating and contributing to projects versus those with malicious intent.”

He’s not wrong.

As Jim Zemlin, the Linux Foundation‘s executive director, said at the Open Source Summit North America in Seattle, we’ve been making progress with security. But “trust is something we need to talk more about,” he added. We need to answer the question: “Who writes all this software? This is different from a security question. Security is ‘Is there a vulnerability?’ Who is more of a trust question? Do we trust this identity? Enough to give them a maintainer role?”

Bad news, folks. Zemlin admitted we don’t have a good solution to this problem.

Indeed, we’ve seen such attempts before. In 2021, for example, researchers at the University of Minnesota tried to insert vulnerabilities in the Linux kernel to see if it could be done. Spoiler alert: They failed, and they were banned from the Linux kernel.

But don’t get comfortable. The Linux kernel has a large team of passionate, brilliant maintainers. Few projects are so lucky.

Dan Lorenc, founder and CEO of the security company Chainguard, put it well. “Projects get stale, maintainership changes, and there are a lot of considerations to keep in mind when granting someone new commit access to a critical project. There’s no single right way to do this, but cataloging best practices with the community would go a long way to helping prevent this in the future.”

What are the trust best practices? We honestly don’t know yet. But, if we’re to trust our open source projects, we must figure it out.

April 17, 2024
Auto Reply

April 17, 2024
CDF Survey Surfaces DevOps Progress and Challenges

A global survey of more than 10,000 developers conducted by the Continuous Delivery Foundation (CDF) finds 83% of developers are involved in DevOps-related activities, with a third (33%) actively using continuous integrations tools, monitoring tools to track infrastructure performance and testing applications for security vulnerabilities.

Revealed today at the cdcon event, another 29% of respondents said they were actively involved in continuous delivery/deployment. The most widely used DevOps tools and platforms are source control management (29%) and issue tracking (28%), but only (21%) said they build continuous integration/continuous delivery (CI/CD) pipelines.

According to Mark Waite, community manager for CloudBees, the survey results said that while DevOps practices are widespread there is a clear need for organizations to achieve higher levels of maturity given the uneven adoption of best practices. For example, only a quarter (25%) of respondents said they programmatically manage infrastructure.

Overall, the survey suggests that organizations are on a DevOps journey that results in specific DevOps practices being adopted to meet unique requirements versus adopting a set of standards that are universally applied, Waite noted.

For example, the survey finds only 14% of respondents implement code changes daily, while another 17% require less than a week. More than two-thirds (68%) require a week or more, the survey finds. Similarly, only 9% deploy code multiple times a day, while another 20% are somewhere from once per hour to once per week. Only 11% said they could restore a service in less than an hour.

Those percentages have remained relatively consistent for the three years the CDF has been conducting this survey. However, the survey indicates that organizations that use managed CI/CD platforms are slightly more productive than organizations managing these platforms themselves. However, the report also notes that organizations using multiple CI/CD platforms tend to be less productive than those that have standardized on a single platform.

It’s not clear to what degree organizations are coping with the rise of platform engineering. The methodology, meant to manage DevOps workflows at scale, is standardizing DevOps tools and platforms. Historically, each DevOps team has tended to prefer whichever tools and platforms it selects, but over time multiple platforms can result in both higher levels of friction and increased costs.

Ultimately, no one-size approach to DevOps fits every organization. The one thing organizations that are committed to DevOps share is a commitment to higher levels of automation. In fact, with the rise of artificial intelligence (AI) the next era of DevOps is dawning.

In the meantime, finding and retaining software engineers remains an issue. There has been an ongoing effort to shift more responsibility for IT operations toward developers. However, as the cognitive load placed on developers increases, the amount of time they have to write code decreases. Not every developer writes code 100% of the time, but the less time developers spend focused on code the less productive they will be in terms of the amount of code that make it into a production environment. The challenge, as always, is striking the right DevOps balance.

Photo credit: Marc A on Unsplash

April 16, 2024
Survey Surfaces Widespread Reliance on Generative AI Among Developers

A survey of 885 developers conducted by Docker, Inc. finds reliance on artificial intelligence (AI) to help build applications is rapidly becoming pervasive.

Nearly two-thirds of respondents (64%) are using AI for coding (33%), documentation (29%), conducting research (28%), writing tests (23%) and troubleshooting/debugging (21%). The most widely used generative AI platforms are ChatGPT (46%), GitHub Copilot (30%), and Google Gemini (19%).

Overall, 65% of the developers surveyed said they view AI positively because it simplifies processes (61%) and enables them to focus more on crucial tasks (55%). Less than a quarter (23%) view AI as a threat to their job.

However, nearly half (45%) said there is too much emphasis on AI. Nevertheless, 40% of respondents identified generative AI as the most important trend in software development, followed closely by AI assistants for software engineering (38%).

Dr. Julia Wilson, user experience researcher for Docker, Inc. noted that more senior and full-stack developers tended to view GenAI as most important, whereas more junior developers with less than five years of experience viewed AI assistants for software engineering as being more important.

It’s still early days when it comes to applying AI to software engineering but it’s clear there are plenty of use cases. Most of that usage currently benefits developers. However, as reasoning engines embedded within large language models (LLMs) become more advanced, it’s now only a matter of time before generative AI platforms can orchestrate a series of tasks that previously would require DevOps teams to write scripts to programmatically perform. Instead, the generative AI platform will create the required scripts required. Those capabilities will serve to eliminate a lot of the toil that ultimately conspires to burn out members of a DevOps team, noted Wilson.

It remains to be seen, however, what impact generative AI will have on how DevOps teams are structured. In theory, an existing DevOps team augmented by AI should be able to build, update and manage a lot more applications. In many cases, the need for entry-level developers might be sharply reduced or, conversely, it may turn out that the junior developers can manage tasks that previously required a senior developer. At the same time, AI may ultimately make DevOps more accessible to a wider range of organizations that previously lacked the resources required to hire and retain software engineers.

The one certain thing is AI is not going back into the proverbial bottle. In fact, the next generation of generative AI platforms will be trained on a narrow set of code that has been vetted for quality and security. That approach should reduce the number of instances where a generative AI platform “hallucinates” in a way that produces code that simply doesn’t work or is rife with known vulnerabilities. General-purpose LLMs such as ChatGPT were trained using code examples pulled from across the Web so the current level of the code being generated is inconsistent.

As a result, one short term concern DevOps teams should have is whether developers become too dependent on generative AI platforms that, by definition, are probabilistic rather than deterministic. In fact, it’s often challenging for a generative AI platform to consistently surface the same code when responding to identical prompts.

As is the case with any major innovation, the challenge is making sure that AI is used both responsibly and safely anytime it is being used to generate code.

Photo credit: Thomas Lefebvre on Unsplash

April 16, 2024