So, thank you. Thank you, Michael.

From UX Agency to AI Teammates

As you said, I'm Tahi. I'm co -founder of Mooch .agency with my wife, Natalie, there holding the camera up. Everyone look at her. She'll hate it.

So, we actually started as a UX agency a few years ago and then incorporated AI. And we're now sort of a full -service UX and AI consultancy. We do implementation and basically advising companies on how to implement AI for their business.

And so what I want to run through today is basically how we took Claude from being just a standard kind of tool that you use to an AI teammate, an advanced AI teammate. And how that helped us to kind of speed up, move faster, deliver better high quality code. And high quality content.

The Problem with Vibe Coding

So first of all who here would consider themselves a vibe coder or who here has heard about vibe coding? right and Keep your hand up if you would consider yourself a vibe coder Right. Okay, so we got a few in the room.

I'm sure that you're familiar with this kind of feeling This was me. Maybe I would say about a year ago maybe a bit less just feeling overwhelmed with everything that was going on with AI and feeling like I had to really really keep up with all the things that were going on

but also you know just like constantly at the computer for you know 12 16 hours a day and just token maxing vibe coding trying to get ideas out trying to build stuff and not really thinking about the decisions I was making about the things that I was actually building and trying to do it while I was building the thing.

So that led me to basically looking like this on a Friday night when I should be enjoying myself, should be going home, having dinner. And so I thought to myself, there must be a better way. There must be a better way to be building apps, building vibe coding, building content, and so I realized that the reason

why I felt so stressed, so uptight, so fraught with anxiety about the stuff that I was building was because I was trying to, as you can see up there, vibe coder, I was trying to make decisions about what I was delivering while I was delivering it.

So a typical week might look like this. I'm building, but I'm also trying to make important decisions around it. What am I building? Who am I building it for? On the fly.

And what I managed to do was move to a situation more like the bottom, being more of a 5 p .m., where I make important decisions up front at the start of the week, and then it flows more smoothly throughout the rest of the week.

Decide Slowly, Deliver Fast

And it kind of led me to a framework, which we kind of reference internally, internally, which is you decide slowly and then you deliver fast, you make important decisions at the beginning as a human, what problem are we solving, who is it for, what does good look like, what do we cut out completely, and then you can speed up delivery.

So you can build the page, you can write the copy, you can deploy the code, you can share the report. and you know if if anyone here has been using AI a lot you understand that delivery time or execution has dropped by 90 maybe more maybe 99 % so my feeling

was we can afford to kind of slow down and make those important decisions because it will actually help us speed up in the long run so our model the one

A Sprint System for AI-Assisted Work

that we actually use today is one where we have a backlog of tickets with everything that we might do any idea that we have that we might take on and then we plan a sprint at the beginning of the week so on a Monday we plan that sprint we have one goal in mind and Mooch bot who's our internal agent will look at our entire backlog propose some tickets and then we will decide as humans we make the decision about what goes into the sprint that then turns into tickets those tickets have criteria they have an owner and you'll see more

on that later there's delivery so that happens Tuesday to Friday and that's where I want to show you later that much more actually executes autonomously on on those tickets on number three.

Throughout the week, we also review. So me and Natalie will review. And at the end of the week, there'll be a close. And that's where we have our retro.

So if anyone here is maybe part of a product team or has been part of a product team, you kind of understand that, or you're at least familiar with some of these principles of having a backlog, backlog, having a sprint, having a retro, and having these reviews.

So we kind of really went back to our roots, to our UX roots, to kind of pull this together and bring Moochbot in as a member of the team rather than treating them like a tool.

So here we've got the kind of four key components of how it looks in reality, and I'm going to go in deeper into to each one of these you'll see.

The Four Components of Moochbot

So you've got a scheduled task. How this works is at the moment for us we have Claude and we connect it to Notion and within Claude we have some scheduled tasks and it says wake up at 7am, complete the tasks that are assigned to you in Notion on the board and then spin off an agent to review it and then assign it to one one of us to review properly.

The backlog is the backlog that we spoke about before. We'll take a closer look at that.

Then there's the chat. That's sprint planning, where we can say, right, what tickets are going into the sprint? What's important in this sprint? What do we need to deliver? Make those decisions up front. Saves us a lot of time towards the end.

And then the ticket itself, and I'll show you what that looks like.

Scheduled Tasks and Autonomous Runs

so this is basically the so this is the 7 a .m. run our mooch bot our little mooch bot runs at 7 a .m. and 1 p .m. every day so when we wake up in the morning he's already done some work we can check it over we can make sure that it's right and he runs again at 1 p .m.

and the 7 a .m. run is essentially a scheduled task within Claude code and it has it's basically made up of instructions what what to do, plain English. And you can see some of these here, or at least an example, which model it's actually going to use to execute. And it might also spin off some subagents that will actually execute while it orchestrates, where it lives. So that actual schedule task will live either remote in the cloud or on our device. And then, as I talked about, the schedule. schedule.

So, an example is your mooch bot, work through all of your in progress tasks, check for any blocked tasks, skip those immediately. Pay special attention to the outcome field. That is what we're delivering. Your time limit is 55 minutes because you don't want the agent to run for hours and hours on end if it gets caught in a loop. And then obviously report report back, let us know how it went, we'll review that as well, as well as the output.

