Anticodeguy

LLM Updates Ruined My Disciplines <written by a human being> I ran thorough retros on two projects where I've recently been seeing brutal overengineering that wasn't there before. And, as it turns out, the culprits behind the overcomplication were the latest updates to both flagships - Claude and ChatGPT. Along with the fresh models, they got new system prompts and rules for working with agents, and those broke the logic of the disciplines I'd set up in the projects. For example, Astra's system prompt literally says: "Autonomy and persistence": "Do not settle for a partial or 'helpful enough' solution … to save time, effort or tokens". Which is exactly what I've been writing about these past few days: even if solving the task just needs a simple SQL query, the model is instructed to go full throttle, not sparing any tokens... And Anthropic, for their part, equipped their harness with new rules for working with worktrees, which comes down to moving the session log into it. And now, to resume, say, yesterday's session, it's not enough to just launch a terminal from the project's working folder - it won't be in the session list. First you have to remember where the worktree lives, cd into that folder, and only from there call resume. How any of this is supposed to help with using agents, I have no idea. But for now, in my projects where all of this was already accounted for by working procedures, it's all gone to hell. And now I need to rebuild my disciplines around the new instructions. Until the next update.

Claude Notifications

<written by a human being> One of the likely suspects behind the overengineering I'm seeing from different AI-agent models in my projects is my own discipline rules. One of the first rules I added to the instructions was that shortcuts and hacky, patched-together solutions should be avoided, and that every solution should be thorough and complete. The point of this rule was to prevent things like fabricating data just to pass tests - something I'd observed more than once in the early stages of the project. That is, an agent would write the code, write the tests, but then feed the system deliberately correct data during testing, guaranteeing the tests would pass. Obviously, that approach isn't of much use. The second example is shortcuts and band-aid fixes themselves. Whenever a bug was found, agents kept applying temporary patches - again, just to get tests passing quickly - without bothering to actually fix the root cause. I introduced this rule with the best of intentions, but it seems that, after some time, it starts pushing AI agents toward the opposite extreme - overcomplicating absolutely everything. Even in cases where a single command on the server would suffice, they start inventing an entire system to automate that process, complete with tests and all the other trappings of mature software development. To be fair, this only started quite recently, after the release of Fable 5.1 and Astra. Before that, the flagship models handled all these tasks more than successfully and were quite capable of judging whether a solution was proportionate to the task at hand. What changed, I don't know. I've tweaked the rules, but so far without success - the overengineering hasn't gone away. I'm still looking into it.

<written by a human being> The latest Fable also suffers from a tendency toward overengineering, just like Astra. The task seemed no harder than previous ones - set up the Stage environment where we'll test improvements before releasing to prod. To me that sounds like a routine technical task, one I don't really keep track of since the flagship models knock these out pretty easily. But a few sessions later, with that familiar suspicion that something was off, I asked why it was taking so long to get the stand up, when the prod one had been set up in literally one easy session and had been working fine ever since. It turned out Fable had launched into a flurry of activity automating the stand build process. It built a full-fledged replacement for the GitHub runner, which I actually wrote about not long ago, by the way. It also cooked up a system that automatically generates numbers for PR branches so no one gets confused about where which fix was deployed. A separate layer of extra checks, tests, and a whole bunch of other embellishments that clearly were never going to be used. It turned out the agent had designed the system assuming a human would be handling deployment, so it needed to be wrapped on every side with foolproof safeguards, automations, and helpers. What it somehow failed to account for is that the AI agent does all of this in a single pass with a couple of standard commands, and the application build itself happens on a box, just like, say, in production. Of course, once you confront the agents with these facts, everything suddenly becomes crystal clear to them, they dutifully admit the mistake, and then proceed with a much better understanding of the original task. But how do you get them to work the right way from the start, without sometimes burning days and millions of tokens on it...

