AI-First Project Management for Developers | Alex Gavrilescu on Backlog.md

7,812 words · about 31 min to read · YouTube’s automatic captions

Autonomous AI coding requires precise markdown specs

0:00 One very important thing that I noticed when working with AI is that even if you give enough context for an AI agent to work on a single task, they still have no idea about your project. And backlog MD was basically my trial of AI and like a challenge for myself to really try to be as autonomous as possible and try to let AI code 100% of the time in my tasks. And by doing this, I realized the most important part are the specs. And so backlog creates the specification about the task which is essentially the information in that task that it can be used as a spec for an agent to implement that change would you say?

0:36 So I start code or codex and they tell these agents hey I want to build this feature use backlog and this CLI to keep track of the tasks and to split it into multiple subtasks. Before we jump into this episode, I wanted to let you know that this podcast is for developers building with AI at the core. So whether that's exploring the latest tools, the workflows, or the best practices, this podcast's for you.

1:07 A really quick ask, 90% of people who are listening to this haven't yet subscribed. So if this content has helped you build smarter, hit that subscribe button and maybe a like. All right, back to the episode. Hello and welcome to another episode of the AI Native Dev. And you may hear in the background there's a bit of noise. We are at uh Devox Belgium and joining me is Alex Gabriellescu. Um how was my how was my pronunciation? We were saying just off off air. It was a very British pronunciation.

1:36 Yeah, this is the most British pronunciation of my family name I ever heard. I like it. Yeah, it's

1:41 We'll take that. We'll take that. So, Alex and I are both at uh Deox Belgium as I mentioned. And by the way, uh uh about probably about 3 4 weeks ago, uh we released an episode with uh Stefan who is the the chief head god of of DevOps. And um I am happy to say his app is working perfectly. Um if you did watch that session, it was a very much a vibecoded application and he was a little bit worried. We were a little bit worried like oh my gosh, this is it's very vibe coded with specifications. But there's only one real test and that's at a conference at DevOps to test it out and

2:17 it works.

2:18 It's perfect. It's working very very well. So well done Stefan. So yeah, we're talking a lot about specri development uh here at Deox and and Alex um first of all tell us a little bit about yourself cuz I think some of the things that we're going to talk about with with backlog and things like that is very much is very much kind of in you know built in a in a in a spec driven mindset uh in terms of in terms of going forward. So tell us a little bit about yourself, a little bit about Batlog MD.

2:44 Right. So I'm a lead engineer in Vienna for a gaming company

2:48 and I'm coming from an agile environment. to using scrum uh having all the requirements with PS uh thinking ahead few months uh ahead with all of the features like really thinking them through and then there is the coding part and right now everything happens like uh between humans so it's uh uh no AI no nothing just classic development uh we have a backend team we have a a mobile uh development team so they all collaborate together. Uh this is uh what I'm doing during the day, but obviously in my free time I'm trying to learn as much as possible about AI and trying to keep up to date with the latest trends.

3:32 And uh backlog MD was um basically my my trial of AI and like a challenge for myself to really try to be as autonomous as possible and try to uh let AI code

Vibe coding fails due to context loss

3:47 100% of the time in my tasks. So um what was the reason why I started building backlog MD is uh I started with side projects. I started working with AI. I was just prompting prompting all the time and I was just getting really bad results. So I was basically doing VIP coding and then I realized how what successful uh processes I use at work that make makes the collaboration between humans uh effective enough to to uh build successful gaming features and then I try to learn from the human

1 Highlight · Specs are the most critical part of AI coding

4:25 process and try to adapt it to AI and by doing this I realized the most important part are the specs. So everything starts with specifications, requirements, not just about the feature you want to build but also everything around it like security specifications um CI/CD specifications like just the language that you should use like C#, TypeScript, Java, whatever language and you should have all of this context uh right before you start. So in order to be really successful with your task.

5:01 Really really interesting. Let's just

5:02 break that down a little bit. So, so you you were doing a lot of vibe coding. What typical tools were you using for vibe coding?

5:09 Um, cloud MD um um code.

5:14 Yeah.

