devopsy.kinsta.cloud

Tag: spotify

Cursor Acquires Graphite to Streamline AI-Powered Development

Cursor, the artificial intelligence (AI) coding assistant valued at $29 billion, has acquired code review startup Graphite to address what Cursor CEO Michael Truell describes as a growing bottleneck in software development.

The companies declined to disclose financial terms but confirmed the transaction involves a mix of cash and equity.

While AI has dramatically accelerated code writing, the review process has remained largely unchanged, consuming an increasing portion of engineering teams’ time.

“Over the past 2.5 years, Cursor has made it much faster to write production code,” Truell said in a statement. “However, for most engineering teams, reviewing code looks the same as it did three years ago.”

Graphite, founded nearly five years ago, raised $52 million in a Series B round in March. The startup serves tens of thousands of engineers at more than 500 companies, including Shopify Inc., Snowflake Inc., Figma, and Perplexity AI.

The accord brings together complementary tools in the AI development workflow. Cursor helps programmers write code through natural language prompts and intelligent suggestions; Graphite specializes in reviewing those changes and determining when code is ready to ship.

A key feature of Graphite’s platform is “stacked diffs,” which lets developers submit code for review and immediately begin working on the next module rather than waiting for approval. This eliminates traditional bottlenecks where engineers must wait for one piece of code to be reviewed before starting dependent work.

Graphite’s AI-powered review tool also catches cybersecurity vulnerabilities, performance issues, and ensures code complies with company-specific formatting guidelines and documentation requirements. The platform provides customizable dashboards and keyboard shortcuts to speed up the review workflow.

Both products will continue operating independently in the near term, with deeper integrations planned throughout 2026. Lutsky emphasized that Graphite’s brand and product aren’t going anywhere, but the company now has significantly greater resources to enhance its offerings.

The deal comes just one month after Cursor announced it had reached $1 billion in annualized revenue and marks the company’s third acquisition. Cursor previously bought AI coding assistant Supermaven in November 2024 and acquired talent from enterprise startup Koala in July.

The acquisition positions Cursor aggressively in an increasingly competitive market dominated by OpenAI, Anthropic, and GitHub Copilot. However, Truell downplayed concerns about competition from major AI labs, noting that Cursor’s strategy focuses on combining the best available models with proprietary technology and superior user interface design.

Looking ahead, Truell said the company has no immediate plans for additional acquisitions or an IPO, instead focusing on product development as it pursues its ambitious vision for the next decade of automated coding.

December 20, 2025
Anthropic Acquires Bun to Accelerate AI Coding Tools

Anthropic says it has acquired Bun, a high-performance JavaScript toolkit, to turbocharge its artificial intelligence (AI) coding capabilities — further underscoring a significant push into developer tooling as it scales Claude Code, its code-generation platform.

Financial terms of the deal were not disclosed, but Anthropic emphasized that Bun will remain open source and MIT-licensed. The existing development team will continue working on the project, with development proceeding publicly on GitHub.

Bun, founded by Jarred Sumner in 2021, has emerged as a popular alternative to Node.js, offering developers an all-in-one solution that combines runtime, package management, bundling, and testing. Known for its speed and lightweight architecture, the toolkit has accumulated more than 83,000 stars on GitHub since its July 2022 debut.

Sumner noted the natural synergy between the two organizations, noting that Bun’s focus on developer speed complements AI coding tools’ similar objectives. The integration is expected to enhance not only Claude Code but also the Claude Agent SDK and future AI coding products, potentially reshaping how developers interact with AI-assisted programming tools.

The purchase comes as Claude Code achieves an annualized revenue run rate of $1 billion since its May launch. The AI coding tool has been adopted by major enterprises that include Netflix Inc., Spotify, and Salesforce Inc., cementing Anthropic’s position in the enterprise AI market.

“Bun will be instrumental in helping us build the infrastructure for the next generation of software,” Anthropic said in a statement. The company has been using Bun internally for several months, with the Bun team prioritizing issues identified by Claude Code developers.

What is more, the deal feeds into Anthropic’s broader expansion strategy, supported by substantial backing from Big Tech. Last month, Microsoft Corp. and NVIDIA Corp. announced plans to invest up to $15 billion in Anthropic, part of a larger partnership that includes a $30 billion commitment from Anthropic to utilize Microsoft’s cloud services.

