A few months ago, I noticed something happening. I would spend all day working with LLMs—prompting them, reviewing their work, and correcting them—and when I wasn’t working on my own code, I was reviewing LLM-generated code. By the end of the day, I was exhausted. This was a very unusual thing for me: I’ve been a software developer at startups for 30 years, and while sometimes I might have gotten stressed out, I had never been exhausted by the actual act of writing code.

And I noticed that I wasn’t the only person. My peer staff engineers were also tired. The junior engineers on my team were stressed out and worried. LLMs were doing more of the work that they would have normally done themselves and they weren’t sure that they were learning the right things to continue to have a career. On top of that, they didn’t even have a real idea of what that might look like.

It felt like, overall, the team was shipping more, but understanding less. We were worried about the quality of the code that we were shipping, worried that the next time something broke in production, there wouldn’t be anybody able to understand it and fix it. We also had less and less of an idea of what was going on outside of our team as well; everything was moving faster and it was harder to keep up.

Read our O’Reilly book, Observability Engineering

Get your free copy and learn the foundations of observability,

right from the experts.

Download Now

What was happening, and what could we do about it? Well, LLMs have drastically changed how software engineering is done. I’m going to elaborate on my observations on what those changes are. As for what we can do about it, the title of this blog post gives it away. But it’s important to know why we should be spending more time talking to humans, who we should be talking to, and about what.

LLMs have changed the core work of software development

The root of what’s happening (and why we’re seeing so much more exhaustion and stress) is the fact that LLM-driven coding is changing core parts of the software engineering lifecycle and of the day-to-day work of a software engineer. To understand these changes, we need to go back to first principles and remember what it is our teams are trying to accomplish.

What is the core of software engineering?

For me, the core of software engineering involves the following four functions:

• Design: Decide what we’re building and how we should build it to meet the requirements and be resilient in production.
• Implementation: Actually build the thing.
• Validation: Make sure the thing we built actually meets the requirements and will work in production. Validate that the requirements still make sense. Validation is usually done by someone else in addition to yourself to get different context and skills and knowledge share.
• Operation: Run the system in production and provide feedback into the design and implementation of the next iteration.

Typically, this has been treated as a loop (note: this is also known as the Plan-Do-Check-Act cycle in other domains. I like DIVO because it’s a cooler acronym). Design up front, implement by writing code, validate through code review and testing, and then operate in production and deal with the fallout. We’ll call this the DIVO loop going forward.

A pre-LLM workflow

How did this high-level core manifest itself? A typical medium-sized project might involve this work:

• One or two days of design, either solo or collaborating with your team.
• A week doing implementation, usually solo.
• A couple of hours of validation and code review, involving someone else on the team.
• A couple of hours of watching it in production to make sure that it’s working.

For the most part, it meant that there was a rhythm to the day. For example:

• Spend a few minutes, maybe an hour, reviewing PRs.
• Spend most of the day writing code.
• On the odd day when projects are being kicked off, focus on designing things with your team.
• When you ship something, observe it in production to make sure that it has the desired outcomes.

What has changed?

LLM-based development is different in a few specific ways that have cascading impacts:

• Implementation is often much faster than it used to be, especially for refactors and writing tests. You can generate output multiple times faster than before.
• The code and mistakes that LLMs make are often different from the code that humans make. This often makes validating the quality of code written by LLMs harder.
• Working with an LLM generally involves natural language skills that are more like interacting with another human (i.e., it feels more like Slack than crafting algorithms and logic). You’re describing a design, letting it try to implement it, and then looking at and validating the results. Basically, it’s a miniature design, implementation, and validation loop, except that often the implementation is in minutes.

Instead of a single long DIVO loop covering multiple days, you’re doing dozens of small DIV loops inside a bigger DIVO loop.

Overall, less time is being spent on implementation, and more time is spent doing design and validation.

What hasn’t changed?

It’s also important to know what aspects of software development LLM-based development don’t change:

• You still need to coordinate with teams, especially towards the end of the development cycle when you’re going to ship your changes to prod:
  • Notifying dependencies that you’re changing how something works
  • Working with your product/sales/marketing teams to actually launch the project publicly.
• You still need to do final validation of what you’re shipping.
• You still need to be responsible for your changes operating in production.

Another important result of adopting LLM-based development broadly is that you can expect that everybody else is shipping faster, not just your own team. This means that the amount of cross-team collaborative communication needs to increase.

What is the impact on individual engineers?

Let’s look at the impact of these changes on senior and junior developers (I’m not referring to traditional senior or junior engineer levels. I’m referring to senior and junior on the relative experience and responsibility scale).

As a more senior engineer:

• You’re spending an increasing amount of time doing design and validation, both on the specific projects you and your team are working on, and on work other teams are working on, because they’re all moving faster.
• Looking at all of these different things in flight requires a lot more context switching, and loading of context for work that you didn’t do yourself. The context-related overhead is starting to overwhelm the actual amount of time working on your own projects.
• This doesn’t apply just to the development side of things. There are more operational impacts on the systems you own based not just on what your team is shipping, but on what the teams around you are shipping. The operational landscape around you is changing more rapidly than it has before.
• Basically, all of the low-skill, easy parts of software development are being handled by the LLMs and you’re now spending an ever-increasing amount of your time on high-skill, high-effort design, validation, and communication.
• You’re in a spiral of ever-increasing, ever more exhausting work.