5:15 So, so and and what were the what were the ex what examples of that those problems did you did you kind of hit in cord code? So the problems were uh like a single single task problems that would uh repeat themselves on every single task. So what I want to mean by this is uh I tell the agent to build a certain feature and he reached the goal

2 Highlight · Why vibe coding sessions fail to scale

5:42 and he managed to build this feature but by uh going back and forth on on a lot of things and with the next tasks I would repeat again the same same instructions and I would stumble upon the same issues again and again and again. This is the problem with vibe coding. Basically, every time you have a new session with your agent and you try to build as much as possible within your context window.

6:07 Mhm.

6:07 And this doesn't scale obviously.

6:09 Yeah. And as soon as you close that window, context is lost, you have to build that up again in your next window.

6:16 Exactly. And maybe you forgot the instructions that you told him to

6:19 prevent certain issues and you have again the same

6:23 problems. and a lot of the things that you mentioned that you would put into specs like security considerations and things like that. How would you describe those needs to your vibe coding tool?

6:34 Yeah. So obviously with vibe coding you um can like do a lot of damage. You can deploy some some changes some patches to production that actually break things. Um and you need guard rates, but you need these guard guard rates also with humans like the we we all use specifications about uh security and measures that check check uh points for example like staging environment to test all of these measures to to prevent issues and with VIP coding suddenly everyone forgot about them.

7:10 Yeah.

7:11 So what did then you kind of like

Splitting giant markdowns into atomic tasks

7:12 mentioned you you moved more into the spec environment. Tell us a little bit about that. Yes. So I started creating markdown tasks manually. Actually before that I started creating a huge markdown with all of the specifications and all of the features that I wanted to build. Uh the problem with that it was a a huge context and I would uh immediately inject this context uh into the model and uh the agent with this model will maybe be effective maybe not and I will not have uh good success rate and sometimes I will have to roll back but it would be very hard to roll back a whole product or a whole feature

7:49 and what's interesting there is you're nowhere near the context window you nowhere near the the the maximum context size. Yeah,

7:56 you're just hitting that mark whereby the results based on the amount of context you provide degrades massively significantly from from that.

8:06 Yes, the the this agent have um feature called compaction.

8:11 Uh this basically tells the agent to make a summary of all of the previous conversation and start with the minimum context from that summary. But the problem is that the instructions that are contained in the summary are half of the ones that you instructed him initially and um you have to um most likely start from scratch again because you don't know what he he misses.

8:36 Mhm. Okay. Okay. So what was what's what's next in the in the spect?

8:39 So what what was next? The immediate next step was to split the big markdown file into smaller tasks. So I would have similar to how you have in uh Jira or in Lina or other project management tools single tasks that uh just define what has to be built. And I basically translated this into markdown files because markdown is a universal language that is plain text with formatting uh that both humans and agents can uh understand very well and agents were actually more effective and I could easily roll back single tasks at the time. And you did this manually or you did this with

9:18 Yes, at the very beginning I was creating manually and I uh when I reached around 50 manual created tasks I I was uh like any power software engineer I would try to automate this. How can I automate this manual creation of tasks? So I build backlog MD for uh enabling this and have an easy way to create task by uh using your terminal.

Using Backlog.md entirely via the terminal

9:42 The best way to learn about it is to see it right. Should we uh should we take a look at a quick demo of backlog?

9:48 Uh sure.

9:48 Talk us talk us through it.

9:50 So the first thing that you will do with uh to even run backlog you would have to install it.

9:55 So you can use banan you can use mpm or brew uh and you should install it globally uh in your computer. Why globally? Because then you don't have to install it in every single project that you're using and you can immediately use it in every folder. So this is going to take few seconds and

10:16 even on conference Wi-Fi just

10:18 yes exactly

10:20 uh this is because ban is very fast on installing dependencies.

10:24 Mhm.

10:24 And afterwards uh you can run backlog as as this no other instructions. This is going to give you some uh some initial hints what you can do with backlog. So you can see here you can create tasks, you can list the tasks, you can see the board. I will uh show it very quickly. You can also run a browser and again I will go in detail about this and an overview that shows what the statistics about your project. How many tasks are finished and how many are remaining and the link to the docs. And the next thing to to do normally you would want to create tasks but because this is I'm running backlog inside the backlog project and I'm using backlog to keep track of the tasks for backlog itself I already have hundreds of tasks. So let me show you how it looks the board.