Managing the Backlog

So then taking a closer look at the backlog, we've got the backlog here with a bunch of tasks. Each task will have an owner, and it will have priority, and it will have a status.

So obviously these are made up, but Moochbot will assign himself tickets that he can complete end -to -end, and he's been told to do that, and then he'll assign us tickets that we also need to get involved in the priority basically dictates which order he completes the tickets in

Sprint Planning with an AI Teammate

and then this is the sprint planning it's sort of like a sprint planning that you would have with your regular pm you're going to talk about the tickets that you you think should go into the sprint go back and forth try to understand the root of the problem try to understand what the priorities are where they sit and so we do that with moochbot in the same way that you would we'd do it with a human.

We'd say, start the sprint planning for sprint 18, which is the sprint we're actually in right now. And then use the grill me skill, which some of you will probably know. Grill me about the tickets until we're confident that they're ready.

And so Moochbot has an internal playbook. This internal playbook dictates exactly how we do the sprint. So a lot of the stuff in here, plus some other stuff.

It will look at the last sprint board, all the tickets that we created and all the outcomes of the last sprint, all the learnings from the last sprint, the retro that we did at the end of the last sprint and anything else that's relevant.

It will recommend some tickets for the sprint and it will give a confidence level. I usually won't just say lock it, I'll usually be like that doesn't sound right let's do it again and then it will ask me a bunch of

questions it will grill me on every single aspect of the ticket every single deliverable every single gap in its understanding of what the ticket looks like or what the outcome should look like who it should be for things like like that. All the key things. We'll go back and forth until we're happy.

And I should also say that there's one of the tricks that we use for this part is basically saying to Moochbot, what would boost your confidence in delivering this ticket? That's one of the main things that we say. So that actually has helped me to really get under the skin of a lot of these problems and find the gaps in what Moochbot doesn't even know that it doesn't know.

The Board and Ticket Workflow

So this is the board. This is the fourth and final part of that, the quadrant. So this is what our typical board looks like. I'm sure you've seen many like it. You've got not started, you've got in progress, you've got in review, blocked, and done.

And so Moochbot spot will essentially move the items from in progress all the way to done if he doesn't need any help with the ticket. For ones where he needs our help, maybe some manual tasks, it will be in review, we'll review it, and then it will go on.

One thing I want to point out is that just like you would have with a hire at your company, with a designer, with with a developer, with a copywriter, they'll pick up one ticket at a time and they'll work on that one ticket and during the next stand -up you'll ask them, so, what did you do yesterday? What are you working on today? And we treat Moochbot exactly the same way. One ticket at a time, understand what he's done, review it, move it along.

And so this is a closer look at that ticket. ticket. The outcome at the top, made up Acme Bakery. So mobile checkout completion on the Acme Bakery order page is back at or above six week baseline.

What's the user story? As someone who's ordering bread on their phone, I want the payment step to accept my card first time. And then the acceptance criteria. This ticket is only done when these are checked checked off. And you can see some of the manual tasks there.

And so these are super important because the agent needs context of who this is for, why it's important, what the outcome should look like, what good looks like, and each individual requirement of when this ticket should actually be crossed off and done.

Results: A More Deliberate Way to Build

So just to recap, going from an anxious, very very anxious, very frustrated vibe coder who was just basically building whatever came to my mind and trying to make important decisions about the shape of the product, the shape of the content, the shape of the app to someone who is thinking very deliberately, very intentionally emotionally about what that should look like at the start from the beginning making that plan but doing it in a very structured and repeatable way so that we can build on it over time

this is what we've gotten to so the method is decide slow deliver fast treating it like your first hire and adding a self -improvement loop and I kind of skipped over a little bit but that self -improvement loop is essentially the retro and the learnings that come out of each sprint So we're in sprint 18 now, we've got 17 sprints worth of learning, all in a loop, that build on each other. So Moochbot learns from the very first one all the way up to now.

And then the outcome of what that gets you is you're not running multiple sessions, like I said, haven't got six, seven clawed windows open, trying to bounce between them, trying to run all this stuff. you simply wake up in the morning 7 a .m. Claude wakes up he sees the ticket he starts attacking it he moves it to done or he moves it to in review I check it tell him it looks good he moves on to the next one and so there's two runs a day less rework so decisions happen up front we don't have to keep bouncing bouncing back and forth.

Talked enough about that.

Why the System Improves Over Time

Important, bad ideas die early. So with this backlog situation, you've got tons of ideas that actually shouldn't see the light of day, and so those get to die early because you get your agent to grill you on the importance of these tickets, the importance of this work, and so you can decide to cut a lot of that that rubbish before it ever makes it into the sprint.

And then it compounds. So over time, this compounds, we talked about that, all the learnings, yeah.

Building Your Own AI Teammate

So last slide is, we just talked about the advanced teammates and that's Notion connected to Claude.

What we're actually running tomorrow is a workshop whereby we help you build the perfect AI teammate, which is perfect for beginners. It's a half -day workshop, recurring jobs on your own Claude and ChatGPT account, and it's at Second Home in Time Out Market. So that's what we're running tomorrow morning.

Thank you. Excellent.