<written by a human being> Seems like I overextended trust in Astra when it comes to autonomy on tasks. Still can't figure out where this drive to overcomplicate simple tasks comes from. For example, updating the database version. You'd think - update on test, check dependencies, run tests, do the update on prod. Astra decided to get creative with the task: build an automated system that searched for dependencies, detected errors during the switch, provided a rollback point in case of a failed update, and wrapped all this goodness in a generous layer of tests. When I came back to the session a couple hours later, suspecting something was off, and asked why all this had been built, and reminded it that the database already has automatic regular backups and could easily be rolled back if needed, the model, in its typically guilty manner, admitted the mistake. A few hours, hundreds of thousands of tokens, thousands of lines of unnecessary code that just went into the trash, and no result. The next session I was already combing through all the project's disciplines looking for what triggers this drive toward overcomplication and over-engineering, but honestly, I haven't pinpointed a clear culprit yet. Sure, I could have caused all this myself with my overly detailed instructions and constraints, which literally don't let the agent do straightforward actions and force it to pile up automation even where it's clearly excessive. But on other projects where I haven't built such strict disciplines, I notice the same thing. By the way, the latest Fable is guilty of this too. Maybe I'll tell you separately about its cases. And of course, once I find the answer and a solution, I'll share that too.

The Right Way Of Instructing AI-Agents

<written by a human being> Something strange is going on with ChatGPT's limits. As soon as I started using them at full throttle, I immediately noticed a significant jump in consumption - it now looks even worse than with Claude Code! First, I burned through my weekly limits in three days. Fine, I thought, that's probably because I started actively using Codex alongside Claude Code, handing more and more tasks over to the new Astra. I still had 3 weekly limit resets that ChatGPT generously provides. So for the first time I decided to use one, reset my weekly limits, and kept working. But by the end of the day I was surprised to find I'd already burned through more than half of the weekly limits that had only been reset that same day! What? And I hadn't launched any extra sessions or some kind of ultra modes - the same set of sessions in Medium mode that had been running for the previous 3.5 days. I'm baffled. But I have a strong feeling that limit consumption is a highly inconsistent thing that's deliberately adjusted depending on compute load. And today there was also news that OpenAI has paused sales of subscriptions to the higher-tier Pro Plan due to rising demand. That makes it a bit clearer. Demand for compute is growing like never before. Have you noticed an increase in token consumption, or is this just my own story?

Two Fronts One Back <written by a human being> My current project has an interesting architecture: one backend serves several fronts. And I'm not talking about the user and admin fronts, obviously, there's an admin panel too. But specifically there are several user-facing fronts, aimed at different target audiences. Overall nothing supernatural, but working with AI agents brings up some nuances. The thing is, functionality on the two user-facing storefronts overlaps, and of course I want to reuse the already-built blocks in both places. The advantages are obvious: when you improve some element or functional block, both storefronts get the update at once, none lagging behind. No need to duplicate code, track updates in every place, work on the same thing multiple times. I think that's clear enough. But for AI agents this is much harder to grasp. Because they're already constantly itching to construct a spaceship when you just want to swap some text, and with several fronts they zealously rush to rewrite from scratch the code of an element that's already working on another storefront. So I'm now building, as a separate layer in the project, a new set of rules and guardrails that will strictly enforce these constraints - don't build anything new that already exists as a frontend element or functional block. The first iteration was unsuccessful - I didn't track in detail the moment where things started to diverge. So I had to go back a couple of steps to do it right and clean this time. But lesson learned.

Something strange happened

