devopsy.kinsta.cloud

Author: Derek Ashmore

Coding Agent Teams: The Next Frontier in AI-Assisted Software Development
It’s 2025, and coding agents are old news. It has become commonplace for programmers to work with an AI-powered agent, such as Copilot or Cursor, to help accelerate the software development process.

Today, innovative programmers are taking AI agents a step further. They’re building entire teams of coding agents, an approach that doubles down on the efficiency and scalability of AI-assisted coding tools.

That said, replacing a single coding agent with a multi-agent team also presents new challenges, not least in the realm of deciding exactly how to construct and orchestrate agents.

Read on for details as I unpack the reasons why developers are pivoting toward the coding agent team model, as well as the top coding agent frameworks to consider. This article draws on my personal experience leveraging teams of coding agents to streamline my own software projects over the past several months.

What is a Coding Agent Team?

A coding agent team is exactly what it sounds like: A group of AI agents that assist with coding.

Agent teams are innovative because until recently, most developers relied on just a single AI agent to help them write, build, test, and/or deploy code. They used AI-assisted development tools that were more or less designed to operate as if they were a single, full-stack developer and DevOps engineer, capable of handling all aspects of the software development process and life cycle.

Coding agent teams replace this approach with a collection of agents, each tailored for a different development task. The exact number of agents and their roles can vary, but as an example, one agent might write frontend code, while another develops an application backend, a third writes and executes tests and a fourth reviews test results to determine whether code is fit for deployment. And alongside all of these is a “team lead” agent, responsible for receiving high-level instructions from a human developer and delegating them to individual agents on the team.

The Benefits of Multiple AI Agents for Coding

Switching toward a multi-agent approach to AI-assisted software development offers a range of benefits that help to make the development process even faster and smoother than it would be with a traditional, single-agent model.

1. Faster development

The ability to have multiple agents working concurrently increases development velocity. When you can write your frontend and backend code in parallel, while also beginning the testing and review process as soon as code starts to appear, you go from idea to release much faster than you would if you had a single agent performing these tasks sequentially.

This benefit is especially important in the context of large-scale projects, where the ability to work on multiple application components in parallel can significantly speed up the development process.

2. Agent specialization

Agents tend to work more efficiently and effectively when they are optimized for specific tasks. For example, an agent designed for frontend development is likely to produce higher-quality frontend code by connecting to a model optimized for this purpose.

In this sense, a coding agent team is preferable to relying on a generic agent to write all of your code. The latter may be able to do it all, but not in an optimal way.

3. Simulating Human Teams

The multi-agent model makes it easier to align AI-assisted development workflows with the structure of human software development teams. Each AI agent can handle tasks that would fall to different programmers, such as (again), frontend and backend development.

In this way, agent teams allow human participants in the development workflow to work alongside agents that are customized for their particular domains, further boosting productivity and efficiency.

4. Turning Developers Into Product Owners

Even more than single coding agents, agent teams empower developers to act as product owners who can oversee all aspects of the development process. Developers define what they want to happen, then hand implementation over to agents.

The result is less time manually coding and more time focusing on application features and optimizations – leading ultimately to a better product delivered in less time.

Practical Approaches to Building AI Agent Teams in Software Development

Putting the multi-agent model into practice can be a bit challenging because, like many other agentic AI technologies, solutions for building and managing teams of AI agents remain fractured. Various frameworks exist, which with different strengths and limitations. Thus, a challenge for developers is selecting the coding agent framework that best aligns with their overall goals and priorities.

Having experimented with multiple AI agent frameworks for software development, I’ve landed on the following as the leading options at present (although it’s important to note that the fast-evolving nature of this space means that this list could look different just months from now):
- MetaGPT: Simulates project management, development and quality assurance roles. A good option for end-to-end codebase creation.
- CrewAI: Uses a role-based, modular agent approach. Excels for structured team workflows that are broken into distinct development tasks.
- AutoGen: An event-driven agent framework from Microsoft. Ideal for highly automated agentic software development workflows. Offers the advantage of multi-model support (including Claude and OpenAI/GPT).
- OpenCode: A lightweight, CLI-based framework for managing agent interactions. Ideal for developers who prefer terminal-centric coding workflows.
- Claudeflow: An open source agentic AI framework that integrates natively with Claude. Uses a team lead model, with a lead agent responsible for delegating tasks to other agents. Good for workflows with clearly defined development roles.
Conclusion: Taking AI-Assisted Coding to the Next Level With Agent Teams