As a more junior engineer:

• In the past, improving implementation skills was the primary thing that you needed to do to progress in your career. Your ability to implement quickly drove your seniority.
• With LLMs doing most of the implementation and low-level validation, those lower level skills aren’t as valuable. High-level design, validation, and communication skills are. But you can’t learn those skills from LLMs. By definition, your job is to do the things that the LLMs are incapable of doing, so it can feel like you’re caught between what the LLMs can do and what the more senior engineers can do. There are only two ways to gain those skills:
  • Gaining experience by making mistakes and seeing the results.
  • Learning from people who already have those skills and experience.

Recapping:

Senior engineers are exhausted by spending more of their time doing high-skill, high-effort work, which involves lots of context-switching and loading new context. They feel like they are the bottleneck for the output of their team/company.

Junior engineers are stressed because they feel like they are being replaced. They want and need to improve their design, validation, and communication skills, and the best way to get these skills is by working with more senior engineers. But the senior engineers are busy because they are the bottleneck for the team.

In addition, everyone is feeling stress simply due to the overall uncertainty that AI as a new technology introduces.

How do we solve these problems?

• Reduce the amount of context-switching and context transfer costs so that everybody can work more efficiently.
• Work to increase the number of engineers capable of doing the higher-level work by leveling up your junior engineers.
• Create more social cohesion between people on your team to help manage stress and change. We are in a period of true instability right now. Change won’t be slowing down any time soon.
• Spend more time talking to humans.

Reduce parallelism and context churn

Explicitly fight against parallelizing and fragmenting work at an individual and team level. Fight the instinct to try and use AI as “efficiently” as possible by doing more and more work in parallel. You’re not necessarily getting more work done that way, you’re just generating more context churn for everyone on your team.

If you do parallelize to try to move faster, structure the work in ways that allow you to reduce the amount of context that you need while you’re working on them. If you’re going to do side quests, make them related to your main quest, or have them be related to each other.

Pair (but don’t pair program)

Reduce parallelism and the need for context switching and transfer between team members by having pairs of developers work together. In particular, consider having pairs of senior and junior developers work together in a master/apprentice setup. This doesn’t have to be a long term thing—it can be just for an individual small deliverable—but you want to avoid changing out who’s working on something if you can avoid it.

I’m not advocating what you might stereotypically think of as pair programming. LLM-based development means pairing is very different, and arguably much more beneficial than it used to be.

In traditional software development, pair programming often meant that you were doing implementation (writing code) together. This was strictly a consequence of the fact that most time spent in software development was doing implementation.

While beneficial, it wasn’t necessarily as meaningful as it could have been. Oftentimes, implementation didn’t lend itself as well to transferring critical skills that characterized being a senior engineer.

LLM-based development is much more focused on rapid design and validation cycles as opposed to implementation. This means that there are more opportunities for the junior engineer to learn valuable senior-level skills of design and validation, as well as to transfer critical context on what’s being worked on between participants.

In these rapid design, implementation, and validation loops, pairing compresses what might have been weeks worth of learning about how to design and validate systems in a pre-LLM world into hours. You can level up your junior engineers much faster than you used to be able to, as long as you create the right environment for learning.

Focus on:

• Sharing context. Senior engineers often have more context on the relationship between the project and the business. Junior engineers often know more about the specific details and roadblocks driving what they’re working on. Sharing this context allows everybody to gain more understanding about what’s going on in the businesses and systems that are relevant to them.
• Creating a safe space for articulating thought processes. Don’t clean up what you’re thinking like you would for a design document. Exposing the internals of your thought process is actually critical here. Be comfortable making mistakes and telling stories of mistakes that have been made in the past. The principles of cognitive apprenticeship may prove to be useful here: focus on having your senior engineers model and demonstrate behaviors in real-world situations, and have your junior engineers drive the development lifecycle.
• Not worrying about being “productive.” Take time for side quests and non-work conversations. You’re not trying to maximize short-term output! Learning and creating relationships is just as important as shipping code.
• Talking to one another. If one person is just watching and not contributing, switch to a different work stream, spend more time discussing the task at hand, or stop the session and pick it up another day.

Communicate with other teams

Remember that your team is part of a broader organization and everybody moving faster means that there needs to be more overall coordination and communication. It’s important to spend more time keeping track of the broader context of what’s happening around you.

Use the same principles of spending more time talking with each other with other teams. Spend more time talking about what projects you’re working on with each other. Think about embedding engineers from your team in other teams you’re working with.

Conclusion

As AI coding continues to accelerate the pace of software development implementation, it has become increasingly important to understand its impact on the people and the human systems that surround software development.

Those impacts can be good rather than bad, but only if you proactively change how you work in a way to adapt to those changes and focus on what the people on your teams need.