My Workflow With AI: How I Code, Test, and Deploy Faster Than Ever

0:00[Music]

0:07Today I want to share my development

0:09workflow with AI. I want to share how I

0:12start working on new feature, how I

0:13manage product requirement documents or

0:15PRDS, how I write code and test it and

0:19how I move through the development life

0:21cycle. The way I approach all that today

0:25is very very different from the way I

0:28did all that in the past. There is a

0:30whole team working on each and every

0:33single feature with me being the only

0:37human involved. You will see a very

0:39effective yet very simple approach to

0:42development with AI. You will see a

0:44model, a few agents, one ID, several

0:47MCPs, and a lot of memories

0:50instructions. All of them combined into

0:53an effective workflow. You will see how

0:56I orchestrate all those with a

0:58relatively small number of instructions

1:00that expand into quite a few tasks

1:03executed autonomously. My motivation is

1:06quite selfish. I want to share with you

1:09how I do what I do in hopes that you

1:12will share with me your approach. I want

1:14us to learn from each other. All in all,

1:17I will share my AI based workflow and I

1:20encourage you to share yours so that we

1:22can learn from each other. How does that

1:24sound? You'll take a quick break for me

1:27to introduce you to Blacksmith, the

1:29sponsor of this video. Here's the story.

1:31No matter which AI agent you use, you

1:34will eventually push code to GitHub, and

1:36that will trigger GitHub actions that

1:38will build binaries, run tests, make a

1:41release, and do whatever else workflows

1:43normally do. That's where Blacksmith

1:45comes in. It makes your GitHub actions

1:48much faster and cheaper at the same

1:51time. And all you have to do is change a

1:53single line in your workflows. A single

1:56line for faster and cheaper workflows

1:58that make them run on high performance

2:00CPUs instead of GitHub's old servers. On

2:04top of that, they made significant

2:05software optimizations that allow you to

2:08get much faster Docker builds and faster

2:10colloccated cache. Unlike some other

2:13solutions you might hear about here in

2:15this channel, this one is truly a

2:17no-brainer. Sign up, add that single

2:20line to your workflows, and enjoy faster

2:22GitHub actions workflows at much, much

2:26lower price. Big thanks to Blacksmith

2:28for sponsoring this video. And now,

2:29let's go back to the main subject.

2:35Let's say that we would like to work on

2:37this project which happens to be a CLI

2:39written in Go that I use to manage

2:42videos in my YouTube channel. If you

2:43would travel back in time, adding a new

2:45feature to this project would typically

2:48start by someone deciding what the

2:50feature is and then writing a detailed

2:53product requirements document that

2:55contains all the information one might

2:57need to understand what's it all about,

2:59which technical decisions should be

3:01made, the architecture, all the tasks

3:03that might need to be done, and whatever

3:05else we might need. We could spend

3:07anything from minutes to days on the PRD

3:10alone before a single line of code is

3:12written. Once we are done, we would

3:14store that PRD in whichever issue

3:17management tool we might be using. That

3:19could be Jira. In which case, I would

3:21have to quit my job and move somewhere

3:23else. Since my relationship with Jira is

3:26the same as my relationship with the guy

3:28that bullied me in school, we'll use

3:31GitHub issues instead. So, let's do just

3:34that. Let's create a PD and store it as

3:36a GitHub issue, but this time with

3:38cursor agent. We'll start by instructing

3:41it to create a PRD. Currently, the

3:44project outputs on the screen

3:45information that the user should set the

3:47language of a video uploaded to YouTube

3:50manually. And I want language selection

3:53to be always set to English and set

3:55automatically when a video is uploaded.

3:58Just in case that memory is not working,

4:00we'll instruct the agent to use

4:02taskmaster to create that PRD. Now, to

4:05be clear, there's much more involved

4:07than that prompt. We'll see later how I

4:09instructed the AI to do everything it is

4:12and it will be doing. For now, the

4:15detailed PRD is stored as a GitHub issue

4:17and anyone can work on it. Quite a few

4:20actions were performed as a result of

