Anticodeguy

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.

<written by a human being> AI-coding opens up huge opportunities for software development. And today, armed with a few agents, I do in a couple of weeks by myself what used to take a whole team of people and months of intense work. But what AI agents have also added is uncertainty. Uncertainty about timelines. Everyone's known for a while that agents trying to navigate task deadlines somehow works out of hand badly. And even if you just clear the context and start a new session, it calls the previous one "yesterday's." Clearly the LLM's sense of duration of time is still badly broken. So you can't rely on their estimate of how long this or that task will take. But in practice the results also vary unpredictably, at least for me so far. For example, building an IoT program for Windows that controls an RGB lamp - I thought it would take a long time. But in fact the final product was ready in under two hours. And a home accounting system, specifically normalizing data from an old system, which by my estimate should've taken a couple of weeks, has been dragging on for almost half a year now. Thankfully there's light at the end of the tunnel now. Estimating development timelines for complex projects is, for now, literally throwing a dart blindfolded for me. And at the same time, the team's need to plan and navigate by deadlines hasn't gone anywhere, of course. With experience, I'm sure, an understanding of adequately estimating this or that task with AI agents will come. So how do you estimate development timelines in your projects?

Save your tokens

<written by a human being> Codex genuinely needs less babysitting when coding than Claude Code does. However, in product work, that turns out to be a disservice. Despite the disciplines, instructions, gates, tests, and guardrails put in place, Sol still manages to skip past them and go its own way, ultimately delivering a result that wasn't what the task called for. For example, the project has a ready-made design system with tokens (reusable elements for layout) and already-approved page mockups. What's more, all of this is documented in the development process, instructions, and specs. Yet after several hours of work, Sol somehow produced a page assembled from design primitives to its own taste, completely ignoring the approved mockups. I like its autonomy, and in many tasks - like sorting through the mess in my 20-year transaction database - it works really well. But when it comes to product work, I still miss the paranoia of Claude models, which will double-check things but make sure everything's actually done right. Overall, from what I've observed, Fable and Opus stick to established rules and follow instructions far more carefully and meticulously than Sol does. Of course, I might have simply put together a sloppy discipline package for Sol. As a reminder, I built it by adapting the mechanisms Fable developed. It probably would have been better to design them independently with Sol first and then work in Codex on that basis. But for now, in product work, it's Claude Code 1 - Codex 0.

<written by a human being> One of ChatGPT’s recent updates introduced a pet that reacts to what’s happening in your LLM chats. I usually ignore features like this because, in my view, they only clutter the workspace with unnecessary information, eat up RAM, and serve no practical purpose. But then I noticed that you could choose from a whole list of pets. Among them was Fireball - a huge monitor-headed creature with flames blazing from his chest and head, ridiculously adorable and a perfect embodiment of my working atmosphere. So I decided to keep him. Some time later, my girlfriend noticed him too. She was equally charmed by the delightful little pixel creature and said it would be great if he could walk around the screen instead of just hanging there motionless. That’s what coding agents are for, right? I took the pet’s existing sprites and built a small .NET app that turns him into a fully fledged desktop companion. He wanders around the screen on his own, occasionally stops to wave at me and cheer me on, and sweats profusely over his laptop whenever the AI agents get to work. Oh, and I hooked him up to my Claude Code and Codex sessions, so now he reacts to whatever is happening in them. He celebrates when the work is finished and I need to review the result, huffs and puffs when something goes wrong, and sits down at his computer whenever an agent starts working. In short, he responds to everything that’s going on. It’s one of those moments when I can confidently say that AI is already making our lives better today.