On balance, I should note that not every development project or need is best served by a coding agent team. For very small codebases, a single agent is usually better. It may also be appropriate to use just one agent to address discrete tasks, like remediating a specific bug.

But for most software development projects, pivoting toward a team of coding agents is a faster, more productive way to work. The biggest hurdle to clear is simply deciding which agent framework to use. From there, programmers can deploy a fleet of agents tailored for their unique software development needs.
October 9, 2025
Best Practices for CI/CD Migration: The GitHub Enterprise Example
Continuous integration/continuous delivery (CI/CD) software — meaning solutions that teams use to build, test and deploy applications — has come a long way over the past decade. While organizations once cobbled together CI/CD pipelines using disparate open-source tools, they now have a plethora of end-to-end, vendor-supported enterprise CI/CD platforms that they can use instead. Because these solutions offer everything teams need to deliver software, they are simpler to deploy and manage.

Yet, while there are clear benefits to adopting an enterprise CI/CD platform, migrating to one can be difficult. It poses several challenges, such as the risk of CI/CD pipeline downtime and security and compliance challenges.

That is why businesses migrating to newer CI/CD solutions should approach the process with a detailed, step-by-step plan. Here’s a look at the challenges to navigate, along with tips on how to make CI/CD migration as smooth as possible.

To ground the discussion, I shall focus on migrating to GitHub Enterprise, a CI/CD platform from GitHub, the software development platform now owned by Microsoft. GitHub Enterprise is the option that more and more businesses are choosing to help companies modernize their IT and software delivery practices.

Challenges to GitHub Enterprise Migration

As a comprehensive CI/CD platform that is available as a fully hosted solution, GitHub Enterprise is relatively easy to use once you have migrated to it. The challenge, though, is getting your code into the platform, along with making the process changes necessary to begin using the solution in place of a legacy CI/CD suite.

You may expect to face challenges that include:
- Application delivery delays: A drawn-out, time-consuming migration process translates to downtime for CI/CD operations, which means that your developers won’t be able to push out application updates. This can ultimately harm the business because users aren’t receiving feature enhancements while your CI/CD pipelines are in transition.
- Performance risks: Failure to choose the right GitHub Enterprise deployment strategy and to configure the solution in an optimal way could slow down CI/CD performance and reduce developer productivity due to issues like insufficient infrastructure resources for building and testing applications.
- Training requirements: Skilled software developers can typically learn to use a new CI/CD platform easily enough, but there is still an upskilling requirement. It is important not to overlook the need to provide developers time to learn GitHub Enterprise (or whichever solution you are migrating to).
- Security and compliance: To mitigate risks like the injection of malicious code into your applications, it is critical to implement access controls during the migration process, which prevents unauthorized users from accessing the new CI/CD platform.
Best Practices for a Smooth GitHub Enterprise Migration

The good news is that with the right approach, migrating to GitHub Enterprise or a similar CI/CD platform doesn’t have to be risk-prone. The following best practices can streamline the process.

1.    Choose the Right Hosting Option

Like many CI/CD platforms, GitHub Enterprise is available in two basic forms: A fully managed, cloud-based option and a version that users can install and manage using their own infrastructure.

In general, the fully managed solution tends to be the better choice because it significantly reduces setup and maintenance effort on the part of users. However, the self-hosted option may be better for organizations that need greater control over their CI/CD environment. This tends to be especially true for businesses in verticals like finance and insurance, where security and compliance mandates may be easier to meet when the organization runs CI/CD software on its own infrastructure (and therefore has greater control over how sensitive data is managed and secured).

2.    Configure Granular Access Policies

Like most modern CI/CD suites, GitHub Enterprise provides access control features that businesses can use to determine who can do what within CI/CD tools. For example, you can give some developers read-only access to source code, while allowing others to modify it. GitHub Enterprise also supports environment-based access settings, which means you can configure different levels of access for the same users across dev/test and production environments.