4:21that prompt. Among other actions, the

4:24agent used taskmaster to create the PRD.

4:26I will not go into details of how

4:28taskmaster works here in this video

4:31since I already did that in the video

4:33over there. So, check it out afterwards.

4:36The gist is that taskmaster is one of my

4:38favorite MCP servers that handles tasks

4:40related to PRDS. It creates them, it

4:43breaks them into tasks and it

4:44orchestrates the work of coding agent so

4:46that all the tasks are eventually done.

4:49It's awesome. After the PRD was created,

4:52the agent called GitHub MCP to create an

4:54issue based on that PRD. That alone is a

4:56huge improvement. Gone are the days when

4:59we would spend more time wondering what

5:01the request to develop a feature or a

5:04bug fix is all about. The pd created by

5:07taskmaster was converted into a GitHub

5:09issue and the comment was added

5:11indicating that we started working on

5:14it. As a result that and all other

5:16issues in that report now contain all

5:19the information one might need. Having

5:22detailed information in issues was

5:24always always important. But now that we

5:27are using AI, it is essential. We'll see

5:31later why. Normally at this point, I

5:34would review that PRD and if needed

5:36provide additional instructions to

5:38fine-tune outcomes. No AI is perfect and

5:41trusting them blindly is not a good

5:44idea. At least not yet. However, for the

5:47purpose of brevity, I will skip that

5:49rule today. And you should not, and I

5:52repeat, do not take that as

5:54encouragement to do the same. Most of my

5:56time, however, is not spent on creating

5:59PRDs, but on implementing new features

6:01or fixing bugs. So, let's switch to the

6:04next phase and see how I decide what to

6:07work on.

6:11When I start a new session, the first

6:13thing I do is discover what the pending

6:16PRDs or bugs are and decide which one to

6:20work on. That's easy. All I have to do

6:23is ask the AI, hey, get PRDs. Thanks to

6:26the memory graph that we'll explore

6:28later, the agent understood that means

6:31that it should retrieve all the issues

6:33from GitHub and filter them based on the

6:36PRD label. The final result is the list

6:39of all the PRDs we might work on. Those

6:41were all created by Taskmaster, but this

6:43time they're coming from GitHub issues.

6:46Now, most of the time I do not know the

6:48details of a PRD. Even if I wrote it,

6:50I'm too old to remember it. So, my next

6:53step is usually to ask the AI to show

6:56the details of whichever PRD I might be

6:59interested to work on. That over there

7:02results in yet another trip to GitHub to

7:04retrieve all the details from the issue

7:07I referenced and output the details. All

7:09the details. Okay. And now finally after

7:12digesting the PRD I prefer checking how

7:15hard will it be to implement it. Quite a

7:17few things over there need to happen for

7:19it to analyze the complexity. Among

7:22other steps the AI has to figure out all

7:25the tasks required to complete the PRD

7:28and use that information to calculate

7:30how complex it might be to implement it.

7:33In this specific case, there are 20

7:36tasks in total, and many of them split

7:39into subtasks. There's 88 of those. With

7:43the system I'm currently using, that

7:45would probably be a couple of days of

7:46work, maybe a week. Not today, though.

7:49Today, I expect it to take a few hours

7:52in total. It could probably be done in

7:54half an hour, but I prefer taking it

7:57easy and reviewing each step of the

8:00process that is about to start. Still

8:02moving from a week of work to a few

8:05hours is quite an accomplishment. From

8:08here on I could repeat the process and

8:11explore other pods or I could work on

8:13that one. And that one we just explored

8:16seems fun to work on. So I'm ready to do

8:20some real work.

8:24It took the AI a few moments to organize

8:27everything. It gathered all the info it

8:29needs and generated whichever resources

8:31it needed to be generated. Once it

8:34finished the preparation, it suggested

8:36that I should work on the first task.

8:38Recommended that there should be five

8:40subtasks and ask me whether I want to

8:44expand those subtasks. Most of the time

8:47my answer is just do it. Which results

8:50in creation of those recommended tasks

