Anticodeguy

Migrating Knowledgebase With AI Part 6

<written by a human being>

Last week I met a guy who produces Instagram stars, including those who came from movies and TV shows. Yura is a person behind the scenes who, with a whole team and his expertise, pushes to the top of the charts the influencers we all know from social media and think they got that popular on their own. Some of them, sure, are genuinely talented producers themselves, but that's more the exception. Most people like me have expertise in other areas, but not in content production. Hence the mediocre results. So when I get a chance to talk to a professional like that, I'm happy to listen to his recommendations and try to implement something. His key recommendation for my personal brand was the need to create more entertaining content that hooks interest from the first second. Obviously I'm pretty bad at that - I try to make content useful for nerds like myself, but it doesn't have the qualities of something hooking, which means it has basically no chance of grabbing a random viewer's attention on social media. Honestly, I still have no idea how to apply this to my content, but Yura gave a couple of tips on where to start, who to look at, and how to change the approach to producing my own content. On Thursdays I usually shoot videos, but tomorrow I planned to instead run a session rethinking what kind of content I create. Time to try something new!

<written by a human being>

While Fable's still available to us mere mortals, I want to squeeze max value out of it. And, of course, the question of saving tokens in every session comes up hard. Some time ago I set up context window size and fill display in the status-line of my harnesses - Claude Code and Codex. In Claude Code I even made a visual progress bar that shows context window overflow. But working with Fable, I realized this info doesn't carry practical value. I still try to wrap up the session before hitting the 200K token threshold in the context window. So it's always loaded max 20%. And I thought, what if I set myself and the agent a synthetic limit of 150K tokens, which triggers a warning that it's time to wrap the session and do /wrap (at the end of which I have a handoff-prompt for passing context to a new session). And on top of that - visually make it clear to me that we've hit the boundary of what's allowed. Said - done. First thing I set up a hook that at 120K tokens (with some margin) gives the agent a warning, after which the agent starts hinting in its messages that it's time to wrap the session and suggests doing wrap itself. And this doesn't happen mid-task - I added a condition where the agent has to bring current actions to a logical conclusion point where it can be interrupted. And the second part - I redid the progress bar in the status-line so it shows fill of my synthetic 150K limit. This gives me a visual incentive and a hint that every next request of mine is getting a lot more expensive.

Migrating Knowledgebase With AI Part 7 - Grand Finale

Migrating Knowledgebase With AI Part 5

<written by a human being>

For the corporate Hermes agent I set up a separate Claude Console account, which lets you create API keys and use Anthropic's models directly (no middlemen). My subscription ran out of Fable limits and I decided to try hitting it directly through the API. But in the end I used Opus, because I wanted to compare the dynamics of limit consumption vs the cost of buying tokens through the API. In Claude Code there's a /status command that lets you see the "cost" of a session, how much was spent on tokens. Imagine my pleasant surprise when I saw $487 there! I immediately rushed to the API console dashboard, even though I was 100% sure I hadn't intentionally turned on auto top-up of the balance. But the dashboard didn't show these expenses - it recorded around $10-15 spent on tokens. And the session had grown to about 200K tokens. So I'd easily spend 200 bucks via API over 6-7 coding sessions. And here's where my template completely breaks. For $200 I get a month of intensive work from several coding agents running simultaneously and almost continuously throughout working hours, 7 days a week. And via API, 7 sessions? After getting used to the volume of work you can pull off on a $200 subscription, this kind of insane token spend starts to feel wild. Two conclusions from this experiment: 1. /status has nothing to do with reality 2. API is insanely expensive, an order of magnitude more expensive than the subscription. Am I doing something wrong?

<written by a human being>