Staging <written by a human being> Made another bow to classical development on my current project, which seems to have grown to the stage where I feel the need for a separate stand where the product gets checked before release to production. First, after another release I found a critical regression. Or in plain terms, what worked before the release now doesn't work. And despite hundreds of tests and my own checks, catching it on the dev environment didn't happen. Second, when several agents work in parallel, each one needs to spin up a test stand for its own branch to run tests and do final acceptance of the changes. Several instances of a Nest.js app running at the same time on one machine make themselves unpleasantly known through a performance drop, which is very noticeable in 2026. And yes, my machine isn't exactly cutting-edge anymore either. Third, I don't work 24/7 and I still sleep at night, and I shut the PC down (I ask the agents to do this once work is done). So in the morning, if something needs checking for readiness, the stands have to be spun up again (they don't survive system reboots). Which means burning tokens again in the same sessions. Seasoned developers are rolling their eyes right now, of course. Because how could I have managed all this time without a proper staging or pre-prod - a separate server where a copy of the production version of the app is deployed with the latest PR's changes merged in. Duh! And all of the above gets solved in one swoop - my machine isn't occupied by extra instances and containers with the app, with the right sizing the question of parallel running instances gets solved, and it works 24/7 if needed. Meaning in the morning I can just go to the link where the update is available and do the acceptance. By the way, that's also where a full-fledged autotest mechanism gets deployed, meant to catch regressions deterministically, not in a way where if an agent forgot to check, the screwup slips through. That's it, off to set up staging.

Astra Is My New Video Editor <written by a human being> After the fresh ChatGPT model Astra came out, as usual, I didn't pay much attention to it, just switched my dev sessions over to it and kept working like before. But then videos started popping up everywhere about how great Astra is for video editing, including programmatic editing via Remotion or Hyperframes. Given how fast Fable eats up tokens on tasks like this, I decided to try the more budget-friendly ChatGPT. And what can I say - Astra crushed it! I think the first video actually came out even better than the ones Fable used to make me. More dynamic, more interesting and fitting graphics. And the result speaks for itself - after literally zero months in views, yesterday's video pulled in the usual 1.2K in the first night. Limits-wise, sure, it's still rough. You can see how much even ChatGPT models burn through on tasks like this. Though everything's relative. And Astra felt like it ate up less of the weekly limits for video editing than Fable. Though the experiment wasn't clean, since I had a bunch of code tasks running in parallel at the same time. Reminder of my video editing stack: Eleven Labs for transcript prep, video-use for the initial cut, audio normalization and color grading, Hyperframes for motion-graphics, final edit, and now also sound effects generation! Astra, welcome to the team!

if you think that AI nowadays can make a video for you, you are wrong

How To Push Through Limits <written by a human being> How I broke my own record for the number of agents running simultaneously and burned through a week's worth of Claude Code limits in two days. On Saturday Anthropic generously reset the weekly limits, which for a nerd like me marks the start of intense work sessions. On top of that, a deadline is approaching by which I need to ship a release, and the number of open tasks is in the dozens. Well, great challenge! First thing, I asked Fable to scout and groom the backlog of tasks planned for the release and figure out which ones could be parallelized. Once I had that list, I started spinning up agents, one per task. At the peak I had 10-11 Claude Code sessions running + one Codex session. I was more sparing with Codex, since its weekly limits were already running low. Naturally, at that load I was burning through the full 5-hour limits. So over the course of one day I spent around 55% of the weekly limits, both overall and Fable's. Naturally, it wasn't hard to burn through the remaining 45% on the second day, yesterday. And I can say it was pretty effective: dozens of tasks and PRs, 90% ready for release. But I basically had no weekend. Of course, at this development speed, there's a constant need to do product QA. From prompt to test stand everything runs autonomously, but shipping to production without manual review still isn't happening yet.

Gaming Is Bad For Vibe-Coding <written by a human being> Yesterday, like nothing was up, I loaded a dozen agents to write code and went off to play a game on Steam. Seemed like everything was going fine and, as usual, I'm keeping an eye on a couple of agents on the second monitor. And I noticed some discipline hooks starting to fail on timeout, meaning they weren't executing because of long waits for a response from the system. At first I didn't think much of it, but the errors kept repeating. And in absolutely every running session. Meanwhile the orchestration of the coding agents seemed to keep going - the head agents were obediently waiting for the executors to come back with their reports. I sent Codex to check what was going on and it turned out that a lot of system commands, not just hooks, were running with massive delay. Instead of a hundred milliseconds, the wait time was exceeding even tens of seconds - two orders of magnitude longer than it should be! Very weird... I went and checked all the sessions and it turns out they were all stuck in place - the child agents' time counters were past hours, and several tens of thousands of tokens had been spent, meaning no useful work had been done this whole time. Turned out that the EasyAntiCheat system, which is exactly what it sounds like it's for, hangs its checks on literally all (!) system events, shamelessly eating up PC resources and even blocking the normal operation of AI harnesses! To say I was pissed off is saying nothing. And this hadn't happened before - the behavior clearly came with the latest updates. Has anyone else run into this?

Responsibility To Create <written by a human being> I've been thinking about how AI, in a funny way, pushes us to actually create and be creative. Because before it showed up there was a really convenient set of excuses that let you justify laziness and the lack of any action toward building something, toward actually bringing to life the things you'd wanted to do for a long time. But after work you're all tired, no strength, no energy. Or you're missing this or that knowledge. Or making your dream real required expensive programmers and a pile of investment. Now for real, for a couple dozen bucks you buy an indulgence for all these sins, called a monthly Claude or ChatGPT subscription. Missing knowledge? Here it is, all of humanity's knowledge up to this moment, gathered in one chat. Can't code? These beasts write code faster and often better than the programmers you'd have hired for your project. No energy after work? Buddy, this thing genuinely works on its own, autonomously, if you set the task properly. And there's one more cherry on top - weekly limits. You already paid and there's no going back. If you don't burn through the tokens, they just burn away. Meaning your money's on the line - you literally need to create something if you don't want to waste it for nothing. Personally for me that's a great driving motivation, not exactly forcing me to constantly build something, but at least constantly reminding me that there are still free tokens lying around that could be poured into that system I've been procrastinating on for ages. And sometimes they reset the limits mid-week too...

Handoff prompt

<written by a human being> The strange thing about AI coding. It supposedly speeds us up massively and now one person does the work of 3-5 people at once. But on the other hand there's this feeling of slowdown in terms of productivity. Though maybe it's just a feeling. And maybe it's only relative. But either way, you compare yourself to the speed the world's moving at and it feels like you're not moving fast enough. Or does it just feel that way? To not go too deep into philosophy, back to the applied coding tasks. Objectively I understand that in a month with AI, alone, I built what a full IT team of 5-8 people would've done in about half a year. But at certain moments, like right now, between releases, it feels like everything's moving insanely slow. And the main thing is - I can't do anything to influence it. Development of the system is split into two parallel tracks - two different functional trees, so parallelism exists at the macro level. Then within each track tasks are, of course, prioritized, and critical ones for current business tasks get closed first. And finally, the work gets handed to the flagship model in orchestration mode, meaning it launches several agents at once. Parallelism at the micro level is covered. But that's it. How do you speed up development further from here? Tasks that can be parallelized get run in parallel. What other optimization methods can be applied? Or is this the current ceiling and the speed of work depends on the speed of code generation of the specific LLM model. Is that our current bottleneck? How do you optimize development?

<written by a human being> When developing with AI agents there's this overwhelming urge to do everything right, the way it's supposed to be done, without skipping a single step. Because now it's not hours of tedious grinding over project documentation, it's writing a prompt and checking the result a few minutes later (or hours, sure). But sometimes you want to simplify and speed things up, especially where following the strict protocol really isn't necessary. For example, when spinning up an internal admin panel for the team, I decided not to build a design system from scratch, but to take ready-made professional UI libraries instead. Obviously professionals who've been refining these ready-made packages for years, iteratively improving every element inside, thinking through the details, getting feedback from users, patching the holes - obviously they end up with a far more mature product than anything I'd try to build from scratch. That's exactly the kind of product I was counting on for the internal admin panel, and I took Refine as the framework and shadcn as the UI shell. Seemed to be going well - I accepted the admin prototype in the form of a plain wireframe mockup, and then there were a few sessions of backend prep and finally the frontend wiring. And what I saw was literally the same wireframe prototype, which for some reason Codex kept insisting, quite convincingly, was the final look built on the shadcn UI library. After reviewing the whole codebase with a fresh Fable, it turned out the agents had only taken ready-made primitives from shadcn - literally just the code for buttons and other visual blocks, not a full UI system. And one of the reasons for this "dumb" agent behavior was overly strict prohibitions in my disciplines, which literally forbade making design and layout decisions without my sign-off. So now I'm reworking the instructions and disciplines, and properly implementing the UI library, once again convincing myself that skipping proper design work always costs you more in the end.

Creating micro-learning format with AI be like...

<written by a human being> Continuing on the theme of planning and estimating development timelines, yesterday I heard this wish from the team for transparency - something everyone's clearly missing while agents write code in the background. Of course, here we go back to the roots of classic development - no need to reinvent the wheel. In product management there's a long-established tool called a Roadmap, which is at once a planning tool, a control tool, and a discipline tool. A Roadmap lets you sketch out milestones at a high level on the calendar timeline, giving the team a sense of orientation - when and what will be ready. With a team of people, this thing works well as a motivator. When you see a certain deadline, it gets etched into the back of your mind, and you'll do all your work with the lingering thought that you need to get everything done by the set date. Of course I'm talking about responsible people, not hopeless slackers who couldn't care less about your deadlines. But here's the catch: with AI agents, that kind of "motivation" doesn't work. And they're not slackers - quite the opposite, actually - but they're terrible at estimating time. And it basically doesn't matter whether you kick off the agent a month before the deadline or an hour before - it'll work at the same speed and intensity either way. So trying to influence an AI agent's output with a deadline is a doomed idea from the start. And yeah, I tried it. Figured out real fast it's useless. What's left is a combination of meatbags + digital, where the human keeps track of the deadline and tries to plan the agents' work by anticipating their execution speed. That's the best I've got for you right now.