If you’re like everyone else who works in software development, it’s a good bet that almost every single thing that you thought you knew about your business and engineering has changed as a result of the advent of modern LLMs. How should you respond to these changes? How should you change how you and your team develop software?

The following is what I’ve come to as a set of theory and practice for adapting to what is, and continues to be, one of the most rapid changes to how work is done in arguably any career. It’s worth noting that none of this is predicated on whether you are an AI believer or a skeptic. Even if you believe that 90% of what people are claiming about AI is just hype, the remaining 10% still has the ability to radically change what it means to be a software developer.

Also, before I dive into this, a caveat: yes, a lot of this is vastly oversimplified. What I’m proposing here is mostly a framework for how to think about things. You should apply your own judgement to your situation.

Theory

Think about business and product context first

Before you start thinking about what changes you may or may not want to make to how you (and your team) write software, the first thing you should do is understand the impact of these changes on your team’s objectives and priorities. While the practice of software development is changing as a result of AI, it’s important to think about the business and product impact first. After all, the goals of your team may be changing due to AI.

The only certainty about AI is that it has increased uncertainty for nearly everything. Every single aspect of your company’s business model, or the product that you are developing may need to be rethought.

I’d like to talk about the bit of context that tends to have the most impact on how we choose what software development practices we use: the tradeoff between speed of development and risk.

Almost every decision we make about whether to adopt a particular software engineering methodology (test-driven development, unit testing, continuous deployment, feature flags, etc.) is driven by the tradeoff between speed and risk. To be put more clearly: will adopting this practice allow your team to reduce risk without resulting in an unacceptable decrease in the speed in which you ship?

As your team grapples with uncertainty in the business, the answers to those tradeoffs that you made in the past likely should be re-evaluated. Let’s take two hypothetical teams at Honeycomb as examples.

The first team is a greenfield frontend product engineering team. Looking at their business, AI has drastically changed the nature of what kind of product they can build. For them, it’s far more important to move quickly and iterate on the design so that they integrate LLM-based technologies into their product. They are willing to accept increased levels of risk in order to ship more rapidly.

The second is a core querying technology team. Product engineering teams rely on its platform. As the product engineering teams increase the rate at which they ship software and increase risk, it may actually behoove the core querying to become more resilient and able to absorb the impact of rapidly changing, unpredictable usage patterns. Thus, this team might want to maintain or even decrease the amount of acceptable risk in their software development processes in service of making their platform more stable.

Expressed in a chart, you might see their speed to risk tradeoff expressed as a curve of speed against risk. Each team might be comfortable with any practice that keeps them below the speed/risk tradeoff curve.

LLM development practices have different speed/risk tradeoffs

One of the things that has made LLMs so transformative in software development is that LLMs have made it possible to implement radically different software development practices, some of which allow you to increase the speed of development. Because these practices are so new, though, the long-term speed and risk implications of adopting these practices are still not well understood—and changing from moment to moment.

Let’s compare a few different types of development practices.

First, “traditional” development practices: human-written code and human code review. At this point, it is still generally true that the lowest risk code is written (albeit slowly) by humans, and also reviewed by humans. However, as you attempt to speed things up, you’ll need to decrease the quality of code review and/or testing in order to move faster. At some point, you’ll hit the speed limit for how quickly a human can type out code.

Next, “supervised agentic” development practices: where LLMs are writing the code, but humans are guiding it and reviewing the code being written. It may not be as low risk as human-written code (you gain a lot of context while writing the code yourself) but the speed of code generation is faster, and you are more bottlenecked by the speed at which humans can review the code.

Lastly, a “fully agentic” practice: the humans are driving the specifications for the code, but the LLMs are doing everything else—writing the code and reviewing it. Again, we continue to have a higher level of risk, but at the potential trade for vastly higher speed, since humans are no longer a bottleneck.

Choose the tradeoff for your team

The most important thing to know is that different teams, or even different codebases within the same team, may end up with vastly different development practices. The greenfield product development team, which is more willing to take higher risks for speed, may end up being okay with the higher risk associated with a fully agentic development practice.

Whereas the core query technology team with a low risk tolerance may decide that they should adopt “supervised agentic” development that still relies on human-reviewed code to meet the risk requirements that are appropriate for their team.

None of this is static

It’s critical to remember that both the business environment and agentic technology are evolving rapidly. Six months is a long time in the current technology environment, so make sure that you periodically re-evaluate both the business and development practices built into the way that you work.

Practice

Most of the practices you can adopt in your development workflows aren’t novel. There are plenty of software engineering best practices that have been around for decades that are helpful when doing software development with agents. Most of these practices evolved to help large engineering teams manage more people working on ever-larger codebases, and agentic coding has similar issues.

Many of these practices were difficult to implement in the past, often because the amount of effort required to implement them would slow you down too much. But agentic coding has scrambled many of these tradeoffs—writing large volumes of code has become much easier. It’s worth re-evaluating many of these practices, especially if they were deemed “too slow” or “hard to maintain” in the past.

Manage your risk tolerance

The primary way in which you can shape what development practices you can put into place is to manage your risk tolerance. That risk tolerance is a result of various different things:

• The architecture of your code and systems
• How your system is deployed
• How you observe your code
• The processes you use for all of the above
• The people on your team

Ask yourself what parts of these can you—or should you—be changing?

Code and architecture

Separation of concerns

Your team is responsible for managing a body of code and systems. Some of it has low risk tolerance, and some of it has high risk tolerance. One of the things that you can do to improve your team’s overall level of risk tolerance and its ability to adopt speedier agentic development practices is to separate systems with different levels of risk tolerance and create well-defined boundaries between them.

