Transcription
Colleagues, I welcome you to the Katcode channel. Today we will talk not only about the release and factory of version 1.8. It is super fat. We will talk about it thoroughly. I am even a little excited. In a way, I am nervously on edge before I start telling you. But we will also touch upon an important topic. How does such an approach differ in general? Why is this spec-driven needed at all? Why in some cases, I don't know, a oneshot, or just interaction through prompts, do this for me, fix this, is much faster, much cheaper than such a complicated scenario. Yes, this is indeed true. There is vibe-coding, a term I don't like, but today I have upgraded it to another name. Conscious vibe-coding or conscious AI development. We will talk about it today. So, friends, yes, the world is developing wildly. We are all in search of quick dopamine in short videos. Quickly give advice, quickly give a recommendation. I am now coming to you again with my water, but I recommend you listen to me, as I have already gone through the same pitfalls four to five times and have some experience in development, in generating code with AI, specifically with AI Factory, I am passing it on to you. But I also want to convey it in words, so that you understand what it is about. Also, friends, besides talking about AI Factory, about conscious coding, we will talk today about how I approach developing my own skills, what this process looks like. After this, you will understand how powerful this tool is after all. Additionally, there is currently an opinion that skills are harmful, as the default system prompt to the LLM becomes huge. That is, we start with Claude-code. Our context flies away with all the skills, with all the context of the skills that you have. I will not tell you in words that this is so, or that it is not so. I have implemented proxying, convenient proxying of all requests and, accordingly, responses from the Anthropic API. And we will see right there what system prompts are, what exactly flies with the requests. Okay, friends, let's go.
Friends, regarding conscious vibe-coding, if you are at the very beginning of your journey and still don't fully understand how to start, how to move correctly, what to use, how to form your development roadmap, and then want to dive into practice on a real project with complex tasks, then I invite you to my workshop with Oleg Miifl on conscious AI development. The link will be in the description. Sign up.
So, friends, let's start with the question of conscious vibe-coding. Unfortunately, I cannot show you my stumbling over pitfalls right now. The projects with which I began my immersion into the world of LLMs are complete garbage. But I will try to tell you about them now, what they represented. As LLMs evolve, we periodically use different models for different tasks in the development process. Day by day, the results, accordingly, vary. Today, the LLM wants to, uh, give you a lot of summaries for each step. It wants to use this particular coding style, this structure. Tomorrow, it's completely different. As a result, even at the level of project aesthetics, structure, we will have, uh, here at the root, a lot of various summaries with unclear names. Why are they needed, what is responsible for what, why does the LLM scan them every time and send them with context. Subsequently, as soon as you play around with it, it will be something further. Rendering, it will all go into production, some bugs will appear, something will need to be fixed, you will go into endless iterations of fixing these bugs, plus you will create new ones. I think those who have already started their immersion understand what I am talking about now. As a result, vibe-coding turns into a black box. You control nothing. You don't understand what's happening under the hood as much as it's simply possible. The most important thing is that working in a team is simply impossible. This garbage will be further layered by each additional operator. And it doesn't matter which approach you take, even if you create agents, even if you enable, I don't know, code teams, and the agents themselves will set tasks for themselves, fix them, and so on. In this approach, you will sometimes spend up to 5 hours on some fix. And it's not a fact that you will achieve the result, it's not a fact that you won't break something else. Especially when you are just starting and you don't yet understand all the pitfalls. You don't know how important logs are, but at the same time, you don't want to shoot yourself in the foot with these logs, so to speak. When are tests needed? In general, the workflow becomes complicated as soon as you go beyond the scope of a simple landing page of some personal project you invented, which will never go public. With this, it's okay. If you just want to play around, you don't need any spec-driven. But as soon as you work on a serious project, work in a team, conscious vibe-coding is the only correct approach. We are not inventing all this for no reason. Context is mega-important. Here I am demonstrating a project that we are developing in a team of three developers. In parallel, each developer in several sessions is doing a huge number of features through Gitwork 3 and so on. And at the same time, the project structure does not change. We have a specification, and each iteration adheres to it. Unfortunately, I opened the wrong project, friends. I opened AI Factory. Here it is. Accordingly, it is completely generated using artificial intelligence and exclusively through the AI Factory workflow. And the factory generated both the local Docker Compose and the Docker Compose for production. Moreover, every time with any changes, there will be a configuration audit, a security audit, whether everything is okay with log rotation, whether they are written to std out, and so on. A huge number of points from an experienced developer, so as not to shoot yourself in the foot anywhere. And we get excellent conscious development, when our project is documented. There is documentation both in MD files and auto-generated DOCA HTML. We have binaries, meaning this is not a simple project, it's a project in Go. Here is both the master and the client. And we immediately get all the routine implemented, generated by AI. Makefile or Taskfile, which each of you will choose. Docker configuration, structure, documentation, where the entire project workflow is described. A security audit checklist is constantly performed. This is written in Security MD. If there are any problems for the future, they are all recorded, which will need to be fixed. I'm not even talking about reviews and everything else.
Okay, friends, let's move on to the next question. Okay, I understood what conscious vibe-coding is. I want to see the influence of these skills on the context. There is a guess that all this flies into the system prompt and so on. Okay. Here is my proxy system. That is, I interact with Claude-code. All events are taken into account here, proxied through my local server. I see everything that comes from Claude, what I generate for Claude, what models are used. Yes, so that you understand, even if you have the default model OPC 4.6, Claude in planning mode will automatically switch to Haiku, for example, or somewhere else. That is, these moments can also be seen. As a result, upon initialization, upon the first request, we see the system prompt. Yes, it's big. It includes Claude MD. It includes a list of skills, but only at the meta level. That is, in Claude-code, this moment is optimized. It does not carry the entire context of skills with it, it only carries the upper part of the meta. That is, look, now I will show you what it represents, if you still don't understand. So, I've moved a little off track again. Let's say, here are the skills. And each skill has meta at the top. Accordingly, this, yes, is with the system prompt. This is meta-information, but it is an optimized context that the LLM needs further. It already knows which skills and how they work, what tools they include. Subsequently, when you interact with it, it will be able to automatically include skills based on the context. That's all. This is the most important thing you should know. Not all skills fly with the context. Well, yes, at the same time, definitely, friends, returning to the story with unconscious vibe-coding, with oneshots, you will spend fewer tokens. Everything will be executed faster, as you don't need to plan anything. You have a much smaller context, as each time, essentially, the LLM is blind, it starts from scratch, it doesn't know where what, what is responsible for what, it will cover something, it will ignore something, you will be treading water. That is, here it's up to luck. If we talk about the spec-driven approach, then first plans will be generated, there will be a project description with its complete structure, there will be some security additions, something we can ignore in the process when you make fixes, so as not to go into an infinite loop of fixing the same thing, memory will be created with the problems you have already encountered. And, accordingly, when you implement a task, this will be pulled in by context, these moments will be studied. More tokens will be spent, but here, I think, in the long run, all this needs to be analyzed, how many more tokens will ultimately be spent on your endless iterations of fixing the same treading water, or tokens on the fact that you will pull in patches from previous fixes and not step on the same rakes. Accordingly, there is also planning, that is, each feature is a full-fledged plan with tasks, with phases. You can disable the session at any time and start from the same moment. You can work in parallel through Gitwork 3. This is a completely different approach, a completely different level.
Next question, friends. Let's move on to how I, accordingly, generate skills. I think some of you may have a question: "What's the point at all?" Well, okay, there's AI Factory, there are certain skills, something about commits, something about deployment. Now there are skills for Dockerization. I myself will go into AI and say: "Make me a Dockerization skill or use, say, in Cursor, as you write, there's a create skill button." This is all okay, but my skill creation process is completely different. Release 1.8 came out, important utility skills Docky Rise, CI, and Build Automation appeared. What do they represent? Let's be brief. For example, Docky Rise. That is, you relieve yourself of certain routine configurations. Based on your project, AI will conduct an audit and create Docker Compose configurations for you, both for local development and for production, taking into account the best practices it has researched on the internet. But besides all this, I spent two full days on the Docky Rise Skill, from about eight in the morning. I ran it through a lot of my projects. I indicated what I use instead of engines. How to determine versions? How to bypass moments when the LLM's internal memory doesn't yet know that a certain newer version has appeared? How to correctly rotate logs? Where to write these logs? About the fact that you need to monitor ports so that they are not exposed externally, so that no sensitive data flies anywhere. Accordingly, on some already large projects that have been in production for a long time, I deleted all Docker configurations, ignored them using AI Factory, and as a result achieved the effect that these configurations were even better than the previous ones, which were already worked out, which have been in production for several years. Okay. Thus, we completely get rid of Dockerization routine, and at the same time, it is at a high level. Next, let's say you use a Makefile, or a Taskfile, or a Justfile, or a new Makefile. Accordingly, with one skill, you can generate it according to best practices and interact conveniently, call these commands. Now, what's most important, there's a web of your entire project. You ignore Docker configurations, your documentation is updated, your Agents MD is updated, your README is updated. You don't need to think about it constantly. You generate CI, with tests, with linters, and so on, for both GitHub and GitLab with one skill, with references, with ready-made templates. And all this spins in one mode. You do some feature, implement it, and AI Factory will automatically check if there is documentation, add a new section, change a new section, improve your skills in the process. That is, a system of self-improvement, self-development. After implementation, you can call a check of what you have done, so that the LLM goes through it again with a larger context and definitely does not allow any problems. Fixes with patches. You will not achieve any of this at the level of simple vibe-coding with prompts. Fix it, do it, fix it again. You won't achieve this.
Friends, the next question. I think some of you are already conscious developers, conscious vibe-coders, use the spec-driven approach, but use some other tools like me, before AI Factory with speckit, or Open SPC, or something else. There are a huge number of them. If you just look at the skills and factories and see not only automation but also relief from routine at the highest level with Dockerization, with Makefiles, with CI, with documentation, and so on, you most likely won't see all of this in the spec-driven tool you are using. Most likely, there will only be a workflow. That is, do, fix, improve, research, maybe something will be added like in OpenSpec, study with me. But this is all exclusively for vibe-coders, so that the vibe-coder doesn't get lost in these thickets and has a certain workflow. He has at least planning, at least he can continue from the same place at any moment, that is, add a little more intelligence to him. But all this seems to be implemented not by developers, not for developers. AI Factory is written specifically by a developer for developers. This is extremely important. I wrote it for myself. I started diving into vibe-coding, into AI development, and every time I stumbled upon certain pitfalls and tried to think about how not to step on them again, to automate routine, to improve my workflow. And thus I came to AI Factory. Before that, I used both Open Spec and Spec Kit. Like you, I don't want to reinvent the wheel, and if something exists, I will use it. But it wasn't in the form I needed. It wasn't for developers, so AI Factory was created.
Let's quickly go through release 1.8. This is a very cool release. It's fat. It seems to me to be on par with release 1.0, when AI Factory first appeared. I have rethought a lot here. Let's quickly go through it. First, I continue to add agent support. Now, as far as I remember, we have more than eleven agents. Antigravity, Rcode, Killcode, Winsurf, Warp Encoder have appeared. Before that, I also added Open code. There's a huge number, by the way, for my memory, a hint, 14+, but apparently, plus is marketing that has been added here, there are actually 14. Plus, at the level of contribution, if you want to add more support, I have made a flexible approach at the code level, as it's not always possible to just throw in a certain agent and say put all this in the tool directory or .cursor, it doesn't always work out that way, sometimes a different structure is needed, but transformers are provided here, and you can see what they look like if you need some non-standard agent, you can look at how, for example, Mer Antigravity is done. Here are not skills, they are divided into skills, workflows, rules. A completely different structure, not at all according to the skill specification. They invented their own wheel, but AI Factory allows integrating such agents as well. Okay, we've dealt with this. This is for developers. I am also waiting for you in this project. Together with your pull requests, we will make this tool even cooler.
Next, new skills. I've already talked a little about them, but let's go through them again. We have CI, that is, generation of CI/CD pipelines for Gitlab and Gitlab, depending on what you choose. There are linters, tests, builds, security checks, in general, everything you interactively choose in the process. Dockerization, I've even shown you, that is, Docker Compose for local and production. Finally, with the choice of nginx instead of engines. This is directly built into the rules. This always bothered me. Plus, the LLM still doesn't know where to get the correct image and what the latest version is. All this is already implemented at the level of this skill. Verify is, accordingly, verification. That is, you have made an implementation, and this is a post-verification. Is everything really according to quality? It will go through all the checks again, validate everything. This is important for complex tasks. Build automation, in principle, we have also looked at. This is like Makefiles, that is, with quick access to certain commands. Includes Docker, accordingly, including tests, including help. Here's such a beautiful one, where you will see all the commands. All this will be included, and you will have uniformity in all projects. Docs, we have also looked at. Accordingly, based on the context of your project, documentation will be generated. It will be divided into sections, so there will be an entry point. Each section will be back to README, the next section, the previous one. In general, all this will be properly formatted. Well, and accordingly, if required, you will also have HTML docs.
Okay, we've dealt with this. Let's return to Workflow. I have improved parallel development. If you call the skill feature, you can also specify the parallel option. Accordingly, a directory will be created for Git 3, and you can work in parallel. That is, you can work through Claude Teams, launch agents, they will all be tinkering and not bothering anyone to do features in isolation. And they will have hints on how to see what features are currently being done, clear the work 3 after completion, and so on.
The next important point is skill enhancement for fixes. Before, when you called fix and wrote about some problem to fix, it immediately planned under the hood, but then proceeded to fix. Now you will have interaction. You will be asked, maybe you want to do plan first, that is, go with the plan first approach. And if yes, then first it will generate a fix plan, you will study it. If everything is good, then run fix again without any arguments. It will see that the plan is present and will proceed to implement it, accordingly, with all patches and according to the standard fix workflow.
The next feature is that you will be supported in the process and offered to clear the context. That is, I have already gained experience here for myself. I do some task. I, accordingly, close the session, start a new session. I have a plan there. I started a new session to reset the context, or did a clear, accordingly. But at the AI Factory level, there were no such recommendations. Now this will be integrated into many workflow skills. Accordingly, after implementation, you will be offered to do either clear or compact. The same after the planning mode ends. And so on. In general, AI Factory will also think for you here.
Accordingly, here is such a large release. Plus a lot of fixes that I made in the process. How do I arrive at these fixes, friends? I simply cannot imagine my life, my AI development without AI Factory now. All projects, both small and large, start with AI Factory Init. And then I start generating configuration, generating routine. In the process, I find some shortcomings, somewhere I understand, ah, this moment can be optimized, this step can be skipped, done faster. I didn't account for this, didn't double-check, it wasn't added to the documentation. All this happens in the process, it's the same development. It's impossible to make a polished version 1.0 project right away, so that it runs smoothly. Here you have to monitor all of this. And because it's my tool, without which I'm like without hands, it will constantly develop. The workflow will improve. Well, and it will be mega-cool if you join this project not only as users, as conscious developers, vibe-coders who use and write projects with this tool, but also in the process find some moments and make pull requests, as we are all 100% developers now. All of you who have AI, no matter what your background is, you are now also a developer. You don't need to come to someone with a task, you can implement it. Just like I would. You most likely have the same top-notch model. It is capable of everything that I am capable of with AI Factory. The only thing is, I will do reviews more qualitatively, but that won't go anywhere. A pull request will come, I will do a review and advise on how to move forward.
So, friends, let's summarize what we understood today. First, what is conscious vibe-coding and simple vibe-coding. I think I was able to get through to you. Don't be hasty, don't be endless treaders in place, don't create unmaintainable hell in your code, so that later someone else besides you can understand what's happening. It could be maintained, it could be fixed, it could be somehow expanded, scaled. Be a conscious AI developer. Use spec-driven and at the same time constantly try to improve this workflow. Develop your habits of clearing context, new sessions, parallel execution, using different models, using different approaches, accordingly, using AI Factory, and possibly improving it together with me.
Next, we understood how skills work in Claude-code, that they don't fly with the context entirely, only meta flies. This process is optimized and correct. For your development, I also recommend proxying all events so that you see everything that happens at the level of your interaction with the LLM. This will give you an understanding of what's happening, that at the start some requests are sent, that with your prompt another dozen requests are sent, how it all looks, how many tokens came and went. You can also, like me, coolly divide into users, assistants, what tools were used, MCP skills, whether there were any errors, and so on. All this will be useful to you.
We also reviewed release 1.8. I think it impressed you, just as it impressed me. We also figured out how exactly I generate these skills, that it's not just AI generation, but essentially, these are my skills. This is the transfer of my experience. And, accordingly, of course, it's endless development. I can't put all my experience here at once. And in the process, when I stumble upon problems, I will describe them here, so as to save time in the future and not return to the same problems. In essence, AI Factory is time saving. At the start, you spend more tokens than usual, but in the long run, you will save them. Besides saving tokens and time, you will save your energy and resources by not returning to the same problems, working calmly in a team, with the ability to maintain, scale your projects, work in parallel, and so on. Don't invent unclear arguments. There is no other way now in AI development. Only spec-driven, only thoughtful context, only thoughtful prompts, planning of what needs to be done. And generally, we will call this conscious vibe-coding. Conscious AI development.
Friends, I am glad that you are joining these ranks with me. And we will be among the first to qualitatively, correctly write projects and create benchmarks for workflow interaction with LLMs, as it is still completely unclear who among us is a quality LLM operator. How to determine this quality, by what means. All this is still being developed in the process. That's all, friends. I hope I was useful to you. You are not too tired of the water, but I had a serious task to reach you and answer these several most important questions that, perhaps, are stopping you and preventing you from further developing, interacting with AI. I hope for your like, I hope for a subscription, if you haven't done so yet. Subscription, bell, but this is your life, decide for yourself. To like, not to like, to subscribe, not to subscribe, to comment, not to comment. I only say respect for these actions. if you still perform them. In general, thank you for them. Thank you for watching. See you in the next video on the Katcode channel.