Anticodeguy

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.

Important observation when working on projects with AI

<written by a human being> Once the codebase of a web app is written, it needs to be built into the final working product and put online, opening it up to external users. This process is called compilation, same as when you build desktop software. For web apps the build runs on a remote server, and not the one where the final version lives, so you don't break it while it's being used. And breaking it is easy - one error in the code and the build falls over, the app doesn't compile and users can't work. That's why the app build happens independently from the live version, and during it all kinds of checks run to make sure everything works as expected, normally. This process is called CI, or Continuous Integration. Obviously, to run an app build you need a server where all this happens. And, of course, the code itself. We keep the codebase in a Git repo, which is usually wired up to the build servers. And for convenience this part gets automated: the moment you merge in fresh changes, the CI process kicks off automatically, which is the final confirmation that the app works with your changes. GitHub generously supplies its users with the capacity of such servers and lets you run builds without limits for public repositories. For private repos, however, there are limits, which, of course, you can raise for money.

<written by a human being> In the process of developing pretty much any system there are secrets. Not the kind you want to share with everyone around you. I'm talking about environment variables, API keys, SSH keys, access passwords and other values that, obviously, you don't want exposed anywhere. Usually these secrets are specific to a particular environment. For example, for the dev environment there's a test circuit and it has its own API layer. You can safely connect to it and test different scenarios with no chance of damaging data in the production environment. Obviously, production keys won't work for the test environment and vice versa. But how do you safely hand them over to fellow developers who work with the same test environment? Sure, you can keep it simple and just drop them into the corporate chat. But passing production keys through chat is unsafe, same as passing keys in plain unencrypted form in general. That's what special services were created for - they take on all the hassle of keeping track of keys, encrypting them, safely passing them to each other. And everything is stored centrally in one place, which gives you convenient methods for managing keys. For now I've settled on Infisical, which has both a cloud and a self-hosted version, if you want to keep everything under control. There's also 1Password and Bitwarden, for example - here you have to pick based on each specific case, but the point is that these are ready-made reliable storages for project keys and secrets. Infisical, by the way, natively supports working with AI agents, which is very relevant right now, obviously.

Simple but extremely important task for you and the agent

AI Coding is an addiction <written by a human being> You get seriously hooked on AI coding. Once you see the first results of working together with agents, getting off that dopamine needle turns out to be pretty hard. That's because we've basically invented the perfect drug. It doesn't require any serious prep and it's extremely accessible - interacting with AI happens through natural language, which we've had since childhood. And it doesn't matter which language - AI understands all of them. It constantly gives you a sense of reward - every session generates some kind of result one way or another, which creates that exact positive feedback loop you want to feel again and again. That feeling of completion triggers a dopamine spike and the urge to repeat. And if the session didn't go well, you feel frustration and the urge to try again, but differently this time, to come out on top. The perfect emotional rollercoaster! And finally, if you apply it to something creative, you see the result of your work in the real world. A new tool that helps you and someone else in life, solves a specific problem. Which only reinforces the feeling that you're doing something good and useful. All of this together creates a genuinely brutal combination. I think support groups for anonymous AI coders are coming soon.

Human-Made Creativity Is Safe from AI <written by a human being> Back in the Midjourney boom era, I wrote a post claiming that human creativity would be valued even more than before, in this age of AI "creativity." And today that thought is increasingly becoming reality and taking on visible shape. Lately I've noticed that, for example, on YouTube there's basically no advertising left that was made by a human from start to finish. Sure, this might just be my feed, but every day I see videos where 90% is fully AI-generated, 8% are abstract presentations with logos where it's hard to even tell how they were made because there's no creativity in them at all, and the remaining 2%, where a real human suddenly appears, it immediately becomes obvious the script was written by AI and the guys didn't even bother removing the obvious clichés. I'm not going to try to evaluate this state of the market, just stating the plain facts for now. But what seems obvious to me is that in this endless stream of AI generations, handmade works will stand out sharply and grab attention like never before. First, once the mass consumer gets used to this landscape and it becomes the norm (it seems it already has), human creativity will stand out noticeably within this now literally homogeneous mass of generative content. Second, in order to stand out, a person will one way or another have to invent new genres, look for unusual approaches, come up with original ideas, since everything else will immediately get copied and mass-reproduced. As a result, creativity will reach a new level never seen before, and I'm convinced we're in for a lot of cultural discoveries precisely because of this competition with AI.

<written by a human being> With the growing number of projects I'm working on with AI, I've noticed the following. For complex projects I add a disciplinary layer that keeps agents on a leash and following established canons, rules, patterns, templates and systems, which is of course very convenient. But for every project these canons will be different, because the context is very different and the specifics vary, especially if you dig deep. This means that even a supposedly standard task triage procedure will differ from project to project. If only because of a different set of statuses or different project management systems and their capabilities. Overall this isn't a problem if there are 2-3 projects, these particularities are easy to keep in memory. But I don't rely on my memory and prefer reliable digital systems that don't let me down. But literally this week I started noticing that when switching between projects, I need to recall not just the work context but also the mechanics of the disciplinary layer, which only increases cognitive load and the chance of error. And here I am sitting and thinking that it wouldn't be bad to have such a meta-system that would play an aligning role for any project whatsoever. A system that would remain constant, while the variables would live at the level of the projects themselves. A system that would let you understand, at any moment, the state of a project in the coordinates of the local disciplinary system. Or maybe such a thing isn't needed and I'm just dreaming up another layer of overengineering...