11:15 So backlog uh gives you a component board

11:18 that is configurable with how many statuses you want. So the default ones are to do in progress and done. And here you can see what is going on in this project. And all the tasks that you see here are in sync between multiple git branches. So backlog uses natively git to fetch information from other branches. So if you work with other people uh as long as they push uh the changes on a task. So for example, I take over task 200 and I assign it to myself and I put it in progress. as I make a push on my featured branch, you will see it also in your backlog instance on on the main branch for example. So this is also nice to to use it as a collaboration tool.

12:00 And can you filter based on branches and things like that here?

12:03 Uh so uh the the logic behind it is it's a bit hidden from from the developers. Y

12:10 uh backlog should be smart enough to find what is the task with the latest updated date.

12:15 Nice. And that means is the the mo the newest state. Obviously, if you change a task um by mistake, this will trigger uh that that task is the late has the latest update version. But in normal use cases, this should not happen. Gotcha. Okay. And what you can do from here, you can find the details of the task. So for example, uh let's see one uh task that I would like to build next. Um this one. I press enter and I immediately see the details of the task. So what I would like to have in the near future is drag and drop in the terminals.

12:53 Yeah.

12:53 So like you do in J you drag your task from uh to-do to in progress. I would like to achieve the same in in the this can come board. So this is the task for that feature is not implemented yet. It's in to-do. And what we can see here are the task ID, the title, some metadata about the task, some dependencies because backlog also supports dependencies that basically um prevents the the agent to work on tasks which are not ready to be started. So this is also important um in a specdriven development. We have a description that basically tell us why are we even doing this feature. So adding the drag and drop functionality uh uh using shift plus arrow uh will allow the users to to not leave this terminal interface and to change the progress very easily. So this is very nice from a user perspective. And we have some acceptance criteria which are the core of backlog. Basically the acceptance criteria is something that

13:57 can be testable, something that can be easily verified and measurable and uh basically represents the increments of imple like the smaller increments within this single task.

14:09 Mhm.

14:10 And whenever an acceptance criteria is done, it will be ticked. So I will show you very soon how that looks.

14:17 Uh let's open a task that has been completed. Um this one for example. So you can see the status is done.

14:25 Uh it has been uh taken over by openi codeex. Uh also another feature uh uh about backlog is labels. So you can label your your tasks and filter um later uh by labels. And here we can see the acceptance criterias are all obviously implemented. We have here an implementation plan. Uh I will talk about uh the implementation plan a bit later but it's part of the spect development. You always want to uh ask the agent how he would like to develop this task and then you review and then at the end we have the implementation notes which are sort of um permanent context what has been done in this task. So if for any reason human or an agent would like to see what happened in this task, they would read implementation notes and have this permanent context about it.

15:19 Yeah.

15:19 So yeah, this is uh the primary interface. We also have a task list view uh which is this one. Here we have just a a long backlog of tasks. Uh we can also um check the details and if it's longer scroll. We can also search for tasks. So maybe let's find tasks about tailwind. Uh yeah, this this one uh there is no task actually about tailwind but anyways

15:56 um you we can also filter by status. So to-do done in progress uh priority again. So, this is also like a second command panel where you manage your tasks.

16:09 Yep.

16:10 Um, and that's basically it for the UI. Um, we also have a web interface.

16:16 Mhm.

16:16 Uh, for people that like to have more uh um visual uh guey for for interacting with task. We also have a plane mode for AI agents. Let me show you that one because I think it's more important. So for example uh we were looking at task 200. So backlog task 200 minus minus plane.

16:42 This will show the same information but in plain text. And this is what agents should use.

16:46 Yeah. Yeah. Yeah. I see.

16:49 Yeah. Okay. And and so let's talk a little bit about I want to kind of talk a little bit about the way in which so you mentioned you built this a lot through specifications and things like that. How did you go about building those specifications? Did you use a tool? Did you handcraft the specifications yourself? How did you how did you deliver that to them?