Anthropic was recently valued at $183 billion and has positioned itself as a major competitor to OpenAI. The company’s success has been driven largely by strong enterprise adoption of its Claude AI platform.

December 6, 2025
Agile and Innovation: Striking the Right Balance in Software Development

The tech industry is abuzz with a contentious debate: Is Agile stifling innovation? Security expert Moxie Marlinspike brought this question to the forefront, challenging the very foundation of modern software development practices. However, a closer examination reveals that the issue is more nuanced than it first appears.

Marlinspike argues that Agile’s focus on incremental development and short-term goals restrains creativity and limits the ability to undertake ambitious, long-term projects. At first glance, this critique strikes at the heart of Agile methodologies. Yet, the real culprit is not Agile itself but its misapplication within many organizations.

Potential Pitfalls of Overemphasizing Process

Beyond the surface-level critique that Agile stifles innovation lies a more complex reality: The problem is not inherent in Agile’s principles, but in how organizations implement them or not. The issue is an overemphasis on process; when teams get too caught up in Agile rituals and tracking vanity metrics, they can lose touch with the more creative side of their work. Instead of encouraging and promoting innovation, it creates a culture obsessed with ticking boxes rather than thinking outside of them.

Another key factor is the lack of ‘elbow room’. True innovation requires space for experimentation and exploration. When Agile methodologies are pigeonholed and held under the tight reins of deadlines and deliverables, the lack of space for creative thinking means these methods fail to boost the very innovation they aim to foster. Failing to understand the flexibility that Agile methods offer your team automatically sets you up for failure.

The growing number of less experienced developers entering the field might worsen this problem. Many newcomers lack the holistic understanding that comes with the experience required for effective software engineering and innovation. This can lead to a surface-level application of Agile principles without grasping their deeper intent. It is more about understanding the original principles, which promote adaptability and doing the right thing, than simply sticking to the rules.

Agile in Action

That being said, not all Agile views and experiences are steeped in doom and gloom. Real-world teams are proving that Agile can work effectively when done right. Companies like Spotify have molded Agile to align perfectly with their team’s workflows and take advantage of their culture that supports autonomy and has trust and safety in place. By adapting Agile methods to suit their work and creative space, the team successfully sculpted a way of working that works in their context. Agile methodologies are not a destination but a journey that needs to be redirected and replanned, depending on the unique dynamics of your team and business.

Similarly, navigating the dynamic world of digital streaming, Netflix adopted Agile methodologies to maintain adaptability, prioritizing experimentation and rapid iteration. They have adopted a flexible approach to creating content, working in shorter bursts that allow for constant tweaks based on feedback. This way, they can quickly adapt and keep their work in sync with what their audience wants. Again, by embracing Agile’s original principles of welcoming change, Netflix has transformed content creation from a rigid, linear process to a more expressive and responsive ecosystem of creativity.

The Future is (Still) Agile

The key to harnessing Agile’s innovative potential lies in striking the right balance between structured process and free-rein creativity. Organizations need to prioritize the human element of Agile — the collaboration, creativity and motivation of their team members — over rigidly sticking to unchanging rules and guidelines. This means embracing an environment where teams have the freedom to explore new ideas, take calculated risks and think beyond immediate KPIs. Metrics should not be used as a punitive tool, but as a guide to help better understand team performance.

A huge part of reimagining Agile is recognizing that an overemphasis on being process-oriented can be limiting, while real innovation and change come from returning to Agile’s core principles: Valuing each individual and interaction. This means moving beyond checklists and ceremonies to truly understanding and nurturing the human dynamics that drive exceptional work. It is about rebuilding organizational structures around the people rather than processes. This also means recognizing when structures are failing teams. A one-size-fits-all approach suffocates creativity and stifles individual potential. Instead, organizations must develop the sensitivity and flexibility to create bespoke environments that allow each team to thrive in its unique way.

January 24, 2025
Spotify to Provide Opinionated Instance of Backstage IDP

Spotify today announced it is making commercially available an instance of its internal developer portal (IDP) based on the open source Backstage platform the company earlier contributed to the Cloud Native Computing Foundation (CNCF).

