Anticodeguy
Открыть в Telegram
Technomad & systems thinker exploring paths to freedom and prosperity https://stan.store/anticodeguy
Больше645
Подписчики
Нет данных24 часа
Нет данных7 дней
-230 день
Архив постов
645
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.645
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.645
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.645
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.645
<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.645
<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.645
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.645
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.645
<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...645
Update on my home accounting system
<written by a human being>
For the first time in a few months I'm seeing real progress in my accounting system, which I've already written about a bunch of times. Reminder - this is one of those "weekend" projects I burn through leftover tokens on.
Today I actually felt the real convenience of my interface: I send a photo of a purchase receipt to my Telegram bot, and it recognizes it and writes the transaction straight into the database with all the parameters I care about - exact time, counterparty, category, adds the items to the database, correctly figures out which account to charge.
Eventually, with enough accumulated data, I'll be able to, say, track real inflation through the price of specific goods, or measure currency purchasing power, or calculate how much I personally boosted 7-11's revenue this year.
With the system I'm still using during the transition to the new one, I have to get home, turn on the computer, open the program, find the right account, enter all the parameters by hand. Obviously I don't enter all of them, to save time - just the key ones, category and amount. So less data goes in, but it takes way more actions and way more time.
There's still a long road ahead of cleaning up data from almost two decades of tracking every single one of my financial transactions, and when I finish that, I'm gonna feel a disproportionate amount of satisfaction. By the way, thinking about putting my income and expense history online as an experiment.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.