All the recent hype on AI has been around boosting productivity, meaning the amount of code written in a unit of time. Beside the fact that it is questionable if this is the kind of productivity that really matters, productivity is not always what you may want to improve. What you need to improve depends a lot on the phase the project is in its lifecycle.

What is the top priority for a start up project?

I’m talking about projects and not companies here because there are start up projects even in mature companies. A start up project is a project that is just born. It has some distinctive features. First of all it still has to prove that there is room for it in the real world. That it serves a real need, that it can payout for itself. Second, there are still a lot of things to be discovered, to be defined. In both of these cases speed is the key factor. The project needs fast feedback loops to have a better understanding of the environment and its relations to it. It needs fast time to market to quickly build a market share before some competitor does and to reach the break even point before the money and/or the patience of the funders run out. In this case delegating entire features to the AI can make sense, if (and is a big if, we will see it later on) that means releasing them faster. Sure there will be bugs, but they would have happened even if the code were rushed out manually. Sure you will lose some knowledge in how the system works, but this is all technical debt that may be worth taking to reach the main goal: release fast, learn fast, succeed fast (or die). There are plenty of blog and social media posts out there describing how to set up a swarm of agents that will work for you, so I’m not going to spend many words on this topic. Let’s look at a different situation, instead.

What is the top priority of a mature project?

A mature project is different. Speed is not the number one priority. Stability is. A colleague of mine once said: “Look, the system is already running, it is making a lot of money every hour. Every time you do something on it, there is a chance you will break it, and the company will lose money. So, the less you work, the more money the company makes”.
Is there any room for AI in this kind of project or should you carefully chisel your code manually like a goldsmith, like in the good ol’ days? Sure there is! You can use AI to improve the stability.
Stability can be improved in different ways. The most obvious one is fixing bugs. But to fix a bug without introducing another one you must have a deep understanding of the ins and outs of the system. More frequently than not in mature projects, this kind of knowledge got lost along the way. People have come and gone, changes have piled up, and now nobody knows exactly how things work, or even how they should work. So, rebuilding knowledge is another way to improve stability.
Beside the need to keep the system up and running as is, usually there is also the need to evolve the system, even if at a much lower pace than in the start up phase. To be able to do that you need to start paying off the technical debt that had accumulated in the start up phase. By definition the technical debt is what makes it harder, or even impossible, to work on the system at a reasonable speed and without breaking things. Exchanging technical debt for speed has been the right thing to do in the start up phase, and it is also thanks to that trade off if the project has succeeded, but now it is time to pay it off, if you don’t want the system to become unmanageable.
AI can help a lot with all these activities.

Write the code, but let the AI review it

They say that the best way to predict the future is by contributing to shaping it. In the same way, the best way to understand a software system is contributing in writing it. In a mature project you don’t need to rush features out, you need to double check that what you are doing fits in the system, you are not introducing any regressions and maybe you are even improving things a bit, applying the boy scout rule. Sure you can let the AI write the code and then review it, but it is very difficult to understand if a piece of code is the best possible way to solve a problem in a given scenario without putting your mind to the problem solving first. And once you have spent time on problem solving, then writing the code is trivial. Personally, writing code helps me to reason about a problem, so I prefer to do it manually. But then you can use the AI to double check that you didn’t make any local error in the new code, and that it doesn’t break some other part of the code base. In my experience the AI is much more capable than humans in catching errors that are not evident looking just at the new code, but that depend on how the new code interacts with the old one. On the other hand humans are better than the AI in judging if the new code has a reason to exist in the first place or not. So AI reviews do not replace human review completely, they are just faster and better in catching some subtle issues.

Reverse engineering the system

The AI can help to unfold complex legacy code bases, to rebuild the knowledge on how things work that got lost along the way. Even in this case the best way to proceed is to try to navigate and understand the codebase on your own first, and then double check with the AI if your understanding matches its one, in that case it is probably correct. The AI cannot understand the system for you, in the end you need to build a mental model of the system on your own, but it can help in getting you unstuck and in double checking your assumptions and your hypothesis. It can also help in explaining snippets of code, when they are written in a language you are not familiar with.

Delegate mechanical housekeeping activities

There are a lot of refactors, reworks, housekeeping activities in general that are too fuzzy and complex for traditional automation, like the IDE rework features, and are too long to do manually, compared to the value they add. Replacing or removing an outdated library, updating to a new version of the same language, porting from a language that the team does not master to a one that the team is more confident with. These are all activities that do not bring direct business value, but that can be a precondition to be able to work effectively on the system. These sorts of things can be effectively delegated to AI, provided that you have a no regression test suite that you can trust.

Write no regression tests

Speaking of tests, they are another of those activities that everybody is always willing to do, but strangely enough there is never time to do them. The problem is that a no regression test does not add any business value per se, so it’s difficult to convince the management to invest in them. But it is an enabler for faster and even automatic development cycles, so it would really be nice to have, if only we had time! The AI can help make writing tests quick enough to slip them in between “real” work. Even in this case I prefer a mix of human and AI. I delegate to the AI almost all the boilerplate necessary to set up the test environment in the way I like. Then I manually write the tests covering the most important flows, then I ask the AI to double chek and extend them to cover corner cases.

Ask the AI for alternatives

There are always multiple ways to skin a cat, and on mature projects it is always worth taking some time to evaluate possible alternatives to solve a problem or to implement a feature. On the one hand there is the time to do it, on the other there is a high risk of introducing regressions, so you must be more careful than in a green field project. AI is a good partner to brainstorm with to quest for new ideas. It is always available, never tired, never judging and always eager to say something.

Is improving productivity in writing code improving the overall productivity?

The Goal, the famous book by Goldratt that introduced the theory of constraints, makes it clear that increasing the productivity of just one step in a production pipeline does not automatically increase the productivity of the overall process. If you increase the productivity of a non bottleneck step, the overall productivity remains unchanged, because it is controlled by the bottleneck step(s). So, is writing code the real bottleneck step in a software production pipeline? Let’s try to understand. First of all, what are the steps in a software production pipeline? They can vary, but more or less should be:

  1. requiremets gathering
  2. design the architecture
  3. split the activity in tasks, estimate and plan
  4. code
  5. test
  6. release

The first step cannot be delegated to the AI because it requires interacting with other people. And in my experience it can take a lot of time.
Steps 2 and 3 can be delegated but at the risk of progressively losing the mental model on how the system works. This is very dangerous because it severely reduces your ability to maintain and change the system in the future. It can be an acceptable risk sometimes in a start up project, definitely not in a mature one.
Step 4, coding, can be delegated to AI, as well as point 5, testing. But if you are still testing manually then producing code at the speed of light is useless, because the bottleneck will be manual testing, so all you will get is to increase the pile of code waiting to be tested.
The last step, release, can already be sort of automated if you practice continuous delivery, but if you don’t, it may really be a bottleneck. If you release once every 6 months (it happened to me), then coding faster does not mean release faster. It could mean release more, but it depends if the other steps can keep up. So I don’t have a one size fits all answer, it depends on your use case, but before trying to speed up the coding step, be sure that it is your real bottleneck.

Conclusion

So, in the end, unless there are compelling business constraints to release features at a breakneck speed, even at the risk of making the system unstable and accumulating tech debt, it’s probably more sensible to use the AI to make the code more robust and the system more stable. Because a well maintained system, a system where complexity hasn’t gone out of hand, a system the team truly knows and understands is also a system where new features can be introduced pretty fast and pretty safely, even manually.