4 ms·

I believe AI isn't replacing developers, instead, it's turning every software engineer into a hybrid between EM + IC, basically turning them into super-managers

I believe AI isn't replacing developers, instead, it's turning every software engineer into a hybrid between EM + IC, basically turning them into super-managers. What we need is better tools for this upcoming new phase. Not a new IDE; we need to shift the whole paradigm. Here's one example: If we give the same task to 3 different agents, we have tools to review a diff of each OLD vs NEW separately, but we need tools to review diffs of OLD vs NEW#1 vs NEW#2 vs NEW#3. Make it easy to mix-and-match what is best from each of them. From what I've seen, the idea that AI is turning developers into super-managers is why some people struggle to adapt and quickly dismiss the experience. Those who love to type their code and hate managing others tend to be more hesitant to adapt to this new reality. Meanwhile, people who love to manage, communicate, and work as a team are leveraging these tools more swiftly. They already know how to review imperfect work and give feedback, which is exactly what thriving with AI looks like.

voidhorse 1y ago
> They already know how to review imperfect work and give feedback, which is exactly what thriving with AI looks like. Do they, though? I think this is an overly rosy picture of the situation. Most of the code I've seen AI heavy users ship is garbage. You're trying to juggle so many things at once and are so cognitively distanced from what you are doing that you subconsciously lower the bar.
- favoboa 1y ago
  You're absolutely right about the garbage code being shipped, and I would bucket them under another group of adopters I didn't mention earlier. There are people hesitant to adapt, people thriving with AI, and (not exhaustively) also this large group that's excited and using AI heavily without actually thriving. They're enjoying the speed and novelty but shipping slop because they lack the review discipline. However, my sense is that someone with proper management/review/leadership skills is far less likely to let that code ship, whether it came from an AI, a junior dev, or anyone else. They seem to have more sensibility for what 'good' looks like and can critically evaluate work before it goes out. The cognitive distance you mention is real, which is exactly why I think that review muscle becomes more critical, not less. From what I've observed, the people actually thriving with AI are maintaining their quality bar while leveraging the speed; they tend to be picky or blunt, but also give leeway for exploration and creativity.
AdieuToLogic 1y ago
> From what I've seen, the idea that AI is turning developers into super-managers is why some people struggle to adapt ... This "idea" is hyperbole. > Those who love to type their code and hate managing others tend to be more hesitant to adapt to this new reality. This is a false dichotomy and trivializes the real benefit of going through the process of authoring a change; how doing so increases one's knowledge of collaborations, how going through the "edit-compile-test" cycle increases one's comfort with the language(s)/tool(s) used to define a system, how when a person is flummoxed they seek help from coworkers. Also, producing source code artifacts has nothing to do with "managing others." These are disjoint skill sets and attempting to link the two only serves to identify the "super-manager" concept as being fallacious. > Meanwhile, people who love to manage, communicate, and work as a team are leveraging these tools more swiftly. Again, this furthers the false dichotomy and can be interpreted as an affirmative conclusion from a negative premise[0], since "[m]eanwhile" can be substituted with the previous sentence in this context. 0 - https://en.wikipedia.org/wiki/Affirmative_conclusion_from_a_negative_premise https://en.wikipedia.org/wiki/Affirmative_conclusion_from_a_...
- favoboa 1y ago
  Thanks for the detailed critique. I think we might be talking past each other on the "super-manager" term. I defined it as a hybrid of EM + IC roles, not pure management, though I can see how that term invited misinterpretation. On the false dichotomy: fair point that I painted two archetypes without acknowledging the complexity between them or the many other archetypes. What I was trying to capture was a pattern I've observed: some skills from managing and reviewing others' work (feedback, delegation, synthesizing approaches) seem to transfer well to working with AI agents, especially in parallel. One thing I'm curious about: you said my framing overlooks "the real benefit of going through the process of authoring a change." But when you delegate work to a junior developer, you still need to understand the problem deeply to communicate it properly, and to recognize when their solution is wrong or incomplete. You still debug, iterate, and think through edge cases, just through descriptions and review rather than typing every line yourself. And nothing stops you from typing lines when you need to fix things, implement ideas, or provide examples. AI tools work similarly. You still hit edit-compile-test cycles when output doesn't compile or tests fail. You still get stuck when the AI goes down the wrong path. And you still write code directly when needed. I'm genuinely interested in understanding your perspective better. What do you see as the key difference between these modes of working? Is there something about the AI workflow that fundamentally changes the learning process in a way that delegation to humans doesn't?