Pia Nilsson, senior director of engineering for Spotify, said Spotify Portal for Backstage, available as a private beta today, provides platform engineering teams with low-code/no-code framework for setting up an IDP.

In addition, Spotify is now making enterprise support available for organizations that adopted Backstage, along with additional plug-ins that simplify integrations with tools and platforms from third-party vendors such as New Relic, Atlassian, Snyk and Datadog.

Finally, Spotify is adding capabilities to manage hackathons and surface usage insights. A forthcoming plug-in also promises to make it possible to add data entities to a software catalog residing in Backstage.

Backstage has been gaining traction as an IDP mainly because it provides an extensible framework for centralizing the management of developer environments.

Spotify Portal Implementation

Some organizations have found it challenging to build and deploy Backstage. So Spotify is now making available a more opinionated Spotify Portal implementation that is simpler to deploy, configure and manage using templates, noted Nilsson.

As applications have become more challenging to build there is more focus on improving developer productivity. At the same time, IDPs enable platform engineering teams to streamline the number of tools being employed in a way that serves to reduce the total cost of software development.

Many developers want to add tools as they best see fit, so DevOps teams need to find a way to strike a balance between reducing the cognitive load developers encounter and what could become an overly heavy-handed approach to centralizing DevOps workflows. If talented developers start heading for the exits because they don’t like the experience being provided, IT leaders will find it difficult to replace them.

Giving DevOps Teams More time

The hope is that IDPs, when used within the context of platform engineering, will give developers more time to focus on writing business logic. However, application development is as much art as it is science. Just because developers have more time it does not necessarily follow that the insights and inspiration needed to write code automatically ensue. IDPs and platform engineering, at the very least, however, create the opportunity for developers to write more business logic faster. The degree to which that occurs naturally varies from one organization to the next.

Each organization will need to decide to what degree to embrace platform engineering, but regardless of their level of commitment IDPs can play a critical role in making it simpler to onboard developers to new projects, noted Nillson. In addition, an IDP makes it simpler for DevOps teams to track metrics such as the rate at which code is being updated, she said.

IDPs, of course, are not necessarily ideal but with the rise of Backstage there is clearly now more standardization, as DevOps teams continue to seek to eliminate as much friction as possible.

April 30, 2024
Spotify Adds More Plugins for Backstage Developer Portal

Spotify this week added additional plugins for its open source Backstage platform that is used to build developer portals. The new plugins make it simpler to address role-based access and access Insights, a tool from Spotify that tracks Backstage usage trends.

In addition, Spotify is also enhancing a Soundcheck plugin for Backstage that is used to visualize and track development of software components. Forthcoming capabilities include a no-code interface that makes it possible to programmatically create checks of code without writing any code.

DevOps teams will also be able to view, export and understand how teams and components are doing compared to established best practices and monitor trends, graphs and historical views, and receive notifications when levels change.

Finally, Spotify is committing to adding additional integrations with third-party tools and platforms such as Snyk, Sonarqube and the open source Argo continuous delivery (CD) platform.

There are now five plugins available via a Spotify Plugins for Backstage subscription service, and Spotify said more are planned.

Meg Watson, a group product manager at Spotify, said Backstage has been gaining traction in cloud-native application environments that are especially challenging to develop using multiple tools. Because of Backstage, developers are not only more productive but turnover has also been reduced because developers are provided with a better experience, she noted.

There’s a lot more focus than ever on developer productivity, which Backstage addresses by creating a catalog of blueprints that developers can readily consume rather than requiring them to build these capabilities themselves multiple times over. The goal is to create scaffolds that developers can consistently reuse across multiple application development projects.

Backstage was donated to the Cloud Native Computing Foundation (CNCF) and is now being advanced by contributions from multiple vendors. Much of that focus is on lowering the barrier of adoption for the platform, said Watson. Specifically, Spotify is working on a QuickStart for Backstage edition of the platform that is simpler to install, she said.

In general, Spotify is trying to strike a balance between centralizing the management of DevOps workflows and the need to enable developers to define workflows that are natural to them versus ones that have been imposed on them, added Watson.

It’s not clear to what degree Backstage will help fuel the adoption of a shift toward platform engineering to centralize the management of DevOps tools and platforms. The concept of a portal through which developers can self-service their own needs may not be new, but as an open source project, Backstage has made it simpler for many organizations to achieve that goal.