17:08 So it that's quite interesting because the first tasks I created manually. So this kind of format I came up manually by creating them myself.

17:18 Mhm.

17:19 And after four or five tasks I already had backlog CLI command to create tasks. So afterwards I just recursively started using backlog to manage tasks about backlog.

17:30 And so backlog creates the specification about the task which is essentially the thing or not necessarily specification of the task but the information in that task that it can be used as a spec for an agent to um is it to implement that change would you say?

17:43 Uh so yes and no. So backlog itself doesn't create specifications. So backlog is a tool that AI agents use

17:51 but it's not calling agents. is not connected to AI agents by by default. So you would have to start the flow this way. So I start code or codex or jamina CLI and I tell this agents hey I want to build this feature use backlog MD CLI to keep track of the tasks and to split it into multiple subtasks.

18:14 There are some agents uh instructions that come with backlog that tells the agent how to use backlog itself. So afterwards the agents will know how to split a bigger task that you have in mind into smaller tasks that fit backlog.

18:29 But backlog itself

18:31 uh it should be as minimal as possible and should not be in the way. It should be sort of a tool that both the human and the agent use on the side when gotcha. So so it's claw that kind of like determines the split almost and then adds that into into

18:44 back. I see. Cool. Um so let let's talk a little bit more about that in in in in terms of how you would use backlog with AI tools. Um is it when you say Claude will use uh backlog is it using it as a CLI and using bash is it using it as a MCP server? Uh so for the moment we only have CLI.

19:08 Okay.

19:08 So uh the agent instructions that ship with backlog um let me show you uh how you would configure this. When you initialize backlog on a on a project uh you will run backlog in it. You would put the project name and here the most important part of using backlog is to choose the agent instructions for the agent that you're using. So if you're using cloud you would use close cloud MD or now agents MD is becoming a standard.

19:33 So once you select one or many agents, backlog will create this file or append to an existing file if you already have it all the instructions how to use backlog. So it will tell cloud when the human asks you for creating a task you should run backlog task create. When the human asks you to edit a task, you should run backlog task edit and so on.

19:55 Mhm. Awesome. And so it adds that into the agents MD or the cler it automatically knows when starting this is how it does it. This is what it should do. Awesome. And I think you mentioned before there was an MCP server on its way.

20:06 Yes. So uh I didn't start with MCP connection uh at the very beginning because when I started with the backlog in June uh the support was still um not there for a lot of agents but recently MCP is getting more and more momentum and they want to also add MCP support backlo. So in the next days we're going to probably see it uh live.

20:29 Amazing. Amazing. And given that we're probably going to be releasing this next week,

20:32 yeah,

20:33 could even be there right now. So do check that out on the on the backlog on the backlog tool. So yeah, there's I guess there's, you know, Claude and other agents can use backlog to, you know, break down tasks and add them into the backlog, but also of course it's quite proficient as a coding agent. Um, it can go ahead and take tasks off. And I think one of the tasks that you did see then was potentially even worked on and and completed by Claude. So

21:00 it could effectively do some work, update the tickets.

21:04 Yeah.

21:05 Maybe something very important that I didn't mention is that backlog's code was written 99% by eyes because this was my initial challenge.

21:13 Yeah.

21:13 And the only info uh files that I wrote manually were the agent instructions. So how to use backlo obviously

21:22 but afterwards every single line of code was um written by AI. So backlo code is really really AI specd driven AI developed.

21:31 Amazing. Amazing. Cool. Let's talk a little bit about um a key piece here which is context. Um obviously there's the right amount of context that we can provide agents. If you you provide too little it won't have enough to do a job effectively. you can provide too much as you mentioned and it degrades. There's that goldilock zone of context. A lot of context engineering has gone into Battlelog MD. Talk us through some of

Onboarding agents like human teammates

22:01 the kind of I guess the the areas that you felt pain and some of the key decisions that you made.

22:05 Yeah. So, let me start with comparison with how humans work because I think there

22:10 is also not very straightforward. So uh I at work I me and other developers struggle sometimes to um break down a bigger feature in smaller tasks. And what happens for a human when uh you don't break it down correctly and then the scope explodes basically you

