Anticodeguy

What AI does really well and fast - data processing

<written by a human being> Over the course of my career I've spent quite a lot of time on development teams, and I understand well how responsibility gets distributed among people and how to structure that process so development runs continuously. With AI agents now in the picture, that process has stopped being so obvious. Within a single session, an AI switches roles several times over. Once the backend and API are ready, that same agent immediately moves on to the frontend, handles debugging and testing, and when it's done, it deploys the feature itself and writes the release notes. Having several developers on a team work in parallel obviously speeds up the process of producing lines of code. But now, spinning up a second "developer" just means opening a second terminal tab and pointing an agent at another task. Literally a couple of clicks. Adding new people, on the other hand, comes with a huge amount of preparatory work - figuring out mechanisms for sharing context, access rights, secrets, and other things, which only adds vulnerabilities to the infrastructure. Of course, I understand - and I've written about this myself - that a single operator's cognitive capacity for running AI agents is limited, and personally I can't handle more than 4-5 sessions at once. So for real scaling when developing complex products, distributing tasks is still necessary. But it seems to me that it should look different than it did in pre-AI-era product teams. So far, the split I find most compelling is a product-based one, where one person is responsible for developing a single product across its entire vertical. Infrastructure, by the way, stands apart - that's something a dedicated specialist really can handle independently and cleanly. But how to divide a product between several people armed with AI agents, I still haven't figured out. And whether that's even necessary at all.

<written by a human being> For a few weeks now I've been running Codex back to back with Claude Code for my day-to-day tasks. And I have to say, I'm more than happy with the results. I now delegate part of the tasks to Codex, which just methodically does everything. Had to tighten up the discipline in my projects to actually use Codex properly. Agent instructions get read equally well by both harnesses, sure, but everything else needs customization: hooks, guards, skills, and so on. For now the tasks have split up like this. Codex - Infrastructure tasks - Discipline tasks and cleaning things up - Code tasks on already-built product solutions - Bugfixes Claude Code - Product work - Design and other tasks that require "creativity" - Orchestrating complex tasks - Brainstorms and building new concepts This way I've managed to significantly offload Claude Code, and now two subscriptions are more than enough for all my tasks to keep working nonstop, without sitting around waiting for limits to reset. Codex, by the way, doesn't restrict usage by intraday windows at all - you can burn through the weekly limits in a single session if you want. Doing that, though, is a lot harder than with Claude.

I can't believe what just happened...

<written by a human being> The experiment using the Hermes harness for team-based work as a corporate AI agent failed. Or at least it doesn't live up to the hopes placed on it. It all started, or rather ended, when Anthropic banned using accounts with regular subscriptions for stuff like this. The only option left is the API. But the API costs a horse's worth of money and doesn't justify the expense in any way compared to personal subscription use. And without that, the whole point got lost. Because the team tasks assigned to the general agent were mostly creative. Like helping write a social media post or brainstorming a product decision, which Claude models are especially good at. GLM models handle these kinds of tasks pretty mediocrely, even though a lot of people try to compare them and put them in the same league as even Fable. In practice, not even close. However, for a lot of routine tasks, GLM, which lets you use your subscriptions for such harnesses, works well. Like helping keep tasks up to date in the task manager, daily pinging colleagues, or periodically sending cat pics for morale. Probably need to put in more effort to set up skills, enrich memory, and other tricks, but for now it feels like the juice isn't worth the squeeze. What's your experience with Hermes, OpenClaw, and other harnesses? Or have they already run their course?

<written by a human being> Continuing yesterday's post about the full development cycle. If you missed the earlier points, look there. 7. I'll still break out the development of a disciplinary system as its own separate point, since it precedes any product work. Because if you put it off, the very first lines of code will go off-canon, and afterward you'll either have to untangle the mess trying to restore documentation and retrofit it to the functional map, or just redo it properly according to the rules. 8. Next comes finalizing the stack and architecture, and drafting the first batch of system documentation, which at this stage should ideally include the first ADRs. 9. Now that the architecture is settled, you can spin up the infrastructure. Here it's worth taking care of dev and testing environments right away, so you're not pushing unverified releases straight to production. 10. Next is deploying the stack and laying the foundation for further product development. Here we set up the authentication layer, prep the applications, and install all the libraries and dependencies needed for the work. All of this, of course, in line with the ADRs prepared earlier. 11. And then, with the foundation in place, you can move on to the product development cycle: Task → Requirements & documentation → Prototyping & design → Development → Testing & refinement → Handover/acceptance → Release. If point 7 was done well, there should be minimal issues at every stage. If problems do show up anyway, run a retro after each session and keep refining the discipline until you get the result you want.

