agents essentially performing all the coding implementations, another issue I’ve noticed is keeping track of all my tasks, which coding agent is interacting with my task, and so on.
Task management has become a challenge in itself because we’re doing so many tasks at once. There is a challenge keeping track of everything. Of course, this is quite a good problem to have because we’re essentially saying that we’re doing so much work that it’s hard to keep track of everything, but as with anything else within engineering, we need to discover bottlenecks and resolve them so that we can unlock increased productivity.
In this article, I’ll discuss my coding workflows, how I keep track of all my tasks, how I keep track of which coding agent is doing what work, and so on.
Why task organization is harder now with coding agents
I always like to cover the why in any article that I write. In this article, I’ll discuss why task organization is harder now. The simple fact is that with coding agents now, we’re just performing way more work as programmers.
Previously these tasks listed below could take a whole day (or several days) in themselves:
- Implementing a design
- Resolving a complex bug
- Implementing a new feature
These are now tasks that you work on in parallel and complete in a maximum of one day. There are very few coding tasks now that take many days to implement. If so, it would be more complex features that I’m working on.
This is, of course, in stark contrast to before LLMs, i.e., before the release of ChatGPT in December 2022, where you would have to work on one task at a time; of course, you would have to do them sequentially, and each individual task would also take a lot longer to work on, for several reasons.
This could, for example, be that you will have to research a new framework, that you introduce new bugs that you didn’t intend to, that you have to fix. Or it could be that someone else was releasing a lot of code to dev, so we had to rebase on top of it. All of these are essentially non-challenges now, because:
- The coding agents rarely create silly bugs anymore. They’ve basically been eliminated through writing code with AI coding agents and reviewing it with AI coding agents.
- You don’t need to learn new frameworks anymore because the coding agents either know them from before if they’re very established frameworks, or they can go online, research the frameworks, and understand them that way.
Thus, we’re working on a lot more tasks, and we need to have control over all the tasks we’re working on, how to test them, and which coding agent is working on what, so that we can follow them up appropriately.
How I do task management with coding agents
I’ll give a high-level, task-agnostic overview of how I work with coding agents and keep track of them here. And then in the next section, I’ll cover some specific tools that I’ve used and my feedback on those.
In general, I want to highlight the following points:
- You need to ensure your coding agent task management system is connected to your coding agent through an API or an MCP. You should not be interacting with the system manually yourself, writing comments, updating on progress, and so on. That’s simply a waste of time, and you should make sure your coding agent does that automatically for you.
- You should make sure to work in separate worktrees when you do your work. If not, you’ll have issues with coding agents overlapping. There are numerous ways to work with separate worktrees. Claude Code has a separate flag you can use for it and many other coding agent interfaces such as Emdash handle it automatically for you. Furthermore, you should ensure that you name these worktrees appropriately so that it’s easy to come back to the worktrees whenever you do, or it’s easy to pick up on what’s been done within a worktree whenever you come back to it.
So basically, whenever I receive a new task, which can be from any of the tools that I discuss below, I’ll immediately spin up a new worktree session in my Emdash application or new workspace, as it’s called, and start working on the task. If I receive the task through Slack, for example, I’ll include the link to the Slack message so the agent is aware of it, and I’ll ask the agent to do research, and we’ll discuss how to start the work. I’ll also make sure that I rename the worktree something unique and appropriate so that I can know exactly what work is being done there just by the worktree name without having to read any logs within the coding agent.
I’ll then do this for multiple tasks, of course, and continue until I either have too many tasks to keep track of at once, so I don’t feel like I have a good overview anymore, or there are no more tasks to continue on, and I’ll just finish the tasks I’m currently working on. After the coding agent has finished the planning and research, I’ll fire it off, and it will start the work, and I’ll tell it to continue working until it gets its work to dev.
This is an interesting approach because you might think that in a lot of cases you’ll want to verify the feature is working locally before taking it to dev. And if it’s a very complex feature, I agree with you; you should do that. But for most tasks that you’re working on, this is actually not the case, especially if you’re working on less complex issues. And I’ve found that I’m better off just having the agent merge it into dev because, in a lot of cases, that’s simply correct, then I can check off the task and consider it done. In some cases, maybe 20 to 30% of the time, I’ll see some issue in dev, and I’ll ask the coding agent to fix that and merge it into dev and test again. I find that this, in total, saves me a lot of time compared to having the agent implement it locally and then merging into dev once I’ve verified it.
Another thing I do, which I find very useful to keep track of the work I do and how to test it, is that I ask the coding agent to create HTML reports whenever I test stuff. So, for example, once the agent has gotten stuff to dev, I of course need to test everything to make sure it works. In these cases, I tell the agent to make an HTML report with the following features:
- At the top, give a short summary and include the name of the worktree so I know which worktree we’re working on. Also make sure the browser tab is named after the worktree.
- Include each sub-task that we’ve been working on with the following: The original message in the task. For example, if it was a Slack task, include the original message quoted verbatim, include what the agent did, shortly summarized, and include a bullet point list on exactly how I can test what the agent has done, so I can verify if it’s correct or not. Also include two buttons saying “verified” and “not fixed”, including a field where I can comment.
- I then go through this HTML report, looking at each sub-task, testing it exactly how the bullet point list says, seeing if it works. If it works, I just check it off and tell the agent that the task is done. If not, I say it’s not fixed, and I give a comment on what it needs to do and tell the agent to go on and fix that.
I found that this is a very efficient way of having agents work until a task is actually complete, and it’s very efficient for me to quickly understand how to test different tasks, so I don’t have to manually remember how to test them, and to check them off if they’re complete or to know what needs fixing if it isn’t complete.
Specific tools I’ve tested and my review
Now I’ll cover the specific tools I’ve used. I’ve tried a few different ways to do task management, and I think all of them can work. However, most importantly, you need to find something that works for you.
Every programmer’s situation is different. It could be differences in how the company does work, it could be differences in tools that the company uses, or simply preferences in how to do programming. Thus, I urge you to be inspired by what I discuss here today, but to find a solution that works best for your specific use case.
In the rest of this section, I’ll cover some different ways I’ve tried to do task management with coding agents and what I think of each approach.
Linear
Linear is a specific application that’s designed for project management for programming. Linear is definitely very developer-focused, which you can see from the design of the app, but it works very well. You can track where tasks are based on whether they’ve been merged to dev, whether they’re currently in the PR review, and so on.
I have had great success by connecting Linear to my coding agent and working from there. So, for example, whenever I receive a new task, which could come from a Slack message, it could be a bug I discovered myself, etc., I just create a new Linear ticket for it with my coding agent, and then I start working on that.
The great thing with this approach is that you don’t need to write a full spec every time you want to perform a task. You can simply hand the coding agent the link to the Linear issue, and it will handle everything:
- Reading the task and understanding it
- Marking the task as in progress so that people can see you’re working on it
- Commenting on the task as the work progresses, either mentioning assumptions that you’re making, decisions that you’ve taken, and so on, using the comment system in Linear
- Marking the task as complete whenever the coding agent is done with it and it’s been verified
Linear is also great because it’s a very good system to track all changes because they have an activity log, and you can collaborate with teammates by inviting them to projects and issues.
I find that Linear works very well if you’re in an established position where you have a lot of developers and other people interacting with your product, and you need to keep track of everything and have a very organized setup.
Slack
I also tried to do some task management in Slack, specifically when I receive a lot of product feedback or bug feedback in the Slack channel, and I can just work from there. For example, you can use it very similarly to Linear, where you have a comment system. You can react to tasks to show that you’ve seen the message, and you can check off tasks when they’re done and so on.
The great thing about using Slack for task management is that a lot of other communication and work within a company happens in Slack. Slack is the place a lot of startups, at least, and other companies use to communicate, where you can have different groups and so on. But typically also where you will report product feedback and bugs; thus, working directly in Slack, updating on progress for tasks and so on, is a great way to keep track of all the work you’re doing.
One downside I would note for Slack is that it’s not very suitable for many developers working on the same projects. First of all, it’s hard to have full project management in Slack. It’s better for product feedback and bug reporting specifically. Secondly, it doesn’t work that well if there are many developers working on something because you can’t subscribe people to issues in the same way, and you don’t have the same activity log that you get in Linear.
Of course, it’s critical to make sure that your Claude Code or Codex or other coding agent is connected to Slack so that it can automatically update or read messages, update on progress, and report when stuff is done, so you don’t have to manually interact with Slack. This is basically what you should do for all the applications that you implement within your company.
Notion
Notion is also an option you can use that has a good task tracking system. You can connect your agents to Notion, just like I’ve done for Linear and Slack.
I still actually use Notion for my personal task management system, i.e., not necessarily just programming tasks but every task I need to do, simply because of the simplicity and having a Markdown editor that’s online, so I can reach it from any computer or phone. I also think the interface is very clean, and I organize it as you see below.
Notion can also work well for multiplayer if multiple people are working on stuff, and you can create basically any task management system you want. They have Kanban boards, for example, and so on. However, again, I think Notion kind of suffers a bit from the same issues as Slack does, where it works very well if you’re a single developer organizing all your tasks and having everything there, but it starts to struggle the moment several people are working on it. In other words, I think it works well in very early stages, and when your company grows, you’re going to struggle to use Notion as a good coding agent task management system.
Conclusion
In this article, I’ve discussed how I organize all my coding agent work. First, I discussed why coding agent organization has become an issue now, because we’re working on so many tasks at once that it’s hard to keep track of everything if you don’t have specialized techniques to deal with it. I then discussed how I do task management with coding agents, covering my high-level approach to working on tasks with my coding agents. I also covered some tools that you can use to organize your coding agents and my opinion on each of the tools and when they are useful. I believe coding agent orchestration is very important, and it’s something you should spend time optimizing because it’s very easy to work on a lot of tasks at once and get confused about which agent is doing what, or it’s hard to keep track of everything. I just urge you to spend time optimizing this because it can save you a lot of time in the future.
👉 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