As an example of this, let’s take a look at an administrative tool for a web application.

Some parts of it are extremely high risk: an error in the account deletion code could be catastrophic, or an escalation of privileges could result in someone having access to data that they shouldn’t have.

Some parts of it are extremely low risk: it’s not really a big deal if the layout of the page isn’t perfect for a couple of days.

If this is implemented as a single, undifferentiated codebase, any change to the admin system needs to be reviewed by a human to make sure that there are no issues, even if it’s just moving some buttons around in the UI.

Instead, create an exhaustive, well-tested boundary around the high-risk areas of the codebase, and separate it from the low-risk code. For example, make the account deletion API its own, separate, independently tested and maintained library, and have the API take a confirmation argument like the account name to make it harder to be accidentally invoked by a human (or badly written frontend code).

Documentation and comments

In the past, one of the arguments against detailed documentation and comments in the codebase was that it was easy for them to get out of date. But with agents writing code, it’s much easier to validate that any changes in the code result in updated comments and documentation. This will allow for quick access to context for both human code reviewers and agents.

Observability and auditability

Another way to reduce risk is to make it easier to see what’s going on inside the system in order to catch issues before they impact customers—or at the very least, to resolve them more quickly.

Instrumentation requires maintenance, so use this opportunity to have agents improve the quality of your instrumentation as well as update tooling that relies on them for observability.

If you’re not going to be inspecting the code as part of the check-in process, you need some other mechanism for evaluating code quality. Think about doing periodic audits to evaluate the quality of the code being generated by your processes, allowing you to recalibrate your agentic coding workflows to produce better output, or to discover places where you can refactor to reduce risk.

Testing

Testing (primarily automated) is a time-honored way of reducing risk. Agentic coding can make it possible to maintain more exhaustive and comprehensive test suites with less effort. Remember that improved testing can make it easier and safer to refactor code, which supports improving your code architecture.

Deployment

Better deployment practices can help mitigate the risk of deploys.

Can you move to a more continuous deployment methodology where there are fewer individual changes being deployed at once? Can you use feature flags to allow you to quickly enable/disable features? Can you leverage red-green deploys to allow you to automatically roll out and roll back features based on instrumentation and observability into how your change manifests in production?

People

I’m breaking this out from the Practice section because even though this is technically practice, an oft-ignored aspect of change is the tendency for us not to pay attention to the human aspects of change. In the midst of all of the focus on agentic coding, it’s important to remember that ultimately, it’s the humans on the team that will determine if your team is successful.

No matter how much code you’re shipping using agentic coding, the value of that code is still entirely dependent on whether the humans gave agents the right instructions for what to build and how to build it. How do you make sure that the humans on your team are happy and making the right decisions?

Acknowledge the stress of change

Software engineering as a practice and career are changing more rapidly now than at any time ever before. Every single software engineer is having to relearn what it means to do software engineering not to a different way of doing it, but to something where even the most experienced developers have only been using LLM-based coding for a year or two, and where the “best practices” are often only months old… and where they might change out from underneath you next week. The most important thing to do is to acknowledge that this is happening, and prioritize helping your team learn new ways of doing engineering.

Adapt workflows to the people on your team

Some tend to work best in uninterrupted, high-flow sessions. Others are great at connecting with the team’s customers and routing information between team members. Make sure that you adopt workflows that work with your team’s needs.

• For example, some agentic development workflows are highly interruptive and stressful. Just because they allow you to ship “faster” doesn’t mean that they’re good for the health of the people on your team. Try and understand what is sustainable for your people. Optimize your workflow for human comfort.
• Similarly, there is often a lot of low-cost, low-value work that doesn’t get done because it’s not worth the distraction to the members of your team. How about maintaining a backlog of these tasks to throw at your agent?

Invest in quality of life

Make the day-to-day experience of being a software developer better.

• Use LLMs to build tooling that gets rid of your on-call toil. Had to do something more than once? Point an agent at it and write a tool (or skill).
• Use agents to help maintain well-written, up-to-date documentation and code comments.

Other teams should likely have different practices than yours

Other teams at the company have likely adapted what workflows are appropriate for them, but they still need to interact with and work with your team (and vice versa). Document your workflow so that it’s easier for other teams to work with you. Share your learnings.

Don’t overoptimize

Constant change and pressure will stress your team out, and often, trying to stay on the bleeding edge doesn’t provide any real benefit. Manage the rate of change of your tooling and processes.

Invest in the team

Agentic coding can save you a lot of time. Use it to level up your team. Since purpose and context is going to be more important in the agentic coding era, it is even more critical that the people on your team are able to participate more fully in the tactical and strategic decision-making that separates senior engineers from junior engineers.

Spend more time doing knowledge-sharing between team members:

• About agentic development, as it progresses.
• About the codebase you’re working in.
• About general software development practices and skills.
• About the product and business that you’re working in.

Give people more time to experiment:

• Let them experiment with different agentic coding methodologies and see what works for them.
• Experiment with learning new skills. Have them implement a feature end-to-end, to see how all different aspects of software development and the code work together, and to have them fully own the software lifecycle.
• Let them just do something fun and interesting without the stress of it having to be useful or productive!

Conclusion

I’m not sure that there’s a meaningful conclusion here that will stand the test of time, but I always like to keep this in mind:

There’s no such thing as hard and fast rules that apply in all situations, and you and your team are the people that are the best positioned to understand your situation. The thing that brings me the best peace of mind is to have a team that you trust, and that are willing and given the space to figure out what is for the best.