> Most of the successful engineers and engineering leaders I have had the pleasure of working with were able to hold a discussion on almost any topic, whether technical or not
Haha yes I've seen that too, I think the distinction is that it is not "fluent on everything" but rather "curious about everything". The best developers I know will happily admit when they don't know something and look it up, no matter the topic.
I like the analogy. It feels right. But I don't think it actually is, because it leans hard on the _feeling_ of failure, vs. the actual failure.
The failure that actually matters here is product failure. Angry users. Security incidents. Downtime. Broken workflows.
Stressed and uncomfortable developers have, historically, been a leading indicator of product failure. Software is complex and when devs can't handle the breadth of ownership + the depth of expertise at the same time, it means bad work that leads to product failure. It's not clear that agents fail in the same way, or that our collective intuition about how and when to trust agents is sufficiently developed to predict product failure in the same way.
As anecdata: I know a bunch of growth-SaaS/last-batch-of-IPO companies where the devs are all stressed, the feature ship rate is up, and incidents are down. All at the same time.
So yes, quick learners and just-in-time depth is important, but so is intuition about where discomfort is going to produce true failure. The discomfort isn't a feeling to throw away, simply trusting that you'll learn everything in time. Ownership requires holding a model of the system in your head and proactively steering where you dive.
> Ownership requires holding a model of the system in your head and proactively steering where you dive.
Absolutely, and the feeling of discomfort is a signal that you need to dive, a signal that your mental models might need updating. I think that builds up over time through many dives
Mostly agreed with just in time learning. This is not just something that can be learned from the code though, this may require a huge amount of code context across multiple repositories and configuration files, as well as a knowledge of history, process, other tribal knowledge etc. So to me that's still the really difficult part of the job and AI definitely helps but doesn't entirely solve this. I see it often wants to solve some issue at not quite the level of depth or high level understand that you would want.
I think this is probably a good way to think about it. Breadth is going to be important if you want to reasonably navigate the new world. In an emergency even if you are using an agent you will be much quicker if you know what questions to ask the agent and how to guide it.
I would argue that recognizing if the agent is an adversary also requires breadth and a willingness to dive deep when you need to. Both things that the article highlights.
Before agents that is what every high performing person I've ever worked with was like. It was the kind of person I wanted to hire when I was in charge of that sort of thing. Enough breadth to know where to dive deep and enough willingness and curiosity to dive deep.
> You need a high-level, far-away map of the entire system, and you need to know just enough to know where you need to dive in
One thing that puts me squarely in the Optimist camp is that such a map can often be created by AI just-in-time. Sure you might not know every detail of what it said, but you can simply follow up and build your understanding.
yep, the just-in-time mapping and exploration are what builds up your breadth, but I think you still need a baseline to be able to tell when the map you've been given looks right but isn't
> Most of the successful engineers and engineering leaders I have had the pleasure of working with were able to hold a discussion on almost any topic, whether technical or not
Reverse Gell-man? https://en.wiktionary.org/wiki/Gell-Mann_amnesia_effect#Engl...
Haha yes I've seen that too, I think the distinction is that it is not "fluent on everything" but rather "curious about everything". The best developers I know will happily admit when they don't know something and look it up, no matter the topic.
I like the analogy. It feels right. But I don't think it actually is, because it leans hard on the _feeling_ of failure, vs. the actual failure.
The failure that actually matters here is product failure. Angry users. Security incidents. Downtime. Broken workflows.
Stressed and uncomfortable developers have, historically, been a leading indicator of product failure. Software is complex and when devs can't handle the breadth of ownership + the depth of expertise at the same time, it means bad work that leads to product failure. It's not clear that agents fail in the same way, or that our collective intuition about how and when to trust agents is sufficiently developed to predict product failure in the same way.
As anecdata: I know a bunch of growth-SaaS/last-batch-of-IPO companies where the devs are all stressed, the feature ship rate is up, and incidents are down. All at the same time.
So yes, quick learners and just-in-time depth is important, but so is intuition about where discomfort is going to produce true failure. The discomfort isn't a feeling to throw away, simply trusting that you'll learn everything in time. Ownership requires holding a model of the system in your head and proactively steering where you dive.
> Ownership requires holding a model of the system in your head and proactively steering where you dive.
Absolutely, and the feeling of discomfort is a signal that you need to dive, a signal that your mental models might need updating. I think that builds up over time through many dives
Mostly agreed with just in time learning. This is not just something that can be learned from the code though, this may require a huge amount of code context across multiple repositories and configuration files, as well as a knowledge of history, process, other tribal knowledge etc. So to me that's still the really difficult part of the job and AI definitely helps but doesn't entirely solve this. I see it often wants to solve some issue at not quite the level of depth or high level understand that you would want.
I think this is probably a good way to think about it. Breadth is going to be important if you want to reasonably navigate the new world. In an emergency even if you are using an agent you will be much quicker if you know what questions to ask the agent and how to guide it.
yes exactly, in most cases you will have an agent you can use to help you solve the problem anyway, but you need to know what to ask it to do
Guiding works as long as the agent is neutral or on your side but if it’s secretly an adversary ..
I would argue that recognizing if the agent is an adversary also requires breadth and a willingness to dive deep when you need to. Both things that the article highlights.
Before agents that is what every high performing person I've ever worked with was like. It was the kind of person I wanted to hire when I was in charge of that sort of thing. Enough breadth to know where to dive deep and enough willingness and curiosity to dive deep.
We’ve been trusting (or distrusting) our agents for all of recorded history. The choice between Claude or Codex matters. Trust matters.
this is true for humans too
> You need a high-level, far-away map of the entire system, and you need to know just enough to know where you need to dive in
One thing that puts me squarely in the Optimist camp is that such a map can often be created by AI just-in-time. Sure you might not know every detail of what it said, but you can simply follow up and build your understanding.
yep, the just-in-time mapping and exploration are what builds up your breadth, but I think you still need a baseline to be able to tell when the map you've been given looks right but isn't