AI Coding Tools and Project Management: How long do tickets take now? By Ed Lyons
When AI coding tools were new, their assistance could be described as a very powerful auto-completion tool. A developer’s productivity would get a boost, but it might not have been obvious to a project manager who on the team was or was not using it. But with the current state of these tools, that may no longer be the case.
On some projects, the situation is better understood as the following: a few senior developers have silently joined the project, and will be assisting the ones you already have. So what was once a ticket that would take three days to complete, might now take only one or two. But even if the effect of coding AI tools was just saving every developer one hour a day, this is a difference that project managers need to look for, even on projects where AI is not allowed for the codebase.
That’s right – even if AI is not allowed on your project, perhaps due to concerns about proprietary information leaks or cost, it could still be used safely and project managers must account for it. Developers who are not allowed to use AI can still access generated code in generic searches on the web, and they can also create separate prototyping projects on their machines with plain vanilla labels and no proprietary information to get the key logic correct that can then be pasted back into the proprietary code. This “clean room” iterative approach can save hours of work, and your developers might be doing this quietly already.
Regardless of how AI coding tools are used, it is now appropriate and perhaps even essential for managers and developers to discuss them in task estimation and status updates. When considering a task, a project manager might ask the team, “How much of this could be generated?” One developer might say, “Well, maybe I could get half of this generated, but there would be a lot of other customization.” Another developer in that refinement meeting might disagree and say, “I recently used a particular tool and prompt to get something similar almost entirely generated.”
Teams need to get a feel for how useful these tools are for their particular project. With large legacy codebases, the productivity improvements may be smaller than in a new application. AI coding tools also understand some technologies far better than others. Project managers should also seek to understand what features can be generated easily, and which cannot. Common features that are seen in many applications are good candidates. Changes to business logic or legacy components might not be.
A lot of this comes down to the creativity and skills of developers on the team. Coding tools often cannot come up with the exact code that is needed. But experience in using these tools can allow developers to generate key pieces of the solution, create test cases that will assist hand-coding, or make debugging more efficient.
There are other dynamics project managers should be aware of that come from the “pair programming” feel of using these tools. Their ability to create complex working code and continue iterating through improvements has meant that I am “stuck” less often, and for shorter periods of time.
So if a manager notices that someone seems to be unable to make progress on a ticket, in addition to recommending a team member help, they could say, “Have you tried talking to AI about what isn’t working?” just to make sure they remember. I sometimes forget to chat with AI when I get deep into hand-coding a piece of code. Similarly, someone can spend too much time chatting with AI without making progress, due to not asking the right questions or because the tool just isn’t helpful for that task.
In sprint retrospective meetings, it is a good idea to discuss how AI coding tools were used, and how they could be used more effectively in the next sprint. For instance, technical team leads might continually update prompt guidance for what terms and phrases should be used for better results on a particular project.
Take Away
The potential productivity gains from AI coding tools are now so great that their use is no longer purely a matter for individual developers. They now affect the entire project, and project managers should discuss them in project meetings.