A while ago I set up Hermes (a more up-to-date and secure analog of OpenClaw) for the team, which was supposed to work in the corporate messenger Mattermost. Deciding to save on tokens, since I suspected that adding an AI bot to a corporate chat would require a huge amount of them, I decided to try kie ai, which gives you one API key and lets you use different models, an analog of the more widely known OpenRouter. And since they offer buying tokens "in bulk," they often have discounts and it's supposed to be cheaper than buying tokens directly from providers. But that's where all the pros ended. First, it was pretty problematic to connect Hermes to their API and I had to write a couple of workarounds to get everything working. Second, requests from the chat started returning errors after three-four iterations. Even though there were still plenty of limits left, non-flagship models were being used, and rate limit thresholds weren't being exceeded. So for whatever reason, the API just didn't want to work smoothly. Everything changed when I switched Hermes to the direct Claude API. Every request started going through on the first try, the Plane integration worked the way it should, and the bot finally started behaving the way it's supposed to. So if you can't get OpenClaw or Hermes to run properly, don't use aggregators - try connecting directly to the API from the provider of the model you need.

<written by a human being>

Fable turned out to be really good specifically for orchestrating other agents. And this is genuine autonomous work. You don't have to sit there and constantly push tasks forward - that's exactly what Fable does on its own. It runs through a series of planned tasks, working on them for hours straight without stopping. You'd think it should eat up all available limits, right? But no, it manages them pretty sensibly, handing off implementation to Opus, keeping for itself the work of managing the overall picture, the global context, and the agents themselves. So as a result of a multi-hour session, Fable might spend around 150K tokens on itself, while fully completing 5 code tasks with Opus. That whole volume of tokens it spent on Opus, I would've spent myself, of course, if I were running these agents myself. If not more, since the agent probably knows better how to handle agents than a meatbag like me. But all of this works in my case because I have the discipline to run a project management system, which I've talked about before more than once - Plane, Linear, GitHub Issues. There are mechanisms there for building a critical path, where one task blocks another and it's always unambiguously clear what to take into work and what's waiting on something else to finish. For Fable this is a convenient mechanism that it handles beautifully and it helps guide things if something is structured wrong. Basically, in a well-structured project Fable will bloom in full color.

Migrating Knowledgebase With AI Part 4

<written by a human being>

Fable is open again and still part of the subscription, so of course I couldn't pass up trying it on the hardest tasks I've got right now. And the hardest thing right now is managing AI agents so they actually do the work right and hit the goals. And Fable is nailing it! I'm building a new information system, and Opus and I put together a whole toolkit for working on product features - skills, instructions, linters, guards, hooks and triggers, other verification mechanisms, documentation methodologies. I sent all of it to Fable for analysis, with the task of finding inconsistencies, contradictions, gaps, and nuances that weren't accounted for in how AI agents work with this system. It found around a dozen and a half points that needed fixing, and on its own (without me asking) created tasks to fix them. And it didn't burn nearly as much time and tokens as Opus usually does on tasks like this. In the next session I asked Fable to orchestrate the tasks it had created itself, delegating execution to Opus agents. And that's where the real surprise hit me - Fable worked for about 1.5 hours and came back with a report on completing 7 tasks and a question about whether it should move on to the follow-up tasks that got identified and filed along the way. For comparison - Opus does one task like that, but manages to stall out on pretty simple questions, asking for my decision. With Fable I feel like I can hand off orchestration completely and trust the calls it makes. Not all of them, though - product decisions I still want to weigh in on myself (for now), but I'm continuing the experiments. We'll see how it goes from here. But for now this really is the kind of delegation I've been wanting to get from AI.

Healthy alternative to /goal for complex projects

<written by a human being>

It hit me why I barely use /goal in my projects anymore. The same effect is achieved by proper context. And proper context is set up like this. 1. Dedicated directory for the project. If you're working on your own PC, just create a local folder; if on a VPS, it can be an isolated container. 2. Files relevant to the project go into the created directory. 3. Set up a project tracker: at minimum a text file to record progress, ideally a full-fledged project management system like Linear, Plane, or GitHub Issues. 4. When the project kicks off, create agent instructions (AGENTS.md or CLAUDE.md) with a specific structure so any AI agent can quickly get up to speed on the project context. 5. Create local skills, specifically tailored for working on this particular project. 6. As work on the project progresses, the agent's memory gets built up. These files aren't automatically shared between agents from different providers - meaning Codex won't find Claude Code's memory - but you can deliberately point to them and sync them with each other. 7. Run retros that periodically clean out and optimize memory, instructions, skills, and tidy up the repository (project directory). With all of the above in place, working with an AI agent on this project becomes very smooth, predictable, scalable. And most importantly - even with a plain prompt you get what /goal gives you: continuous autonomous work until the result is reached.