22:30 uh have delays uh the then you rush and then you have a lot of technical depth to to solve later. So for humans this is also a big issue but for agents it's even more of a problem because the agents are uh sort of like humans that you hired 5 seconds ago

22:47 and you have to give them enough information for them to immediately start working on a task which is something that you would normally not expect from any any human without proper on boarding. And this is basically what um software engineers in the next uh upcoming months will have to learn more and more when dealing with AI. So how can I give as much information as possible about the software that I'm building and the task itself so that the agent will work as a as a human uh teammate.

23:19 Mhm. And

23:19 so how did you what was the balance that you struck in terms of too much or too little? So I was um struggling a lot to tell AI agents how big a task should be. And then I had um a sort of like a a

3 Highlight · Letting Claude determine atomic task sizes

23:35 magic um how can I say it? It was uh unexpected.

23:41 Mhm.

23:41 Uh that I told uh Claude, hey Claude, break down this feature into smaller task that can each of them can fit in a good PR.

23:50 Okay. And while for me a good PR is very subjective, cloud immediately started splitting them in the most atomic tasks that can implement the requirements without blowing the scope. That's really interesting. So the you know when we think about breaking tasks down, what we might consider it is

24:11 breaking it down into into into bite-sized chunks that we as people could would think this naturally fits together. But what you're saying there is Claude breaks it down. Perhaps it does it similarly, but it it it maybe more intentionally does it whereby those are consumable pieces of change that it as a as a as an agent can actually capably deliver.

24:37 Yeah, I think this is because uh the training data that they have been trained on. So probably they've been trained on a lot of um repositories and a lot of PR especially from GitHub and there they could see good examples of how much it can fit in a good PR that can that doesn't have a lot of comments and it's merged as quick as possible without issues.

24:59 So if I was to say look I've got this feature I would go over to Claude and say break this feature down and add a bunch of stuff into backlog. Um and it would then break it down, add it to backlog and then you would say right can you go ahead and start working on these ones? How would what would the next step be beyond beyond that?

25:16 Obviously you would have to review these tasks.

25:18 Okay.

25:19 Uh the the human in the loop is is essential at this point in time. Um and actually the human in the loop is important right before starting the task. So not in in my uh in my experience the the coding part is always done well if the task and the specs are uh well described.

25:40 Yes.

25:41 So what I'm putting a lot of effort and I'm trying to not become lazy is to really review every single task.

25:48 Mhm. And then I will ask the agent to come with an implementation plan because this is also what humans do and what some humans do and what I like to to have in my team to if we want to build a feature together, we will create an implementation plan and agree on it or maybe review it and uh build this architecture at least on the paper together and then someone will implement it and this is how I effectively work at uh team. Well, how automatable is the uh

Evolving from multi-agent chains to unified models

26:18 is that process? Can you have you tried using LLMs as a judge or using different models to critique almost the the breakdown of various tasks?

26:29 I think this is changing a lot. So between when I started working on backlog and today

26:35 uh few things have changed. So before I would really use um one agent for creating the tasks,

26:41 one agent for creating the implementation plan and another agent for the execution. So three a sessions with different context window that that they're not biased between each other.

26:51 Yeah.

26:52 Right now models are becoming better at following a lot of instructions. So at least the task creation and the implementation plan could go together or the implementation plan and and execution do go together. uh but I don't use specialized agents um to as of today anymore because I feel with the latest models that are available today this is uh the results are good enough

27:17 yeah sounds good let's talk a little bit about what could be done with AI what couldn't be done with AI obviously the whole thing was built with AI under your guidance so

27:26 right so disclaimer uh backlog doesn't have a production database it's not hosted online doesn't have any login for user information. Uh I I was um

27:39 because the data because the data exists in git repos.

27:42 Exactly. All of the tasks are stored in your git repository and uh you can use git security to to enhance the security. So I I don't have to deal with this part.

27:52 You're just using the whole of GitHub as your database. That's what you're doing.

27:55 Uh GitHub or any other Git provider

27:57 or any other Git provider. Yeah.

27:58 So they implement the security for me. So

28:02 um so I didn't have to face serious production issues as I would do in my normal job.

