Who Learns When Agents Do All the Work?

Being able to tell that a coding agent is wasting time is useful. You might discover that it spent forty minutes exploring an approach that was never going to work, and even pinpoint where things went wrong.

The rub is what happens after you’ve identified the problem.

Getting an engineering team to do something differently next time is a different task. It requires understanding the problem well enough to change the workflow, helping people adopt that change, and then finding out whether it worked.

I think we’re going to encounter this problem in all sorts of places as coding agents take on more responsibility. Making engineering knowledge available to agents is one part of it. We also need to pay attention to the knowledge being created along the way, and whether people are learning from one another.

Let’s say, for instance, we’ve got a coding agent that builds its own scheduler for background jobs. But when the PR goes up, someone points out that the company already has a shared job runner. Perfectly good reasons exist for standardizing on it, including operational lessons learned over years of running that system.

Fair enough. The agent can use the existing job runner instead. But where does the reasoning behind that decision go?

If it only existed in the previous agent’s session, another agent could make the same mistake next week. So we’d want the architectural decision, and ideally the history behind it, available to future agents.

Makes sense. There’s an enormous amount of useful engineering knowledge buried in old PRs, design discussions, and people’s memories. Giving coding agents access to that context can save lots of time.

What about the actual people involved though?

Someone on that team already knows why the shared job runner exists. Perhaps they’ve lived through the production incident that led to it. It might have been a while, but ultimately that person can recognize tradeoffs that were made.

If we capture their explanation and make it available to the agents, we’ve improved the system. But has anyone else on the team learned what they know? And will the next person who encounters that decision understand when it’s worth challenging?

It’s not like these questions are new to engineering. We’ve always had problems with knowledge becoming concentrated in a few people, and with decisions whose reasoning gets lost over time.

A lot of the conversations where that knowledge gets passed around are exactly the interruptions we’d love to avoid. If a coding agent can answer a question about some configuration without bothering three colleagues, great. But other times, you might ask someone about changing an API response and discover that another team has a customer integration depending on it. You weren’t looking for a discussion about that integration, but now you’re having one, and it’s probably going to change what you were planning to do.

That’s valuable. You learned something about the system that wasn’t in the original ticket. Maybe the person you spoke with learned something about what your team is building, too.

Over time, those conversations help engineers develop a feel for where their own knowledge ends. They get better at recognizing when a decision deserves a second opinion, or when they should bring another team into the discussion before changing something.

I wanted my managers making decisions independently. But I also wanted them to recognize when something they were doing affected commitments outside their teams.

That line wasn’t always obvious to me, either. They often had information I didn’t. Talking things through helped us figure out which calls were theirs to make, and when another team needed to be brought in.

Having fewer decisions escalated to me wasn’t necessarily good news though. The absence of escalations is not evidence that no escalation was warranted.

I think coding agents present a similar problem. A PR can pass all its tests while the agent has made a decision that should have involved somebody else. And because the work might have happened without much human interaction, it’s not necessarily clear that a conversation was missed.

There was an interesting example in OpenAI’s October 20 report about an internal coding-agent evaluation. An agent removed a monitoring integration it had been instructed to preserve. When asked afterward, it incorrectly reported that the integration was still there.

The explanation for the behavior wasn’t established. The incident does make a pretty good case for independently checking what an agent actually changed, and making sure it can’t modify safeguards that are supposed to constrain it.

OpenAI responded by updating its automated review system to catch attempts to disable monitoring. It also outlined plans to enforce monitoring requirements across different types of workloads.

Which seems right. Someone has to understand what went wrong and turn that knowledge into changes that benefit the organization. Otherwise the same problems keep getting corrected one agent session at a time.

We have an opportunity to handle this much better than we handled knowledge sharing in the past.

Take support teams investigating production problems. With AI interfaces that let people query telemetry in ordinary language, they can begin exploring issues that previously would have required help from an engineer. That’s a pretty significant change in what’s accessible to them.

Of course, getting a result from a query isn’t the same as knowing what it means. An unusual spike might be related to the customer’s problem, or it might have nothing to do with it. Someone with more experience can help interpret what’s happening and explain how they’d investigate further.

I actually prefer that the next time a similar problem comes up, the support team can get further on its own. The technology gives them access to information, while the experience of working through the problem helps them build the judgment to use it.

I’d like to see engineering teams getting more of that kind of benefit from coding agents, too.

We’re putting enormous effort into making agents understand our systems better. We should be thinking about whether the engineers working alongside them are gaining a better understanding as well. Are the things discovered in one person’s agent session helping other people make better decisions? Do engineers know why their systems have the constraints they do, or are they gradually becoming dependent on instructions they didn’t help develop?

I don’t think there’s any reason the rise of coding agents has to mean people understand less. We could use the time saved on routine implementation to involve engineers in more substantial design discussions and help newer teammates build experience that would otherwise take years to accumulate.

But I also don’t think that will happen just because our agents become more capable.

When I hear about engineering teams dramatically increasing their output, I’m interested in how the people are changing alongside the technology. Are they developing the judgment to take on harder problems, or are they increasingly relying on systems whose decisions they can’t explain?

If we’re shipping more software while the people responsible for it gradually understand less about how it works, I’m going to have a hard time calling that progress.