<written by a human being> So, I've got a full development cycle for complex information systems using AI agents taking shape. Let me put it all together into one picture. 1. Gathering initial requirements, which underlies any development and is meant to answer the question of why we're even here building something. AI can help here with wording and structure. 2. The standard discovery process of collecting all possible information, except now it's mostly done by AI agents. 3. Interviewing stakeholders, aimed at gathering detailed system requirements, filling gaps in knowledge and context, and nailing down acceptance criteria. AI can quite conveniently support this process, modeling the object structure, functional map, and even a prototype of the future system on the fly, while structuring the requirements at the same time. 4. Next comes prototyping, building the CJM, and cyclically repeating the previous stage until all blind spots are covered and contradictions resolved. As usual, AI helps systematize all of this and build the actual prototype. 5. The finished and agreed-upon prototype, functional requirements, acceptance criteria, CJM, and all the other artifacts created in the previous stages get consolidated together and turned into requirements for the design, tech stack, infrastructure, and architecture of the future system. 6. In parallel with the design, which of course AI can handle these days too, you can kick off architecture design, stack selection, and disciplinary requirements for running the project. At this stage it's important to set all of this in stone as a system of instructions, conventions, rules, skills, guards, hooks, linters, and all the other mechanisms that keep the eager AI agents on a leash. So, this is already getting pretty hefty, and I know nobody reads my posts as it is because of the length, so I'll stop here and continue tomorrow.

I spent a whole week being dumb and launching the review agent manually!

<written by a human being> After gathering requirements for a system, your hands start itching to build. And these days it's so easy to just dump the whole mess into a pot with AI agents: let them cook it. As always, a caveat: this works up to a certain threshold of complexity. If we're talking a static site or a simple system with a couple of basic functions - that'll be enough. But for more complex systems you'll end up with a mess that's harder to untangle later than to just build from scratch, but this time with a clear structure. And this is exactly the step you shouldn't skip - designing the structure. But you can genuinely simplify it by delegating the cognitive work to AI, leaving the meatbags to just approve the external structure - the user journey and a rough app structure in the form of a mockup. Again, an AI agent can flesh out the simplest HTML skeleton, easy for a stakeholder to read, easy to understand and easy to digest, right there during a dialogue with you, where you fill in the requirements. When you visually read through such a prototype, logical inconsistencies, gaps, and unnecessary connections immediately jump out. I asked mine to add a Customer Journey Map to the mockup, one that lights up interactively as you move through the "pages" of the prototype. This way every step and every page element gets meaning and leads the user toward the end goal. And if it doesn't lead there - we cut the element or change the structure on the fly. So we're one step closer to getting a quality dev result instead of AI slop.

<written by a human being> AI agents today let you run stakeholder interviews - collecting business requirements and clarifying process details - in a way that's way more fun and interesting than it was in the pre-AI era. Back then you first had to gather a ton of information to show up to the interview as prepared as possible. Then ask as many questions as you could based on that information. After the interview, dive back into the pile of materials, entities, functions, piece together the overall picture from it, and inevitably find a bunch of gaps, which of course lead to yet another follow-up interview. And this cycle repeats several times, until all the necessary knowledge has been dug out of the process owners' brains. But now, all the heavy lifting of processing large volumes of data, finding connections between them, and pulling all that stuff into a single structure can (and should) be handed off to AI agents. What's more, they can do it on the fly, while you're talking to the stakeholder. Here's how I set up the process. Beforehand, I gave the agent the task of gathering all available materials on the system being built, along with the inputs used as the basis for the refinements. Then it created a canvas with a wireframe prototype, where details would get thrown in and the structure would take shape with each iteration of new input. And finally, prepare a series of questions covering all the branch points and knowledge gaps missing for the full picture. Then during the Zoom call with the stakeholder, I ask them the questions the agent feeds me one at a time in chat, and after getting an answer, I send it back to the agent. As soon as it gets the answer, it immediately updates our prototype, adding a new structural unit, a new requirement, a constraint, and so on. So right before our eyes, the prototype starts taking the shape of the future system. Meanwhile we're just talking to each other like in a regular interview.