Just about every DevOps team is now being asked to find ways to help improve developer productivity at a time when many organizations are trying to do more with fewer resources. Regardless of the motivation, however, it’s apparent that DevOps workflows are continuing to evolve and mature.

In the meantime, DevOps teams would be well-advised to eliminate as many bottlenecks as possible before they negatively impact developer productivity.

May 10, 2023
Critical Vulnerability Discovered in Open Source Backstage Platform

Oxeye today disclosed that it has discovered a critical vulnerability in the open source Backstage software used to build developer portals. Backstage was originally created by Spotify.

A 1.5.1 update to the Backstage platform remediated a sandbox escape vulnerability that can occur via a third-party Scaffolder plug-in that could be used to conduct unauthenticated remote code execution (RCE).

Oxeye CTO Ron Vider said Oxeye worked with Spotify to responsibly disclose the issue and enabled a patch to be created prior to the disclosure of the vulnerability, which Spotify gave a 9.8 out of 10 severity rating.

Backstage is now being advanced under the auspices of the Cloud Native Computing Foundation (CNCF), but is already widely used by organizations such as American Airlines, Netflix, Splunk, Fidelity Investments, Epic Games and Palo Alto Networks, as well as by Spotify.

The vulnerability is another example of a potential template-based attack through which run shell commands can be manipulated to inject malware into an application development environment.

In general, separating the logic from the presentation layer as much as possible can greatly reduce exposure to the most dangerous template-based attacks.

Vider said Oxyeye is focusing its vulnerability research on cloud-native platforms such as Backstage that are generally being used to build modern applications based on a microservices architecture. It’s not clear to what degree organizations have transitioned away from more monolithic approaches to building applications, but it’s clear that a much larger percentage of applications are now being constructed using microservices.

Cybercriminals, of course, are targeting these platforms as part of a sustained effort to compromise software supply chains in the hope that the malware they inject will find its way into multiple downstream applications. Those attacks, in turn, are convincing more organizations to embrace DevSecOps best practices to better ensure the integrity of their software supply chains. The challenge is many of those attacks are being aimed at open source software projects that don’t always have enough resources to quickly develop a patch in the event a zero-day vulnerability is disclosed.

While it’s impossible to know the extent to which cybercriminals are already exploiting vulnerabilities in DevOps platforms, the level of cybersecurity scrutiny being applied has dramatically increased in the wake of a series of high-profile breaches. The Biden administration has even gone so far as to issue an executive order requiring federal agencies to better secure their software supply chains. As a result, DevOps teams should expect there to be a lot more DevOps platform vulnerability disclosures in the months ahead, and that those vulnerabilities will require immediate patching.

Like it or not, software supply chains are going to become more secure. The only thing left to be determined is the level of pain that will be experienced as more vulnerabilities are discovered in the DevOps platforms that were used to construct them.

November 15, 2022
How App Stores Are Addressing Fragmentation in the Linux Ecosystem

According to DistroWatch, 273 Linux distributions are currently active, with another 56 dormant and 521 discontinued. While some of these have shared underpinnings, it still makes for an extremely varied landscape for companies and developers.

It means developers must create multiple versions of their applications to be able to provide their software to all Linux users or just address a fraction of the market. Also, developers require multiple versions of build tools, which inevitably results in significant resource overhead.

Desktop application distribution is complex across all operating systems in general; in Linux, this is further compounded by such fragmentation and inter-dependencies both in the packaging and distribution of software.

For example, Fedora uses the RPM packaging format, while Debian uses the .deb format. Moreover, packages built for one version of a Linux distribution are often incompatible with other versions of the same distribution and need to be built for each version separately.

Developers need to satisfy all these requirements at the same time to be able to successfully offer their products to their users, which can be difficult with limited resources.

In a way, the choice of distribution and subsequent promotion of Linux software is a chicken-and-egg problem. Initially, companies and developers must decide what parts of the Linux desktop system they want to target. Then, once they have their products available to end users through one or more of the distribution channels, they still have to invest in separate efforts to promote their applications and capture usage.

Unfortunately, there is insufficient data to assist in the selection and optimization of either the distribution or the promotion process. Linux software developers generally lack sufficient immediate visibility to the usage and popularity of their software.