28:08 But I think this is a big limitation right now and the next steps would be like how we can effectively do security reviews um performance reviews um yeah and this kind this kind of like guard rails for to production uh application.

28:27 Yeah. And and from the point of view of AI, you know, actually using backlog MD, I guess how much would you say AI empowers the usage of backlog uh MD because it sounds like using something like Claude really unlocks the full features of that autonomy of breaking tasks down, throwing it into Batlog MD, and the terminal bases, the the the CLI based usage fits so well with the terminal UIs of of these agents. Yeah, I usually just have two tabs. One for the execution of the task or task creation and one

29:02 look what is going on.

29:04 Uh and I don't have to leave the tab. And this can also run in a sandbox machine

29:10 uh without any GUI or any uh uh any browser. Uh we can just SSH into into a virtual environment and there we can run backlog and cloud.

29:21 Yeah. Would you find backlog MD useful if it wasn't for AI agents like Claude in terms of using the the UI?

29:31 So, uh I heard lots of people um using it successfully

29:37 uh for not AI tasks. So, they create a task uh manually from the web interface.

29:42 Uh they manage them. they they um basically have a Trello but that just works with the Git repository and backlog and DS CLI installed on their computer. That's it. And they don't have to

29:54 think about hosting. They don't have to think about uh creating accounts or anything else. It's it's very simple. So there are some use cases where backlog actually can be used outside of AI.

30:05 Yeah. But yeah, I think this uh stronger points are when when you need to really break down a big feature with in smaller context windows.

30:15 Yeah, we we here on the podcast and at Tesla and hearing a lot about it here at the conference as well, we love to use the words AI native and similar to cloud native, it's really about rethinking how we would go ahead and change our processes, change our tools, change our way of working. um using a technology as a first class citizen. So using a

Agile frameworks must adapt to infinite bandwidth

30:38 technology natively in your in your organiza in your in your ways of working. So when we look at some of the if we was to redesign how we how we use uh well how we develop software like our basic processes and things like that um how does an agile workflow do you feel change with you know these new cool AI development processes and tools? So I think agile frameworks um the the ones that are built today are built mostly for humans

31:11 and they don't fit very well for AI agents or the whole AI native world.

31:18 Uh but I think agile itself it's a very very important way of of working. If you look at the core principles of agile, uh they really allow you to build solid software maybe that you don't know exactly how you will end up building it at the end because that the whole point of agile is to steer it to uh review to have some stakeholder communication and those are core principles are there to stay. Um we we need to empower these core principles and connect them with AI. uh what I see um not being so important in the future is like the bandwidth calculation that comes from certain

32:00 uh scrum processes because with AI we have virtual infinite bandwidth

32:05 and this is this is a big change that the companies will start to uh look into and try to find a solution for it because if now we have sprints and we try to understand how much we can fit in a twoe sprint in the future you can have AI agents working the whole night and can burn through five sprints until the morning. Given that

32:26 they have this automatic review steps. So I'm not talking as of today but maybe in few months from now this is going to be a challenge that we need to solve.

32:34 So what is that bottleneck now then that's stopping that is that like you say the fact that we're doing

32:39 in that world it's automated code reviews. Today we don't have that. Is it still that human uh human interaction that is the bottom?

32:46 Yes. Currently as of today this is the biggest bottleneck. So a human has to tell that a certain task is done successfully and it really implements the specs even though um if the specs are correct using in my case using backlog the implementation is also uh most of the times going to be successful I still want to review it at least one time and

33:10 I don't see right now a moment where you can reliably have an automated review process and automated merging into your main branch and then you can say okay now we can deploy this to production I would myself not feel confident enough for such thing but

33:27 assuming that the review steps security uh performance quality all of these things will be automated then the next big bottleneck will be conflicts

33:38 uh and by conflicts I mean not just like merge conflicts but really uh building a product uh requires you to start building the fundamentals then you build layers on top of layers and then you have the final product at the end. But each layer is dependent on previous layers

33:54 and we have to bake this into the AI flow

33:57 where the agents can first of all not clash into each other and second they know they have to wait for certain things to be ready in order for them to start. M

