Anticodeguy
الذهاب إلى القناة على Telegram
Technomad & systems thinker exploring paths to freedom and prosperity https://stan.store/anticodeguy
إظهار المزيد645
المشتركون
لا توجد بيانات24 ساعات
لا توجد بيانات7 أيام
-230 أيام
أرشيف المشاركات
645
Overengineering is a huge problem when working with AI
<written by a human being>
And it eats up tokens, time, money, and mental peace. It's like AI's already reached the level where it's capable of making critical judgments about its own work. But for some reason it still struggles with running a basic sanity check and checking whether its own actions, and whether the plan is proportional to the task at hand.
In a new repo for a system I'm building, I decided to set the foundations of discipline right away, so I asked the agent to do a review and copy over everything that would be useful for the new project.
And it started off fine: it put together a detailed plan of what to bring over, we agreed on a few nuances, and I sent the agent off to orchestrate the plan we'd agreed on.
A few minutes later I saw about 7 agents at work, who, on the orders of the main one, were writing plans and specs for how they were going to do their job of copying files!
Let me be clear again - the task was dumb file copying: skills, instructions, and other stuff from one project to another, with minor adjustments for the current project after. And the adjustments were minimal: repo name, file structure and project context, nothing crazy.
But the wise AI, for some reason, apparently after reading instructions in the other project that product features need to be documented, decided to send its helpers off to write documentation on the documentation!
Naturally I stopped this heresy, after which I still had to burn a few hundred thousand more tokens cleaning the malicious context out of memory and making it understand that you don't need a chainsaw to cut an apple. By the way, the model in use was Fable, so no, this is unforgivable.645
Claude Code systems don't work for Codex
<written by a human being>
I've already written more than once about how I build development systems in my projects. And they give very good results. But I hadn't focused on the fact that I build these systems with Fable, while development itself runs mostly on Claude models.
But since I switched to the $200 ChatGPT subscription a couple weeks ago, I'm giving more and more dev tasks to Codex, which works completely differently.
Yeah, it easily finds instructions and skills, even hooks fire correctly. But how Codex interprets and applies all of it differs from Claude Code. And this thin edge of difference I haven't quite pinned down explicitly yet, but there's definitely something there.
One thing I know for sure - memory. Of course Claude Code and Codex have it structured differently, but it'd be great to somehow share it between models. You could, sure, just copy Claude Code's memory files and feed them to Codex, but memory is a dynamic thing and changes from session to session.
This is a task that's currently running in the background for me, while I compare the results of different vendors' models.
But Codex is currently winning at backlog-clearing tasks, for example. It just goes and methodically closes tasks one by one on its own, working non-stop for several hours straight. And it only stops when it runs out of unblocked tasks of that class. And yeah, all of this with a simple prompt like "let's clear the tech debt." Claude Code can't do that.645
<written by a human being>
Yesterday I ran a crash course for my colleagues who are just starting their journey in AI programming, on the basics of working with Git repositories. And I thought about how wonderful it is that we're returning to the fundamental basics of software development!
Because this isn't the same thing as vibe-coding, which in my understanding is sending a prompt into a wrapper (I'm not afraid of that term) like Replit or Lovable and sitting around waiting for it to give birth to the app you wanted.
No, I'm talking about full-fledged programming, where everything starts with designing the architecture, data schema, processes and documentation before writing the very first line of executable code. Except now the applied tasks are done by one of the AI models, not you yourself or your colleagues.
But conducting this whole process, controlling execution, making product decisions, brainstorming and steering out of difficult situations and deviations that will inevitably arise - that's your real job.
And, of course, to confidently navigate this boundless ocean of software engineering, you need to understand its fundamentals. And the nice part is that the AI itself can teach you along the way. The main thing here is not to be lazy and to ask questions - why was this decision made, is it really optimal, how is this usually done in best practices, and other questions like that.
Every day I learn something new from adjacent fields, like system administration and DevOps engineering, which I've always found interesting but never had the hands to really dive into.
Enjoy the moment and get to know the insanely interesting world of software development.645
AntiSwitcher Build In Public Report
<written by a human being>
I'm pretty much done working on the automatic keyboard layout switcher utility, so writing a quick report as promised.
Reminder - I work on this project on weekends, great time for token-maxing before the limits reset on Monday. I handed the work on Antiswitcher exclusively to Codex as an experiment, since I still have some bias against Claude and one of my tasks is to build a counter-balance with other models.
But that's not the point - the point is that Sol, I think, handled the job beautifully. Latest thing - we migrated to the fresh .NET 10 version and built a new interface. Okay, Claude Fable stepped in here, but strictly as a designer!
Sol designed the initial prototype mockups of the interface well, but with Fable we worked on the details and applied the signature Anticodeguy style.
And the implementation itself was fully on Sol. There'll be a few more iterations on the interface, but overall I'm more than satisfied. The program runs solid, no crashes, does its job great. And now with a nice interface too.
And the main thing - zero dependency on subscriptions, licenses, or even the network at all. Fully autonomous, just how we like it.
Bottom line: Codex is great at C# and .NET - proven in practice.645
Messy project vs systematized one
<written by a human being>
Yesterday I finally got the home accounting system dev project in order, which, frankly, should've been done a long time ago. But since development was moving along pretty briskly, I didn't really see the need for it.
But now the difference between working in a project with a clear system that's consistently followed by AI agents in every session, versus just chaotic coding, is obvious to me. It's night and day.
What the dev system includes.
1. Of course, agent instructions, familiar to everyone
2. But they need to be kept on a diet, so a lint check on the volume of instruction files is mandatory, so they don't go over a certain threshold
3. Skills specific to the current project, which reflect the particulars of working with the chosen stack, infrastructure, task management system, established processes, and so on
4. Hooks and commands that trigger at certain stages of sessions, for example at the start or end, when you need to report on the work done
5. Guardrails and linters that just won't let through errors that can be strictly classified
6. A CI process that every development iteration has to pass
7. Principles and rules of work, like TDD and SDD, which if not described in detail, will often get ignored
8. Task classification, which lets you structure the flow of sessions differently for the corresponding types of work
9. The retrospective process itself, which lets you comb through everything described above and build it from scratch when it's not yet in the project
Of course, to build all this you need to dedicate a couple of sessions to it, which include recon, discovery, analysis of session logs, the codebase, best practices and recommendations from the AI developers themselves. And I'd recommend doing this only with flagship models.645
The difference between Claude Code and Codex. Yeah, again...
<written by a human being>
Yeah, I'm comparing the two mastodons of modern AI coding again. Mostly out of necessity, because of this week's Claude model outage, which forced me to switch to GPT-Sol.
I already mentioned before that Sol works independently and makes decisions on the fly, without waiting for mine. Fable is also quite independent in this regard, but it won't act without explicit permission and will try to align every fork in the road with you.
That kind of independence is prone to overengineering. In one of the tasks I literally had to stop Sol after seeing that for the simplest one-page MVP HTML form, whose data just needs to go to a corporate messenger via webhook, it started building a separate service for sending, setting up a chatbot, and nearly spinning up a database.
But in straightforward coding tasks where you just need it to work, this approach handles it beautifully. Sol just goes off for a long stretch and stops when the work's done - the perfect executor!
That said, I noticed that for the simplest tasks, like backlog triage, where you just need to sort through tasks and check status relevance, Sol takes way more time and tokens than, say, Opus.
So there's some level of complexity above which it's more efficient to use Sol, and for simpler tasks below that level - Opus. For more creative stuff requiring cognitive forks, Fable is still the flagship for now.645
<written by a human being>
Yesterday, for several hours in a row, Claude models weren't working properly. And in that moment I really appreciated having a backup option - a paid Codex subscription, which bailed me out, filling the downtime with its generous tokens.
In moments like these you realize how dependent we've become on the normal functioning of AI providers' data centers. And how vulnerable this ecosystem still is, since there aren't that many alternatives.
I'm sure that sooner or later the market will consolidate, a lot of new players will show up, and model development will hit a plateau, where new models stop being very distinguishable from previous versions.
By the way, this is already showing up. Over the last few months, aside from Fable, there haven't been any noticeable jumps in model quality. A lot of people are even writing that Opus 5 is worse and dumber than Opus 4.8.
By the way, when setting up working repos it's better to configure them neutrally, with instructions suited for any agents, rather than tailored to specific models. Claude, for example, will by default log project notes into a CLAUDE.MD file. So it's better to explicitly tell it that they should be stored in AGENTS.MD, so as not to confuse other models that will also be working with this repo.
And of course, you need to have fallback models on standby. In case the main one fails to work for whatever reason. And honestly, things get a lot simpler when you have a few options on hand and, for example, for coding, where all the requirements are already gathered, you use Codex, and for more creative tasks with product brainstorming, say, Claude models.645
How to make an AI agent work all night
<written by a human being>
Duration alone is a bad metric for a "successful" session. It's way more interesting to measure the final result and its deviation from expectations.
But some tasks genuinely take time, and that's clear upfront. In that case, drafting a plan of action beforehand works well. Do it before starting the work, and the agent can easily spot the places where important forks might come up, the ones where it'll need your call, and clarify them in advance.
Next, the actual goal of the task. That final result you're expecting to see. Ideally it's defined by a set of acceptance criteria (hello again, software engineering). With a set like that, the agent has a very easy time navigating the task's readiness stage, and it'll keep polishing it until it hits the stated criteria.
Next - the requirement of autonomy. If you don't spell this out clearly, the agent will stop at the very first fork and wait for your decision. Nothing is more frustrating than leaving an agent to work "overnight," coming in the next morning, and seeing it stopped 5 minutes after start waiting for your answer. By the way, I've noticed GPT models are more independent here and make their own decisions more often than Claude models do.
And last - the models themselves. Flagships handle orchestration a lot better, actual conducting of other agents, making intermediate decisions. So this kind of task I confidently hand off to, say, Fable, though I ask it to call worker sub-agents with Opus models, so they don't eat up all the limits in a single session.
This way, the head Fable session eats up around 200-250K tokens on fairly complex tasks, where it called up a dozen agents, worked for several hours, and actually drove the assigned task to a final result.645
<written by a human being>
If you're looking for an AI tool for team collaboration that has unified context, a set of skills, memory that ties different aspects of the business together - Hermes is your answer.
Hermes is a harness, a management system for AI agents, that automatically handles memory storage, skill setup, cache management and all the other stuff you'd either have to solve yourself or just settle for whatever the AI developers offer as their solution.
The problem with working with individual Claude or ChatGPT accounts is that each of them lives its own personal life. And you can only connect them through some shared network resources - Google Drive, repositories, and other tools like that.
But even then, the agent's skills and memory are stored locally on the user's computer. Hermes flips the approach - it lives on a remote server itself, and every user knocks on its door. And it's on that remote server where everything it needs for work is stored, and most importantly - that same unified context, accumulating over time.
The key thing here is building the right, convenient interface for all users to reach the Hermes agent through. Because everyone will have their own sessions, and group ones too. That's why integration with communication systems like modern messengers and corporate chats is built in.
For example, in our case I connected the Hermes agent to Mattermost (a Slack analog). And Mattermost is deployed on a separate corporate server that the Hermes agent also has access to.
Now we're feeding it all kinds of context, which will eventually teach the agent to understand any of us from half a word.645
<written by a human being>
My new personal record - stood up a static multi-page website in one day. With AI agents, of course.
I used to build sites like this on website builders, and it usually took several days. Because you need to gather the material and content, work out the page structure, think through the design and layout, set up all the technical part and infrastructure, prepare all the design assets, and only after that can you actually start building.
And the build itself is iterative - first a rough draft with content filled in, then cleaning up the design and layout, then polishing details and a few rounds of testing.
I'll note right away that yesterday's case involved an existing old site (built on a website builder, by the way) that needed to be rebuilt from scratch on our own infrastructure. So the content was already there. But obviously I wasn't going to assemble it by hand.
The process looked like this. I gave the task to the first agent with a description of the project and what needed to be done. It did the recon, gathered all the materials from the old site, including links to shared network folders where the videos and photo reports were uploaded. Created a new repo for the site, set up everything needed to start work in it, and gave me the initial prompt to kick off the project.
With that prompt I loaded a new agent into the already-created repo. And the second agent set up all the necessary scaffolding for the site (it's Astro SSG), studied all the content available and collected by the previous agent, put together the site structure, pulled the needed data from the brand book, and prepared a brief for Claude Design.
Then Claude Design built out the design system and the design of the site itself. And finally, the last agent took the finished design mockup and, in orchestration mode, built the site, set up the infrastructure on remote servers, put the media assets on S3 storage, deployed the site, and handed over a final report.
Honestly - there are a few things we still need to finish up today, but the sheer fact that this got done in a day genuinely impressed me.645
<written by a human being>
Right now I've got a handful of web and desktop apps of different classes and complexity behind me, and I can say with confidence that after a certain threshold, before you even start development, you simply have to build out a system of processes on top of which AI agents will do the actual work.
For simple apps, like a desk lamp controller or a static website, that's obviously overkill. But for full-scale complex applications - the ones with a bunch of modules, multi-layered architecture, various network interactions, and elaborate business logic - trying to just wing it from the start is doomed to fail.
My home accounting system is a clear example of that. I've been writing it for several months in a row now (though to be fair, I only work on it on weekends), and I still can't get it into a normal production state, and I'm still cleaning up data accumulated over almost two decades of financial record-keeping.
On the other hand, there's the online events management system, which is already in operation after a month and a half of development, the first of which was spent entirely on setting up the process system.
Processes for working with the repository, task management system, documentation, testing, infrastructure, dev and prod environments, handoff and acceptance, a whole network of instructions, rules, skills, tooling. All of it was meticulously prepared, checked, and audited several times over. Which ended up meaning that now, in a fresh session, it's enough to just write the task number and go get lunch, and come back to functionality ready for acceptance, fully compliant with all the established conventions.
I'm planning to build something similar for my home accounting too. We'll see if it's possible to turn the situation around, or whether it's actually cleaner to start from scratch.645
<written by a human being>
I've somehow never gotten around to fully using Ultracode mode in Claude Code, and honestly there wasn't much need. I'd heard it lets you run a bunch of agents and close out complex tasks faster. But I've been doing pretty well with my own orchestration skills and I'm more than happy with the results.
But yesterday, to burn through the tokens left before the end of the week faster (token maxing, yeah), I decided to crank Claude's coding volume knob all the way up and try out this much-hyped Ultracode. Spoiler - I'm going back to my own orchestration skills.
The goal was to knock out a tail of three small tasks in my home accounting system. In my usual Fable orchestration mode, it carefully studies the context, calls Opus agents to write the code, sends it for review once ready, waits for all child sessions to finish, merges all the branches and prepares me a report.
Ultracode arrogantly dispatched 5 agents at once for 3 tasks, 3 of which were for some reason on audit. A couple minutes in I noticed each agent had already burned through around 200K tokens. I figured that's just how it is in max-thinking-intensity mode and left it alone. But five minutes later I saw one of the subagents' token count had crossed a million! That's when I sounded the alarm.
Not only were three tiny tasks burning tokens I could've easily stretched across 5-7 similarly sized tasks, they were also getting dumber from context window overflow, which was bound to hurt the quality of the work. Turns out the subagents dispatched by the head agent were themselves running in Ultracode mode and could dispatch their own agents inside themselves, showing me only the combined token consumption.
Either way, this was a clear overkill for tasks like that on every metric. I ended up banning agent dispatching in Ultracode mode, only one level of nesting with precise and careful control. Basically went back to my regular orchestration mode.645
<written by a human being>
I spend a lot of attention on wrapping up a session. I watch for context window overflow, run a retro and type up a handoff so that in the next session I can pick up right where the current one left off.
But for a while now I've been pushing another challenge to the back burner - how to resume work across all the sessions, which, obviously, there can be quite a few of at the same time.
And it seems like the answer is right there in the previous paragraph about handoff - just copy it and start from where you stopped. But what if work across several sessions was interrupted for one reason or another? Say, weekends (yeah, that happens too) or a forced break that made you leave all those sessions hanging, unfinished.
And even if all of them were properly closed with a retro and a handoff - the ideal case - Friday evening, Monday morning you still need to remember which sessions were even open, in which projects and repos?
I don't trust my own memory, so I prefer to log everything. But in this case the AI agents already took care of us! They already log all the sessions locally.
So a really easy solution to this problem turned out to be a simple script that I can run at any moment in any terminal. The script goes through all the logs of past sessions across all projects, say, as of Friday evening, and gives me a short report showing which repos to fire up a terminal in and how many there even were.
Very simple and pretty effective.
We'll check it on Monday.645
<written by a human being>
A few weeks back a Chinese flagship model called GLM blew up, dubbed the Claude Code killer by every rule of clickbait social media dramaturgy.
I haven't tried coding with GLM yet, but it caught my attention after Anthropic banned using Claude monthly subscriptions for harness agents like OpenClaw and Hermes.
I tried running Hermes through the API for Claude Code and burned 50 bucks in a day and a half of pretty lazy agent work. Which, obviously, doesn't fit into any reasonable cost bracket. GLM officially supports using such harnesses with their coding subscriptions.
And their subscriptions, by all accounts, come out significantly bigger than Claude Code at a similar level of coding quality, while burning through limits much slower. Sounds pretty appealing for use with OpenClaw or Hermes, don't you think?
That's exactly what I'm testing right now - hooked up the mid-tier coding plan subscription for $64.8 and checking how far it lasts under heavy Hermes usage.
A couple of hiccups came up during setup.
1. No workarounds needed to cross Hermes with GLM models. There's no documentation specifically for Hermes on their site, but the instructions for OpenClaw are more than enough for your agent to figure out how to hook up the right API. On the first attempt my Claude Code tried to set up a shim and route requests through it, which the server just rejected. Connect directly, no workarounds.
2. Peak load doesn't affect the API liveness check. For some reason my Claude agent latched onto that phrase in the docs and blamed all its setup failures on it. But once the direct connection was established and everything worked, I had to forcibly strip those "peak hours" notes out of its context and memory.
Day two - flying great.
Used up 6% of the weekly quota.