Okay.
It's time for us to go to the crew module as well, you know?
You know that that's the next step.
And of course, you also know that I like to get rid of all of the gunk.
No more gunk for us, but we'll keep in, of course, the hooking up to the YAML files.
Let's get rid of everything else from here, and we will do our work to define the agents.
So agents, the first agent is called the engineering lead.
And good old cursor is giving us some good suggestions here, but not perfect because we don't need
the engineering lead to be able to execute code.
That's not its idea, it's just meant to be designing stuff.
All right.
But now the back end engineer.
So thank you cursor for that.
But you have missed this time what we really need here.
So we do indeed want it to be able to have code execution.
We want the code execution to be safe in a Docker container.
Absolutely.
The, uh, max execution time.
We probably want to give it a bit more.
Well, not not that long.
That's rather too long.
Let's give it a few minutes to work on this.
Why not?
And then Max retries.
We'll give it five times before we are upset.
That seems pretty good.
Okay.
The front end engineer.
Oops.
Need to remember my decorator.
The the front end engineer.
Let's have a look.
So actually we're going to have it right front end.
But we're not going to have it try and execute because that would bring up a gradio UI in the Docker
container.
That'd be a whole different, different ball game.
So we're not going to do that.
But we are going to have it do its creation.
And now we just have the test engineer.
So thank you cursor.
And that seems like a good enough start.
But the test engineer we absolutely want the test engineer to not only write the unit tests but then
to run the unit tests.
But it probably doesn't need.
Well we'll give it we'll give it a couple of minutes to do that, and we'll give it five retries as
well.
That seems fine.
Okay, those are our agents.
Next, it's time for us to define our tasks.
And this is going to start to get very complicated.
The design task is just going to look like that.
And I bet curse is going to know everything else.
That's all we want for the code task now.
And, uh, let's see if it can help us more.
That's probably great for the front end task.
And, uh, the test task.
Is it going to help us with that?
Yes it is.
It's got a strangely indented, but no, it's brought it back.
That's nice.
And I think that's it for our tasks.
I don't think there's anything missing here.
Perfect.
All right.
Thank you.
Cursor.
Those are indeed our tasks.
It's time though.
It's time for our crew.
Let's see if, uh, cursor can do this.
Oh, no no, no, that's all.
All a disaster.
This is, uh, a moment to, uh, definitely mention that you do have to be mindful of this.
The whole vibe coding thing.
As I said before, it is common for Llms to generate too much code and to to just put stuff in there.
And often people send me problems they've got and I can see that they've used an LLM to generate lots
of code, because it will tend to err on the side of more.
Of course, in this situation, we don't need to list out all of the agents like this.
We can just say the agents are self dot agents.
That's the why we decorated them.
And we can say that the tasks is self dot tasks.
And we also need to mention that the process is process sequential and verbose is true.
And that really is it.
But we would normally call this def crew like that.
And I think we've got it.
Okay well you know what's left.
We have to do our run function and we will come to that right now.
Okay.
This is the usual main full of stuff.
Gonna delete all of that.
Going to delete all of this stuff here and leave us with something very simple.
So let's have a think about this, this run.
So, so first of all, we know that the what we've got here is we've got requirements are going to be
let's let's just give ourselves a variable that we'll have we'll have a variable requirements okay.
Module name was one of them.
And we'll have that be a variable module name.
And class name is going to be a variable class name.
Isn't it great the way again cursor just guesses since we had that before that.
That's going to be our thing.
And now engineering team.
That's because that the the function, the method that we decorated with, with the crew is indeed called
crew kickoff with our inputs.
Okay.
So all that remains now is for us to actually come up with the assignment.
And I have produced an assignment which I wish to show you now and which I think you may find rather
interesting.
So here is the coding challenge that we have for our team of agents.
Let me tell you about this challenge.
And then I'm going to tell you why.
This is an interesting challenge.
So the requirements we would like a simple account management system for a trading simulation platform.
The system should allow users to create an account, deposit funds and withdraw funds.
The system should allow users to record that they've bought or sold shares and providing a quantity.
It should be able to calculate the total value of the user's portfolio and the profit or loss from the
initial deposit.
Users should be able.
The system should be able to report the holdings of a user at any time, and the PNL at any time.
And it should be able to list the transactions that the user has made.
And it should prevent the user from withdrawing funds that would leave them with a negative balance,
or buying shares that they can't afford, or selling shares that they don't possess.
And I'm telling it, the system has access to a function get share price, which returns the current
price of a share, and includes an implementation that returns a fixed price for three shares there.
So that should be built into this code.
So that's the challenge.
It's like to build a kind of framework for simulating trading activity, which you know that's a fair
bit of work to do that properly.
That's that's not going to be easy.
And you may wonder why why this particular challenge?
Well, here's the thing.
In the last week of our course, we are going to try to build agent traders.
We're going to be using back to OpenAI agents SDK.
And we're going to be using MCP.
It's going to be really cool.
And the idea is going to be, can we build like a set of traders of agents that are able to monitor
financial markets, look at actual live real time prices and make trading decisions?
But for this to work, we're going to want to have a kind of framework that they can make trades in
and that a framework that will keep track of portfolios and so on.
And there are some frameworks that you can get off the shelf, but they're very heavy weights because
they're sort of big financial markets, backtesting frameworks.
There isn't something that I could find easily that's just a lightweight account management stock portfolio
management framework.
And so I thought, why don't we get AI to build it for us?
And what could be better than having our own crew, our own engineering team, take on this challenge
and try and build out this, this whole framework for us.
So that's why this is a two for one.
Not only are we doing this week's project, putting together a crew of software engineers and a test
engineer and so on, but also this is going to hopefully provide us with a framework that will then
be able to reuse, give us a head start in week six, so we don't have to build our own and do a whole
ton of coding.
So it's actually going to save us some time as well to boot.
Well, with that introduction, I think it's time to try and run this thing.