8:52through taskmaster connected to entropic

8:55sonet model. This is when it truly

8:57starts. The agent sets the first task to

9:00in progress. Then the first subtask also

9:02to the in progress status and starts

9:05writing code and tests. Next few hours

9:08is spent on AI working on each of those

9:1188 tasks and me correcting it and

9:14providing more information. Think of me

9:16in that process as a code reviewer and

9:18AI agent with everything else I set up

9:21as a developer. It is effectively doing

9:24the same job I was doing before and

9:28probably disliking me just as much as I

9:30disliked people who were reviewing my

9:32code in the past. Probably. Now, I will

9:34not bore you going through all those few

9:37hours of work. So, let's jump to the end

9:39of the process.

9:44One might think that after we're done

9:46with coding, we're done working, right?

9:49I'm sure you're not one of those. There

9:51are quite a few other tasks we might

9:53need to perform once the code is done or

9:55to be more precise when we think it

9:58might be done. We should create a branch

10:00if we haven't created it already. Push

10:02changes to it. Create a pull request.

10:04Ask someone to review those changes.

10:06Implement suggested changes. Approve the

10:09PR and merge it to the main branch.

10:11Delete both local and remote branches.

10:13Execute CI/CD workflows that will do

10:15whatever workflows do and potentially

10:18quite a few other tasks. In the past,

10:20all that could be time demanding and

10:23maybe even considered chore, a waste.

10:26Not today. Today, all I have to do is

10:29tell the AI that we are done. As a

10:34result of that single sentence, the AI

10:36agent, the model, a few MCPS, and most

10:39importantly, instructions I stored in

10:41agents memory kick in and start the

10:44final process. During that process, the

10:46current status is checked. modify the

10:49new files are staged. New branch is

10:51created. Staged commit is pushed to it.

10:54A PR with all the details is created.

10:56Code reviews done by multiple other

10:59agents are performed. And I'm presented

11:01with findings. From there on, I can

11:03choose to implement suggested

11:05improvements and fix the issues that

11:06were detected. Once I'm done with that,

11:10the process continues. The PR is merged.

11:12The branches are deleted, temporary

11:14files are removed, and I'm done. Unless

11:17the workflows that are triggered notify

11:20me of another issue, something else. By

11:22done, I mean that it is built and tested

11:26and released, and the tag was created,

11:28the application is deployed, and

11:30whatever else my workflows might do.

11:33Now, I probably missed to mention all

11:35the tasks that were performed. That does

11:37not matter. What matters is that all

11:40that is done exactly the way I want it

11:42to be done and all I had to do is tell

11:45the AI that I am done. AI did not do

11:50what it thinks it should do but executed

11:53the tasks that exactly reflect my

11:56process and my way of working. It's

11:58awesome. I'm done. That PRD is fully

12:00finished. And the only question left

12:02unanswered is how did all that happen?

12:08Everything I did today might sound

12:10complicated to set up. Everything we saw

12:13did not happen by using cursor or any

12:15other AI agent out of the box. This is a

12:18custom solution. Yet, it is a solution

12:21that is very easy to set up. It's a

12:23recipe with the following ingredients.

12:26We need an LLM model, an ID, an agent, a

12:29few MCP servers, and quite a few

12:32memorized instructions and processes.

12:34you're already probably using LMS and

12:36ID. So I will not go deeper into those

12:38except to say that right now I prefer

12:41using either Google Germany or anthropic

12:43cloth sonet models and that my favorite

12:46ID is cursor that already comes with an

12:48agent. You might have made different

12:51choices and that's fine since the rest

12:54of the setup works in more or less any

12:57combination. Next there are MCP servers.

12:59So let's take a look at them. Unlike

13:01some other projects I'm working on, this

13:03one uses only four MCP servers which in

13:06my opinion are essential. The most

13:08important one is memory which contains

13:10all the instructions agent needs to

13:12understand my way of working. That's how

13:15for example it knows that it should

13:17execute a bunch of tasks when I said

13:19that we are done. Now to be clear, you

13:22do not necessarily need that MCP since

