Tactical tornadoes in the age of AI-assisted coding

In his book "A Philosophy of Software Design", John Osterhout has coined the term "Tactical tornado", which he defined as follows:

The tactical tornado is a prolific programmer who pumps out code far faster than others but works in a totally tactical fashion. When it comes to implementing a quick feature, nobody gets it done faster than the tactical tornado. In some organizations, management treats tactical tornadoes as heroes. However, tactical tornadoes leave behind a wake of destruction. They are rarely considered heroes by the engineers who must work with their code in the future. Typically, other engineers must clean up the messes left behind by the tactical tornado. Which makes it appear that those engineers (who are the real heroes) are making slower progress than the tactical tornado.

If you write software, the chances are that, as you read this paragraph, some particular people come to mind (or maybe not... then you're either very lucky or I potentially have some bad news for you). Of course, we all know the truism that done is better than perfect. However, people and organizations differ in what they consider acceptable.

I would argue that "it does what we need it to do" is the lowest bar that you can set and that ultimately leads to the accumulation of tech debt and the inevitable stalling of innovation and developer velocity at the company (a discussion of the dynamics of tech debt accumulation is a topic for a separate post). Unfortunately, in many cases, the bar is set not far above it. As a result, engineers who are trying to be strategic about the software they ship have to go against the incentives set by their organizations, often at a personal cost in terms of promotions and recognition, while technical tornadoes thrive.

Now, let's think through how the introduction of AI-assisted coding affects this dynamic.

First of all, I feel like most of us agree that AI in itself is neither good nor bad; it's just a tool. So, what really matters is how it is being used. There are definitely ways of being fairly strategic with your AI coding by doing some version of the following:

• Spending time on providing the assistant with the context about your overall system and a particular problem that you're trying to solve
• Setting the coding guidelines for the agents: what patterns you want it to use, or not use, etc
• Iterate with the coding assistant on the approach to solving the problem, and create a plan of action. A common pattern is to commit that plan to a standalone md file that you load up into a fresh session to avoid context that is too large.
• etc

However, aren't these the steps that would be helpful even without an AI-assistant? Basically, you need proper documentation of your system, current objectives, product requirements, and an implementation design doc. Tactical tornadoes usually do none of that, but instead jump straight into implementing the most expedient way to solve the problem that would "work" (i.e., satisfy the basic product requirements and not always 100% but "close enough").

So, here's the question: who will experience a greater boost in productivity from using AI-assisted coding tools? A strategic developer who is going through all the steps necessary for the assistant to act in a strategic manner (ideally, investing in a project-level context, system documentation, etc), or a tactical tornado?

AI seems to be reasonably good at getting to a working state already with minimum effort, however, getting it to be strategic, takes a considerable amount of work. So, if I were to make a bet, I'd put my money on tactical tornadoes getting a higher multiplier to their output. As a result, the share of code produced in a purely tactical fashion will be rising, likely accelerating the accumulation of tech debt.

The only way to prevent that, in my opinion, is for the leadership (both technical and product) to step up and raise the bar for the required quality of developer work. Developers exhibiting desired behaviors (i.e., documenting their systems, thinking through and writing down their designs, and ensuring that new developers can be productive in the code base) should be rewarded. After all, people respond to incentives laid out in front of them, and it's a bit naive to expect developers to keep going out of their way to make clean, sustainable systems purely out of appreciation for the craft.

What do you think? Do you agree that Tactical Tornadoes will experience a bigger boost in productivity than strategic developers? Are there other ways to avoid the acceleration of tech debt accumulation?