Transcription
So, I've created an entire AI development studio, and I want to share with you my progress on it. Um, it's definitely a work in progress, but it's doing some pretty mind-blowing things, uh, that I think others might be interested to see. So, uh, I'm going to share with you the dashboard. I'm going to share with you a little bit of what it's doing right now and show you some of the interaction that I have with it.
Uh this began as uh an experiment uh in creating a few uh clawed code agents that could work together with each other uh in order to produce better code than just a single agent would be able to do. And the reason why I decided to do that was because a single agent uh has a few um disadvantages. One is that it's limited in context to its session. It starts cold with whatever context you give it and then every new session starts cold. And as the context grows and grows and grows within a single session, it uh loses fidelity. It's it's harder for it to remember things. It starts to kind of freak out a little bit. Um and it it it the performance kind of degrades as the session continues.
One of the other uh major issues is that uh claude code sessions generally don't look at their work and evaluate it themselves. They will do their best on the first shot to create a feature or do whatever it is they've been asked to do. They usually don't look back at what they just did uh and evaluate if there are errors or bugs or ways that it could be done better. Uh the human kind of has to either do that themselves or tell code to do it and that takes a lot of intervention. Um, one of the other downsides is that cloud code is a general purpose coding tool, but if you have any experience with real um, development teams, there are different responsibilities. There's front-end code, there's backend, there's database, there's security, there's, you know, process and project management and design and lots of different roles. And while a claude code session could do all of those things, it won't. It's not going to do all of that by default. You're going to have to ask it to kind of switch hats and do something else throughout the flow of the conversation that you're having with it. And that takes a lot of manual intervention. It takes a human kind of just thinking about that and knowing that it should do that.
But the major thing that um I think is most important is that it hearkens back to the first issue which is that a cloud code session really has no memory other than its own context, its own session. Um it has a hard time knowing when it should go out and look at other resources, if it should read something, if it should look something up. it doesn't have any memory of previous sessions and what those sessions did. So for example, you might have a session where you ask it to deploy something and it tries to deploy it. It makes a mistake and then it has to work through that mistake and has to figure out what went wrong and then it eventually figures it out maybe with some human intervention and gets the deployment done. If you open up a new session and ask it to deploy, it's probably just going to make all those same mistakes all over again and have to figure it out all over again. So, there are ways to kind of mitigate this by telling the session to create some documentation and to kind of update its uh standard operating procedures, but there's no guarantee that future sessions are going to actually follow that process or even know that that process exists.
So I tried to address all of those things through this system and again it's a work in progress but it's doing some pretty incredible things and the core innovation is that I have embedded a knowledge base into the platform itself. So, I'm trying to work with the way that claude code works. And the way cloud code works is through markdown files essentially um or code files in general, but markdown files are central to the way that code um documents things and keeps its own identity and its memory going. So, when you initiate a session in a regular code session, it's going to look at all the relevant code and it's going to read the code. That's what it does. and it starts fresh and it just reads the relevant files um right from the beginning. If your lessons from previous sessions and your learnings and your standard operating procedures and everything, if those uh lessons exist somewhere else, not in the code, code is never going to see it. The session will never see it. You can do as much documentation as you want, but your session will never actually see it. it doesn't know to look for it.
So what I developed is a basically a code commenting convention where the claude code session will embed knowledgebased article references into the code itself in the relevant places. So if you tell code to do a deployment uh it's naturally just the way code works it's going to look for any deployment related code within the codebase and now it's going to see a knowledgebased reference in that code that tells it hey look at this markdown file so that you understand the best practice and the process for how we do deployments. it'll look at that markdown file and then it'll come back and actually do the deployment correctly. So that's a huge innovation um that has already started to show how how well it works in the system.
The other thing as you can see from the screen here is there are 13 separate agents each with their own responsibilities. We have analysts, we have architects, we have designers, front-end developers, back-end developers, full stack developers, devops, uh growth and marketing, security, project management, process evolution, uh QA, and documentation. We could probably come up with more, but these are the ones that we have working right now, and 13 is plenty. Uh and the way that they work is that they pass messages to each other. So project management coordinates everything, creates a board of tasks and or or tickets rather and assigns those tickets to the relevant agent who should get it done. But it also tells that agent who it should message when that ticket has been completed, when that ticket's been updated, or if they have questions about something. And so then you can see this constant flow of messages happening between these agents. So for example, it looks like here we've got Dev Rio, this is our back-end developer sending a message to PM ADA that this feature is now launched or merged into this branch. Some of the really interesting stuff is when we have developer agents talking to each other. So this isn't quite that, but this is interesting. We have QA, our QA uh agent talking to DevOps. uh it identified an issue that we need a branch restore and then DevOps is going to take care of that. So these agents are discovering issues themselves. They're staying within their scope and messaging other agents that are specifically scoped to handle that type of task. And this creates a much better workflow uh than just one session trying to do everything.
The thing that's super interesting about this is that you can look, you can see these are popping up in real time here as they're working. You can see a full trail of all of the project communication that has happened here. You can see every single piece of communication that is going between these agents and ultimately do a metaanalysis of the entire project to see how your team is working. And there's actually an agent that is specifically designed just to do that. That's process EVO. Here we just call it EVO. EVO periodically looks at all of the artifacts of the project and it finds ways to improve the team's progress uh or process rather and then it makes recommendations and then the team within constraints is actually empowered to just go ahead and evolve its own process to improve it. And then if it has recommendations that are more sensitive, it raises those to the human for the human to uh evaluate, make suggestions or approve. So right now you can see we have five pending recommendations from EVO about how to actually improve the process, which is amazing.
So right here, I haven't even seen this one yet. It's aligning with the constitution that I gave it. Principle one, serve the user. Principle three, high stakes principle 7, no cutting corners. And it's making a recommendation saying that um we need a verification gate on the staging handoff. So basically, it's saying um that sometimes the team tells me, the human that things are ready on staging for me to review, but they're not really ready. That there's some errors on there. So it's saying we actually have to test it ourselves before we give it to the human to test. We have to do a better job of testing.
So, that's the kind of 10-minute overview that I have available right now here at the cafe before I hop on my next call. But, I wanted to kind of build in public and show you what's going on here. If you're interested, if you have any questions, please, you know, drop a comment, let me know what you're thinking. Um, and I'll continue to share progress and actually let you look under the hood at what's going on here.