Traditionally, there have been multiple dimensions to how creators distribute their software: official websites, where companies and developers offer software downloads on their own domains; code repositories such as GitHub, GitLab and SourceForge; and application repositories in which Linux-based operating systems typically provide software through self-hosted storage locations.

To achieve the highest level of penetration, software developers will often distribute their applications using some or all of the above methods. Likewise, most users will utilize multiple methods to obtain software they need. While this gives developers more freedom in how they deliver applications to the end-users, it creates additional fragmentation.

In recent years, there has been significant effort to address the fragmentation in packaging and simplify the distribution of software through the establishment of software centers, in which some Linux distributions offer store-like destinations with a graphical frontend, software ratings, screenshots, descriptions and other user-focused data that allows better search and discovery.

Currently, there are three of these in the Linux space—AppImage, Flatpak and snaps. They each approach and handle the various aspects of usability in different ways.

AppImage and Flatpak technologies are architected to primarily support GUI desktop applications. Snaps are designed to work with servers, cloud infrastructure and IoT devices, in addition to desktop applications.

Spotify, a snaps publisher, is an example of a company benefiting from this approach. On one hand, it requires the Spotify engineering team to maintain both the snap and the traditional Deb package. On the other, the snap version is significantly easier to release, which has also helped with the simplification of the Deb release, as well.

The primary reason is the ability to use easy rollbacks, which have already been used. This feature removes uncertainty that a possibly broken version of the Linux desktop client application might be pushed out to the users. Spotify engineers first release the snap version, and after ascertaining that it works and behaves correctly, they build the Debian package, too. Snaps allows the Spotify team to more closely follow the weekly cadence of releases they have for the Windows and Mac versions.

The emergence of self-contained packaging and distribution mechanisms addresses a major problem in the Linux application ecosystem–the difficulty in establishing a successful business model because of the packaging and distribution challenges. The new formats reduce the fragmentation, as they minimize the number of permutations developers need to support for their applications.

The shift toward centralized application stores that are not specific to any particular Linux distribution offers higher discoverability and better consistency in the user experience.

Developers need fewer resources to support multiple target platforms, which allows them to focus their efforts on the core product, with the understanding their software will be available to the wider desktop audience, without having to depend on distribution-specific dependencies.

Since the aspects of new, refined models of promotion and distribution in Linux are still relatively young, we see improvements but there is still opportunity to develop and adopt better, data-driven practices.

As this field continues to evolve, the store model will help drive growth and usage of the Linux desktop, offering software developers a refined, more tangible experience than ever before.

— Martin Wimpress

September 17, 2019
DEVOPS AND CONTINUIOUS DELIVERY; THE NEED FOR SPEED

Some good stuff around the DevOps scene this week on DevOps and Continuous Delivery, which the pundits are saying will be a major spend area in 2014.

First up is the Devopsguys who with a little commentary reposted this infographic from Zend Technologies. It demonstrates the real value in DevOps and continuous delivery. One thing that jumped out at me was that according to the data, ninety- nine percent of the Companies surveyed are now recognizing a greater need for DevOps strategies than before. Zend built the graphic utilizing data from various credible industry sources.

Of course you can’t talk about Continuous Delivery without at least mentioning Jez Humble, after all he literally wrote the book on it. He recently posted on his blog four visualizations by Nhan Ngo, a QA Engineer at Spotify. The four visualizations were created while reading Jez’ book, Continuous Delivery. Some pretty intense stuff. Nhan Ngo made it look almost simple, almost like like a comic strip, but there is nothing funny about it.

If you really want to get into the trenches, here is an interesting video that I found called Continuous Delivery and Zero Downtime from the site Night Hacking. The scenario is your “Continuous Integration system is well oiled and kicks in after every commit. Your code is compiled. Your tests are green. You feel ready to take your project to the next level and move to Continuous Delivery.”

We aren’t done with our look at DevOps and Continuous Delivery just yet, DevOps Reactions probably illustrates best how Continuous Delivery works. It works in the model, but in the real world it requires real skill.

If you would like something mentioned here or have something you think I should Shout Out; email parker@devops.com and don’t forget to comment here.

March 18, 2014