34:06 and once you automate also this part then you really have a product that you once you give all the idea and you verify that idea is what you expect you let them run for hours days maybe even weeks fully automated.

34:22 And what does a it's interesting what does a retro look like? Is it is it do we do a retro with agents? Do we have a agent retro or do we have humans trying to give feedback? We kind of have the the agent retros right now. They are called agents MD or cloud MD. I think those are the closest thing to to human retros. So basically

34:44 you finish working on a task using backlog or any other tool. Then you realize you stumble acu across some patterns some negative patterns that you want to avoid in the future. So what you normally should do go to your ampd instructions say please don't do it like this or do it like that and try to prevent these issues from happening again. So the the retro in the sense of looking back and trying to do more of what went good and do less of what went bad

35:13 exists

35:14 more or less with this agent instructions. But if we have to think about more structured process where humans and AI agents are looking together what went wrong in in a certain product, I think there's still room to to implement. And also what is probably missing right now is let the agents see the final product.

35:36 Yes.

35:36 And this is where the retrospective is really effective. So we together as a team we need to build a big product and this is how it looks and this is uh how users are using it and we did a good job or a bad job implementing these features and this is missing right now

35:54 and and that's key there. The the thing that you said there about users giving their feedback after something's happened. Sprints are a nice kind of these sprints are nice because maybe you do some work for a week or a couple of weeks, you give it to someone, you get some feedback and actually in the time you're getting that feedback, it's not like you can accelerate and you know do three four time 4x the amount of work and keep adding.

36:16 So if we can develop and deliver so fast, is there a risk and what is that risk of us being able to deliver faster than people can consume it and people

Disposable software changes rapid prototyping

36:27 can give good feedback? Is is that is that a risk or is that actually something that's very easily fixed because well

36:36 building is cheap now if we make a mistake we roll back quite quickly and you continue to build. Yeah, I totally agree with uh with you on this and uh I heard the story at one of my Vienna meetups from a guy that is a plumber and he doesn't have coding experience and he vibe coded a small application to calculate the the measurements for the tools that he have to use and how to be a good plumber. and he said he got a quote for a few thousand euros uh from a software developer for a thing that he built himself in a couple of days by by coding.

37:10 We're in we're in trouble cuz if plumbers can vibe code, I can't I can't do plumbing. We're in we're in trouble, Alex.

37:18 Yeah. So, I think uh what we're going to witness in the next months is also um sort of a single use software.

37:28 Yeah. Maybe like a usable disposable software disposable software.

37:31 Yeah. Everyone can just implement small and medium size applications and they can use them once and

37:38 maybe they're not necessary afterwards. So they don't have to even have a production quality.

37:44 So it's almost like prototyping change,

37:46 being able to say, "Hey, here's a here's a here's closer to the main vision. Play with it.

37:51 Let me know what you like and dislike." And of course, I can just spin up, you know, parts of those changes in my new version. maybe change it a little bit more. So, it's a maybe more about using that using that that speed of development to create pro like more fullyfledged prototypes that we can then actually test on folks rather.

38:09 Yes, exactly.

38:10 Very interesting.

38:11 One one very important u thing that I noticed when working with AI is that even if you give enough context for an AI agent to work on a single task. So you put all the information that is necessary to start that at least will be necessary for a human.

38:27 They still have no idea about your project like effectively they start reading the files that they have to modify when they start working on the task.

38:36 Yeah.

38:37 And by the time they are done that's the moment where they really know

38:41 almost everything about how the task should be done. But the task is already finished at this point.

38:45 Yeah. So maybe what we're going to see from now on is I do a quick prototype, a quick run, let the agent ingest all the context, not just from me, but also from the co code itself automatically

38:59 build it, throw it away and if we still have context window, we start from scratch in a clean architect to a clean um like domain driven design really nicely done and maybe this result is going to be better on the second try.

39:15 Right. Right. Interesting. Let's trigger people. Alex, you ready? Are you ready to trigger the audience?

39:20 Yes.

39:20 Let's trigger the audience. Does Scrum even have a role in this future?

