After two decades in software development, I pieced together a few personal conversations I have had with former peers who are now senior leaders about adopting A I in the software development life cycle. Here is a common theme that has emerged in late twenty twenty-five.
Clay called me on a Tuesday night, which meant something was wrong. We had worked together for six years before he left to take a director role at a company you would recognize. He does not do social calls. When Clay picks up the phone, there is a problem he cannot solve and he is out of people to ask.
I need to talk through something, he said. And I need you to tell me if I am crazy.
He had been running an A I coding agent rollout for three months. Executive mandate, full organizational buy-in, generous training budget, the works. And his team was splitting in half in ways he could not explain.
I have got engineers who picked this up in a week, he said. They are shipping features at twice their previous velocity. It is everything the vendors promised. But I have got other engineers, people with fifteen years of experience, people I would trust with anything, who cannot get anything useful out of the same tools. Same training. Same documentation. Same access. Completely different outcomes.
I asked the obvious question first. Was it age?
That is the thing, Clay said. I thought it would be generational. It is not. It is not even close.
He told me about Maya, a fresh graduate who had been on the team for eight months. She was cooking. Shipping faster than engineers with a decade of experience. She had taken to the agents like she had been using them her whole career.
And then there was Carl. Thirty years at the company. Hired when they were still writing cobol. Carl was one of Clay's best agent users.
Carl, I said. Thirty year Carl.
Thirty year Carl. The guy comments his code like he is writing a letter to his future self. He has been explaining systems to new hires since before I was born. He picked up the agent in a week.
So who was struggling?
That is what is killing me. It is not the people I expected. I have got mid-career engineers, ten years in, who cannot get anything useful out of these tools. I have got senior staff who have been here fifteen years. They are not dumb. They are not resistant. They just cannot make it work.
I asked Clay what he saw when the struggling engineers tried to use the agent.
They prompt it the way they would think about the problem themselves. Shorthand. Assumptions. References to things that are not written down anywhere. Then they get frustrated when the output does not match what they had in their head.
I asked what Maya and Carl did differently.
Clay paused. They explain things. Like, actually explain them. Maya writes prompts like she is onboarding a new hire. Carl writes prompts like he is documenting a system for the next thirty years.
There it was.
Here is what I told Clay. The engineers who are struggling do not have a tools problem. They do not have a prompting problem. They do not have a generational problem.
They have an externalization problem. They have never learned to explain context, or they learned it once and stopped practicing. And now explaining context is the whole game.
The correlation is not age. It is not seniority. It is not intelligence or technical skill. The correlation is whether someone can take the knowledge in their head and put it into words that a collaborator with zero institutional context can actually use.
Maya can do that because she just came from an environment where she had to. School is nothing but explaining your thinking to people who are evaluating it. Carl can do that because he has been onboarding new hires and writing documentation for three decades. Explaining context is a muscle Carl never stopped exercising.
The mid-career engineers who are struggling? Somewhere along the way they stopped. They got good enough at their jobs that they did not need to explain themselves anymore. They navigated complex systems through intuition built over years of pattern matching. They absorbed context through osmosis, sitting near the right people, overhearing the right conversations, building mental models through thousands of small interactions.
That intuition lives in neurons, not words. They have never had to externalize it because they have never needed to. The knowledge just was there when they needed it.
When they direct an agent, they get code that technically does what they asked but misses everything they assumed was obvious. The agent did not know that this particular service returns two hundred okay even on failures. This is exactly why your codebase needs to be agent-maintainable. The agent did not know the team tried that approach two years ago and it caused an incident. The agent did not know the naming convention in this module is different because it was acquired from another company.
The engineer knows all of this. They just cannot say it.
Clay called again two weeks later.
I have been watching more closely, he said. You were right. It is the explaining thing. It is always the explaining thing.
He had started paying attention to how his engineers communicated in contexts that had nothing to do with A I. Pull request reviews. Architecture discussions. Onboarding conversations with new team members.
The engineers who are good with agents? They are the same ones who write pull request descriptions that actually help reviewers understand what they are looking at. They are the ones who can walk a new hire through a system without assuming knowledge the new hire does not have.
And the ones who struggle?
Their pull request descriptions say fixed the bug. Their architecture explanations skip three steps because the steps are obvious to them. They are not bad engineers. They are just bad at externalizing what they know.
I gave Clay a mental model that helped me. Think about what an A I coding agent actually is from an operational standpoint. Strip away the marketing language. What you have is a collaborator who is technically capable, has solid fundamentals, learns quickly, and is starting from absolute zero on your specific codebase, your architectural decisions, your organizational context.
This is functionally identical to a computer science intern who just finished their third year. Book-smart. Capable of producing working code. Completely dependent on you to provide the context they are missing.
Maya treats the agent like an intern, Clay said. Carl treats it like a junior engineer he is mentoring. The struggling folks treat it like, I do not know. Like it should already know what they know.
That is exactly it. Maya and Carl are good at explaining context to humans, so they are good at explaining context to agents. The struggling engineers never built that muscle, or let it atrophy, so they are stuck.
The third call came a month later. Clay sounded different. Quieter. Like he had seen something he was not sure he should say out loud.
I need to tell you something, he said. And I do not know what to do with it.
He had been doing one on ones with the engineers who were struggling most. Trying to understand where the gaps were. Trying to figure out what kind of training would actually help.
Some of them cannot externalize context because they never learned how. That is the first problem, the one we talked about. But some of them. He trailed off.
Some of them what?
Some of them cannot externalize context because they do not actually have it. They do not understand the systems they have been working on. Not really. Not at a level where they could explain it to someone else.
I let that sit for a moment.
I have got an engineer, Clay continued. Fifteen years of experience. Respected. Senior title. And when I asked him to walk me through how one of our core services actually works. Not to explain it to an agent, just to explain it to me. He could not do it. He has been working on that service for three years.
How is that possible?
Because for fifteen years, he has been stitching things together. Copy this pattern from over here. Modify that snippet from Stack Overflow. Follow the template from the last project. The code works. It ships. Nobody asks questions because everything moves slowly enough that you cannot tell the difference between someone who understands the system and someone who has learned to navigate it without understanding it.
Clay had stumbled onto something that nobody talks about because it is too uncomfortable. Traditional software development moved slowly enough to hide a lot of sins. When you are shipping quarterly, when code reviews are cursory, when the same patterns get copy-pasted across projects for years, you can build an entire career on pattern matching without ever developing a deep mental model of what you are building.
These engineers are not stupid. They are survivors. They figured out that you did not need to understand the system to work on the system. You just needed to know which incantations to copy, which templates to follow, which senior engineer to ask when you got stuck. The system rewarded shipping code, not understanding code.
Now they are sitting in front of an agent, and the agent is asking them to explain what they want to build. And they are realizing, some of them for the first time, that they cannot explain it because they do not actually know.
The agent is an X-ray machine, Clay said. It is showing me things about my team that I could not see before. I am not sure I wanted to see them.
This is the part of the conversation that gets uncomfortable. Because we are not just talking about a training gap anymore. We are talking about engineers who may have spent years, decades, building careers on a foundation that was never as solid as it looked.
But here is what I told Clay. Even this is fixable. It is just a different kind of fix.
The externalization problem has two variants. The first is engineers who have the knowledge but cannot articulate it. The second is engineers who never built the knowledge in the first place because the old system never required it.
For the first group, you are teaching communication skills. For the second group, you are teaching the fundamentals they skipped. Both are learnable. Both respond to practice. Neither is a character flaw.
The engineers who have been stitching without understanding? They are not lazy. They are rational actors who optimized for the system they were in. The system rewarded shipping. It did not reward understanding. They did exactly what they were incentivized to do.
The system has changed. The incentives have changed. Now they need to adapt. And the good news is that understanding systems, actually understanding them, at a level where you can explain them to someone starting from zero, is a skill that can be developed at any point in a career.
It just takes longer than a prompt engineering workshop.
Clay called one more time, a few weeks later.
I figured out what Carl and Maya have in common, he said. It is not that they are both good at explaining things. It is that they both actually understand what they are building. Maya because she just learned it in school and it is fresh. Carl because he has been building mental models for thirty years and never stopped.
He had started thinking about his remediation program differently. It was not just about teaching people to externalize. It was about giving some of them permission, and support, to go back and learn the things they had skipped.
I have got a senior engineer who asked if he could spend two weeks just reading the codebase. Not writing code. Just reading. Understanding. Building a mental model he never had.
What did you tell him?
I told him yes. And I told him it was brave to ask.
So what do you actually do about this? The answer still sounds embarrassingly old-fashioned. Book clubs. Pair programming. Coding katas. Architecture reviews.
But now we understand why these practices work. They are not just building the externalization muscle. They are building, or rebuilding, the understanding that externalization requires.
Book clubs force engineers to articulate technical concepts to peers. But they also force engineers to actually learn the concepts well enough to articulate them. You cannot hide behind pattern matching when you are explaining chapter four of Designing Data Intensive Applications to colleagues who will ask follow-up questions.
Pair programming makes thinking visible. It also makes not thinking visible. When you are narrating your approach to a partner, you cannot just copy a pattern and hope it works. You have to know why.
Coding katas with an emphasis on explaining your approach before writing code create low-stakes practice. You fail in a safe environment. You learn that the gap between doing something and understanding something is wider than you thought.
Architecture reviews where junior engineers present and senior engineers ask questions flip the usual dynamic. They also expose who actually understands the systems and who has been navigating by landmarks. Not to punish anyone, but to know where the investment needs to go.
These are not soft skills, I told Clay. These are the hard skills now.
Clay pushed back. Some of these engineers have been faking it for a long time. What am I supposed to do. Fire them?
I told him that was the wrong frame. These engineers have been doing exactly what the system asked them to do for years. They shipped code. They met deadlines. They got promoted. The fact that they did it without deep understanding is a failure of the system, not a failure of the individual.
The question is not whether to punish them. The question is whether to invest in them.
And the answer should almost always be yes, because the skills they need to develop are the same skills everyone needs now. The engineers who cannot externalize need to learn to externalize. The engineers who do not understand need to learn to understand. Both of these respond to practice. Both of these are valuable regardless of what happens with A I tools.
Give the agents to everyone. Not because struggling engineers will magically improve through exposure, but because the struggling reveals exactly where the development work needs to happen.
Meet people where they are. Some of them have gaps they have been hiding for years. That is not a moral failing. That is a debt that has come due.
And move with urgency. Your competitors are figuring this out too.
Clay texted me last week. He had started the book club, the pair programming rotation, the architecture reviews. But he had added something else. Dedicated time for engineers to just learn their own systems. No tickets. No deadlines. Just reading code, building mental models, developing the understanding they had never been required to have.
It feels weird, he said. Like I am admitting that people did not know what they were doing.
I told him he was admitting something different. That the old system never checked. And now he was building a system that does.
He sent a follow-up an hour later.
Carl volunteered to lead the pair programming sessions. Said it reminds him of how he learned thirty years ago. Maya asked if she could help with the architecture reviews. Said she wants to learn what senior engineers look for.
The engineer who asked for two weeks to read the codebase? He has become one of Clay's best agent users. Turns out once he actually understood the system, explaining it to an agent was the easy part.
The knowledge was always available. The understanding was always possible. We are just finally building systems that require both.