How to make Zoom stream to YouTube

<written by a human being> Before developing an information system comes the process of designing it. And before the design itself comes discovery. This is the process of surfacing business requirements, forming acceptance criteria, constraints, and goals for building the system. In classic development this is done by business analysts (and/or system analysts, depending on whether the company has them). The process looks like this. Analysts gather all the available information from accessible sources, classify it, and put together a draft list of product requirements, which is usually riddled with huge context gaps - the collected materials are clearly not enough. To fill these gaps, analysts conduct interviews with the stakeholders of the processes that are planned to be automated in the system being designed. By this stage they already have a list of questions whose answers are supposed to close the blind spots identified at the previous stage. In the end, all this information - including interview results, process observations, and other techniques (savvy analysts have plenty in their arsenal) - is consolidated into final requirements, which, once agreed upon, become the basis for designing the system. If the business's materials are stored online and directly accessible, it's very convenient to unleash a horde of AI agents on them to extract requirements and gather context. It's automated with literally one prompt. But the interview stage is much more interesting, and tomorrow I'll tell you how I solved it with AI without taking away the human interaction.

Watch Your Wild Token Spendings <written by a human being> When you give Fable carte blanche to go wild on tokens, it can pretty easily go on a bender. Yesterday I had it implement a fairly heavy epic, as usual, in orchestration mode. Everything was going fine, but by the end of the session I saw that one of the subagents' context window had ballooned to over half a million tokens! Naturally I stepped in and told the insatiable agent to stop. Reminder: past a certain threshold (roughly 150-200K) the model's intelligence starts degrading, and every new iteration costs more, so there's not much point continuing in the same session. So today I'm adding a new directive to the discipline set: budgeting the context window of orchestrated subagents. Test thresholds are 150-200K tokens, after which two hooks fire (one at each boundary). The hooks brake the subagents with a command to bring the work to a logical stopping point and halt, returning a report on the plan (which is already baked into the relevant discipline). Might need to bump the thresholds up later, but let's see how it goes - I'm expecting a noticeable savings, especially during "blind" sessions when orchestration runs unsupervised. By the way, that unfortunate subagent session ended up costing $233 in equivalent Opus 5 API spend.

If you asked me for one simple recommendation for vibe-coding

<written by a human being> Codex is noticeably slower than Claude Code. When working on a complex set of tasks, I usually assign orchestration to Fable, and I've gotten used to its speed by now. But Fable's limits run out very fast, after which I switch to Sol for that kind of work. I'll say upfront that I don't yet have a great feel for Sol's different effort modes and don't always know when I should switch to a lower level for a specific task. Because effort, obviously, affects how fast the model works. And here's where the snag comes in: of course you always want the smartest model at the highest effort level working on the hard tasks. But Fable almost always sits at Medium or High, because going higher eats through the limits at an unacceptable rate. Codex Sol, though, really puts you in a dilemma: it burns through limits very economically, and even at high effort levels they last way longer than Fable's. But it also takes more time to get to a solution. Where the tradeoff lands here - I still haven't figured out, but on high settings Sol definitely takes way longer to finish tasks than Fable does in orchestration mode. I want to believe Sol is carefully and thoroughly checking every step, working carefully and competently. Honestly, I'm happy with its results and have no complaints about the quality of the work. This week I'll try playing around with the effort settings to finally find that balance between speed and quality.