13:24most agents are capable of managing

13:26their memory. I prefer that MCP since

13:29agents are changing very fast and I

13:31often switch from one to another and

13:33while doing that it is important for me

13:36to keep the same memorized instructions.

13:39If you opt for built-in memory that

13:41might require conversion from one format

13:44to another and then comes context 7

13:46which provides up-to-ate documentation

13:48from thousands of projects. Further on,

13:50there is taskmaster AI which manages

13:52PRDS and orchestrates the agent to work

13:55on tasks that constitute a PRD. I

13:59extended Taskmaster's capabilities to

14:01additional instructions stored in memory

14:03mainly focused on using GitHub issues

14:06instead of local files. Finally, the

14:09last MCP is GitHub which enables

14:12interaction with as you can guess

14:14GitHub. Logical, right? that one might

14:18not be necessary since agents are

14:20perfectly capable of using GitHub CLI.

14:22Nevertheless, MCP tends to work better.

14:26So, there it is. I will not go into

14:28details about those MCPS since I already

14:30explored them in those videos over there

14:33somewhere above my head. If you feel

14:35like using the same MCPS, you can just

14:37copy and paste the JSON from the output.

14:40The main and probably the most important

14:42part of my setup are entries inside the

14:44memory MCP. So let's take a quick look

14:47at those related to PRDS. Not to all of

14:50those, only those related to PRDS. There

14:52are currently 17 memory entities related

14:55to PRDS. There are instructions what to

14:57do with pull requests, code coverage,

15:00testdriven development, PRD handling,

15:01and so on and so forth. It would take

15:03too much time to go through all of

15:04those. AI should have created a separate

15:07JSON file with those so you can explore

15:09them on your own. Just do it later. Now,

15:12you're free to use them, but I advise

15:14against it. Use them as inspiration, but

15:17create your own that match the way you

15:20work. If you do that, do not overthink

15:22it. Do not try to capture everything at

15:25once. Instead, I suggest to keep

15:28updating it while you're working. That's

15:30at least what I do. The moment I notice

15:32that the agent is doing something I

15:34don't want it to do or doing it in a

15:37different way than how I like to work, I

15:39write a prompt that says, "Update your

15:42memory with this and that." whatever

15:44this and that is. Similarly, if you know

15:46that there are processes you execute

15:48often, instruct it to memorize them and

15:51associate them to a sentence like, hey,

15:54memorize that when I say that we are

15:56done, you should do this and that,

15:58whatever this and that is. The last

16:00component is the least interesting since

16:02everyone is almost certainly using it.

16:04There are workflows that are executed as

16:06a result of creating a pull request or

16:08merging it to the main branch. In my

16:10case, those workflows are defined as

16:12GitHub actions. Now, this is not a video

16:15about workflows, so I will not go into

16:17that workflow or any other mostly

16:19because it's boring. The last part I

16:22should mention is the very beginning of

16:25each of the sessions I start. The first

16:27thing I execute is always the same. It's

16:29retrieval of the entries from the memory

16:32graph. I do that by executing custom

16:34cursor rule. That way, every time I

16:37start working, I know that the agent

16:39gets all the instructions I assembled

16:41and stored in the memory MCP and follows

16:43them depending on what I instructed to

16:46do. If you want to take a look at that

16:48rule, here's how it looks like. It is a

16:50simple one that instructs the agent to

16:52retrieve and process all information

16:54from the memory MCP knowledge graph to

16:56guide our session. If you're not using

16:59cursor, other agents tend to have

17:01something similar. For example, cloud

17:03code has custom commands. So you should

17:06be able to do something similar no

17:07matter which agent you are using. And

17:11that's it from me. I shared one of my

17:13workflows today. That was development of

17:16an application. But there are others. I

17:18have similar yet somehow different

17:20workflows for managing infrastructure.

17:22Another one for operations and so on and

17:24so forth. Now it's your turn. How do you

17:26do whatever you're doing? Please share

17:28in the comments. Thank you for watching.

17:30See you in the next one. Cheers.