We Don’t Program Anymore, We Manage Programming (AI impressions, part 3 of 5)

Man holding papers and looking stressed in a busy office environment

This is the third part of the series “Impressions of Our Current AI Usage”, as outlined by the introduction article.

In the early years of my career, there was a sudden increase in books about management in the technological fields, especially software development. I didn’t make the connection then, but it was right around the time when the first generation of academically educated software developers were senior enough to climb the corporate ladder one step further and become middle managers. Authors like Tom DeMarco and Timothy Lister wrote books that we discussed fiercly, because their propositions clashed with our observed reality of commercial software development.

“Why are our managers so bad at their job?” we asked. Don’t they see the obvious problems that they themselves created? What we didn’t get was that those managers were very experienced developers, but absolute beginners in their new job – leading people that develop instead of developing things themselves. They knew exactly how they would solve the technical problems, but were forced to concentrate on the very untechnical problems of people under their supervision. Nothing in their previous career prepared them for the challenges that “dealing with people problems” would impose upon them.

I personally know several senior developers that turned down (or reverted) a promotion to a management position, because they might gain some money and status, but lost all the things they were passionate about and good at. Working hard to create the environment where others can have the fun you would want to have yourself, is not the most rewarding job in the world. I fully understand them. And I say that as the founder and boss of a software development company. I’ve found my balance between being a manager and a developer, but it’s a constant negotiation.

The premise of our job as software developer was that customers tell us what they want and we describe it to the computer. In essence, we were translators between the worlds of humans and machines, right down to the languages: Some languages for human interaction, others for machine interaction. Because the computer was dumb as a rock, we needed to craft the solution with immaculate precision and in great detail. If anybody asks why software development took so long and was so demanding, imagine explaining quantum field theory to a first grader, so that the child can work in a laboratory among experienced physicists without screwing everything up.

And now, there is artificial intelligence (currently in the form of LLM-based agents) that produces working source code if prompted roughly right. Back in my days, we would call this role a “junior developer”. Which transforms our role to that of a manager: We bring the requirements from the customer, sketch a solution with our senior developers and architects (in the best case, this is also us) and explain it in necessary detail to the junior developers. Then we wait for them to translate our vision for the computer, review the result and iterate as long as necessary.

The only advantage of this scenario in comparison to the same role a decade ago is that the current junior developers aren’t human anymore. So while we need all the skills a capable manager should have, we don’t have to deal with different personalities and human problems in the workplace.
Except that LLMs tend to exhibit the worst work personality types (charming overconfident dazzlers) and are as ruthless and negligent as human junior developers in their “early ability – peak stupidity” phase. As their manager, you can work with human junior developers on their character journey, using the tools from the “people problems” part of your role, while you can only hope for the next version of LLMs to be more pleasant to deal with.
So, as middle managers between the customer and the juniors, we don’t have to deal with “soft topics” anymore. But we have to endure their effects (good and bad) daily. We are “promoted” to be highly ineffectual managers that supervise a bunch of knowledgable, but otherwise clueless juniors. That’s more or less the experience of previous senior developers that became managers and found themselves overwhelmed and underjoyed. The problem is that our new machine-based junior developers are so fast with their work that we can’t replace them with humans and expect similar performance. And the classic “instruct, oversee, review”-cycle that middle managers go through again and again is sped up from days or weeks to minutes. Which leaves virtually no leeway for typical management activities that still run on human speed and require time.

My hope is that managing AI agents requires a totally different skillset than managing human junior developers. Because otherwise, I can attest most of us experienced developers a pronounced inability and unwillingness to be effective in this new role. And I don’t want to imagine a world where most software development is done by poorly managed AI agents while their managers act and feel like fish out of the water.

One thought on “We Don’t Program Anymore, We Manage Programming (AI impressions, part 3 of 5)”

Leave a comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.