As a best practice, take advantage of these granular access control options by assigning different access rights to each team that uses your CI/CD platform. For example, you might have an admin team whose privileges extend to changing the configuration of GitHub Enterprise, while another team that merely uses the platform has a lesser level of access.

3.    Use OpenID Connect to Integrate With Cloud Environments

GitHub Enterprise offers an identity management option that leverages OpenID Connect (OIDC) to integrate with third-party cloud environments.

When you take advantage of this feature, you can automatically run workflows (like application builds) on public cloud infrastructure without having to store cloud access credentials as long-lived GitHub secrets, which presents a substantial security risk. In addition, this approach automatically creates a log of GitHub workflows and action executions, which you can use for audit and monitoring purposes.

4.    Leverage Single Sign-On

Another way to streamline the migration into GitHub Enterprise is to integrate the platform with whichever single sign-on (SSO) provider (like Microsoft Entra or Active Directory) your business already uses. Ideally, you would also enable multi-factor authentication (MFA) through your SSO solution to add another layer of security.

This approach eliminates the need to manage GitHub Enterprise access credentials separately from your existing accounts. It also reduces the burden placed on your IT team during migration because instead of having to ‘reinvent the wheel’, they can simply use a sign-on solution that already exists.

5.    Document Common Tasks

To ease the learning curve for developers as they migrate to GitHub Enterprise, document common tasks — such as how to migrate code from local repositories or another CI/CD platform into GitHub Enterprise.

This is another tactic that eliminates the need for your team to reinvent the wheel repeatedly; instead of forcing each engineer to figure out how to migrate on their own, everyone can follow a prescribed plan.

6.    Publish Workflow Patterns

Going further, consider publishing detailed steps on how to use key features in GitHub Enterprise, which are likely to be important for all your teams. For example, you can detail how to create pull requests or build Docker images in the platform, or how to execute infrastructure-as-code (IaC) deployments.

Here again, this strategy reduces the learning curve and helps get your team up and running on the new platform as quickly as possible.

7.    Automate Common Workflows Using GitHub Actions

Furthermore, you can create fully automated workflows for common tasks using GitHub Actions, a feature that lets you trigger automated operations across various parts of your CI/CD pipeline. For instance, you can automatically trigger an application build after code has been checked in, or automatically begin testing after the build is complete.

Highly complex workflows that may vary between projects or teams are not great candidates for this type of automation, but core routines can be fully automated, making it even easier for your team to begin using the new platform.

Conclusion

No matter how you approach it, migrating to GitHub Enterprise or another modern CI/CD platform requires time and effort. But by being strategic about how you approach migration, you can minimize that time and effort — as you must if you want to avoid the risks that come with CI/CD migration and get your pipelines up and running in the new platform as rapidly and smoothly as possible.
December 10, 2024
Security, Automation and Developer Experience: The Top DevOps Trends of 2024

If you ask most folks to describe the top DevOps trends in 2024, you’ll likely hear buzzwords like AI or DevSecOps.

Those are certainly trendy topics. But based on my everyday work helping businesses plan and execute DevOps strategies, I’m noticing a different set of salient trends in DevOps. Although much is being said about how technologies like AI might impact DevOps, the biggest changes I’m seeing right now involve other types of solutions and techniques.

Here are what I view as the three most important current DevOps trends, along with a breakdown of how they may change DevOps tools and processes.

Policy-Based Management and IaC Drive DevOps Security Innovation

Security has always been a priority for DevOps practitioners. But right now, I’m seeing DevOps teams adopt new strategies to improve the security of the applications and environments they support.

One large-scale change is the greater use of cloud-based policy management to enforce security best practices in cloud environments. Teams configure cloud services and resources using the code-based configuration frameworks that cloud providers support, then scan the configurations to detect risks.

This approach makes it possible to enforce cloud governance consistently, centrally and automatically. Instead of simply writing governance policies and hoping that engineers remember to follow them when they configure cloud resources, businesses are building automated governance guardrails via policy-based management.

In a similar vein, more and more of the DevOps teams I work with are embracing static code analysis of infrastructure-as-code (IaC) templates as a means of detecting risks. As with policy-based management of cloud resources, an IaC-centric approach to infrastructure provisioning makes it possible to automate infrastructure management and identify security risks earlier in the development lifecycle.

