[0:00]As we hand off more of our coding work to AI agents, we need a workflow that actually scales. Most people start by prompting agents directly.
[0:07]The next step up from that is spectrum development. This is where you write clear instructions and task breakdowns into a markdown file before an agent touches any code.
[0:15]The markdown files fall apart really quickly. They're not a great way to manage complex work. You can't manage dependencies, you can't update status very easily and no one in your team can really see what's going on with the work.
[0:25]So in this video, I'm going to show you a better alternative. We're going to use a task management system like linear or Jira to act as an agent control plane.
[0:33]We're going to build a workflow where AI will help you plan your work, break it down into tasks and then push those tasks into a task management system.
[0:40]From there, agents are going to work on individual tasks, they're going to update the status of the tickets and then they're going to open a PR at the end, just like any other member of your team would. So let's get into it.
[0:49]So the first thing I want to show you is the linear board. So if you're not familiar, linear is a task management system, very similar to Jira.
[0:57]The exact task management system we're using doesn't actually matter. We're just talking about the general principles here.
[1:03]But as you can see, I've got a bunch of tasks that are in review. I've got some tasks in my backlog and I've also got some tasks that have been completed as well. So I can see which tasks that I need to go and review that my agent has completed for me.
[1:16]One of the important things to note is when you're working with AI agents, you need to give very clear instructions.
[1:23]This is one of the most fundamental principles. If you've worked in software engineering, you're probably familiar with a really frustrating situation where people will hand you a ticket.
[1:30]But that ticket is really badly defined. It has some vague description and it means you can't actually figure out what you need to do.
[1:36]We can't have that vagueness when we work with an AI agent. We need to be much more specific and more prescriptive.
[1:44]So you can see here that this is an example of a ticket where there's a lot of detail.
[1:47]So there's a link to a spec, which is within the repository, which has contacts about what we're building. We talk about what we're doing, we list out the features we want to build.
[1:57]We give code examples where relevant, we talk about the files that need to be updated, then we also give very clear acceptance criteria so that the agent knows when it's done.
[2:07]This is not something you would often see in a typical developer ticket you would find in the real world.
[2:13]And so this is a great example of where agents can actually help us write better task descriptions. And so you can use AI agents at every point in your workflow as a developer, just to improve the quality of your work.
[2:23]So before we move on, let's talk about an agent control plane. So the idea behind an agent control plane is pretty simple.
[2:29]Instead of managing agent work through markdown files, we're going to be using the same task-based systems we've always used. Just now the agents are the ones picking up and completing work tickets.
[2:40]We can see what's in progress, what's done, what's stuck, all on one board. This gives you proper status tracking, dependency management and real visibility when multiple agents are working on multiple things in parallel.
[2:51]If you're building anything more than a simple app or working with other engineers, this is pretty much essential.
[2:57]This is the exact same way we've always built software. We're just delegating the tasks to agents, not to individual developers.
[3:04]Once you've got this in place, you can start handing off work directly to your agents. If you've got a small fix, you can pretty much assign a ticket to an agent, have the agent pick up the ticket, implement the work and then open a PR.
[3:17]All in one structured end-to-end workflow. If you have something larger, you may still want to be in the loop and you may want to be more involved in that work and you may want to work directly with the agent.
[3:25]You can choose how involved you are, you can stay in the loop and work with the agent interactively as it works through the tickets, or you can hand off more straightforward tasks directly to an agent, let it open a PR for you and then you can review the PR.
[3:36]You can also run automated quality checks on those pull requests as well. In this demo, we're mostly going to be working with the agent in in the loop.
[3:46]But this workflow also scales both ways. And once you've built confidence in your specs, you can step back on the simple stuff and stay hands-on for the work that matters.
[3:54]So we're going to be using an application that I've been building to demonstrate. This is a simple application I'm using to manage my content.
[4:02]It has a weekly content calendar. This is just a way for me to stay organized and stay sane when producing content. So this is just a demonstration app.
[4:11]The application is less important than the actual ideas we're talking about in the video.
[4:15]The first thing we're going to need to do is find a way for our AI agents, like Claude Code or any other coding agent to get access to linear.
[4:23]The agents need to be able to create tickets, to read tickets and update tickets. There are two ways you can do that.
[4:30]One way would be to use the linear CLI tool, which would work fine. The other way is to use the MCP server.
[4:36]This is what I'm going to be using in this video. So to set up linear with in Claude Code, it's really, really simple. You just copy this one line.
[4:44]Once you've installed this MCP server, you just run /MCP once, you authenticate your linear account and then you are able to update tickets, you're able to fetch tickets.
[4:54]Claude Code has full access to working with linear.
[4:58]So let's take a quick look at this in action. So I should be able to query the open tickets in my linear instance.
[5:05]So we can say, Claude, can you go and fetch the open tickets on my linear board?
[5:09]So you can see that Claude was able to extract the tickets from linear. We have three tickets in review and three tickets in our backlog.
[5:16]So we could now choose to assign any of these to Claude to start working on, but before we do that, I just want to talk about the general workflow.
[5:24]So within this project, I've defined quite a specific workflow, and the idea is that we're telling Claude how to act as a senior engineer.
[5:32]So the workflow we're using is to fetch an issue from linear, so we're going to get a ticket.
[5:37]If that ticket has a parent issue, we're going to read the contents of that ticket. This is because I've deliberately put a lot of context in the parent issue so that Claude knows exactly what this project is and what it's trying to do.
[5:50]And then if the description references a spec file, we also go and read that as well. We then update the ticket status and then we determine the correct branch prefix because we want to check out a new git branch.
[6:01]We check out our get branch and then we implement the changes, we run some commands to verify.
[6:06]So as you can see, this is basically the same workflow that pretty much any developer would use if they were working on a software project.
[6:13]So just jumping into the terminal, what we have here are a list of things that we need to fix in our codebase.
[6:19]So I asked Claude to do a simplification report and find basically bugs or issues in our codebase. He found quite a lot of issues, so what we can do here is we can create tickets for all of these issues.
[6:30]Yeah, let's create linear tickets for the top five and then start implementing. So let's first create the tickets.
[6:38]So hopefully now Claude will go ahead and create detailed instructions and detailed tickets inside linear. So let's take a look.
[6:45]So this is an example of a ticket that Claude just created. So this is just some general tidy up and maintenance we need to do in our codebase.
[6:52]But what you'll notice again is that Claude did an incredibly detailed description of the work. We're clear about what files need to be updated and we're very clear about what changes need to be made.
[7:02]If you gave this to a developer, they would be able to work on this ticket because there's enough detail that they don't have to go and ask someone for more context or clarity.
[7:09]So Claude has created the tickets for us. So this is just a demonstration. It's worth noting that maybe it doesn't make sense to create tickets for all of these things.
[7:18]You might be better off just asking Claude to go and fix them straight away. But where you would use this workflow is if you're working on a larger feature for example.
[7:27]You might want to break that feature down into a number of tickets and those tickets may take you multiple days to implement and review.
[7:33]That's where this workflow really shines because you're keeping all of your tickets organized in a task management system.
[7:39]You're not letting things fall through the cracks and you're not relying on markdown files to figure out where you are with your project.
[7:43]So let's take a look at how we would do this. So let's ask Claude to go and implement one of those tickets.
[7:49]So as you can see, this is a really nice way of just handing off work to Claude.
[7:53]It's going to go and grab the linear ticket, it's going to read all of the information and then hopefully it's going to open a pull request for us to check out.
[7:59]So what we're doing now is we're moving away from just vibe coding and prompting Claude in the terminal to having a much more structured workflow.
[8:06]We're creating a new get branch so that we can track the changes. We're going to open a pull request so we have an audit log of what changed.
[8:14]This is just the development workflow you would use as an engineer working on any project.
[8:19]So now Claude is running the build step. If you remember in the workflow, we determined that every time Claude makes a change or it's going to open a PR, it needs to run the build command.
[8:29]As mentioned, you could run a whole bunch of automated checks here. You can make it part of your workflow, rather than relying on yourself to remember to do this.
[8:36]You can kind of encode it into Claude as a best practice. So now Claude is going to go ahead and open a pull request so that we can go and review the changes. It's even given us a link to the change, we can go and check this out.
[8:45]Okay, so now we've made the change. Claude has opened a pull request. We can review the code.
[8:52]This is again valuable. Maybe not for these smaller examples, but when you're working on a bigger feature.
[8:58]You can have a bunch of pull requests waiting for you to review. You can also run automated checks as well.
[9:05]I think it's important to verify the output of these coding agents. So you can run a bunch of automated checks against the code that they generate every time they open a pull request.
[9:12]Again, what we're really doing here is we're encoding a senior engineering workflow.
[9:17]We're not just vibe coding, we're not just prompting these agents randomly. We're following a structured workflow and this workflow will keep you sane as you work with these coding agents over the long term.
[9:26]So we can go ahead, we can review the changes and then if we're happy, this is a relatively minor change. There's nothing here that I need to worry about, so I'm pretty happy to merge this.
[9:34]But obviously if this was a bigger feature, the advantage of this workflow is you could have people review the code. You can look for mistakes, you can find issues.
[9:44]And if you do find issues, you can go back to the coding agent and they can repair those issues.
[9:47]Hopefully you'd agree that this is a much better workflow than just using markdown files or just prompting to delegate work to agents.
[9:54]We went from a feature description to a merge pull request, all tracked on one board. Agents help to every single step from planning to task breakdown to ticket creation to implementation and to code review.
[10:06]The idea here is that we're treating agents like team members. We manage their work the same way we would manage anyone else's.
[10:11]Through a board where everyone can see what's happening at a glance. When you're working on a large project with hundreds of tasks that need visibility, markdown files and vibe prompting don't scale, but a board does.
[10:23]And once this foundation is in place, you can go even further. You can run automated review on every PR. You can have agents monitoring the queue and picking up work on their own.
[10:32]The control plane is the foundation that makes all of this possible.