Self-hosted CI Failed <written by a human being> A couple of days ago I wrote about my attempt to set up CI runners on my own server. It's a system for building apps before releasing them to production. And it all started off pretty energetically, but in the end I couldn't quickly stand up a decent alternative to GitHub Actions, even though technically and in theory it's definitely possible. The first difficulty is that the service has to serve more than one repo and build different kinds of apps. That means you need a queue system, and it has to be prioritized correctly. Next, the build itself needs a system for parallelizing and distributing CPU and memory capacity to speed up the build process. Otherwise what's the whole point, if instead of 10 minutes on GitHub Actions it takes several hours to build on your own server - which is exactly what happened with the first version of my runner. But every time I tried to run real builds, I kept running into new bugs, which spawned a whole pile of new tasks both on the CI-runner side and on the side of the apps themselves for optimizing the CI process. In the end, at this stage it's much faster and simpler to just switch the repo to public access, which removes the limits on GitHub Actions builds. And as the product develops you can go back to limited capacity or hook up compute services like Blacksmith. By the way, for a single app it's way easier to set up a system like this - for my home accounting it took 10 minutes on a home server and it worked fine on the first try.

How to unstuck your agents <written by a human being> Sooner or later, in every project where you work with AI agents, there comes a moment when progress stalls. Like, you coded something new this session, but in the end you just added 3 more tasks to the backlog. Feels like you're doing a lot of interesting and useful stuff, but real user-facing changes still aren't in prod. At moments like this it really helps to step back and (go smoke a cigarette) look at all this from the outside. Ask a senior model (better yet, two, from different vendors) to study the last N session logs and analyze what's holding back progress in the right direction. When there's no task to just keep going with, and instead a clean-context analysis of what's happening, the AI can notice things that you, as the operator, are missing. Especially when your eye's gone blurry from staring too long, these things get hard to spot, especially since the AI can be very convincing and swear on its source code that we're on the right track. For example, the context got clogged with false premises and smoothly steered the tasks into another direction, one that doesn't lead to the intended goal. Or an architectural decision made several sessions ago turned out to be wrong, and the agent can't back off from it without explicit authorization to break the agreements. That's also why, by the way, development in orchestration mode works better, since in that case there's a central management apparatus that helps hold the intended direction. Of course, only if that direction was right to begin with.

Complex Projects and AI Agents 1 on 1

Adapt your Claude development disciplines for Codex <written by a human being> I've already written a few times about the disciplinary development systems I use to organize work on complex codebases. I've also mentioned that I design them with Fable. And naturally, Fable sets up all the instructions, skills, hooks, and guards so they work with Claude Code. But when you switch to Codex in the same repo, it immediately becomes obvious that most of the established rules don't work. Though, for example, local product skills Codex actually picks up and detects pretty well. But the hooks don't work at all, simply because they're technically built differently than in Claude Code. So before blindly handing tasks off to Codex in these repos, you need to run 1-2 sessions adapting all the disciplines to this agent. It'll find everything it needs on its own and propose fixes, so there's no point going into detail here. But it's important to make sure the adaptation actually works as intended, so for the first sessions I recommend closely watching how the work is being done and running a retro against the established disciplines. The only thing I haven't ported over to Codex is syncing design mockups from Claude Design, for obvious reasons. That territory stays with Fable for now, no alternative.

How to CI when you hit your free GitHub limits <written by a human being> Sooner or later, as your app grows, if it's building on GitHub's free compute, you're gonna hit the limits. 2,000 build minutes a month is available for private repos. After that you've got a few options. 1. Make the repo public. Good option for a pet project when you've got nothing to hide - use the free builds all you want. 2. Wait for the limits to reset (once a month). 3. Switch to a paid tier. 4. Set up your own CI build on your own server. For work repos, which I prefer to keep private, I went with the fourth path. For that we're gonna need one Linux server and Codex Sol to set it up. First it's better to describe the current landscape of the dev environment, because the first version of my internal server infrastructure ended up tailored to a single project, while I might need to build several apps from different repos at the same time. Also, to link the GitHub repo with the server, you'll need to create and install a GitHub app, which will act as the connecting bridge on every codebase update. The process of switching to a new CI process isn't fast - I've been messing with it for two days now, but the result is worth it - no more headache and dev delays from external limits. Now it's all under control.