Migrating Knowledgebase With AI Part 3

Why /goal is a bad idea for complex projects

<written by a human being>

Launching an AI agent to autonomously execute some task means it's also going to autonomously make decisions at every fork in the road, product or technical, and in a complex system there's gonna be a ton of those. That means we're fully relying on its judgment. And what you usually end up with, as a result, is that exact AI slop instead of the outcome you wanted. From years of experience working in IT product teams of various sizes, I'll say this with full responsibility: even a team of qualified meatbags led by equally qualified meatbags still doesn't always nail a first-class result on the first try. And no need to reinvent methodologies here that have already proven their effectiveness in practice on any kind of project - decomposition and iterative improvements. Decomposition, or breaking things down into small atomic tasks, is what lets you, first, describe the desired result as precisely as possible, second, as a result, implement it better (in small chunks that get more attention), and third, control the process more precisely, given all of the above. The same thing works great with coding agents too. Once you've broken things down into small subtasks, you can confidently set /goal on each one and even send several parallel sessions to work on multiple tasks at the same time. As long as they're not blocking each other, obviously. And then it's those same iterative improvements. Did it, tested it, then made it even better, and so on toward the ideal (which is unreachable).

Why I (for now) prefer to watch what the agent does rather than blindly trust /goal

<written by a human being>

The answer is very simple - I don't have an unlimited AI budget, which is clearly what this requires. /goal sets an end goal, and there are many different paths to reach it. The AI won't always pick the optimal one. It'll make mistakes, fix them, try other options, and keep going until it reaches the finish line. But what if the task is unachievable to begin with? Even without /goal, I've watched Claude try to endlessly knock on the door of my home server, which had been shut off on a timer. And it would have kept right on doing it - burning tokens and time. Of course, when all the preconditions are met, the working environment is set up and under the agent's control, the task doesn't call for any product decisions, and the path to solving it is obvious and straightforward, the autonomous approach works great. But that kind of autonomy isn't always a good thing or in the project's favor. Even with active supervision, it often happens that you have to roll back the agent's work as unacceptable. Here's an example I'm dealing with at this very moment. Right now the agent is reworking its output for the third time because it misunderstood how to build a library of reusable UI blocks for designing interfaces. Even though I explicitly stated in the prompt that it should first do some research and find similar libraries as examples, it just ignored that requirement and did things the way it saw fit - it dropped in blocks already built from finished interface screens. On the second attempt it went into pure abstraction and created skeletons that have no practical use whatsoever. In a case like this, /goal is of little help, and there won't be much difference from the regular mode either - you'll get the same broken result that still has to be redone. The tokens you've spent aren't coming back. But at least in interactive mode you can stop it in time and steer it where it needs to go.

Migrating Knowledgebase With AI Part 2

How do you actually get an AI agent to work autonomously

<written by a human being>

You can set a /goal, but in that case all you need to do is set the final point, the destination, which you can reach by many different paths. And that's exactly where the key catch is hiding. Yeah, if the task is trivial and you need to make, say, a simple analytical report based on research, this is more than enough. For tasks where the path to getting there doesn't matter much, it's a great working tool. But the moment the task gets complex, the way it's implemented matters enormously. Obviously, I'm mostly talking about development. And AI has a tendency to not always make the best or optimal decisions. Often it tries to cut corners, do it as fast as possible, slap on some crutches. So constant supervision here is just necessary. However, if there are clear decision-making principles, especially when it comes to the technical part, you can achieve a significant level of autonomy with good quality work. To simplify, you need to give the agent the directive that it should make decisions on technical questions on its own and follow a certain set of rules. Ideally, these rules are fixed in a skill or at least in the instructions. The best option is making global architectural decisions and principles before development even starts, fixing them in documentation, and mandatory use of them in every session. A simple directive will also work, like a prompt to make decisions guided by sound architecture with no compromises, by best practices that you have to research beforehand.

