a lot now in the time of LLMs. It’s essentially completely changed how the field works and how you effectively develop a good product and complete work on engineering tasks.
In this article, I’ll discuss how to perform effective project management in the age of AI, both from the perspective of orchestrating tasks and deciding what can be done, and then how to effectively work with the tasks themselves to complete them as efficiently as possible.
Why project management has changed
The main reason project management has changed in the era of LLMs is that the time we spend on various tasks in project management while working on a project, a tech project, has changed radically.
Well, previously, the distribution of time spent for a software engineer could be something like this:
- 70% – Write code
- 15% – Meetings
- 15% – Testing
The time spent coding has now essentially become 0, since I don’t write any code myself. I do, however, spend time prompting agents, which would be a sort of replacement:
- 30% – Prompt agents
- 10% – Meetings (keeping this the same)
- 30% – Testing (much more time is spent testing)
- 30% – Time extra that I can spend on other stuff
The 30% extra time that I’ve unlocked is, of course, just an estimate, but this time can, for example, be spent reading up on new topics, spinning up more agents, and basically getting more work done, testing the platform more, and so on.
So in short, project management has changed because what we spend time on has changed. This requires different optimizations for you to spend your time as effectively as possible, which is what I’ll cover in this article. I’ll discuss how you as a software engineer can more effectively manage both your time and projects to get more work done.
It’s worth mentioning that when I refer to project management, I typically refer to the time you, as a software engineer, spend working on your different projects or deciding which projects to work on, and basically how you get the work done.
Effective project management
In this article, I’ll discuss how to perform effective project management, and I’ll spend most of the time talking about the techniques that I apply to be as effective as possible when working on projects. This does not, of course, apply directly to your specific project management, so I urge you to generalize the knowledge that I discuss in this article and try to apply it to your specific application areas.
I’ll cover specific techniques that I apply in the era of LLMs to get the most out of the LLMs and work as effectively as possible on all of my projects to get as many tasks done as possible.
Map out work more beforehand
The first thing I spend more time on now than I did previously is mapping out work beforehand. My tasks usually come from a Slack message (product feedback/bug), or from a project I’m working on. When I start working on those tasks, I try to map out the work as much as possible beforehand.
The reason you should spend more time on this now is that having work mapped out allows you to have agents run for longer periods of time fully autonomously, i.e., you don’t have to interact with them as often.
To help get the point across, you can imagine a task that you’re working on that you haven’t mapped out at all and that has a lot of ambiguities and unclear aspects to it.
You can then fire off this unclarified task to an agent, and the agent will start working on it, writing code, etc., and so on. However, the agent will of course soon encounter a situation where it’s unsure what to do because you haven’t cleared the ambiguities with it or helped the agent understand the task fully; the agent will then have to stop, ask you, the human, a question on what to do before it will continue. The agent will then have to stop multiple times, likely, before it manages to complete the task.
This is naturally suboptimal use of your time because you don’t want to spend time clearing ambiguities with the agent while it’s running. Ideally, you cleared all of these up beforehand, and the agent can just work autonomously until it completes all of its work, which is typically marked when the code is in the dev branch.
Thus, whenever I hand tasks off to my agent, I try to clear as many ambiguities with my agent beforehand. This can be done by thinking thoroughly through the task yourself or discussing with an LLM if there are any ambiguities you should clear up before starting. I then make the agent present all of these ambiguities to me in an HTML report, and I go through each of them, stating my preferences, so that when I let the agent start working, it can work fully autonomously for a long period of time.
Use the /goal command
The second important point of project management that I do is to actively use the /goal command. This ties closely into the last task that I mentioned about mapping out work beforehand. And this tip will not be effective if you don’t map out the task properly beforehand.
The /goal command is essentially a hook that the agent triggers every time the agent says that it completed the work, and it makes the agent reflect on whether it actually completed all the work you requested from it or not. And of course, if it didn’t complete all of the work, the hook prompts the agent to continue working until everything is fixed. It’s basically a way to force the agent to keep working for longer periods of time to really get all of the work done.
I’ve noticed more lately, specifically with Opus 5, that if I don’t use the /goal command, it oftentimes doesn’t actually complete all of its work. I find that it’s actually a bit lazy. And to a certain extent, it’s lazier than Opus 4.8, and definitely more lazy than Fable 5.
This is, of course, unfortunate, as coding agents should ideally by default just work until all of their work is completed and not require an external hook to continue. But nonetheless, the /goal command is a very good quick fix we can use until that is the case. And I essentially use /goal on all of my long-running tasks.
Minimize unnecessary time spent testing the app
Another topic I want to cover is minimizing the time spent testing the app. Again, this ties closely into the two previous sections that I’ve covered about mapping out work beforehand and using the /goal command. But I find that one of the things I spend way more time on now that we have LLMs to code for us is testing the application.
If you notice the percentages that I covered earlier in this article, you can see that the percentage time that I estimate I spend on testing has roughly doubled from before, relatively, because there’s just more work being done, and I just have to spend more time testing the code. And of course, since testing has become the new bottleneck, you, of course, try to minimize how much of a bottleneck it is, and I just try to automate testing as much as possible using LLMs that interact with my browser.
I think an important point of mapping out all the other work beforehand is that you tell the agent exactly how to test whether what it implemented is correct or not. You need to tell the agent specifically and explicitly what is regarded as a successfully completed task. If you don’t do this, it’s of course going to be difficult for the agent to know whether a task has been successfully completed or not.
My simple setup to make this happen is that I have Playwright MCP accessible to all my Claude Code and Codex agents and allow them to spin up localhost servers and access Chrome and test the servers there. This saves me a lot of time because, in many cases, the agents will find that if they click a button, it lands on a 404 page, or if they click another button, then they don’t see the expected behavior. So this allows the agent to not only see the code that it’s writing, but also literally test it end-to-end in your application to make sure it works as both you and the agent expect.
Conclusion
In this article, I covered how project management for me has changed in the era of LLMs. What I spend time on as a software engineer has now changed significantly. I spend less time coding and more time testing, and I also have more time available to me to spend on other things or just spin up more agents, of course. I think you should rethink the entire project management philosophy or heuristic that you’re running yourself because it’s changed so much before and after LLMs. It’s important not to be stuck in the old project management way, the way that was before LLMs, because this leaves a lot of productivity gains on the table. I urge you to try out new stuff when it comes to project management and try to automate as much as possible in order to get the most out of the extremely powerful LLMs that are now commoditized.
👉 My free eBook and Webinar:
🚀 10x Your Engineering with LLMs (Free 3-Day Email Course)
📚 Get my free Vision Language Models ebook
💻 My webinar on Vision Language Models
👉 Find me on socials:
💌 Substack