Some teams use cloud policy and IaC code scanning to warn one another about security policy changes that might cause an application or service to break. They do this by inserting configuration changes into their code using “audit” mode if their configuration framework supports it, or by configuring IaC scanners to flag changes if an audit feature is not available. This allows engineers to detect whether a change might cause a problem for an existing deployment.

This is important because security and application teams operate separately in many organizations. When the two groups lack an efficient way to communicate about changes, they can disrupt each other’s operations – the “right hand/left hand” problem. Configuration scanning provides a systematic way to ensure that each group is on the same page when it comes time to introduce changes – and the “audit” mode approach provides a grace period that allows time to react before a change takes effect.

Doubling Down on DevOps Automation with GitOps

Another overarching trend currently reshaping DevOps is using GitOps to make DevOps automation more efficient and consistent.

GitOps is the use of Git (or a similar source control system) to manage automated DevOps workflows. It involves defining configurations using code and applying them through features like GitHub actions.

When you opt for GitOps, you move DevOps automation controls from individual workstations to centralized source control repositories. The result is the ability to track and manage all automated workflows via a central hub. Doing so increases efficiency and mitigates issues like different engineers working with different versions of the same automation frameworks on their personal desktops.

In addition, GitOps automatically generates records of what changed and how it changed, because every action is logged through the source control system. This isn’t exactly documentation in the traditional sense and means that GitOps comprehensively documents every change – which is beneficial because human engineers tend not to be so thorough when documenting their actions.

To be sure, GitOps is not without its challenges. Implementing GitOps effectively requires additional skills – namely, expertise with both IaC frameworks and source control systems – that not all DevOps engineers possess. I also notice a tendency on the part of some teams to set up GitOps pipelines but rely on manual approvals instead of automated actions to trigger changes. That approach largely undercuts the value of automating pipelines in the first place.

However, these are challenges that teams can solve through education and by fully leaning into GitOps. In addition, techniques like automated testing of GitOps configuration code can help to build teams’ confidence in automations and reduce reliance on manual approvals.

Going forward, expect to see more adoption of GitOps techniques among teams seeking to level up their approach to DevOps automation. Automating individual DevOps processes (such as software testing and deployment) won’t be enough; truly efficient organizations will turn to GitOps to automate their entire DevOps workflows, from end to end.

Investing in Developer Experience

Making software delivery processes more predictable and efficient is merely a step toward DevOps’s ultimate goal, which is to help developers become productive and satisfied with their jobs.

To that end, I’m noticing interest and investment in developer experience right now. This is playing out through two interrelated initiatives.

One initiative is platform engineering. It involves creating DevOps teams that specialize in certain functions, such as network management or security. Those teams are designated to support those functions throughout the organization. This approach reduces cognitive overhead for developers by freeing them from the need to handle types of work outside their main focus. In other words, instead of forcing developers to be DevOps generalists, platform engineering lets different teams focus on doing what they know and enjoy best – leading to greater productivity and higher levels of job satisfaction.

The other major developer experience trend currently playing out is developer self-service. This means developers can obtain the technical solutions they need on demand without a complicated procurement process. In most cases, organizations enable self-service by implementing internal development platforms (sometimes called internal developer portals) (IDPs) which host ready-made infrastructure resources and software environments that developers can deploy on a self-service basis.

There are risks inherent in these trends. They require specialized types of skills. When poorly implemented, platform engineering and IDP solutions can create more problems than they solve. However, when you ensure that your teams have the requisite expertise, and deploy a carefully planned IDP that gives developers access to the resources they need, you’re likely to see a significant reduction in friction within your organization and a boost in developer productivity and happiness.

Real-World Changes, Beyond the Hype Cycle

Admittedly, discussing DevOps trends centered on security, automation and developer experience may not be as exciting as debating whether AI will take away DevOps engineers’ jobs. But if you want to know what’s truly changing in the world of DevOps – as opposed to which conversations are most hype-worthy – these are the places to look.

Security, automation and developer experience are also among the domains of DevOps where there is a great deal of opportunity to innovate – and, indeed, where adopting new tools and techniques will be critical for organizations that don’t want to be left behind as DevOps evolves.

May 17, 2024