<written by a human being>

What's the point of these development cycles in the first place? The task is pretty straightforward - automate the codebase production process. Automate means that human operator involvement is either not required at all, or at least minimized to the furthest extent possible. When you start writing code with AI agents, you quickly realize it's not as simple as advertised. First of all, any coding agent asks for permission at every little step. Which is fine - it's done for security reasons. Then you switch to unrestricted mode or expand your library of allowed commands - and now your presence is partially no longer required. But then the real fun begins - at every point where there's a logical fork and a decision needs to be made about which direction to go, the agent reasonably delegates that call to the operator. And this is where a dichotomy starts that I don't yet know how to resolve in favor of full autonomy. Some of these decisions are architectural and technical, and they can (and in most cases should) genuinely be handed off to the AI. Especially if you're not deep into the technical details - top-tier AI models definitely know better how to handle those kinds of problems. But when it comes to product decisions - where the criteria are the business landscape and requirements (external context), plus taste, experience, and personal preferences - that's where I don't know how to rely on AI yet. That's exactly why I don't let it blindly take ownership of product questions in autonomous mode. The technical side, meanwhile, automates pretty cleanly: you need to bake into the instructions a rule that the agent should make this kind of decision on its own, based on sound architecture, clean code and data, without compromises and shortcuts. Ideally there's an architecture skill in place, preliminary research gets done on modern development standards, architecture patterns, and best practices, and all of this is handled by a specialized agent with a clean context.

<written by a human being>

Continuing my breakdown of why "newly invented" AI cycles are simply a return to the basics of classical development. And by the way, I'm not saying this with any negative connotation - quite the opposite. It's a good thing that more and more people are starting to dive deeper into the world of development, going back to the fundamentals, which will ultimately lead to more quality software that makes our lives better. I've already mentioned that the same effect /goal produces as continuous operation can be achieved with a well-crafted prompt, as long as it includes the same orchestration and result-validation instructions. But beyond that - /goal is essentially a reinvention of DoD, or Definition of Done, from software development and systems analysis, which is my bread and butter. Duh, you need a clear definition of the end result in order to actually reach it. Groundbreaking news! The key point here is specifically in the correct formulation of that final goal. Because the moment it becomes ambiguous and can be interpreted in more than one way, the probability of reaching the expected outcome drops significantly. The same holds true for /goal and, in general, whenever we hand a task to an agent - it's better to double-check your understanding of how you see the DoD. Where else does DoD matter? In task definition. I've said before that a good practice is using task management systems for AI agents exactly the same way we use them for people. Linear, Plane, GitHub Tasks - doesn't matter. What matters is having somewhere to lock in that DoD, status, and progress. And there it is, everything falling into place. Setting a goal is nothing more than proper task definition - which is a great tool for actually getting it done.

Migrating Knowledgebase With AI

AI loops are just reinventing the classic dev cycle

<written by a human being>

Lately in our AI bubble I keep running into a narrative about organizing so-called agentic loops - the idea being that AI drives a task to completion autonomously, without interruptions for the operator (meaning you) to make decisions. For this purpose, the /goal command is recommended, which exists in all the latest harnesses. Honestly, I've barely used this feature - I've jus tested it after the initial release. And in the end I never really understood the point of it in practice. The idea is that the agent has a final goal it will pursue continuously until it reaches it. But here's the thing - the exact same result is achieved through proper prompting. Meaning, if you: 1. Use unrestricted mode (dangerously skip permissions) 2. Give the agent clear instructions about decision-making rules 3. Provide the necessary access 4. Set the final goal in the prompt 5. Explicitly ask the agent not to stop until the goal is reached ...you get the exact same outcome - it will keep going until it hits the target. I can see how /goal might be useful for one-off tasks that don't repeat. Like the market analysis I ran this week. There you have clear, tangible deliverables you want to get - an analytical report in interactive HTML format covering specific aspects. But for building complex systems - where there are hundreds or thousands of tasks, iterations, features, and architectural decisions - you can't just set a goal and expect the agent to deliver what you had in mind. I'll break this down in more detail in the next posts.