39:26 So, this is a tough question. Uh I know a lot of people are putting a lot of effort into becoming uh good scrum masters, good agile coaches. And while this is very important when working with humans, we really need to think at refactoring the processes the way same way you refactor code.

39:48 So when you refactor code, you don't throw away everything. You just look at what's working and try to improve it and to streamline it and simplify it. And this is what we need to do also with scrum or all all these agile processes that are built for humans to work in a certain way. But now suddenly we have infinite bandwidth. We have different processes like we said like different uh deliverables checkpoints where the humans have to review this and it has to be much much faster than waiting two weeks to have the uh the scrum review where we present the the output to the stakeholders.

40:25 We we might need two three reviews per day in the future. So what would you say are like the key AI scrum measurements or or flags we need to kind of like raise at various points? What what what's the equivalent?

40:40 So what are the core fundamental uh features of scrum? It allows you to have uh certain deliverables in a certain amount of time and to coordinate between teams and stakeholders this uh deliverable so that you can verify if you should proceed or you have to change things. And maybe what we can learn from from scrum is this like create AI uh checkpoints where sort of all of the AIs that worked in parallel the whole night before they reach the same point maybe they handshake between each other and they say okay now we need the human in the loop

41:22 and afterwards we can proceed with another batch of parallel agents but not before the agent has validated. It's almost it's almost an AI scrum that then introduces a human at the right time.

41:33 Yes.

41:33 Yeah. Very interesting. Um let's talk a little bit about the futures. Let's get crystal ball and kind of say okay 6 months time, 12 months time, maybe even longer. What do you expect to see I guess both in and around agents or specs? What are the major changes that

Persistent agents acting as team leads

41:51 you foresee in software development uh in and around those two areas? So we have to look a little bit back to understand where the curve is coming from.

42:00 So uh cloud code was uh released somewhere in March April

42:06 which is insane in it

42:07 and this is like just few months ago and now we already have few iterations of it and can run in parallel can use nested agents. It's so powerful and if I think that in 6 months it's going to be even more powerful given that we're in an exponential curve, it's very hard to predict where we're going to go. But uh the what are the fundamentals? The fundamentals are AI agents that are becoming more and more a hub, a central hub that can decide what to do based on the human interaction.

42:37 Mhm. So uh I expect them to run completely uh 24 by7. Yep. So I don't expect you to have to run code and then you give him a task and then you stop it and then you start with a fresh session. Uh so uh I don't expect you to have to start clothe uh give him a task finish the task close

4 Highlight · The future: persistent 24/7 team-lead agents

43:04 him and start it start a new task in another session. I expect to have a persistent agent that runs 24 by7 that is your central hub.

43:14 This agent should be your input point should keep a context window that has an understanding of what you need to achieve as a human. But then it will use sub agents to actually solve the tasks and it should keep his own context window as small as possible. So that can coordinate sort of a team lead of of agents basically that can spawn agents when needed. And this agent can also be proactive and we saw this uh recently with some chat GPT features where you get proactive information every morning that are relevant for you and I think agents are can do the same but better because agent can use tool uh can call tools can connect to uh other sources of

44:01 information and can maybe get trained on your own uh data and then they can actually actively work things that you can delegate to him or he can come to you and say, "Hey, you should uh prepare for the birthday of your wife that's coming next month." Uh I think it's a good moment to start looking at presents or organizing a party.

44:22 Yeah. When you said that, my heart my heart beat, "Oh my god, is it next month?" My wife, no, it's it's fine. It's it's next year. We're good. But yeah, super interesting. Super interesting. Um Alex, we could go on for many more sessions actually. And uh the booth is uh the booth and the and the expert area is getting very very busy. So I think we should we should wrap up there. But super interesting topic where where can where can people uh go backlog.mmd for for learning more and and and getting started on backlog.

44:53 Right. So I was very lucky that backlog. Md uh the molda domain was excellent.

44:59 So now when I talk about backlog md I just tell people just type in your browser backlog. MD and it will immediately show my GitHub repository so they can learn how to use it.

45:10 Yeah, amazing. So check out backlog MD. Uh Alex, absolute pleasure. Let's go and enjoy the rest of the conference. But for now, thanks very much for listening. Thanks for tuning in and uh see you next time.