bryanrasmussen 1y ago
you seem to think those who love to write their own code and dislike managing others also evidently don't like to communicate or work in teams, which seems a big leap to make.

voidhorse 1y ago

> They already know how to review imperfect work and give feedback, which is exactly what thriving with AI looks like. Do they, though? I think this is an overly rosy picture of the situation. Most of the code I've seen AI heavy users ship is garbage. You're trying to juggle so many things at once and are so cognitively distanced from what you are doing that you subconsciously lower the bar.

favoboa 1y ago
You're absolutely right about the garbage code being shipped, and I would bucket them under another group of adopters I didn't mention earlier. There are people hesitant to adapt, people thriving with AI, and (not exhaustively) also this large group that's excited and using AI heavily without actually thriving. They're enjoying the speed and novelty but shipping slop because they lack the review discipline. However, my sense is that someone with proper management/review/leadership skills is far less likely to let that code ship, whether it came from an AI, a junior dev, or anyone else. They seem to have more sensibility for what 'good' looks like and can critically evaluate work before it goes out. The cognitive distance you mention is real, which is exactly why I think that review muscle becomes more critical, not less. From what I've observed, the people actually thriving with AI are maintaining their quality bar while leveraging the speed; they tend to be picky or blunt, but also give leeway for exploration and creativity.

AdieuToLogic 1y ago

> From what I've seen, the idea that AI is turning developers into super-managers is why some people struggle to adapt ... This "idea" is hyperbole. > Those who love to type their code and hate managing others tend to be more hesitant to adapt to this new reality. This is a false dichotomy and trivializes the real benefit of going through the process of authoring a change; how doing so increases one's knowledge of collaborations, how going through the "edit-compile-test" cycle increases one's comfort with the language(s)/tool(s) used to define a system, how when a person is flummoxed they seek help from coworkers. Also, producing source code artifacts has nothing to do with "managing others." These are disjoint skill sets and attempting to link the two only serves to identify the "super-manager" concept as being fallacious. > Meanwhile, people who love to manage, communicate, and work as a team are leveraging these tools more swiftly. Again, this furthers the false dichotomy and can be interpreted as an affirmative conclusion from a negative premise[0], since "[m]eanwhile" can be substituted with the previous sentence in this context. 0 - https://en.wikipedia.org/wiki/Affirmative_conclusion_from_a_negative_premise https://en.wikipedia.org/wiki/Affirmative_conclusion_from_a_...

favoboa 1y ago
Thanks for the detailed critique. I think we might be talking past each other on the "super-manager" term. I defined it as a hybrid of EM + IC roles, not pure management, though I can see how that term invited misinterpretation. On the false dichotomy: fair point that I painted two archetypes without acknowledging the complexity between them or the many other archetypes. What I was trying to capture was a pattern I've observed: some skills from managing and reviewing others' work (feedback, delegation, synthesizing approaches) seem to transfer well to working with AI agents, especially in parallel. One thing I'm curious about: you said my framing overlooks "the real benefit of going through the process of authoring a change." But when you delegate work to a junior developer, you still need to understand the problem deeply to communicate it properly, and to recognize when their solution is wrong or incomplete. You still debug, iterate, and think through edge cases, just through descriptions and review rather than typing every line yourself. And nothing stops you from typing lines when you need to fix things, implement ideas, or provide examples. AI tools work similarly. You still hit edit-compile-test cycles when output doesn't compile or tests fail. You still get stuck when the AI goes down the wrong path. And you still write code directly when needed. I'm genuinely interested in understanding your perspective better. What do you see as the key difference between these modes of working? Is there something about the AI workflow that fundamentally changes the learning process in a way that delegation to humans doesn't?

bryanrasmussen 1y ago

you seem to think those who love to write their own code and dislike managing others also evidently don't like to communicate or work in teams, which seems a big leap to make.