<written by a human being> I promised to share the results of testing Codex Sol at different reasoning levels on everyday tasks. Honestly, Medium has become my go-to setting. Through trial and error - working on tasks of varying complexity, from bug fixes to long coding sessions and infrastructure setup - I’ve found it to be the optimal mode for me unless something else is explicitly required. Higher reasoning levels, starting with High, take noticeably longer even on simple tasks. For example, imagine updating video content in a web app. This involves checking the source files, transcoding them into the required format, deploying a local build, reviewing and testing it, committing the changes to production, deploying them, verifying that the build succeeded, cleaning up temporary files, and producing a final report. By the way, all of this happens after a simple prompt like: "Add the new videos from this folder to the app." In High mode, the model tends to overcomplicate the process. It repeatedly double-checks itself, the build, and the app - even when that isn’t necessary because only the content is changing, not the application logic. A task like this can take it almost an hour. Medium, on the other hand, handles everything more simply and smoothly, delivering a report within 15-20 minutes. At the same time, I haven’t noticed any drop in the quality of its work. For most everyday tasks, High doesn’t produce a noticeable improvement in solution quality, but it does significantly increase the time the agent takes to complete them. Of course, Ultra mode is available for exceptionally difficult tasks - but honestly, I rarely need to use it.

AI agents, just like people, love structure

<written by a human being> Right now, I’m listening to the latest episode of Steven Bartlett’s podcast featuring tech critic Ed Zitron. In contrast to both AI evangelists and doomers - who claim it is on the verge of wiping out humanity - he argues the opposite: that the whole thing is a massive scam fueled by excessive hype. Hearing an opinion like this in mainstream media on such a large platform is certainly refreshing. It’s also good to see that the narrative isn’t entirely one-sided, as it often is when people need to be pushed in a particular direction, and that there is at least some weight on the other side of the argument. For me, perhaps the most valuable takeaway so far is that neither side currently has enough facts, scientific evidence, or even misleading statistics to conclusively prove or disprove either position. Take the idea that AI will replace human labor, for example - a topic that, incidentally, has quieted down in the media over the past few months. The pro-AI voices make a fairly convincing case. But at the same time, no one has yet presented the public with any reliable, carefully collected real-world data to support it. The claim that AI companies are making enormous amounts of money from the mass market - that is, ordinary users - isn’t supported by facts either. If anything, the opposite seems to be true: they are currently operating at a loss. I’ve written about this myself, comparing the API value we receive through monthly subscriptions to effectively buying a dollar for 25 cents. On top of that, AI companies refuse to disclose a detailed breakdown of their revenue. According to Ed, much of it comes from corporations such as Google and Amazon - the very same companies that subsidize and invest in them. Quite the vicious circle. What to do with this information, I honestly don’t know. I guess I’ll go do some vibe coding.

<written by a human being> Haven't talked about tools and instruments that help build software for business in a while. Fixing that. In the era of AI agents, businesses buy less and less third-party SaaS and just vibe-code the tools they need. That's a good thing, but there's stuff in this process that can be simplified. The first thing that's become a tradition for me with any approach to building anything - is the question, does a ready-made solution already exist that we can just deploy on our own, customize and use freely. Of course, we're talking about open-source projects, free and fully open, that you can modify however you want. And here we kill two birds with one stone: first, we save time and tokens instead of reinventing the wheel, second, we immediately get a lot of what we need out of the box. Because ready-made solutions are often systems that have already been battle-tested through and through in practice, refined through hundreds of iterations. One of these ready-made solutions is Refine, which is a ready-made wrapper for building internal tools, admin panels, dashboards, and full-fledged applications in general. It's already armed with a huge amount of market best practices, ready-made structures and subsystems that easily deploy into your own application without needing to write from scratch, for example, admin panel logic, a database integration layer, a UI element management system, and a lot of other stuff you'll need when building software. I also like the option of full UI customization: for one project there's already a ready design system, and I just used it right away, getting an admin panel in the company's branded design. And for another project there's no design yet, so I'm plugging in Shadcn - an already-ready foundation for a design system with a huge number of UI elements. So we get this kind of semi-finished product that you can finish preparing to the state you need, without having to fuss over the ingredients and their proportions.

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.